On Wed, Dec 2, 2020 at 5:59 PM Johnny Hughes <johnny at 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 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. > > 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 at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > Fin. -- *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 at 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> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20201202/77c49ac2/attachment-0006.html>