Support prometheus exporter friendly_json field

[gchamon]

to: @subspacecommunity/subspace-maintainers cc: @subspacecommunity/subspace-maintainers related to: resolves: https://github.com/subspacecommunity/subspace/issues/139

Background

Prometheus wireguard exporter allows for friendly names to be exported along with wireguard specific info. This pull request aims to support the comment that enables the exporter to do that, thus making monitoring subspace with Prometheus easier for SecOps teams.

Changes

• added # friendly_json tag to both client and peer configs
• moved server.conf generation from entrypoint.sh to both routes /profile/add and /profile/delete
• added MutexBash that allows for synchronized bash execution
• to avoid race conditions, the server.conf generation is hidden behind ServerConfig struct, that uses MutexBash to update the server configuration synchronously
• updated the readme with a docker-compose example that enables the prometheus exporter

Testing

• checkout this branch
• use the following docker-compose.yml

  version: "3.3"
  services:
  subspace:
  image: subspace-local
  build: ./subspace
  container_name: subspace
  volumes:
  - ./subspace-data:/data
  restart: always
  environment:
   - SUBSPACE_HTTP_HOST=localhost
   - SUBSPACE_LETSENCRYPT=false
   - SUBSPACE_HTTP_INSECURE=true
   - SUBSPACE_HTTP_ADDR=":80"
   - SUBSPACE_NAMESERVERS=1.1.1.1,8.8.8.8
   - SUBSPACE_LISTENPORT=51820
   - SUBSPACE_IPV4_POOL=10.99.97.0/24
   - SUBSPACE_IPV6_POOL=fd00::10:97:0/64
   - SUBSPACE_DISABLE_DNS=0
   - SUBSPACE_IPV6_NAT_ENABLED=1
  cap_add:
   - NET_ADMIN
  network_mode: "host"
  prometheus_exporter:
  image: mindflavor/prometheus-wireguard-exporter
  container_name: prometheus_exporter
  volumes:
    - ./subspace-data:/data
  restart: always
  cap_add:
    - NET_ADMIN
  network_mode: "host"
  command: "-a -n /data/wireguard/server.conf"

• docker-compose build
• docker-compose up
• login to http://localhost
• create an admin profile
• cat ./subspace-data/wireguard/server.conf. The config file should be update as soon as you create a profile. It should also contain the friendly_json tag with the correct values
• create a client profile and test if the user_type is correctly set to client
• curl http://localhost:9586/metrics should display prometheus metrics with the correct key=value pairs from friendly_json

Next steps

• Provide a way to refresh current peer config files

[agonbar]

I've tested this, some things that may not be perfect:

• On the example on the .md, we could keep a smaller docker-compose.yml example, with the minimum required, and the complete one, with the exporter, to avoid confusion.
• The friendly_json is also being created in the clients .conf files, this is not needed for the exporter.
• The permissions on the ./subspace-data/ gave me a lot of problems, the exporter wouldn´t lauch, the docker-compose wouldn´t restart, etc.
• We need to rebase this from master

[agonbar]

Ok, the rebase is done, I manually changed the permissions on the folder and tested and the rest works perfectly, so just check the othe points and it will be perfect.

Many thanks for all the contributions!

[gchamon]

* On the example on the .md, we could keep a smaller docker-compose.yml example, with the minimum required, and the complete one, with the exporter, to avoid confusion.

* The friendly_json is also being created in the clients .conf files, this is not needed for the exporter.

* The permissions on the ./subspace-data/ gave me a lot of problems, the exporter wouldn´t lauch, the docker-compose wouldn´t restart, etc.

I wonder if maybe setting the volume map on the exporter for read only would preserve the original permissions from subspace

[gchamon]

@agonbar I tested with read only permissions for the exporter and had zero issues. Here is my complete docker-compose.yml file:

version: "3.3"
services:
  subspace:
    image: subspace-local
    build: ./subspace
    container_name: subspace
    volumes:
      - ./subspace-data:/data
      - ./dnsmasq.d:/etc/dnsmasq.d
    restart: always
    environment:
      - SUBSPACE_HTTP_HOST=192.168.0.4
      - SUBSPACE_LETSENCRYPT=false
      - SUBSPACE_HTTP_INSECURE=true
      - SUBSPACE_HTTP_ADDR=":80"
      - SUBSPACE_NAMESERVERS=1.1.1.1,8.8.8.8
      - SUBSPACE_LISTENPORT=51820
      - SUBSPACE_IPV4_POOL=10.99.97.0/24
      - SUBSPACE_IPV6_POOL=fd00::10:97:0/64
      - SUBSPACE_DISABLE_DNS=0
      - SUBSPACE_IPV6_NAT_ENABLED=1
    cap_add:
      - NET_ADMIN
    network_mode: "host"
  prometheus_exporter:
    image: mindflavor/prometheus-wireguard-exporter
    container_name: prometheus_exporter
    volumes:
      - ./subspace-data:/data:ro
    restart: always
    cap_add:
      - NET_ADMIN
    network_mode: "host"
    command: "-a -n /data/wireguard/server.conf"

Can you help me replicate your issue?

EDIT: I think I understand now. You mean to make it so that the entrypoint deals with the permission issues on the data folder? I could do that easily, if my understanding is correct.

---

Also, regarding the readme. I am not sure what I am supposed to change. Should I make the example with the prometheus exporter shorter? Or is it the other way around?

[gchamon]

@agonbar another thing that came to mind. If you are upgrading a running subspace server, newer client configs will be populated with the friendly_json field, but older ones will lack it. We should think of a routine to migrate older configs to newer configs.

However, this behaviour is not exclusive to this PR. Any changes made to the server configs (like IPV6, DNS and so on) will not reflect in the already created client configs.

I think this warrants an issue of its own and shouldn't impact this feature. Do you also share this POV?

[gchamon]

• [ ] On the example on the .md, we could keep a smaller docker-compose.yml example, with the minimum required, and the complete one, with the exporter, to avoid confusion.
• [x] The friendly_json is also being created in the clients .conf files, this is not needed for the exporter.
• [ ] The permissions on the ./subspace-data/ gave me a lot of problems, the exporter wouldn´t lauch, the docker-compose wouldn´t restart, etc.

[sonarcloud[bot]]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

No Coverage information
0.0% Duplication

[gchamon]

Fixed a problem with updating from a long running subspace service. Updating would cause server.conf to be recreated after the wg0 interface is set during startup, causing any peers created before updating to be missed.

To circumvent it, I added the method Sync to the WireguardServerConfig struct that calls wg syncconf with the updated server.conf. This will effectively delegate both the recreation of the wireguard config and refresh of the wg0 interface to subspace.