Dropping RHEL6, Debian 7 and Ruby 1.8 support

[FloorD]

We consider dropping support in Passenger for RHEL/CentOS 6, Debian 7 and Ruby 1.8. These distributions are very old (in software-years), and it's getting increasingly hard to maintain support. Old distros slow down our development process and thus future improvements.

Dropping support for old operating systems means we'll be able to use C++11, which should simplify our codebase. By dropping Ruby 1.8, we'll be able to upgrade the gems we use during development and testing, and we'll be able to remove various compatibility code.

Older versions of Passenger (that still maintain support) will continue to be available for download, more in a post on our blog: https://blog.phusion.nl/2018/09/18/considering-dropping-rhel6-debian-7-and-ruby-1-8-support/

WDYT? Please let us know in the comments 💬 to this issue! 🙏

[thbar]

Just my own opinion on Ruby - 1.8 EOL'ed more than 4 years ago. I understand why you may have wanted to support it so long (as a type of hosting company in a way), but I honestly think you've done enough. People who are serious about Ruby (even enterprisey ones) must get ready to move forward if not done yet!

[bokmann]

Make it so. By supporting these old versions you are enabling people to avoid security improvements they need. If they are willing to use older versions of this stuff, they should be willing to use older versions of your stuff too. Send the signal... if they choose this path they are on their own.

[rfpronk]

We're still using Debian 7 Wheezy on some of our servers but we do want to get rid of that so don't let us stop you from dropping support for it but let it be a good motivator for us to get the process rolling.
We do of course use newer Ruby versions, even on Wheezy machines so bye bye Ruby 1.8 👋

[astuyve]

While CentOS 6 won't go EOL until 2020, it stopped receiving full releases in May of 2017. RHEL 6.10 was recently released (July 2018), but even still RHEL 7 has been out and supported for quite some time.
I think it's fair to drop support for those systems, given the benefits of supporting less distros.
As for Ruby 1.8, I cannot think of any compelling reason to continue supporting it.

To me it seems that the benefits (faster development, simplified codebase) far outweigh the disadvantages.

[Hohlen]

We're still running Rails 2.3 applications with Ruby 1.8.7 on CentOS release 6.10. Would be bummed if you dropped support, but I totally understand if you feel the need to do such. I guess it's possible we can upgrade to Ruby 2 as per this post:

https://makandracards.com/railslts/47192-ruby-2-3-support

I assume Rails 2.3.18 on Ruby 2.3 would be supported on CentOS 6?

[VvanGemert]

We're also still running one Rails 2.3 application with 1.8.7 on Ubuntu and would really like to keep it running until we've migrated everything to the latest Ruby. I would understand if you dropped support because it's very old tech. We would probably lock passenger version to solve the issue. I wonder how applications are still running 1.8.7 and Rails 2.3..

[triskweline]

When you have an app under active development, it might seem ridiculous that someone depends on Ruby 1.8.

I help run a Rails agency. I can share from my experience that there are a large number of small businesses that had a Rails app developed around 2010 and still run it on Ruby 1.8.7. Today these apps often are barely profitable SaaS services or an internal workflow apps that they hoped to get 10+ years of use of. For such apps there is no active development and upgrading their Ruby or Rails is often equivalent to rewriting or shutting down their app.

In that situation many choose to run 1.8.7 on modern Linux (and Passenger) and just update Rails, or cordon their internal app off the internet to limit exposure. High-impact vulnerabilities are usually found in Linux or Rails, not in Ruby. You can't run arbitrary code or extract the database from an app just because it runs on Ruby 1.8.7. While not ideal, its a compromise to avoid having to rewrite or shut down their service.

In the end, Passenger is your project and the decision is up to you alone. I believe the affected people are not going to comment in a Github thread, and you would be doing them a big favor to keep some version of Passenger on life support that still supports old Rubies.

[bpang]

We have some older apps running in internal environments on 1.8.7, but would not expect updates for passenger for it. CentOS 6, we would appreciate support for, though if push came to shove and we needed to stay current it would just necessitate us migrating some systems to 7.

[LeamHall]

Sorry if this sounds harsh, but Ruby has worked itself out of the enterprise server market. I understand the reasons to stay with a "current" Ruby and don't fault you for that. However, enterprises use servers and provided tools a lot longer than the Ruby "community" provides "support". Dropping support for older software to allow better developer utilization should be fine; you won't lose a large segment of the market that hasn't already been lost.

[ragav]

