Re: [CentOS] Blog article about the state of CentOS
On 22/06/20 10:13 am, Stephen John Smoogen wrote: There are 2 sets of work. 1. There is the work on the tools which were slapped together as an emergency from parts before 8.0. Those mbboxx tools are getting a rewrite and upgrade currently by the CPE team to make them more useful in the future. Stream only helps in that it is the excuse for that work to be done versus it molding and falling apart right after every 8.x release comes out. I didn't know that a rewrite is still needed on the current tool set and granted Stream can help with this, but I hardly think that it's necessary and the tool set can always be tested against the current release (8.2) from git. 2. There is the work that happens because various things are rebased and you need to figure out the HTF you get from build A to build A+1 by rebuilding N packages. That is work that Stream should help on because this is then knowledge is being done in stream before hand. If you know that package A went to A+1 then to A+2 and then back to A+1 but you learned how to do the second A+1 from a flag you used with A+2, then the amount of time reinventing the wheel is shortened. This I do realize and it's the one exception I considered where Stream might come in handy, but not handy enough to justify its existence, imo. Usually in a new point release there might be a small handful of packages that need re-basing, out of those the number of packages that would need to have the spec file tweaked to build them would be minimal (at a complete guess three or less) and out of those the number that would require a change to the tool set would likely average out to be less than one per point release. In a worst-case scenario it might save a day or two on a particularly nasty point release, and this would easily be recouped in the amount of time it would save if the CentOS team did not have to maintain Stream at all. Now these are just semi-educated guesses and I don't have the experience to justify this so I'm happy to consider real numbers that prove me wrong. Peter ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] php 5.6 on CentOS 6
On 6/21/20 5:58 PM, Jonathan Billings wrote: On Jun 21, 2020, at 16:38, Valeri Galtsev wrote: This my reply is not intended for the OP, as he stated he will not listen about End Of Life of of PHP 5. Just in case anybody comes across this thread, please read what is written on the page referred to by Alexander Dalloz: PHP 5.6 is EOL. https://www.php.net/supported-versions.php If you are using the packages PHP packages in CentOS and keep your OS up to date, you can disregard this. This in plain English language says that php 5 is not supported by vendor since Jan 1 2019, i.e. almost a year a a half now. This means that PHP development team does not release security patches, and even though RedHat "backports" patches to older versions, difference in internals between PHP version 5 and version 7 is quite significant, so you should not assume that even if RedHat team still backports security patches for issues discovered in version 7, you are safe: there may be still be issues in version 5 which by no means are discovered by anyone. This boils down to one thing. If you still have anything using PHP version 5.[any] you should migrate this to PHP version at least 7.2. You ideally should have done that before Jan. 1, 2019. I hope, this helps somebody. By no means I meant to question the brilliant job RedHat does backporting (taking my hat off and bowing to RedHat here). However, as I said, there may be bugs in PHP 5 that will not be relevant to PHP 7, hence there is nothing to backport to fix them. I realize you are out of touch with how CentOS packages (and RHEL packages they’re built from) are handled, since you’ve decided to stop using it and move to FreeBSD, but this is how Red Hat backports fixes to php and other enterprise software: https://access.redhat.com/security/updates/backporting Apparently, I didn't manage to make myself clear enough, so you even think I have no idea about how RedHat backports fixes work. You gave the reference, when I read your first phrase, I was going to refer to a backporting page, but here you just gave that same URL: https://access.redhat.com/security/updates/backporting/ Of course, my knowledge is not full and extremely precise, but I have decent idea of how it works, known it for years, and that was basis of my choice: CentOS, not a "rolling release" distribution like Debian. I will reiterate it in general, as I will attempt to base on it the case... but that will be later. 1. RedHat chooses some version of some software [forget here the reason why that specific version], say, PHP 5.3, and does the best to keep that patched and secure for as long as they feel practical 2. When PHP project moves on and stops updating 5.3, RedHat analyzes what new release fixes, ports these fixes back to version 5.3, analyzes patches PHP releases to new versions, and sees whether these patches are relevant to code in version 5.3, and ports fixes to 5.3 version. 3. When PHP moves to higher version, say, 7 but still maintains version 5, RedHat does the same as in 2. However, once version 5 is EOL, PHP project stops patching version 5. However, version 7 shares quite significant portion of code with version 5. So, once patch (or minor release fixing some things) of PHP 7 comes, RedHat again analyzes whether fixes are relevant to older version RedHat still maintains, it will most likely be version 5.6 now. Occasionally, with life cycle as long as 10 years, RedHat has to jump forward with minor version number skipping a few, it may be jump from 5.3 to 5.6, don't catch me not citing exact version numbers. That is in general brilliant and rather effort consuming way RedHat manages to keep for quite long pretty much the same environment, thus allowing those who use it to not constantly adjust their code to ever moving, say, PHP, as opposed to Debian and clones, or BSD descendants (in whose cases PHP 5.6 EOL, you better have all ported to PHP 7 now). And we did not even mention that RedHat audits some code also, so things are even better. However, in this excellent picture there is one piece that is not covered. I know, the likelihood of what I will describe below in small, but it is not zero, not excluded. First: how weaknesses and bugs are discovered? Mostly by: A. User (I am including sysadmin running servers in such) discover something broken, not working as expected, and files bug report or PR (problem report is what some projects call it). B. Several big guys, like Amazon, Google, ... have people auditing important for them parts of code, and file bug reports, and often even patches to fix it C. Several agencies sometimes do their auditing (CERT comes to my mind, someone may extend the list) If something is not discovered, no one will work on fixing it. But it still may represent danger, even though bad guys usually hunt after known stuff. Now, that PHP 5.6 EOL came year and a half ago, majority of
Re: [CentOS] php 5.6 on CentOS 6
> On Jun 21, 2020, at 16:38, Valeri Galtsev wrote: > This my reply is not intended for the OP, as he stated he will not listen > about End Of Life of of PHP 5. Just in case anybody comes across this thread, > please read what is written on the page referred to by Alexander Dalloz: > > >> PHP 5.6 is EOL. https://www.php.net/supported-versions.php If you are using the packages PHP packages in CentOS and keep your OS up to date, you can disregard this. > This in plain English language says that php 5 is not supported by vendor > since Jan 1 2019, i.e. almost a year a a half now. This means that PHP > development team does not release security patches, and even though RedHat > "backports" patches to older versions, difference in internals between PHP > version 5 and version 7 is quite significant, so you should not assume that > even if RedHat team still backports security patches for issues discovered in > version 7, you are safe: there may be still be issues in version 5 which by > no means are discovered by anyone. > > This boils down to one thing. If you still have anything using PHP version > 5.[any] you should migrate this to PHP version at least 7.2. You ideally > should have done that before Jan. 1, 2019. > I hope, this helps somebody. > > By no means I meant to question the brilliant job RedHat does backporting > (taking my hat off and bowing to RedHat here). However, as I said, there may > be bugs in PHP 5 that will not be relevant to PHP 7, hence there is nothing > to backport to fix them. I realize you are out of touch with how CentOS packages (and RHEL packages they’re built from) are handled, since you’ve decided to stop using it and move to FreeBSD, but this is how Red Hat backports fixes to php and other enterprise software: https://access.redhat.com/security/updates/backporting So if someone is coming across this thread, know that if you are using the supported PHP packages in CentOS’s repositories, security fixes are backported, and if security issues are identified in the version in RHEL, they’ll issues fixes during the lifetime of the release. So, in CentOS 7, expect the php 5 packages to be supported for a couple more years, despite all the gnashing off teeth of the PHP upstream developers. If you plan on starting a new project, definitely start with php 7. But if you have concerns about an existing 5.x codebase, as long as you are keeping your OS up to date, you have some time to migrate. -- Jonathan Billings ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Blog article about the state of CentOS
On Sun, 21 Jun 2020 at 15:10, Peter wrote: > > On 22/06/20 7:03 am, John Pierce wrote: > > On Sun, Jun 21, 2020 at 2:01 AM Simon Matter via CentOS > > wrote: > > > > exactly, that was my point.I remember 8.0 was very delayed by how much > > harder and different the build process was. > > That work was completed in the build of 8.0 and to a smaller extent 8.1. > Stream doesn't really add anything here. > There are 2 sets of work. 1. There is the work on the tools which were slapped together as an emergency from parts before 8.0. Those mbboxx tools are getting a rewrite and upgrade currently by the CPE team to make them more useful in the future. Stream only helps in that it is the excuse for that work to be done versus it molding and falling apart right after every 8.x release comes out. 2. There is the work that happens because various things are rebased and you need to figure out the HTF you get from build A to build A+1 by rebuilding N packages. That is work that Stream should help on because this is then knowledge is being done in stream before hand. If you know that package A went to A+1 then to A+2 and then back to A+1 but you learned how to do the second A+1 from a flag you used with A+2, then the amount of time reinventing the wheel is shortened. > > Peter > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos -- Stephen J Smoogen. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] firewall questions
Please take a look at https://www.wireguard.com/quickstart/ we now reduced the attack vector to only the things offered to the public (https, smtp tls and imaps/s) On Sun, Jun 21, 2020 at 3:58 PM Pete Biggs wrote: > On Sun, 2020-06-21 at 16:47 -0400, mailist wrote: > > On 2020-06-21 15:33, Chuck Campbell wrote: > > > I'm running Centos 7.8.2003, with firewalld. > > > > > > I was getting huge numbers of ssh attempts per day from a few specific > > > ip blocks. > > > > If you can control the ssh clients, switch your port number to a > > non-standard > > port. Pick one in /etc/services that does not seem to be allocated. > > Then change > > "Port" in ssh_config and sshd_config; If other clients are being used > > (like Putty), > > it is easy to change it there. > > > > We used to get at least 50 probes per day on port 22. Now we get zero. > > > I used this technique for a number of years - then it got leaked to the > script kiddies the port that was used. We don't have anything > particularly valuable that they were looking for (I don't think!), but > there are lists of subnets & ports out there that the kiddies use so > once one found it, the flood gates opened. SSH is now protected behind > a VPN. > > It's a valid thing to do and makes things much saner, but don't assume > it is a forever solution and don't use it as an excuse to reduce other > protections you may have. > > P. > > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > -- - Erick Perez Quadrian Enterprises S.A. - Panama, Republica de Panama Skype chat: eaperezh WhatsApp IM: +507-6675-5083 - ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] firewall questions
On Sun, 2020-06-21 at 16:47 -0400, mailist wrote: > On 2020-06-21 15:33, Chuck Campbell wrote: > > I'm running Centos 7.8.2003, with firewalld. > > > > I was getting huge numbers of ssh attempts per day from a few specific > > ip blocks. > > If you can control the ssh clients, switch your port number to a > non-standard > port. Pick one in /etc/services that does not seem to be allocated. > Then change > "Port" in ssh_config and sshd_config; If other clients are being used > (like Putty), > it is easy to change it there. > > We used to get at least 50 probes per day on port 22. Now we get zero. > I used this technique for a number of years - then it got leaked to the script kiddies the port that was used. We don't have anything particularly valuable that they were looking for (I don't think!), but there are lists of subnets & ports out there that the kiddies use so once one found it, the flood gates opened. SSH is now protected behind a VPN. It's a valid thing to do and makes things much saner, but don't assume it is a forever solution and don't use it as an excuse to reduce other protections you may have. P. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] firewall questions
On 2020-06-21 15:33, Chuck Campbell wrote: I'm running Centos 7.8.2003, with firewalld. I was getting huge numbers of ssh attempts per day from a few specific ip blocks. If you can control the ssh clients, switch your port number to a non-standard port. Pick one in /etc/services that does not seem to be allocated. Then change "Port" in ssh_config and sshd_config; If other clients are being used (like Putty), it is easy to change it there. We used to get at least 50 probes per day on port 22. Now we get zero. Todd Merriman Software Toolz, Inc. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] firewall questions
On Sun, 2020-06-21 at 14:33 -0500, Chuck Campbell wrote: > I'm running Centos 7.8.2003, with firewalld. > > I was getting huge numbers of ssh attempts per day from a few specific > ip blocks. > > The offenders are 45.0.0.0/24, 49.0.0.0/24, 51.0.0.0/24, 111.0.0.0/24 > and 118.0.0.0/24, and they amounted to a multiple thousands of attempts > per day. It seems oddly coincidental that they are all x.0.0.y addresses - the netblocks they belong to are all much bigger than /24. I can understand getting attacks from a range of IPs from an ISP or the like, but the 51.0.0.0/24 is part of a UK government network and I think they would be all over it if a range of their network was being used for naughty purposes. > > I did some more research, and decided to use a few rich rules to block > these attempts. I currently have these in place: > > #firewall-cmd --list-all > public (active) >target: default >icmp-block-inversion: no >interfaces: p3p1 >sources: >services: dhcpv6-client ftp http https imap imaps pop3 pop3s > smtp-submission smtps ssh >ports: 110/tcp 995/tcp 143/tcp 993/tcp 25/tcp 21/tcp >protocols: >masquerade: no >forward-ports: >source-ports: >icmp-blocks: >rich rules: > rule family="ipv4" source address="49.0.0.0/24" reject > rule family="ipv4" source address="51.0.0.0/24" reject > rule family="ipv4" source address="111.0.0.0/24" reject Is that the correct interface referred to in the zone? Can you see the rich rules implemented properly in the output of 'iptables -L'? (They should be in the chain IN_public_deny.) > > But I still get hundreds of attempts reported in my fail2ban logs from > these ip blocks. How is it that the rich rules don't drop these packets > before pam/ssh/fail2ban ever get to see them? Is fail2ban stopping the individual hosts? Do you have the recidive rule enabled to permaban them? Do you get legitimate SSH connections from anywhere? Can you remove the ssh service and add rich rules to allow certain hosts or netblocks to connect via port 22? Finally, do you have a network firewall that can be used to block the connections? > There must be some precedence in the firewalling I don't understand. Yes, there is a precedence, but it should be working in your favour - the chain 'IN_public' contains the public inbound chain and it should contain: # iptables -L IN_public Chain IN_public (2 references) target prot opt source destination IN_public_log all -- anywhere anywhere IN_public_deny all -- anywhere anywhere IN_public_allow all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere So it should be denying packets before the allowing them (and the IN_public_allow chain is what contains your ssh service definition). P. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] php 5.6 on CentOS 6
On 6/21/20 1:36 PM, H wrote: On 06/21/2020 02:34 PM, Alexander Dalloz wrote: Am 21.06.2020 um 20:30 schrieb H: I am in the process of moving various apps and data off a CentOS 6 server to a new server running CentOS 7. As part of the migration process I need to upgrade an app and corresponding data files which requires php 5.6. I do have php 5.5 (and 5.4) installed since earlier but now tried to install php 5.6 from SCL which failed. This is the package I tried: https://www.softwarecollections.org/en/scls/rhscl/rh-php56/ but the error message is that there is no package 5.6. Is this correct and what would the recommended procedure then be since I do need 5.6 for this. Use Remi's collection or something else? I was hoping SCL would have it since it is well-tried and easy to sandbox on the computer. Thank you. H PHP 5.6 is EOL. https://www.php.net/supported-versions.php Why would a project like SCL spend any efford on patching that old PHP release? Everyone using PHP is happy to get a current release. If your application insists on using 5.6 then move on and look for a different application. Alexander That was not helpful. I gave the rationale in my e-mail message. This my reply is not intended for the OP, as he stated he will not listen about End Of Life of of PHP 5. Just in case anybody comes across this thread, please read what is written on the page referred to by Alexander Dalloz: >> PHP 5.6 is EOL. https://www.php.net/supported-versions.php This in plain English language says that php 5 is not supported by vendor since Jan 1 2019, i.e. almost a year a a half now. This means that PHP development team does not release security patches, and even though RedHat "backports" patches to older versions, difference in internals between PHP version 5 and version 7 is quite significant, so you should not assume that even if RedHat team still backports security patches for issues discovered in version 7, you are safe: there may be still be issues in version 5 which by no means are discovered by anyone. This boils down to one thing. If you still have anything using PHP version 5.[any] you should migrate this to PHP version at least 7.2. You ideally should have done that before Jan. 1, 2019. I hope, this helps somebody. By no means I meant to question the brilliant job RedHat does backporting (taking my hat off and bowing to RedHat here). However, as I said, there may be bugs in PHP 5 that will not be relevant to PHP 7, hence there is nothing to backport to fix them. Valeri -- Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] firewall questions
On Sun, Jun 21, 2020 at 12:33 PM Chuck Campbell wrote: > I'm running Centos 7.8.2003, with firewalld. > > I was getting huge numbers of ssh attempts per day from a few specific > ip blocks. > > The offenders are 45.0.0.0/24, 49.0.0.0/24, 51.0.0.0/24, 111.0.0.0/24 > and 118.0.0.0/24, > so just 45.0.0.0 through 45.0.0.255 and not other 45.x.y blocks ? ditto your other networks?sure you didn't mean /8 or another sized subnet on there? doing some whois, the actual 45.0.0.0 block has a netmask of /15, which is 45.0.0.0 through 45.1.255.255, and belongs to Interop, the IT trade show. 45.2.0.0/16 belongs to Frontier Networks in Ontario, CA 45.3.0.0/19 belongs to Start Cable in Ontario 45.3.32.0/19 belongs to someone in Los Vegas. 45.3.64.0/18 belongs to Virginia Polytechnic 45.3.128.0/17 belongs to Charter Cable (formerly Bright House Networks) 45.4.0.0/14 is LANIC, and further diced into a multitude of Latin America networks. 45.8.0.0/13 is RIPE, and diced into various european networks. etc etc etc. anyways, I didn't see your rules explicitly blocking 22/tcp, which is ssh... -- -john r pierce recycling used bits in santa cruz ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] php 5.6 on CentOS 6
On 06/21/2020 03:15 PM, Michael Schumacher wrote: > H, > >> I am in the process of moving various apps and data off a CentOS 6 >> server to a new server running CentOS 7. As part of the migration >> process I need to upgrade an app and corresponding data files which >> requires php 5.6. [... ]Is this correct and what would the >> recommended procedure then be since I do need 5.6 for this. Use >> Remi's collection or something else? I was hoping SCL would have it >> since it is well-tried and easy to sandbox on the computer. > Remi has been working very nicely every time I needed to install a > non-standard version. There is still a 5.6 version for > CentOS 7 available. > > best regards > --- > Michael Schumacher > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos Thank you, I need it for CentOS 6 though. But, I have figured out another approach - moving it to the new server and doing the database upgrade and migration there. Since I already have php 7 on that machine, there should not be any problems. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] firewall questions
I'm running Centos 7.8.2003, with firewalld. I was getting huge numbers of ssh attempts per day from a few specific ip blocks. The offenders are 45.0.0.0/24, 49.0.0.0/24, 51.0.0.0/24, 111.0.0.0/24 and 118.0.0.0/24, and they amounted to a multiple thousands of attempts per day. I installed and configured fail2ban, but still saw a lot of attempts in the logs, and the ipset created was filling up. I did some more research, and decided to use a few rich rules to block these attempts. I currently have these in place: #firewall-cmd --list-all public (active) target: default icmp-block-inversion: no interfaces: p3p1 sources: services: dhcpv6-client ftp http https imap imaps pop3 pop3s smtp-submission smtps ssh ports: 110/tcp 995/tcp 143/tcp 993/tcp 25/tcp 21/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family="ipv4" source address="49.0.0.0/24" reject rule family="ipv4" source address="51.0.0.0/24" reject rule family="ipv4" source address="111.0.0.0/24" reject But I still get hundreds of attempts reported in my fail2ban logs from these ip blocks. How is it that the rich rules don't drop these packets before pam/ssh/fail2ban ever get to see them? There must be some precedence in the firewalling I don't understand. -chuck -- ACCEL Services, Inc.| Specialists in Gravity, Magnetics | (713)993-0671 ph. | and Integrated Interpretation | (713)993-0608 fax 448 W. 19th St. #325|Since 1992 | (713)306-5794 cell Houston, TX, 77008 | Chuck Campbell | campb...@accelinc.com | President & Senior Geoscientist | "Integration means more than having all the maps at the same scale!" ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] php 5.6 on CentOS 6
H, > I am in the process of moving various apps and data off a CentOS 6 > server to a new server running CentOS 7. As part of the migration > process I need to upgrade an app and corresponding data files which > requires php 5.6. [... ]Is this correct and what would the > recommended procedure then be since I do need 5.6 for this. Use > Remi's collection or something else? I was hoping SCL would have it > since it is well-tried and easy to sandbox on the computer. Remi has been working very nicely every time I needed to install a non-standard version. There is still a 5.6 version for CentOS 7 available. best regards --- Michael Schumacher ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Blog article about the state of CentOS
On 22/06/20 7:03 am, John Pierce wrote: On Sun, Jun 21, 2020 at 2:01 AM Simon Matter via CentOS wrote: On 21/06/20 1:23 pm, John Pierce wrote: but the build process should be the same, no?I can't believe RH would use a completely different build process for the release than for the beta/development stuff. The packages still have to be built as a whole, they need to go through QA testing, isos need to be built and tested. The only thing that I can think of that Stream benefits this process is to help Red Hat find the odd bug here and there before their final release (after which CentOS still has to do everything listed above). As I understand it the whole full build and QA and whatever may still be done again. The big difference is that the whole work of how to build and setting up the build infrastructure has already been done and is known and tested. So the complete build is going quite fast and the big delays are a thing of the past. If it's going to be like that it sounds very good. exactly, that was my point.I remember 8.0 was very delayed by how much harder and different the build process was. That work was completed in the build of 8.0 and to a smaller extent 8.1. Stream doesn't really add anything here. Peter ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Blog article about the state of CentOS
On Sun, Jun 21, 2020 at 2:01 AM Simon Matter via CentOS wrote: > > On 21/06/20 1:23 pm, John Pierce wrote: > >> but the build process should be the same, no?I can't believe RH > >> would > >> use a completely different build process for the release than for the > >> beta/development stuff. > > > > The packages still have to be built as a whole, they need to go through > > QA testing, isos need to be built and tested. The only thing that I can > > think of that Stream benefits this process is to help Red Hat find the > > odd bug here and there before their final release (after which CentOS > > still has to do everything listed above). > > As I understand it the whole full build and QA and whatever may still be > done again. The big difference is that the whole work of how to build and > setting up the build infrastructure has already been done and is known and > tested. So the complete build is going quite fast and the big delays are a > thing of the past. > > If it's going to be like that it sounds very good. > > exactly, that was my point.I remember 8.0 was very delayed by how much harder and different the build process was. -- -john r pierce recycling used bits in santa cruz ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] php 5.6 on CentOS 6
On 06/21/2020 02:34 PM, Alexander Dalloz wrote: > Am 21.06.2020 um 20:30 schrieb H: >> I am in the process of moving various apps and data off a CentOS 6 server to >> a new server running CentOS 7. As part of the migration process I need to >> upgrade an app and corresponding data files which requires php 5.6. I do >> have php 5.5 (and 5.4) installed since earlier but now tried to install php >> 5.6 from SCL which failed. >> >> This is the package I tried: >> >> https://www.softwarecollections.org/en/scls/rhscl/rh-php56/ >> >> but the error message is that there is no package 5.6. Is this correct and >> what would the recommended procedure then be since I do need 5.6 for this. >> Use Remi's collection or something else? I was hoping SCL would have it >> since it is well-tried and easy to sandbox on the computer. >> >> Thank you. >> >> H > > PHP 5.6 is EOL. https://www.php.net/supported-versions.php > > Why would a project like SCL spend any efford on patching that old PHP > release? Everyone using PHP is happy to get a current release. If your > application insists on using 5.6 then move on and look for a different > application. > > Alexander > > > > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos That was not helpful. I gave the rationale in my e-mail message. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] php 5.6 on CentOS 6
Am 21.06.2020 um 20:30 schrieb H: I am in the process of moving various apps and data off a CentOS 6 server to a new server running CentOS 7. As part of the migration process I need to upgrade an app and corresponding data files which requires php 5.6. I do have php 5.5 (and 5.4) installed since earlier but now tried to install php 5.6 from SCL which failed. This is the package I tried: https://www.softwarecollections.org/en/scls/rhscl/rh-php56/ but the error message is that there is no package 5.6. Is this correct and what would the recommended procedure then be since I do need 5.6 for this. Use Remi's collection or something else? I was hoping SCL would have it since it is well-tried and easy to sandbox on the computer. Thank you. H PHP 5.6 is EOL. https://www.php.net/supported-versions.php Why would a project like SCL spend any efford on patching that old PHP release? Everyone using PHP is happy to get a current release. If your application insists on using 5.6 then move on and look for a different application. Alexander ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] php 5.6 on CentOS 6
I am in the process of moving various apps and data off a CentOS 6 server to a new server running CentOS 7. As part of the migration process I need to upgrade an app and corresponding data files which requires php 5.6. I do have php 5.5 (and 5.4) installed since earlier but now tried to install php 5.6 from SCL which failed. This is the package I tried: https://www.softwarecollections.org/en/scls/rhscl/rh-php56/ but the error message is that there is no package 5.6. Is this correct and what would the recommended procedure then be since I do need 5.6 for this. Use Remi's collection or something else? I was hoping SCL would have it since it is well-tried and easy to sandbox on the computer. Thank you. H ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] About support for AMD ROME CPUs
Am 21.06.2020 um 17:35 schrieb 肖正刚: Hi, all We use AMD Rome CPUs, like EPYC 7452. RHEL said that RHEL 7.6.6 began to support these cpus(detials: https://access.redhat.com/support/policy/amd) , but we found that CentOS7.6 with kernel 3.10.0-957.21.3.el7.x86_64 also works fine. So, my questions are: 1) Is there any place that i can find the cpu support info? 2) Dose the kernel 3.10.0-957.21.3.el7.x86_64 from CentOS7.6 already contains changes made by kernel 3.10.0-957.27.2.el7 from RHEL7.6? 3) Does the kernel update has a release note or something like that and where to find ? Any suggestions will help ! Thanks Why do you care for an obsoleted minor release? Alexander ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] About support for AMD ROME CPUs
Hi, all We use AMD Rome CPUs, like EPYC 7452. RHEL said that RHEL 7.6.6 began to support these cpus(detials: https://access.redhat.com/support/policy/amd) , but we found that CentOS7.6 with kernel 3.10.0-957.21.3.el7.x86_64 also works fine. So, my questions are: 1) Is there any place that i can find the cpu support info? 2) Dose the kernel 3.10.0-957.21.3.el7.x86_64 from CentOS7.6 already contains changes made by kernel 3.10.0-957.27.2.el7 from RHEL7.6? 3) Does the kernel update has a release note or something like that and where to find ? Any suggestions will help ! Thanks ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Blog article about the state of CentOS
> On 21/06/20 1:23 pm, John Pierce wrote: >> but the build process should be the same, no?I can't believe RH >> would >> use a completely different build process for the release than for the >> beta/development stuff. > > The packages still have to be built as a whole, they need to go through > QA testing, isos need to be built and tested. The only thing that I can > think of that Stream benefits this process is to help Red Hat find the > odd bug here and there before their final release (after which CentOS > still has to do everything listed above). As I understand it the whole full build and QA and whatever may still be done again. The big difference is that the whole work of how to build and setting up the build infrastructure has already been done and is known and tested. So the complete build is going quite fast and the big delays are a thing of the past. If it's going to be like that it sounds very good. Regards, Simon ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Blog article about the state of CentOS
Il 21/06/20 03:28, Peter ha scritto: On 21/06/20 1:23 pm, John Pierce wrote: but the build process should be the same, no? I can't believe RH would use a completely different build process for the release than for the beta/development stuff. The packages still have to be built as a whole, they need to go through QA testing, isos need to be built and tested. The only thing that I can think of that Stream benefits this process is to help Red Hat find the odd bug here and there before their final release (after which CentOS still has to do everything listed above). Peter ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos I have a question. Why CentOS Stream is needed and what problem it solves? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
