[
https://issues.apache.org/jira/browse/SOLR-15967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485609#comment-17485609
]
Martin Häcker edited comment on SOLR-15967 at 2/2/22, 7:40 AM:
---------------------------------------------------------------
[~sdavids]: That is probably the route I am going to take. However embracing
the docker route for single deployments has some very severe drawbacks:
- I have to set up a process which that ensures security updates to the images
are applied in a time critical manner. That creates a whole new process that I
have to care for, and also learn as the docker image is likely built with a
different linux distribution than what I am used to. I also have to build
monitoring for that and still don't get the same security guarantees that I'm
getting with the linux distro I've chosen - for precisely those reasons.
- Inspecting and debugging it requires me (but especially the people I put this
up for) to know about docker and it's security implications when used on a
server. This is non trivial stuff (compared to just using it in development
with docker compose).
Given those reasons, I'd much rather have a deb/rpm repository to install from
and not have to worry about all of this for simple deployments, server being
down during updates and all. If I want more, the Kubernetes Operator is an
obvious way to scale this and probably the easiest way to do so.
I'd like to think about this from the user perspective: If there is an obvious
and simple way to run solr in a way that means I don't have to learn a lot
about it's deployment and how to keep it up to date, it becomes a heck of a lot
easier to use and implement it into small projects.
I of course do not know about your user base, but I am willing to bet quite a
few of my socks that the majority of installations are not giant clusters, but
instead single servers that add full text search to a small project. Those many
users would really be the one that have a much easier time not getting
themselves owned because they mess up the way they run the docker image and
trip themselves up by miss-applying security updates to the docker image. (Or
not apply them at all because they don't understand the concept).
was (Author: JIRAUSER284534):
~sdavids: That is probably the route I am going to take. However embracing the
docker route for single deployments has some very severe drawbacks:
- I have to set up a process which that ensures security updates to the images
are applied in a time critical manner. That creates a whole new process that I
have to care for, and also learn as the docker image is likely built with a
different linux distribution than what I am used to. I also have to build
monitoring for that and still don't get the same security guarantees that I'm
getting with the linux distro I've chosen - for precisely those reasons.
- Inspecting and debugging it requires me (but especially the people I put this
up for) to know about docker and it's security implications when used on a
server. This is non trivial stuff (compared to just using it in development
with docker compose).
Given those reasons, I'd much rather have a deb/rpm repository to install from
and not have to worry about all of this for simple deployments, server being
down during updates and all. If I want more, the Kubernetes Operator is an
obvious way to scale this and probably the easiest way to do so.
I'd like to think about this from the user perspective: If there is an obvious
and simple way to run solr in a way that means I don't have to learn a lot
about it's deployment and how to keep it up to date, it becomes a heck of a lot
easier to use and implement it into small projects.
I of course do not know about your user base, but I am willing to bet quite a
few of my socks that the majority of installations are not giant clusters, but
instead single servers that add full text search to a small project. Those many
users would really be the one that have a much easier time not getting
themselves owned because they mess up the way they run the docker image and
trip themselves up by miss-applying security updates to the docker image. (Or
not apply them at all because they don't understand the concept).
> Add rpm repo for red hat based distros
> --------------------------------------
>
> Key: SOLR-15967
> URL: https://issues.apache.org/jira/browse/SOLR-15967
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: packages
> Affects Versions: 8.11.1
> Environment: # uname -a
> Linux my.host 3.10.0-1160.53.1.el7.x86_64 #1 SMP Fri Jan 14 13:59:45 UTC 2022
> x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Martin Häcker
> Priority: Major
> Labels: centos, centos7, debian, fedora, ubuntu
> Attachments: Skjermbilde 2022-02-01 kl. 15.17.02.png
>
>
> Hi there,
> it's surprisingly hard to install Solr in a way where I can guarantee to
> automatically get updates, especially security updates in a reliable manner,
> as well as get a documented way to start / run Solr on my distro of choice.
> What I am really looking for is an official rpm repository (and probably a
> deb repo too) that I can add to my package manager and then install a package
> that will give me all the updates I want, as well as starts the database with
> a systemd file that is known good.
> I in particular am looking for a centos 7 repository.
> I think, that this would make installation of Solr so much easier.
> What do you say?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
