All,
This is a friendly reminder.
CentOS 6.10 will EOL at the end of November 2020.
During the first week in December 2020, the 6.10 directory will move to vault.centos.org
Packages will still be available at:
http://vault.centos.org/centos/6.10/
However, once moved, there will be no more updates pushed to vault.centos.org. Therefore, security issues will no longer be fixed, etc.
You should take the rest of the month to either move to a newer versoin of CentOS Linux ... or to procure Extended el6 support from Red Hat (EUS RHEL 6).
Thanks, Johnny Hughes
On 09/11/2020 14:24, Johnny Hughes wrote:
All,
This is a friendly reminder.
CentOS 6.10 will EOL at the end of November 2020.
During the first week in December 2020, the 6.10 directory will move to vault.centos.org
Packages will still be available at:
http://vault.centos.org/centos/6.10/
However, once moved, there will be no more updates pushed to vault.centos.org. Therefore, security issues will no longer be fixed, etc.
You should take the rest of the month to either move to a newer versoin of CentOS Linux ... or to procure Extended el6 support from Red Hat (EUS RHEL 6).
Thanks, Johnny Hughes
As announced multiple times (on list[s], twitter, glog.centos.org and even https://c6eol.centos.org) , CentOs 6 is now EOL and so is being retired from mirror network. It's currently being moved to (capped and limited bandwidth) vault.centos.org and will be removed from mirror.centos.org (and so external mirrors in the next hours/days). mirrorlist.centos.org will also (like we do for all outdated/unmaintained and unsecured releases) start answering "invalid release"
Kind Regards,
On 11/30/20 10:25 AM, Fabian Arrotin wrote:
On 09/11/2020 14:24, Johnny Hughes wrote:
All,
This is a friendly reminder.
CentOS 6.10 will EOL at the end of November 2020.
During the first week in December 2020, the 6.10 directory will move to vault.centos.org
Packages will still be available at:
http://vault.centos.org/centos/6.10/
However, once moved, there will be no more updates pushed to vault.centos.org. Therefore, security issues will no longer be fixed, etc.
You should take the rest of the month to either move to a newer versoin of CentOS Linux ... or to procure Extended el6 support from Red Hat (EUS RHEL 6).
Thanks, Johnny Hughes
As announced multiple times (on list[s], twitter, glog.centos.org and even https://c6eol.centos.org) , CentOs 6 is now EOL and so is being retired from mirror network. It's currently being moved to (capped and limited bandwidth) vault.centos.org and will be removed from mirror.centos.org (and so external mirrors in the next hours/days). mirrorlist.centos.org will also (like we do for all outdated/unmaintained and unsecured releases) start answering "invalid release"
Kind Regards,
Hello
I guess you were one day too fast. RH released today an update for tbird so I guess today was the last day of support, not the first day after EOL.
manuel
On 30/11/2020 11:18, Manuel Wolfshant wrote:
On 11/30/20 10:25 AM, Fabian Arrotin wrote:
On 09/11/2020 14:24, Johnny Hughes wrote:
All,
This is a friendly reminder.
CentOS 6.10 will EOL at the end of November 2020.
During the first week in December 2020, the 6.10 directory will move to vault.centos.org
Packages will still be available at:
http://vault.centos.org/centos/6.10/
However, once moved, there will be no more updates pushed to vault.centos.org. Therefore, security issues will no longer be fixed, etc.
You should take the rest of the month to either move to a newer versoin of CentOS Linux ... or to procure Extended el6 support from Red Hat (EUS RHEL 6).
Thanks, Johnny Hughes
As announced multiple times (on list[s], twitter, glog.centos.org and even https://c6eol.centos.org) , CentOs 6 is now EOL and so is being retired from mirror network. It's currently being moved to (capped and limited bandwidth) vault.centos.org and will be removed from mirror.centos.org (and so external mirrors in the next hours/days). mirrorlist.centos.org will also (like we do for all outdated/unmaintained and unsecured releases) start answering "invalid release"
Kind Regards,
Hello
I guess you were one day too fast. RH released today an update for tbird so I guess today was the last day of support, not the first day after EOL.
manuel
Hi Manuel,
Yes , was astonished myself to see one last update landing today (thunderbird) but what we announced is still correct : after Johnny will have built and pushed out thunderbird, we'll remove content from mirror.centos.org "in the next days", while content was already pushed out to vault.centos.org :)
On 30/11/2020 13:39, Fabian Arrotin wrote:
On 30/11/2020 11:18, Manuel Wolfshant wrote:
On 11/30/20 10:25 AM, Fabian Arrotin wrote:
On 09/11/2020 14:24, Johnny Hughes wrote:
All,
This is a friendly reminder.
CentOS 6.10 will EOL at the end of November 2020.
During the first week in December 2020, the 6.10 directory will move to vault.centos.org
Packages will still be available at:
http://vault.centos.org/centos/6.10/
However, once moved, there will be no more updates pushed to vault.centos.org. Therefore, security issues will no longer be fixed, etc.
You should take the rest of the month to either move to a newer versoin of CentOS Linux ... or to procure Extended el6 support from Red Hat (EUS RHEL 6).
Thanks, Johnny Hughes
As announced multiple times (on list[s], twitter, glog.centos.org and even https://c6eol.centos.org) , CentOs 6 is now EOL and so is being retired from mirror network. It's currently being moved to (capped and limited bandwidth) vault.centos.org and will be removed from mirror.centos.org (and so external mirrors in the next hours/days). mirrorlist.centos.org will also (like we do for all outdated/unmaintained and unsecured releases) start answering "invalid release"
Kind Regards,
Just to let you all know that starting from today, mirrorlist.centos.org nodes answer "Invalid release/repo/arch combination" and also that content was removed from mirrors. Johnny pushed the last updates yesterday, that went out to external mirrors .
These mirrors will also delete all that content so if your *really* need to find such content, https://vault.centos.org is the only way to to go, but due to reduced bandwidth, capacity, we encourage you to use one of the external mirrors listed on vault.centos.org, with probably more resources/bandwidth that we currently have. Some of these mirrors also continue to offer rsync access.
Cheers, and time to have a drink and celebrate 10 years of CentOS 6 : you served us all well !
On 12/2/20 10:45 AM, Fabian Arrotin wrote:
Just to let you all know that starting from today, mirrorlist.centos.org nodes answer "Invalid release/repo/arch combination" and also that content was removed from mirrors. Johnny pushed the last updates yesterday, that went out to external mirrors .
Shouldn't we also delete centos/6 from Vagrant Cloud, and possibly official images hosted by e.g. Amazon Marketplace, Docker Registry, etc.?
On 02/12/2020 17:04, Laurențiu Păncescu wrote:
On 12/2/20 10:45 AM, Fabian Arrotin wrote:
Just to let you all know that starting from today, mirrorlist.centos.org nodes answer "Invalid release/repo/arch combination" and also that content was removed from mirrors. Johnny pushed the last updates yesterday, that went out to external mirrors .
Shouldn't we also delete centos/6 from Vagrant Cloud, and possibly official images hosted by e.g. Amazon Marketplace, Docker Registry, etc.?
I've removed the vagrant image, and sent a requst for the AMP listing to be removed.
Is this really a good idea to remove those things? EOL does not mean CentOS6 will disappear from various legacy setups, they may be kept running for a long time.
On Wed, Dec 2, 2020 at 6:43 PM Karanbir Singh kbsingh@centos.org wrote:
On 02/12/2020 17:04, Laurențiu Păncescu wrote:
On 12/2/20 10:45 AM, Fabian Arrotin wrote:
Just to let you all know that starting from today,
mirrorlist.centos.org
nodes answer "Invalid release/repo/arch combination" and also that content was removed from mirrors. Johnny pushed the last updates yesterday, that went out to external mirrors .
Shouldn't we also delete centos/6 from Vagrant Cloud, and possibly official images hosted by e.g. Amazon Marketplace, Docker Registry, etc.?
I've removed the vagrant image, and sent a requst for the AMP listing to be removed. _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Some folks may continue running EL6 based systems, but we need to make sure it is obvious that we're not providing any security updates. Moving the repos off the mirror network will provide a hint to folks doing a simple 'yum update' that something is not the way it once was.
Pat
On Wed, 2020-12-02 at 21:40 +0100, Marcin Dulak wrote:
Is this really a good idea to remove those things?EOL does not mean CentOS6 will disappear from various legacy setups, they may be kept running for a long time.
On Wed, Dec 2, 2020 at 6:43 PM Karanbir Singh kbsingh@centos.org wrote:
On 02/12/2020 17:04, Laurențiu Păncescu wrote:
On 12/2/20 10:45 AM, Fabian Arrotin wrote:
Just to let you all know that starting from today,
mirrorlist.centos.org
nodes answer "Invalid release/repo/arch combination" and also
that
content was removed from mirrors. Johnny pushed the last updates yesterday, that went out to
external
mirrors .
Shouldn't we also delete centos/6 from Vagrant Cloud, and
possibly
official images hosted by e.g. Amazon Marketplace, Docker
Registry, etc.?
I've removed the vagrant image, and sent a requst for the AMP listing to be removed. _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailma...
On Wed, Dec 2, 2020 at 3:43 PM Patrick Riehecky riehecky@fnal.gov wrote:
Some folks may continue running EL6 based systems, but we need to make sure it is obvious that we're not providing any security updates. Moving the repos off the mirror network will provide a hint to folks doing a simple 'yum update' that something is not the way it once was.
Pat
Whoa!
What will happen if I run a "yum update" on a CO6 machine? We have it run automatically at reboot and I need to know what will happen so I can see if the rest of the scripts we run at startup will be OK.
Yes we are updating them, but it's hard to do when you can't go onsite due to COVID.
On Wed, 2020-12-02 at 21:40 +0100, Marcin Dulak wrote:
Is this really a good idea to remove those things?EOL does not mean CentOS6 will disappear from various legacy setups, they may be kept running for a long time.
On Wed, Dec 2, 2020 at 6:43 PM Karanbir Singh kbsingh@centos.org wrote:
On 02/12/2020 17:04, Laurențiu Păncescu wrote:
On 12/2/20 10:45 AM, Fabian Arrotin wrote:
Just to let you all know that starting from today,
mirrorlist.centos.org
nodes answer "Invalid release/repo/arch combination" and also
that
content was removed from mirrors. Johnny pushed the last updates yesterday, that went out to
external
mirrors .
Shouldn't we also delete centos/6 from Vagrant Cloud, and
possibly
official images hosted by e.g. Amazon Marketplace, Docker
Registry, etc.?
I've removed the vagrant image, and sent a requst for the AMP listing to be removed. _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailma...
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Wed, 2 Dec 2020 at 16:09, Phelps, Matthew mphelps@cfa.harvard.edu wrote:
On Wed, Dec 2, 2020 at 3:43 PM Patrick Riehecky riehecky@fnal.gov wrote:
Some folks may continue running EL6 based systems, but we need to make sure it is obvious that we're not providing any security updates. Moving the repos off the mirror network will provide a hint to folks doing a simple 'yum update' that something is not the way it once was.
Pat
Whoa!
What will happen if I run a "yum update" on a CO6 machine? We have it run automatically at reboot and I need to know what will happen so I can see if the rest of the scripts we run at startup will be OK.
Yes we are updating them, but it's hard to do when you can't go onsite due to COVID.
You will get every system running through messages like this
[root@linode01 ~]# yum update Loaded plugins: etckeeper, fastestmirror Setting up Update Process Loading mirror speeds from cached hostfile epel/metalink | 2.5 kB 00:00 epel-testing/metalink | 2.6 kB 00:00 * base: mirror.dal10.us.leaseweb.net * epel: d2lzkl7pfhq30w.cloudfront.net * epel-testing: d2lzkl7pfhq30w.cloudfront.net * extras: mirror.netdepot.com * updates: mirrors.usinternet.com http://mirror.dal10.us.leaseweb.net/centos/6.10/os/i386/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" Trying other mirror. To address this issue please refer to the below wiki article
https://wiki.centos.org/yum-errors
If above article doesn't help to resolve this issue please use https://bugs.centos.org/. http://bay.uchicago.edu/centos/6.10/extras/i386/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" Trying other mirror.
until it finds some mirror which will work (that one mirror seems to be updating for everyone in the world so is very slow).
or it will do the following:
[root@linode01 ~]# yum clean all Loaded plugins: etckeeper, fastestmirror Cleaning repos: base cr epel epel-testing extras updates Cleaning up Everything Cleaning up list of fastest mirrors [root@linode01 ~]# yum update Loaded plugins: etckeeper, fastestmirror Setting up Update Process Determining fastest mirrors YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. Invalid release/repo/arch combination/ removing mirrorlist with no valid mirrors: /var/cache/yum/i386/6/base/mirrorlist.txt Error: Cannot find a valid baseurl for repo: base [root@linode01 ~]# echo $? 1 [root@linode01 ~]# yum list all Loaded plugins: etckeeper, fastestmirror Loading mirror speeds from cached hostfile YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. Invalid release/repo/arch combination/ removing mirrorlist with no valid mirrors: /var/cache/yum/i386/6/base/mirrorlist.txt Error: Cannot find a valid baseurl for repo: base
so basically the system can not find anything/do anything until a working mirror is there.
On Wed, 2020-12-02 at 21:40 +0100, Marcin Dulak wrote:
Is this really a good idea to remove those things?EOL does not mean CentOS6 will disappear from various legacy setups, they may be kept running for a long time.
On Wed, Dec 2, 2020 at 6:43 PM Karanbir Singh kbsingh@centos.org wrote:
On 02/12/2020 17:04, Laurențiu Păncescu wrote:
On 12/2/20 10:45 AM, Fabian Arrotin wrote:
Just to let you all know that starting from today,
mirrorlist.centos.org
nodes answer "Invalid release/repo/arch combination" and also
that
content was removed from mirrors. Johnny pushed the last updates yesterday, that went out to
external
mirrors .
Shouldn't we also delete centos/6 from Vagrant Cloud, and
possibly
official images hosted by e.g. Amazon Marketplace, Docker
Registry, etc.?
I've removed the vagrant image, and sent a requst for the AMP listing to be removed. _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailma...
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
--
*Matt Phelps*
*Information Technology Specialist, Systems Administrator*
(Computation Facility, Smithsonian Astrophysical Observatory)
Center for Astrophysics | Harvard & Smithsonian
60 Garden Street | MS 39 | Cambridge, MA 02138 email: mphelps@cfa.harvard.edu
cfa.harvard.edu | Facebook http://cfa.harvard.edu/facebook | Twitter http://cfa.harvard.edu/twitter | YouTube http://cfa.harvard.edu/youtube | Newsletter http://cfa.harvard.edu/newsletter
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Wed, Dec 2, 2020 at 4:17 PM Stephen John Smoogen smooge@gmail.com wrote:
On Wed, 2 Dec 2020 at 16:09, Phelps, Matthew mphelps@cfa.harvard.edu wrote:
On Wed, Dec 2, 2020 at 3:43 PM Patrick Riehecky riehecky@fnal.gov wrote:
Some folks may continue running EL6 based systems, but we need to make sure it is obvious that we're not providing any security updates. Moving the repos off the mirror network will provide a hint to folks doing a simple 'yum update' that something is not the way it once was.
Pat
Whoa!
What will happen if I run a "yum update" on a CO6 machine? We have it run automatically at reboot and I need to know what will happen so I can see if the rest of the scripts we run at startup will be OK.
Yes we are updating them, but it's hard to do when you can't go onsite due to COVID.
You will get every system running through messages like this
[root@linode01 ~]# yum update Loaded plugins: etckeeper, fastestmirror Setting up Update Process Loading mirror speeds from cached hostfile epel/metalink | 2.5 kB 00:00 epel-testing/metalink | 2.6 kB 00:00
- base: mirror.dal10.us.leaseweb.net
- epel: d2lzkl7pfhq30w.cloudfront.net
- epel-testing: d2lzkl7pfhq30w.cloudfront.net
- extras: mirror.netdepot.com
- updates: mirrors.usinternet.com
http://mirror.dal10.us.leaseweb.net/centos/6.10/os/i386/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" Trying other mirror. To address this issue please refer to the below wiki article
https://wiki.centos.org/yum-errors
If above article doesn't help to resolve this issue please use https://bugs.centos.org/. http://bay.uchicago.edu/centos/6.10/extras/i386/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" Trying other mirror.
until it finds some mirror which will work (that one mirror seems to be updating for everyone in the world so is very slow).
or it will do the following:
[root@linode01 ~]# yum clean all Loaded plugins: etckeeper, fastestmirror Cleaning repos: base cr epel epel-testing extras updates Cleaning up Everything Cleaning up list of fastest mirrors [root@linode01 ~]# yum update Loaded plugins: etckeeper, fastestmirror Setting up Update Process Determining fastest mirrors YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. Invalid release/repo/arch combination/ removing mirrorlist with no valid mirrors: /var/cache/yum/i386/6/base/mirrorlist.txt Error: Cannot find a valid baseurl for repo: base [root@linode01 ~]# echo $? 1 [root@linode01 ~]# yum list all Loaded plugins: etckeeper, fastestmirror Loading mirror speeds from cached hostfile YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. Invalid release/repo/arch combination/ removing mirrorlist with no valid mirrors: /var/cache/yum/i386/6/base/mirrorlist.txt Error: Cannot find a valid baseurl for repo: base
so basically the system can not find anything/do anything until a working mirror is there.
I'm not really very happy with this throwing an error.
I get it. People need to upgrade. But breaking things that are part of automated processes is a crappy way to get the message across.
As I mentioned, upgrades will take some time still, and now I have more work to deal with our unupgraded systems, so now it will take even longer to upgrade.
Thanks a bunch.
(Sorry for the sarcasm, but this is not a nice way to deal with the situation).
On Wed, 2020-12-02 at 21:40 +0100, Marcin Dulak wrote:
Is this really a good idea to remove those things?EOL does not mean CentOS6 will disappear from various legacy setups, they may be kept running for a long time.
On Wed, Dec 2, 2020 at 6:43 PM Karanbir Singh kbsingh@centos.org wrote:
On 02/12/2020 17:04, Laurențiu Păncescu wrote:
On 12/2/20 10:45 AM, Fabian Arrotin wrote: > Just to let you all know that starting from today,
mirrorlist.centos.org
> nodes answer "Invalid release/repo/arch combination" and also
that
> content was removed from mirrors. > Johnny pushed the last updates yesterday, that went out to
external
> mirrors .
Shouldn't we also delete centos/6 from Vagrant Cloud, and
possibly
official images hosted by e.g. Amazon Marketplace, Docker
Registry, etc.?
I've removed the vagrant image, and sent a requst for the AMP listing to be removed. _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailma...
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
--
*Matt Phelps*
*Information Technology Specialist, Systems Administrator*
(Computation Facility, Smithsonian Astrophysical Observatory)
Center for Astrophysics | Harvard & Smithsonian
60 Garden Street | MS 39 | Cambridge, MA 02138 email: mphelps@cfa.harvard.edu
cfa.harvard.edu | Facebook http://cfa.harvard.edu/facebook | Twitter http://cfa.harvard.edu/twitter | YouTube http://cfa.harvard.edu/youtube | Newsletter http://cfa.harvard.edu/newsletter
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-- Stephen J Smoogen.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Wed, 2 Dec 2020 at 16:37, Phelps, Matthew mphelps@cfa.harvard.edu wrote:
On Wed, Dec 2, 2020 at 4:17 PM Stephen John Smoogen smooge@gmail.com wrote:
On Wed, 2 Dec 2020 at 16:09, Phelps, Matthew mphelps@cfa.harvard.edu wrote:
On Wed, Dec 2, 2020 at 3:43 PM Patrick Riehecky riehecky@fnal.gov wrote:
I'm not really very happy with this throwing an error.
I get it. People need to upgrade. But breaking things that are part of automated processes is a crappy way to get the message across.
As I mentioned, upgrades will take some time still, and now I have more work to deal with our unupgraded systems, so now it will take even longer to upgrade.
Thanks a bunch.
(Sorry for the sarcasm, but this is not a nice way to deal with the situation).
1. I am not happy with this myself. I wasn't happy when it happened in EL5 or EL4 or others. However, it is the way things have been done with EOL releases in CentOS for a very long time and was explained that this would be the way it would happen for a year. 2. Fix 1: Mirror the content from an archive of the site closer to your network. It is only a couple hundred gigabytes. Then either use /etc/hosts or change configs so it is used as the place to get content. 3. Fix 2: Use an upstream mirror like https://archive.kernel.org/centos-vault/ but expect it to be overloaded at times. 4. Fix 3: Just add enabled=0 to CentOS-Base.repo systems. They aren't going to get updates anymore anyway.
On my CentOS6 systems I have a /etc/yum.repos.d/CentOS-Vault.repo which I added the following to: ``` #-----------------
[C6.10-base] name=CentOS-6.10 - Base baseurl=http://vault.centos.org/6.10/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=1
[C6.10-updates] name=CentOS-6.10 - Updates baseurl=http://vault.centos.org/6.10/updates/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=1
[C6.10-extras] name=CentOS-6.10 - Extras baseurl=http://vault.centos.org/6.10/extras/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=1
[C6.10-contrib] name=CentOS-6.10 - Contrib baseurl=http://vault.centos.org/6.10/contrib/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=0
[C6.10-centosplus] name=CentOS-6.10 - CentOSPlus baseurl=http://vault.centos.org/6.10/centosplus/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=0 ```
I then edited the CentOS-Base.repo to ``` [base] name=CentOS-$releasever - Base mirrorlist= http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep... #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=0
#released updates [updates] name=CentOS-$releasever - Updates mirrorlist= http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep... #baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=0
#additional packages that may be useful [extras] name=CentOS-$releasever - Extras mirrorlist= http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep... #baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=0 ```
I am now starting a slow copy of the vault for my later use.
On Wed, Dec 2, 2020 at 5:26 PM Stephen John Smoogen smooge@gmail.com wrote:
On Wed, 2 Dec 2020 at 16:37, Phelps, Matthew mphelps@cfa.harvard.edu wrote:
On Wed, Dec 2, 2020 at 4:17 PM Stephen John Smoogen smooge@gmail.com wrote:
On Wed, 2 Dec 2020 at 16:09, Phelps, Matthew mphelps@cfa.harvard.edu wrote:
On Wed, Dec 2, 2020 at 3:43 PM Patrick Riehecky riehecky@fnal.gov wrote:
I'm not really very happy with this throwing an error.
I get it. People need to upgrade. But breaking things that are part of automated processes is a crappy way to get the message across.
As I mentioned, upgrades will take some time still, and now I have more work to deal with our unupgraded systems, so now it will take even longer to upgrade.
Thanks a bunch.
(Sorry for the sarcasm, but this is not a nice way to deal with the situation).
- I am not happy with this myself. I wasn't happy when it happened in EL5
or EL4 or others. However, it is the way things have been done with EOL releases in CentOS for a very long time and was explained that this would be the way it would happen for a year. 2. Fix 1: Mirror the content from an archive of the site closer to your network. It is only a couple hundred gigabytes. Then either use /etc/hosts or change configs so it is used as the place to get content. 3. Fix 2: Use an upstream mirror like https://archive.kernel.org/centos-vault/ but expect it to be overloaded at times. 4. Fix 3: Just add enabled=0 to CentOS-Base.repo systems. They aren't going to get updates anymore anyway.
All excellent suggestions thanks.
We've never run into this situation before, because there wasn't a FREAKING GLOBAL PANDEMIC for nine months before the EOL date. We had started upgrading our 150+ machines before March 2020, but then, well... you know.
It turns out we do something similar to number 2, so we'll probably be OK.
Maybe the CentOS folks could just drag their feet for a few weeks to give other folks a little break.
On my CentOS6 systems I have a /etc/yum.repos.d/CentOS-Vault.repo which I added the following to:
#----------------- [C6.10-base] name=CentOS-6.10 - Base baseurl=http://vault.centos.org/6.10/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=1 [C6.10-updates] name=CentOS-6.10 - Updates baseurl=http://vault.centos.org/6.10/updates/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=1 [C6.10-extras] name=CentOS-6.10 - Extras baseurl=http://vault.centos.org/6.10/extras/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=1 [C6.10-contrib] name=CentOS-6.10 - Contrib baseurl=http://vault.centos.org/6.10/contrib/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=0 [C6.10-centosplus] name=CentOS-6.10 - CentOSPlus baseurl=http://vault.centos.org/6.10/centosplus/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=0I then edited the CentOS-Base.repo to
[base] name=CentOS-$releasever - Base mirrorlist= http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=0 #released updates [updates] name=CentOS-$releasever - Updates mirrorlist= http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates&infra=$infra #baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=0 #additional packages that may be useful [extras] name=CentOS-$releasever - Extras mirrorlist= http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras&infra=$infra #baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=0I am now starting a slow copy of the vault for my later use.
-- Stephen J Smoogen.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 12/2/20 11:36 PM, Phelps, Matthew wrote:
On Wed, Dec 2, 2020 at 4:17 PM Stephen John Smoogen <smooge@gmail.com mailto:smooge@gmail.com> wrote:
On Wed, 2 Dec 2020 at 16:09, Phelps, Matthew <mphelps@cfa.harvard.edu <mailto:mphelps@cfa.harvard.edu>> wrote: On Wed, Dec 2, 2020 at 3:43 PM Patrick Riehecky <riehecky@fnal.gov <mailto:riehecky@fnal.gov>> wrote: Some folks may continue running EL6 based systems, but we need to make sure it is obvious that we're not providing any security updates. Moving the repos off the mirror network will provide a hint to folks doing a simple 'yum update' that something is not the way it once was. Pat Whoa! What will happen if I run a "yum update" on a CO6 machine? We have it run automatically at reboot and I need to know what will happen so I can see if the rest of the scripts we run at startup will be OK. Yes we are updating them, but it's hard to do when you can't go onsite due to COVID. You will get every system running through messages like this [root@linode01 ~]# yum update Loaded plugins: etckeeper, fastestmirror Setting up Update Process Loading mirror speeds from cached hostfile epel/metalink | 2.5 kB 00:00 epel-testing/metalink | 2.6 kB 00:00 * base: mirror.dal10.us.leaseweb.net <http://mirror.dal10.us.leaseweb.net> * epel: d2lzkl7pfhq30w.cloudfront.net <http://d2lzkl7pfhq30w.cloudfront.net> * epel-testing: d2lzkl7pfhq30w.cloudfront.net <http://d2lzkl7pfhq30w.cloudfront.net> * extras: mirror.netdepot.com <http://mirror.netdepot.com> * updates: mirrors.usinternet.com <http://mirrors.usinternet.com> http://mirror.dal10.us.leaseweb.net/centos/6.10/os/i386/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" Trying other mirror. To address this issue please refer to the below wiki article https://wiki.centos.org/yum-errors If above article doesn't help to resolve this issue please use https://bugs.centos.org/. http://bay.uchicago.edu/centos/6.10/extras/i386/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" Trying other mirror. until it finds some mirror which will work (that one mirror seems to be updating for everyone in the world so is very slow). or it will do the following: [root@linode01 ~]# yum clean all Loaded plugins: etckeeper, fastestmirror Cleaning repos: base cr epel epel-testing extras updates Cleaning up Everything Cleaning up list of fastest mirrors [root@linode01 ~]# yum update Loaded plugins: etckeeper, fastestmirror Setting up Update Process Determining fastest mirrors YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. Invalid release/repo/arch combination/ removing mirrorlist with no valid mirrors: /var/cache/yum/i386/6/base/mirrorlist.txt Error: Cannot find a valid baseurl for repo: base [root@linode01 ~]# echo $? 1 [root@linode01 ~]# yum list all Loaded plugins: etckeeper, fastestmirror Loading mirror speeds from cached hostfile YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. Invalid release/repo/arch combination/ removing mirrorlist with no valid mirrors: /var/cache/yum/i386/6/base/mirrorlist.txt Error: Cannot find a valid baseurl for repo: base so basically the system can not find anything/do anything until a working mirror is there.I'm not really very happy with this throwing an error.
I get it. People need to upgrade. But breaking things that are part of automated processes is a crappy way to get the message across.
As I mentioned, upgrades will take some time still, and now I have more work to deal with our unupgraded systems, so now it will take even longer to upgrade.
Thanks a bunch.
(Sorry for the sarcasm, but this is not a nice way to deal with the situation).
Welcome to the club. Now wait for the free membership to the " You had _years_ advanced notice." to come, it's on its way.
wolfy "I still have a few hundred remote desktops to upgrade ( and could not do that due to remote access restrictions collateral to Covid moving around restrictions )"
On Wed, Dec 2, 2020 at 5:26 PM Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 12/2/20 11:36 PM, Phelps, Matthew wrote:
On Wed, Dec 2, 2020 at 4:17 PM Stephen John Smoogen smooge@gmail.com wrote:
On Wed, 2 Dec 2020 at 16:09, Phelps, Matthew mphelps@cfa.harvard.edu wrote:
On Wed, Dec 2, 2020 at 3:43 PM Patrick Riehecky riehecky@fnal.gov wrote:
Some folks may continue running EL6 based systems, but we need to make sure it is obvious that we're not providing any security updates. Moving the repos off the mirror network will provide a hint to folks doing a simple 'yum update' that something is not the way it once was.
Pat
Whoa!
What will happen if I run a "yum update" on a CO6 machine? We have it run automatically at reboot and I need to know what will happen so I can see if the rest of the scripts we run at startup will be OK.
Yes we are updating them, but it's hard to do when you can't go onsite due to COVID.
You will get every system running through messages like this
[root@linode01 ~]# yum update Loaded plugins: etckeeper, fastestmirror Setting up Update Process Loading mirror speeds from cached hostfile epel/metalink | 2.5 kB 00:00 epel-testing/metalink | 2.6 kB 00:00
- base: mirror.dal10.us.leaseweb.net
- epel: d2lzkl7pfhq30w.cloudfront.net
- epel-testing: d2lzkl7pfhq30w.cloudfront.net
- extras: mirror.netdepot.com
- updates: mirrors.usinternet.com
http://mirror.dal10.us.leaseweb.net/centos/6.10/os/i386/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" Trying other mirror. To address this issue please refer to the below wiki article
https://wiki.centos.org/yum-errors
If above article doesn't help to resolve this issue please use https://bugs.centos.org/. http://bay.uchicago.edu/centos/6.10/extras/i386/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" Trying other mirror.
until it finds some mirror which will work (that one mirror seems to be updating for everyone in the world so is very slow).
or it will do the following:
[root@linode01 ~]# yum clean all Loaded plugins: etckeeper, fastestmirror Cleaning repos: base cr epel epel-testing extras updates Cleaning up Everything Cleaning up list of fastest mirrors [root@linode01 ~]# yum update Loaded plugins: etckeeper, fastestmirror Setting up Update Process Determining fastest mirrors YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. Invalid release/repo/arch combination/ removing mirrorlist with no valid mirrors: /var/cache/yum/i386/6/base/mirrorlist.txt Error: Cannot find a valid baseurl for repo: base [root@linode01 ~]# echo $? 1 [root@linode01 ~]# yum list all Loaded plugins: etckeeper, fastestmirror Loading mirror speeds from cached hostfile YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. Invalid release/repo/arch combination/ removing mirrorlist with no valid mirrors: /var/cache/yum/i386/6/base/mirrorlist.txt Error: Cannot find a valid baseurl for repo: base
so basically the system can not find anything/do anything until a working mirror is there.
I'm not really very happy with this throwing an error.
I get it. People need to upgrade. But breaking things that are part of automated processes is a crappy way to get the message across.
As I mentioned, upgrades will take some time still, and now I have more work to deal with our unupgraded systems, so now it will take even longer to upgrade.
Thanks a bunch.
(Sorry for the sarcasm, but this is not a nice way to deal with the situation).
Welcome to the club. Now wait for the free membership to the " You had _years_ advanced notice." to come, it's on its way.
I hear ya brother.
wolfy "I still have a few hundred remote desktops to upgrade ( and could not do that due to remote access restrictions collateral to Covid moving around restrictions )"
We are not alone. That's no solace though.
Good luck.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 12/2/20 4:26 PM, Manuel Wolfshant wrote:
On 12/2/20 11:36 PM, Phelps, Matthew wrote:
On Wed, Dec 2, 2020 at 4:17 PM Stephen John Smoogen <smooge@gmail.com mailto:smooge@gmail.com> wrote:
On Wed, 2 Dec 2020 at 16:09, Phelps, Matthew <mphelps@cfa.harvard.edu <mailto:mphelps@cfa.harvard.edu>> wrote: On Wed, Dec 2, 2020 at 3:43 PM Patrick Riehecky <riehecky@fnal.gov <mailto:riehecky@fnal.gov>> wrote: Some folks may continue running EL6 based systems, but we need to make sure it is obvious that we're not providing any security updates. Moving the repos off the mirror network will provide a hint to folks doing a simple 'yum update' that something is not the way it once was. Pat Whoa! What will happen if I run a "yum update" on a CO6 machine? We have it run automatically at reboot and I need to know what will happen so I can see if the rest of the scripts we run at startup will be OK. Yes we are updating them, but it's hard to do when you can't go onsite due to COVID. You will get every system running through messages like this [root@linode01 ~]# yum update Loaded plugins: etckeeper, fastestmirror Setting up Update Process Loading mirror speeds from cached hostfile epel/metalink | 2.5 kB 00:00 epel-testing/metalink | 2.6 kB 00:00 * base: mirror.dal10.us.leaseweb.net <http://mirror.dal10.us.leaseweb.net> * epel: d2lzkl7pfhq30w.cloudfront.net <http://d2lzkl7pfhq30w.cloudfront.net> * epel-testing: d2lzkl7pfhq30w.cloudfront.net <http://d2lzkl7pfhq30w.cloudfront.net> * extras: mirror.netdepot.com <http://mirror.netdepot.com> * updates: mirrors.usinternet.com <http://mirrors.usinternet.com> http://mirror.dal10.us.leaseweb.net/centos/6.10/os/i386/repodata/repomd.xml <http://mirror.dal10.us.leaseweb.net/centos/6.10/os/i386/repodata/repomd.xml>: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" Trying other mirror. To address this issue please refer to the below wiki article https://wiki.centos.org/yum-errors <https://wiki.centos.org/yum-errors> If above article doesn't help to resolve this issue please use https://bugs.centos.org/ <https://bugs.centos.org/>. http://bay.uchicago.edu/centos/6.10/extras/i386/repodata/repomd.xml <http://bay.uchicago.edu/centos/6.10/extras/i386/repodata/repomd.xml>: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" Trying other mirror. until it finds some mirror which will work (that one mirror seems to be updating for everyone in the world so is very slow). or it will do the following: [root@linode01 ~]# yum clean all Loaded plugins: etckeeper, fastestmirror Cleaning repos: base cr epel epel-testing extras updates Cleaning up Everything Cleaning up list of fastest mirrors [root@linode01 ~]# yum update Loaded plugins: etckeeper, fastestmirror Setting up Update Process Determining fastest mirrors YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. Invalid release/repo/arch combination/ removing mirrorlist with no valid mirrors: /var/cache/yum/i386/6/base/mirrorlist.txt Error: Cannot find a valid baseurl for repo: base [root@linode01 ~]# echo $? 1 [root@linode01 ~]# yum list all Loaded plugins: etckeeper, fastestmirror Loading mirror speeds from cached hostfile YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. Invalid release/repo/arch combination/ removing mirrorlist with no valid mirrors: /var/cache/yum/i386/6/base/mirrorlist.txt Error: Cannot find a valid baseurl for repo: base so basically the system can not find anything/do anything until a working mirror is there.I'm not really very happy with this throwing an error.
I get it. People need to upgrade. But breaking things that are part of automated processes is a crappy way to get the message across.
As I mentioned, upgrades will take some time still, and now I have more work to deal with our unupgraded systems, so now it will take even longer to upgrade.
Thanks a bunch.
(Sorry for the sarcasm, but this is not a nice way to deal with the situation).
Welcome to the club. Now wait for the free membership to the " You had _years_ advanced notice." to come, it's on its way.
wolfy "I still have a few hundred remote desktops to upgrade ( and could not do that due to remote access restrictions collateral to Covid moving around restrictions )"
We have been doing it this was for 17 years .. Literally since the inception of CentOS Linux. I have announced it several times and it has always been done exactly like this. CentOS Linux 2.1, 3.x, 4.x and 5.x have all been done this way.
It is on vault.centos.org .. download a final copy to your own local mirror.
All older versions are on vault.centos.org and have always been (same versions as mentioned above).
We can not leave, in the production location, things that will never be updated and can have security issues.
On 12/3/20 12:59 AM, Johnny Hughes wrote:
On 12/2/20 4:26 PM, Manuel Wolfshant wrote:
On 12/2/20 11:36 PM, Phelps, Matthew wrote:
On Wed, Dec 2, 2020 at 4:17 PM Stephen John Smoogen <smooge@gmail.com mailto:smooge@gmail.com> wrote:
On Wed, 2 Dec 2020 at 16:09, Phelps, Matthew <mphelps@cfa.harvard.edu <mailto:mphelps@cfa.harvard.edu>> wrote: On Wed, Dec 2, 2020 at 3:43 PM Patrick Riehecky <riehecky@fnal.gov <mailto:riehecky@fnal.gov>> wrote: Some folks may continue running EL6 based systems, but we need to make sure it is obvious that we're not providing any security updates. Moving the repos off the mirror network will provide a hint to folks doing a simple 'yum update' that something is not the way it once was. Pat Whoa! What will happen if I run a "yum update" on a CO6 machine? We have it run automatically at reboot and I need to know what will happen so I can see if the rest of the scripts we run at startup will be OK. Yes we are updating them, but it's hard to do when you can't go onsite due to COVID. You will get every system running through messages like this [root@linode01 ~]# yum update Loaded plugins: etckeeper, fastestmirror Setting up Update Process Loading mirror speeds from cached hostfile epel/metalink | 2.5 kB 00:00 epel-testing/metalink | 2.6 kB 00:00 * base: mirror.dal10.us.leaseweb.net <http://mirror.dal10.us.leaseweb.net> * epel: d2lzkl7pfhq30w.cloudfront.net <http://d2lzkl7pfhq30w.cloudfront.net> * epel-testing: d2lzkl7pfhq30w.cloudfront.net <http://d2lzkl7pfhq30w.cloudfront.net> * extras: mirror.netdepot.com <http://mirror.netdepot.com> * updates: mirrors.usinternet.com <http://mirrors.usinternet.com> http://mirror.dal10.us.leaseweb.net/centos/6.10/os/i386/repodata/repomd.xml <http://mirror.dal10.us.leaseweb.net/centos/6.10/os/i386/repodata/repomd.xml>: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" Trying other mirror. To address this issue please refer to the below wiki article https://wiki.centos.org/yum-errors <https://wiki.centos.org/yum-errors> If above article doesn't help to resolve this issue please use https://bugs.centos.org/ <https://bugs.centos.org/>. http://bay.uchicago.edu/centos/6.10/extras/i386/repodata/repomd.xml <http://bay.uchicago.edu/centos/6.10/extras/i386/repodata/repomd.xml>: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" Trying other mirror. until it finds some mirror which will work (that one mirror seems to be updating for everyone in the world so is very slow). or it will do the following: [root@linode01 ~]# yum clean all Loaded plugins: etckeeper, fastestmirror Cleaning repos: base cr epel epel-testing extras updates Cleaning up Everything Cleaning up list of fastest mirrors [root@linode01 ~]# yum update Loaded plugins: etckeeper, fastestmirror Setting up Update Process Determining fastest mirrors YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. Invalid release/repo/arch combination/ removing mirrorlist with no valid mirrors: /var/cache/yum/i386/6/base/mirrorlist.txt Error: Cannot find a valid baseurl for repo: base [root@linode01 ~]# echo $? 1 [root@linode01 ~]# yum list all Loaded plugins: etckeeper, fastestmirror Loading mirror speeds from cached hostfile YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. Invalid release/repo/arch combination/ removing mirrorlist with no valid mirrors: /var/cache/yum/i386/6/base/mirrorlist.txt Error: Cannot find a valid baseurl for repo: base so basically the system can not find anything/do anything until a working mirror is there.I'm not really very happy with this throwing an error.
I get it. People need to upgrade. But breaking things that are part of automated processes is a crappy way to get the message across.
As I mentioned, upgrades will take some time still, and now I have more work to deal with our unupgraded systems, so now it will take even longer to upgrade.
Thanks a bunch.
(Sorry for the sarcasm, but this is not a nice way to deal with the situation).
Welcome to the club. Now wait for the free membership to the " You had _years_ advanced notice." to come, it's on its way.
wolfy "I still have a few hundred remote desktops to upgrade ( and could not do that due to remote access restrictions collateral to Covid moving around restrictions )"
We have been doing it this was for 17 years .. Literally since the inception of CentOS Linux. I have announced it several times and it has always been done exactly like this. CentOS Linux 2.1, 3.x, 4.x and 5.x have all been done this way.
It is on vault.centos.org .. download a final copy to your own local mirror.
I do have a mirror refreshed periodically, setup in the days where 200 GB disks were not even available in my country, I had to do special import from USA.
my problem is that due to covid MANY ( actually most ) of my colleagues ( on 3 continents ) took their desktops home, without prior announcing me about that ( in quite a few cases the decision was taken in a split-second due to a sick person leading to the closure of the office; we had that happening in basically all our remote offices ). While in office those desktops benefited from the VPN between offices but when working from home they no longer have access to the internal repo.
All older versions are on vault.centos.org and have always been (same versions as mentioned above).
We can not leave, in the production location, things that will never be updated and can have security issues.
I'd play devil's advocate here and say "and breaking the update process fixes things ... how?" but I am (was ) on your side all along.
On Wed, Dec 2, 2020 at 5:59 PM Johnny Hughes johnny@centos.org wrote:
On 12/2/20 4:26 PM, Manuel Wolfshant wrote:
On 12/2/20 11:36 PM, Phelps, Matthew wrote:
On Wed, Dec 2, 2020 at 4:17 PM Stephen John Smoogen <smooge@gmail.com mailto:smooge@gmail.com> wrote:
On Wed, 2 Dec 2020 at 16:09, Phelps, Matthew <mphelps@cfa.harvard.edu <mailto:mphelps@cfa.harvard.edu>> wrote: On Wed, Dec 2, 2020 at 3:43 PM Patrick Riehecky <riehecky@fnal.gov <mailto:riehecky@fnal.gov>> wrote: Some folks may continue running EL6 based systems, but we need to make sure it is obvious that we're not providing any security updates. Moving the repos off the mirror network will provide a hint to folks doing a simple 'yum update' that something is not the way it once was. Pat Whoa! What will happen if I run a "yum update" on a CO6 machine? We have it run automatically at reboot and I need to know what will happen so I can see if the rest of the scripts we run at startup will be OK. Yes we are updating them, but it's hard to do when you can't go onsite due to COVID. You will get every system running through messages like this [root@linode01 ~]# yum update Loaded plugins: etckeeper, fastestmirror Setting up Update Process Loading mirror speeds from cached hostfile epel/metalink | 2.5 kB 00:00 epel-testing/metalink | 2.6 kB 00:00 * base: mirror.dal10.us.leaseweb.net <http://mirror.dal10.us.leaseweb.net> * epel: d2lzkl7pfhq30w.cloudfront.net <http://d2lzkl7pfhq30w.cloudfront.net> * epel-testing: d2lzkl7pfhq30w.cloudfront.net <http://d2lzkl7pfhq30w.cloudfront.net> * extras: mirror.netdepot.com <http://mirror.netdepot.com> * updates: mirrors.usinternet.com <http://mirrors.usinternet.com>http://mirror.dal10.us.leaseweb.net/centos/6.10/os/i386/repodata/repomd.xml
<http://mirror.dal10.us.leaseweb.net/centos/6.10/os/i386/repodata/repomd.xml
:
[Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" Trying other mirror. To address this issue please refer to the below wiki article https://wiki.centos.org/yum-errors <https://wiki.centos.org/yum-errors> If above article doesn't help to resolve this issue please use https://bugs.centos.org/ <https://bugs.centos.org/>. http://bay.uchicago.edu/centos/6.10/extras/i386/repodata/repomd.xmlhttp://bay.uchicago.edu/centos/6.10/extras/i386/repodata/repomd.xml:
[Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" Trying other mirror. until it finds some mirror which will work (that one mirror seems to be updating for everyone in the world so is very slow). or it will do the following: [root@linode01 ~]# yum clean all Loaded plugins: etckeeper, fastestmirror Cleaning repos: base cr epel epel-testing extras updates Cleaning up Everything Cleaning up list of fastest mirrors [root@linode01 ~]# yum update Loaded plugins: etckeeper, fastestmirror Setting up Update Process Determining fastest mirrors YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. Invalid release/repo/arch combination/ removing mirrorlist with no valid mirrors: /var/cache/yum/i386/6/base/mirrorlist.txt Error: Cannot find a valid baseurl for repo: base [root@linode01 ~]# echo $? 1 [root@linode01 ~]# yum list all Loaded plugins: etckeeper, fastestmirror Loading mirror speeds from cached hostfile YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. Invalid release/repo/arch combination/ removing mirrorlist with no valid mirrors: /var/cache/yum/i386/6/base/mirrorlist.txt Error: Cannot find a valid baseurl for repo: base so basically the system can not find anything/do anything until a working mirror is there.I'm not really very happy with this throwing an error.
I get it. People need to upgrade. But breaking things that are part of automated processes is a crappy way to get the message across.
As I mentioned, upgrades will take some time still, and now I have more work to deal with our unupgraded systems, so now it will take even longer to upgrade.
Thanks a bunch.
(Sorry for the sarcasm, but this is not a nice way to deal with the situation).
Welcome to the club. Now wait for the free membership to the " You had _years_ advanced notice." to come, it's on its way.
wolfy "I still have a few hundred remote desktops to upgrade ( and could not do that due to remote access restrictions collateral to Covid moving around restrictions )"
We have been doing it this was for 17 years .. Literally since the inception of CentOS Linux. I have announced it several times and it has always been done exactly like this. CentOS Linux 2.1, 3.x, 4.x and 5.x have all been done this way.
And the last global pandemic that shut everything down was 102 years ago, but don't even think of doing anything different for the sake of your users.
OK, fine.
It is on vault.centos.org .. download a final copy to your own local mirror.
All older versions are on vault.centos.org and have always been (same versions as mentioned above).
We can not leave, in the production location, things that will never be updated and can have security issues.
You could for an extra month. Have a little flexibility given the circumstances maybe?
I know you all won't change, and as I mentioned we're fine, but don't be such hard asses all the time.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Fin.
On 02/12/2020 22:59, Johnny Hughes wrote:
It is on vault.centos.org .. download a final copy to your own local mirror.
All older versions are on vault.centos.org and have always been (same versions as mentioned above).
I wonder what happens if we keep valid, but empty repos for the /6/ links, quite understad there are a fair few people in a bad spot due to not being able to travel etc.
another option maybe 301's from mirror.c.o to vault ?
how about mirrorlist only hands out vault for c6 repos ?
with the intention that in 4 - 6 months we clear that down.
regards,
On 12/3/20 2:07 AM, Karanbir Singh wrote:
On 02/12/2020 22:59, Johnny Hughes wrote:
It is on vault.centos.org .. download a final copy to your own local mirror.
All older versions are on vault.centos.org and have always been (same versions as mentioned above).
I wonder what happens if we keep valid, but empty repos for the /6/ links, quite understad there are a fair few people in a bad spot due to not being able to travel etc.
except for not seeing any updates and breaking new installs that rely on public repos ( which happens already ) ?
another option maybe 301's from mirror.c.o to vault ?
nope. that would encourage people to not update and would certainly overload vault
how about mirrorlist only hands out vault for c6 repos ?
see above
with the intention that in 4 - 6 months we clear that down.
a grace period would have been nice rather than a sudden cutoff even before RH released the last updates but I guess the train has already left the station
On 12/2/20 5:59 PM, Johnny Hughes wrote:
We have been doing it this was for 17 years .. Literally since the inception of CentOS Linux. I have announced it several times and it has always been done exactly like this. CentOS Linux 2.1, 3.x, 4.x and 5.x have all been done this way.
The problem that bit me was that prior to Nov 30, I couldn't even _test_ a change to my kickstart and puppet infrastructure because 6.10 wasn't populated. Then I had to rush like mad yesterday to get new kickstarts, a puppet production merge, 4 AMIs, and a libvirt image tested and released because _all_ newly spun or newly kicked hosts failed. The grace period given was 2 days. I was technically ready to release on Dec 1st having tested out the vault changes on Nov 30. However, EPEL wasn't done syncing to their archived location so my changes were only half way done. At 4am on the 2nd I had to rush around while autoscaling groups were breaking left and right.
So I guess my two asks are these:
1) sync to the vault well before EOL (and obviously sync anytime the main repos get updated in those last few weeks) so that this can be tested by people before the cutoff date. 2) coordinate with EPEL's archive migration.
On Wed, Dec 02, 2020 at 04:36:57PM -0500, Phelps, Matthew wrote:
I'm not really very happy with this throwing an error.
In general, maybe blocking reboot of remote machines when yum repos are not available is something that you might want to reconsider, irrespectively of the CentOS 6 EOL situation (if indeed failing yum upgrade command will make your machines unbootable).
The uplink network can be down at any moment.
On 02/12/2020 20:40, Marcin Dulak wrote:
Is this really a good idea to remove those things? EOL does not mean CentOS6 will disappear from various legacy setups, they may be kept running for a long time.
Specifically for the vagrant images and amp images : folks already have the last image we'd push - so the intention is that no new net installs, unless folks are willing to jump one extra hoop. The artifacts going there have no impact on running pieces.
regards,
On Thu, Dec 3, 2020 at 1:09 AM Karanbir Singh kbsingh@centos.org wrote:
On 02/12/2020 20:40, Marcin Dulak wrote:
Is this really a good idea to remove those things? EOL does not mean CentOS6 will disappear from various legacy setups, they may be kept running for a long time.
Specifically for the vagrant images and amp images : folks already have the last image we'd push - so the intention is that no new net installs, unless folks are willing to jump one extra hoop. The artifacts going there have no impact on running pieces.
My question was more related to those systems not being long-running nowadays, the virtual machines and containers come and go.
regards,
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Karanbir Singh writes:
On 02/12/2020 17:04, Laurențiu Păncescu wrote:
On 12/2/20 10:45 AM, Fabian Arrotin wrote:
Just to let you all know that starting from today, mirrorlist.centos.org nodes answer "Invalid release/repo/arch combination" and also that content was removed from mirrors. Johnny pushed the last updates yesterday, that went out to external mirrors .
Shouldn't we also delete centos/6 from Vagrant Cloud, and possibly official images hosted by e.g. Amazon Marketplace, Docker Registry, etc.?
I've removed the vagrant image, and sent a requst for the AMP listing to be removed.
On the AMP side, we will archive the listing, meaning that the AWS Marketplace will not accept net new subscribers. That means that any currently subscribed customer can continue to access the machine image (AMI) that they have been using, but anyone who was not yet a subscriber to the AWS Marketplace listing will not be able to add the CentOS 6 product as a new subscription. This is already in motion as a result of KB's request and the expected scheduling.
-- David Duncan | Working from Austin, TX Partner Solutions Architect. | +1-512-507-9268, +1-423-771-9529 TZ=America/Chicago | He/Him A: The lost context. Q: What makes top-posted replies harder to read than bottom-posted?
On 03/12/2020 04:55, David Duncan via CentOS-devel wrote:
Karanbir Singh writes:
On 02/12/2020 17:04, Laurențiu Păncescu wrote:
On 12/2/20 10:45 AM, Fabian Arrotin wrote:
Just to let you all know that starting from today, mirrorlist.centos.org nodes answer "Invalid release/repo/arch combination" and also that content was removed from mirrors. Johnny pushed the last updates yesterday, that went out to external mirrors .
Shouldn't we also delete centos/6 from Vagrant Cloud, and possibly official images hosted by e.g. Amazon Marketplace, Docker Registry, etc.?
I've removed the vagrant image, and sent a requst for the AMP listing to be removed.
On the AMP side, we will archive the listing, meaning that the AWS Marketplace will not accept net new subscribers. That means that any currently subscribed customer can continue to access the machine image (AMI) that they have been using, but anyone who was not yet a subscriber to the AWS Marketplace listing will not be able to add the CentOS 6 product as a new subscription. This is already in motion as a result of KB's request and the expected scheduling.
perfect, thanks David.
-----Original Message----- From: CentOS-devel centos-devel-bounces@centos.org On Behalf Of Johnny Hughes Sent: Monday, November 9, 2020 8:25 AM To: CentOS ML centos@centos.org; CentOS-Devel centos-devel@centos.org Subject: [CentOS-devel] Reminder: CentOS 6 EOL on 30 November 2020
All,
This is a friendly reminder.
CentOS 6.10 will EOL at the end of November 2020.
During the first week in December 2020, the 6.10 directory will move to vault.centos.org
How difficult is it to keep (a copy) the latest update online for a while? We have an internal mirror but I am sure there are others out there that might use it for a few more months. Kill the ISO and any other space taking non-updates.
Packages will still be available at:
http://vault.centos.org/centos/6.10/
However, once moved, there will be no more updates pushed to vault.centos.org. Therefore, security issues will no longer be fixed, etc.
You should take the rest of the month to either move to a newer versoin of CentOS Linux ... or to procure Extended el6 support from Red Hat (EUS RHEL 6).
Thanks, Johnny Hughes
-
David Duncan -
Fabian Arrotin -
Jan Pazdziora -
Jason Pyeron -
jc -
Johnny Hughes -
Karanbir Singh -
Laurențiu Păncescu -
Manuel Wolfshant -
Marcin Dulak -
Patrick Riehecky -
Phelps, Matthew -
Stephen John Smoogen