Elasticsearch end-of-life in Debian Stable | Hacker News Reader

Elasticsearch end-of-life in Debian Stable

lists.debian.org

92 pointsRovanion28 comments

Elasticsearch has provided their own package repositories since December 2013.

https://www.elastic.co/blog/apt-and-yum-repositories

It's not a substitute to distribution-maintained packages. With no security support, you'll have to track and upgrade to the latest version. In contrast with other software, you'll have to upgrade your ES cluster (and potentially apply specific upgrade steps) several times a year.

I wasn't asserting anything here, just pointing out that there has been an alternative for almost 2 years.

It looks like ES separates repos by version[0], if that helps at all.

[0] https://www.elastic.co/guide/en/elasticsearch/reference/mast...

Seems like Debian is getting more aggressive on EOL'ing specific packages' security support, and/or upgrading to new upstream releases in the stable distro, lately. There's been version bumps on mysql, php, openjdk and I think virtualbox.

At least we're getting security support(1), but it's a little concerning that more and more upstream vendors seem to leave long-term distros in the dust :-/ Is this a new development? I can't remember similar EOL announcements even just a year ago. Although better to actually announce this than letting packages linger unattended/unannounced...

(1) except php security support in wheezy is also already EOL'ed, before the usual wheezy EOL.

I feel like Debian has maybe finally cottoned onto the idea that it only really makes sense to do "transparently apply security upgrades"-style LTS support for packages that are actual OS infrastructure, because people are increasingly vendoring/containerizing anything that affects whether their app works.

