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 at gmail.com >>> <mailto:smooge at gmail.com>> wrote: >>> >>> >>> >>> On Wed, 2 Dec 2020 at 16:09, Phelps, Matthew >>> <mphelps at cfa.harvard.edu <mailto:mphelps at cfa.harvard.edu>> wrote: >>> >>> >>> >>> >>> On Wed, Dec 2, 2020 at 3:43 PM Patrick Riehecky >>> <riehecky at fnal.gov <mailto:riehecky at 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 at 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 at 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 at 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 at linode01 ~]# echo $? >>> 1 >>> [root at 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.