Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dropping RHEL6, Debian 7 and Ruby 1.8 support #2119

Open
FloorD opened this issue Sep 18, 2018 · 21 comments
Open

Dropping RHEL6, Debian 7 and Ruby 1.8 support #2119

FloorD opened this issue Sep 18, 2018 · 21 comments
Assignees
Milestone

Comments

@FloorD
Copy link
Contributor

@FloorD FloorD commented Sep 18, 2018

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
Copy link

@thbar thbar commented Sep 18, 2018

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
Copy link

@bokmann bokmann commented Sep 18, 2018

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
Copy link

@rfpronk rfpronk commented Sep 18, 2018

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
Copy link

@astuyve astuyve commented Sep 18, 2018

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
Copy link

@Hohlen Hohlen commented Sep 19, 2018

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
Copy link

@VvanGemert VvanGemert commented Sep 19, 2018

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
Copy link

@triskweline triskweline commented Sep 19, 2018

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
Copy link

@bpang bpang commented Sep 19, 2018

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
Copy link

@LeamHall LeamHall commented Sep 20, 2018

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
Copy link

@ragav ragav commented Sep 20, 2018

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
Copy link

@bigtunacan bigtunacan commented Sep 20, 2018

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
Copy link

@rbq rbq commented Sep 21, 2018

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
Copy link

@r-a-c r-a-c commented Sep 21, 2018

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
Copy link

@voxik voxik commented Sep 21, 2018

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
Copy link

@brandondrew brandondrew commented Sep 22, 2018

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

@jamesbrooks
Copy link

@jamesbrooks jamesbrooks commented Oct 3, 2018

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
Copy link

@brandondrew brandondrew commented Oct 3, 2018

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
Copy link

@thbar thbar commented Oct 3, 2018

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
Copy link

@ericfranz ericfranz commented Oct 5, 2018

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.

@CamJN CamJN removed the SupportCentral label Nov 27, 2018
@ericfranz
Copy link

@ericfranz ericfranz commented Jan 9, 2019

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
Copy link
Member

@FooBarWidget FooBarWidget commented Jan 10, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.