In other words (presuming containerization): Debian LTS is the thing you install a Docker daemon onto and then forget about. But Debian LTS is obviously not for use as a container base-image (container-images don't auto-upgrade; and they can be QAed on each app release to ensure the app works with ABI changes of deps.)

Given those two facts, LTS support these days really only has to apply to things that will be run as part of the (from a developer's perspective) black-box abstraction that is "the OS", rather than considered a part of the "service and its dependencies" slug which gets versioned and deployed by the service-owner.

> I feel like Debian has maybe finally cottoned onto the idea that it only really makes sense to do "transparently apply security upgrades"-style LTS support for packages that are actual OS infrastructure, because people are increasingly vendoring/containerizing anything that affects whether their app works.

Or, for that matter, since Elasticsearch is written in Java, most Java developers just use Maven to pull in dependencies and don't even bother using the OS package manager.

I don't think the vast majority of us know how to.

Except - everyone will consider the docker package from Debian LTS too old for any "real" use and will prefer to do `curl ...|bash` dance to install docker, and it will be happy to include statically linked/bundled dependencies.

The modern Linux distribution (the one everybody wants to use) is something which has curl and bash, and can execute ELF binaries.

While Docker (and containers) are on fire at the moment, they're not the only game in town.

I hope you don't forget about doing security updates to Debian LTS installs.

Also, LTS probably has Linux kernels that are far too old.

Hm, I think that the lifetime of the LTS of debian or centos are just too long for some projects, and I can only partly blame the projects.

Backporting fixes into a 5 or 10 year old version of the software isn't fun. Or, for example you could not port to python 3 fully and drop python 2 if you wanted to support centos 7 easily.

It's messy, but I'd rather support removing the packages and probably even languages or python packages from the distros repos so you're geared towards effort immediately, instead of installing elasticsearch and then ending up vulnerable.

Elasticsearch 1.0.0 was released less than 2 years ago. A project with more than 100 M$ of funding may be able to maintain stable branches for users who cannot cope with the non-trivial upgrades to more recent versions.

People want LTS systems - it's why LTS has become a thing in recent years. It's not Debian and Centos forcing it on the community, it's the community asking for it.

For someone who's not terribly familiar with Debian's packaging system and policies, can someone explain this? Is it saying you'll no longer be able to type

`apt-get install elasticsearch`

in future Debian releases? Or is this something else?

this is kinda correct, you won't be able to get it like that out of the box anymore in jessie stable, but you will be able to get it in unstable or by adding back ports to your system.

they think it's too insecure to include in stable.

It's too time consuming to figure out which patches to apply to be able to maintain it rather in case any security issues pop up

Not so much that it's "insecure" in general; more that upstream has made it infeasible for Debian to provide backported security patches for a stable version.

I'm not sure there's a difference in practice.

Sure it's not that there are known problems, but security isn't a thing you have or don't have; it's a process. If your process for identifying and fixing security flaws is broken, that's insecure.

Upstream is patching security flaws just fine. The problem is that you can't get the security fixes alone; they only come along with version updates, which Debian stable doesn't want.

I understand this; I'm saying that a security process that ignores users who value stability over the latest hotness is broken for all use cases I actually care about.

> you won't be able to get it like that out of the box anymore in jessie stable

Yes you will, it's just an old version without security updates.

> but you will be able to get it in unstable

No you won't, Stretch is the current unstable and elasticsearch is going to be removed from it.

stretch is the current testing and elasticsearch is going to be removed from it.

elasticsearch will continue to remain in unstable

Right, my mistake! I'm even running Strech and named my laptop 'testing'. I mixed it up.

The situation is now like this:

* In Debian Jessie, you can still install the Debian Elasticsearch package, but it will not receive security updates any longer.

* In future releases of Debian, this package will not be available in the main repo, but will still be available in the unstable or jessie-backports repos.

* Elasticsearch (the company) maintains its own Apt repositories where they will provide updated versions according to their support policies. If you add this repository to your Debian based systems you can install the (supported) Elasticsearch package with "apt-get install elasticsearch".

It is my opinion that you should not deploy the Debian ES package in a production setting. Use the vendor repo and save yourself a headache.

Vendor packages are rarely properly built, so this is a large no-no for Elasticsearch.

I don't necessarily agree with this statement, but I suppose it depends on the vendor huh.

For what it's worth, I am currently running off the official packages at moderate scale (~30 machines all together) and have not yet had an issue with it, though it's certainly possible that one will arise and I will thereafter curse Elasticsearch forever.

In this particular case though, security updates are critical, so what other choice is there unless you want to package your own?

The redhat/fedora repository versions of ES are so badly broken that they are a hazzard. It would be a service for redhat to pull them too.

Lintian says:

    E: elasticsearch: file-in-usr-marked-as-conffile usr/lib/systemd/system/elasticsearch.service
    E: elasticsearch: description-starts-with-package-name
    W: elasticsearch: description-too-long
    E: elasticsearch: extended-description-is-empty
    W: elasticsearch: non-standard-dir-perm etc/elasticsearch/ 0750 != 0755
    W: elasticsearch: executable-is-not-world-readable etc/elasticsearch/elasticsearch.yml 0750
    W: elasticsearch: executable-is-not-world-readable etc/elasticsearch/logging.yml 0750
    W: elasticsearch: non-standard-dir-perm etc/elasticsearch/scripts/ 0750 != 0755
    E: elasticsearch: dir-or-file-in-var-run var/run/elasticsearch/
    E: elasticsearch: postrm-contains-additional-updaterc.d-calls etc/init.d/elasticsearch
    W: elasticsearch: script-in-etc-init.d-not-registered-via-update-rc.d etc/init.d/elasticsearch
    W: elasticsearch: executable-not-elf-or-script etc/elasticsearch/elasticsearch.yml
    W: elasticsearch: executable-not-elf-or-script etc/elasticsearch/logging.yml
    W: elasticsearch: maintainer-script-calls-systemctl postinst:82
    W: elasticsearch: maintainer-script-calls-systemctl postrm:72
    W: elasticsearch: maintainer-script-calls-systemctl prerm:51

Doesn't look too bad, I'd want to fix the permissions but it's not the worst thing I've seen

Reply on news.ycombinator.com