5 ms·

Elasticsearch end-of-life in Debian Stable

92 points by Rovanion 11y ago

dikaiosune 11y ago
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?
- orik 11y ago
  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.
  - iMerNibor 11y ago
    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
  - duskwuff 11y ago
    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.
    - technomancy 11y ago
      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.
      - duskwuff 11y ago
        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.
        technomancy 11y ago
        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.
  - deleted 11y ago
    [deleted]
  - lucb1e 11y ago
    > 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.
    - chei0aiV 11y ago
      stretch is the current testing and elasticsearch is going to be removed from it. elasticsearch will continue to remain in unstable
      - lucb1e 11y ago
        Right, my mistake! I'm even running Strech and named my laptop 'testing'. I mixed it up.
- pliu 11y ago
  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.
  - dozzie 11y ago
    Vendor packages are rarely properly built, so this is a large no-no for Elasticsearch.
    - pliu 11y ago
      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?
    - thawkins 11y ago
      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.
    - voltagex_ 11y ago
      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
gnoway 11y ago
Elasticsearch has provided their own package repositories since December 2013. https://www.elastic.co/blog/apt-and-yum-repositories https://www.elastic.co/blog/apt-and-yum-repositories
- vbernat 11y ago
  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.
  - gnoway 11y ago
    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/master/setup-repositories.html https://www.elastic.co/guide/en/elasticsearch/reference/mast...
0x0 11y ago
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.
- derefr 11y ago
  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.
  - amyjess 11y ago
    > 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.
    - 11y ago

92 points by Rovanion 11y ago

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?

orik 11y ago
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.
- iMerNibor 11y ago
  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
- duskwuff 11y ago
  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.
  - technomancy 11y ago
    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.
    - duskwuff 11y ago
      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.
      - technomancy 11y ago
        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.
- deleted 11y ago
  [deleted]
- lucb1e 11y ago
  > 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.
  - chei0aiV 11y ago
    stretch is the current testing and elasticsearch is going to be removed from it. elasticsearch will continue to remain in unstable
    - lucb1e 11y ago
      Right, my mistake! I'm even running Strech and named my laptop 'testing'. I mixed it up.
pliu 11y ago
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.
- dozzie 11y ago
  Vendor packages are rarely properly built, so this is a large no-no for Elasticsearch.
  - pliu 11y ago
    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?
  - thawkins 11y ago
    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.
  - voltagex_ 11y ago
    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

gnoway 11y ago

Elasticsearch has provided their own package repositories since December 2013. https://www.elastic.co/blog/apt-and-yum-repositories https://www.elastic.co/blog/apt-and-yum-repositories

vbernat 11y ago
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.
- gnoway 11y ago
  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/master/setup-repositories.html https://www.elastic.co/guide/en/elasticsearch/reference/mast...

0x0 11y ago

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.

derefr 11y ago
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.
- amyjess 11y ago
  > 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.
  - 11y ago