[arch-dev-public] OpenSearch released to Community

[Justin Kromlinger]

You are of course correct, I've replaced the java-runtime dep with -headless. We can't really do
much about the deprecation message, upstream wants you to use their bundled jdk (and nodejs) to
ease their support system. However this sounds like a security nightmare to me, if I fix a CVE of
the system jdk I expect it to be fixed in all java applications – same for the node packages.

Regarding the elasic packages: I agree. Additionally, there are already elasticsearch-xpack and
kibana-xpack packages in the AUR. Is this something we should announce (on the Arch Announce
mailing list)?

Also, regarding the beats packages – even if we provide beats-oss on a fixed version (which also
won't receive security updates) we will just have a bunch of packages marked as "out-of-date".
Sounds like something for the AUR.

On Sat, 1 Jan 2022 22:07:11 +0100
Pierre Schmitz via arch-dev-public <arch-dev-public at lists.archlinux.org> wrote:

> Thanks a lot for your work! I already managed to migrate to OpenSearch
> without major issues.
> 
> I am a little confused about the java dependency. It requires
> java-runtime instead of java-runtime-headless as Elasticsearch did.
> However on launch I get the following warning: "no-jdk distributions
> that do not bundle a JDK are deprecated and will be removed in a
> future release".
> 
> About Elasticsearch packages: As I understand it, we are not allowed
> to distribute anything newer than version 7.10. This version is no
> longer supported by upstream, right? So we wont get any (security)
> updates. In that case we should rather remvoe these packages and ask
> people to migrate to OpenSearch.
> 
> Greetings,
> 
> Pierre
> 
> On Fri, Dec 31, 2021 at 5:39 PM Justin Kromlinger via arch-dev-public
> <arch-dev-public at lists.archlinux.org> wrote:
> >
> > Hello everyone,
> >
> > As mentioned in a previous mail [0] I've taken some time to bring the ElasticSearch fork
> > OpenSearch to Community [1].
> >
> > I've also added twelve plugin packages, a package for the Kibana fork OpenSearch Dashboards and
> > eight plugin packages for that. Additionally I packaged the opensearch-cli Go binary which
> > currently conflicts with the opensearch package. More plugins will follow, but most of them can
> > be installed manually as well (f.e. ingest-attachment).
> >
> > I've tested both opensearch and opensearch-dashboards with my old node data, but some plugins
> > are untested because I have no experience with them (primarily the security plugin), so I would
> > be happy if someone could test them out.
> >
> > Please note that opensearch doesn't use the upstream-included JRE and opensearch-dashboards
> > doesn't use the upstream-included NodeJS but the ones provided by our repositories. Please keep
> > that in mind for any bug reports towards upstream.
> >
> > This brings up the elastic-question: What should we do with the elasticsearch and kibana
> > packages? If we keep them, someone would need to adopt them - I will orphan them since I won't
> > be using them anymore. Do we want to update them to their newest version with the new Elastic
> > license? Or drop them to the AUR?
> >
> > If we update them to a newer version the beats packages versions are complicated as well. The
> > 7.X versions already need additional configuration in opensearch and versions >=7.13 won't work
> > at all [2]. I would recommend new packages for the beats-oss version 7.12.1 or even 7.10.2 as
> > recommended by opensearch.
> >
> > Euch einen guten Rutsch ins neue Jahr or a Happy New Year,
> > hashworks
> >
> > [0] https://lists.archlinux.org/pipermail/arch-dev-public/2021-August/030496.html
> > [1] https://archlinux.org/packages/?sort=&q=opensearch
> > [2] https://opensearch.org/docs/latest/clients/agents-and-ingestion-tools/index/
> >
> > --
> > hashworks
> >
> > Web        https://hashworks.net
> > Public Key 0x4FE7F4FEAC8EBE67
> 
> 
> 



-- 
hashworks

Web        https://hashworks.net
Public Key 0x4FE7F4FEAC8EBE67
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20220105/2bce852a/attachment.sig>