We run a high traffic app that's split between 1.8.7 and 2.3.1 with an nginx front that routes to one or the other for specific routes. We are slowly migrating this app away from 1.8.7 route by route and we'll probably be fully out of 1.8.7 land in 12 months. We could probably just lock the passenger version down but that wouldn't be ideal. It would be nice to get a clear timeline on when you plan to drop support.

[bigtunacan]

I would think that some level of support in Passenger should continue at least for products that are not considered EOL (For example RHEL 6.10 which will still be supported for about 2 years). The biggest concern at an enterprise level for these things is on the security aspect. So a mixed approach would probably be okay as well; so for example you could continue development on Passenger and no longer support what you see as "legacy" systems, but could continue to provide security patches to the older version(s) of Passenger for these legacy systems that are not yet EOL.

[rbq]

I'm actually surprised that Ruby 1.8 is still fully supported in recent Passenger releases. But well, railslts.com still offers commercial support for Rails 2.3 on 1.8.7, so I guess there are (enterprise) customers out there who just can't upgrade/rewrite and are willing to pay? Maybe you can turn long-term support into a commercial (security-fixes only) offering? And—if that turns out to be a viable solution—hand out free licenses to non-profits, open-source projects, …?

[r-a-c]

Hello,

I know, old users, old apps, old OS, a pain in the ass. But they are in fact still in use. A lot of users use your software in centos6 related OSs for example. You are dropping those users, not that OS. Centos6 dies this next year for example. I would wait until those OS are dead

This is the reason why a lot of projects have a supported 'legacy' version for old OSs.

[voxik]

Just FTR, Ruby 1.8.7 on RHEL6 is supported by Red Hat as long as RHEL6 is supported, so if there is vulnerability discovered, it should be fixed.

And FTR, although RHEL6 might look old, as far as I know, there are probably still more users of RHEL6 then users of RHEL7.

[brandondrew]

My opinion is: please don't waste your time supporting languages and distributions that are dead.

[jamesbrooks]

Drop it. 1.8 was EOL'd a while back now, there's no reason you should reasonably keep supporting it.

There are still one or two internal apps I have running with Passenger+1.8 and I'm happy enough to not update Passenger in those cases, that's on me.

[brandondrew]

Enterprises that are using ancient versions of Ruby on really old distros can surely stand to use slightly old versions of Passenger. If they are not given any incentive to upgrade, they never will. There is no reason the rest of the world should have to be affected by companies that are unwilling to allocate any time toward upgrading.

[thbar]

I'll add that for enterprise clients of mine, in the last 5 years they have become more aware of the risk associated with using EOL software. Seeing that something is going to be unsupported or has been for 2 or 3 years definitely help when you want to incentive a decision-making process.

[ericfranz]

Older versions of Passenger will continue to be available for download. If you need to use older operating systems or older Ruby versions, then you still have the option to use an older Passenger version.

If you do drop support for RHEL6 in Passenger v6, will you still provide the ability to install the latest v5 via rpm i.e. https://www.phusionpassenger.com/library/install/nginx/install/oss/el6/ (and thus have other rpms depend on this)? How long will this be available?

Our NSF funded project https://openondemand.org uses Passenger as part of its proxy stack to provide web interfaces to HPC centers and currently we support installing it on RHEL6/CentOS6 and RHEL7/CentOS7. Across the US our rpms have been installed at over 50 institutions for evaluation or production purposes. About 10% have older systems that are stuck with REHL6/CentOS6. By having access to v5 rpms we can continue to support a version of OnDemand for RHEL6/CentOS6 even after Passenger v6 is released.

[ericfranz]

Just following up on this: https://www.phusionpassenger.com/docs/advanced_guides/install_and_upgrade/standalone/yum_repo.html#supported-distribution-versions says:

Our policy is to support all Red Hat and CentOS releases that still receive full updates by their vendors. The earliest Red Hat and CentOS version we support is version 6.

So to clarify, does that mean the decision for Passenger 6 is to continue to support CentOS6/RHEL6 till CentOS6/RHEL6 till end of life?

[FooBarWidget]

No decision has yet been made on whether we actually drop CentOS/RHEL 6 support. So until further notice, the policy is still to support CentOS/RHEL 6 until end of life.

[CamJN]

Closing since
centOS 6 is EOL https://wiki.centos.org/About/Product
debian 7 is EOL https://wiki.debian.org/LTS
ruby 1.8 is VERY EOL https://www.ruby-lang.org/en/news/2014/07/01/eol-for-1-8-7-and-1-9-2/