Deploying prosody server (many instances issue)

User Support General
1

Hello.
I’ve already deployed a prosody server on the Fedora-41 template. And since all other AppQubes are based on this template, I have a new prosody server instance in each running cube. Of course, this is the result of the systemctl enable --now prosody.service command. My question is how to solve the issue of multiple instances. Should I deactivate the prosody.service service in the Fedora-41 template and create a bash script that will run prosody.service every time the server cube starts? Are there any affordable solutions for this?
Thank you

2

See Qubes service — Qubes OS Documentation

3

Dziękuję :slight_smile:

I tried to follow the documentation. It seems I am not an advanced user. Nothing is working for me.

  1. Under the hood, an enabled service in a VM is signaled by a file in /var/run/qubes-service. This can be used to implement an almost enable/disable per-VM switch controlled by dom0.
  2. Adding support for systemd services is pretty simple. In the VM, create the following file (and directory, if needed): /etc/systemd/system/.service.d/30_qubes.conf. It should contain the following:

[Unit]
ConditionPathExists=/var/run/qubes-service/

So

  1. Should I follow 1. and 2. or maybe 1. and skip 2. or 2. and skip 1. ??
  2. What VM should I make changes in?

When I make changes in AppVM everything disappears after reboot :frowning:

Help :confused:

4

The solution is:

  1. to make changes in a TemplateVM (not a AppVM)
  2. to add line: ConditionPathExists=/var/run/qubes-service/service in a systemd service file located in /usr/lib/systemd/system/service.service. Path that is a result of a command: systemctl status service.
  3. to execute a command: qvm-service --enable AppVM service in dom0 terminal

Hope it helps someone

1 Like
5

You should use systemctl edit unit.service instead, this will create an override file in /etc, so if the systemd service file provided by prosody ever changed, your changes will not be overwritten (or this may prevent the file to be updated by the package update, I don’t remember dpkg behaviour).

1 Like
6

Another solution is to use systemctl mask prosody.service in the template, and in the appvm where you want to run it, from rc.local you can use systemctl unmask prosody.service && systemctl start prosody.service

1 Like
7

Or make separate template just for prosody

1 Like
8

Thank you so much, guys.
However, before I apply your solutions, first I need to learn how to use systemctl.
You know: Don’t trust. Verify :wink:

For a short while I considered creating a separate template but it would be to simple.
My goal is to learn Qubes Os maybe even the hard way :slight_smile:

1 Like
9

The way is to use salt from dom0 to declaratively manage your qubes, so if you have to reinstall or extend your setup, it’s super easy, or if you switch to a newer version of a template it’s almost 0 effort.

10

Thank you for your advice. One day I’ll get there: Salt (management software) — Qubes OS Documentation
I’ve been a Qubes Os user for just a week now.