Summary: | koha-common keeps bringing up RabbitMQ even if disabled on purpose | ||
---|---|---|---|
Product: | Koha | Reporter: | Tomás Cohen Arazi (tcohen) <tomascohen> |
Component: | Installation and upgrade (command-line installer) | Assignee: | Bugs List <koha-bugs> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | normal | ||
Priority: | P5 - low | CC: | dcook, tomascohen |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: |
Description
Tomás Cohen Arazi (tcohen)
2025-03-07 19:23:51 UTC
(In reply to Tomás Cohen Arazi (tcohen) from comment #0) > Our current packaging schema is somehow messing with our deployment. > > I have run > > ```shell > systemctl stop rabbitmq-server > systemctl disable rabbitmq-server > ``` > > but after any routine upgrade it gets enabled again. > > I haven't tracked it down but felt it was worth reporting. When you say "any routine upgrade", do you mean an upgrade of rabbitmq-server, koha-common, or any other package? With Tomcat, I had an issue where I wanted to install the software, but it would automatically start itself up at install time, so I had to create a /usr/sbin/policy-rc.d file to explicitly forbid it from starting up automatically via invoke-rc.d. But that was a different scenario. We do the following: debian/koha-common.postinst:rabbitmq-plugins enable rabbitmq_stomp debian/koha-common.postinst:service rabbitmq-server restart Maybe we should be using "invoke-rc.d rabbitmq-server restart" instead there so it's easier to block where necessary. > There's also the situation you cannot install Koha via packages without > requiring rabbitmq, which is also problematic. > > Even if you want to use it, we need more fine-grained control. Take Docker > as an example, in that context you want to run rabbit on a separate > container, or even reuse a single service for many (possibly remote) Koha > instances. We shouldn't be requiring it at all on a default setup. In that case, you can use the "koha-core" package, which just installs the Koha app and its system utilities and client libraries. Docker was one of the things I was thinking of when I first proposed the "koha-core" package. We probably haven't updated koha-common to depend on koha-core because it would cause issues when using "apt-get install koha-common"... (In reply to David Cook from comment #1) > In that case, you can use the "koha-core" package, which just installs the > Koha app and its system utilities and client libraries. > > Docker was one of the things I was thinking of when I first proposed the > "koha-core" package. > > We probably haven't updated koha-common to depend on koha-core because it > would cause issues when using "apt-get install koha-common"... Looking at debian/control again... I'm not 100% sure why we included "rabbitmq-server" in koha-common. Maybe because we needed the "rabbitmq-plugins enable rabbitmq_stomp" and we were considering vhosts at one point. I think we wanted it to "just work". Maybe we should update the docs to something like "apt-get install koha-core apache2 apache2-mpm-itk idzebra-2.0 memcached mysql-server rabbitmq-server" instead of "apt-get install koha-common"? Then we could add notes saying that people can choose to put memcached, mysql-server, rabbitmq-server on a different server? Or drop rabbitmq-server all together if they want? I'm not sure. (Note that I'm open-minded. I wouldn't be opposed to removing "rabbitmq-server" and friends from koha-common and koha-common.postinst. It could actually make life easier in the long-run...) I think since we kind of support a setup where rabbitmq is on a different server or turned off we need to find a way to not turn it on automatically forcing the installation on people. I don't believe having them switch to only use koha-core would work. |