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.
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.
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.
* 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.
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?
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.
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.
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.
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.
29 comments
[ 3.6 ms ] story [ 71.0 ms ] thread`apt-get install elasticsearch`
in future Debian releases? Or is this something else?
they think it's too insecure to include in stable.
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.
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.
elasticsearch will continue to remain in unstable
* 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.
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?
https://www.elastic.co/blog/apt-and-yum-repositories
It looks like ES separates repos by version[0], if that helps at all.
[0] https://www.elastic.co/guide/en/elasticsearch/reference/mast...
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.
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.
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.
The modern Linux distribution (the one everybody wants to use) is something which has curl and bash, and can execute ELF binaries.
Also, LTS probably has Linux kernels that are far too old.
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.