4 ms·

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 `a

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

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