BUG: Can't edit the allowed networks for Manager login about asterisk-hass-addons

[netsoft-ruidias]

@felipecrs just did.
I'll let you know the results as soon as I run some tests.
Thanks

[OnFreund]

I can confirm it's fixed (as well as the friendly_name instead of id fix)

[felipecrs]

Just place the file at /config/asterisk/custom/manager.conf, which will always have precedence.

https://github.com/TECH7Fox/asterisk-hass-addons/blob/main/asterisk/DOCS.md#configuring-asterisk

[netsoft-ruidias]

@felipecrs that's exactly what I did, maybe it wasn't clear.
By placing at /config/asterisk/custom/manager.conf the file is rewritten whenever the container is restarted.

[felipecrs]

I see. This feature was introduced in v3:

• You can now override/customize any Asterisk files (previously, the auto-generated Asterisk files could not be overriden).

https://github.com/TECH7Fox/asterisk-hass-addons/blob/main/asterisk/CHANGELOG.md#300

I'll try to reproduce it later.

[felipecrs]

Code_fOd3ECAr19.mp4

It's working fine for me. The add-on may take a few seconds after initialization to properly replace the file.

[netsoft-ruidias]

Thanks @felipecrs , I learned something new today...

1. I'm using docker-compose to initialize all my containers and services (I have a cluster);
2. If I use docker-compose down and then docker-compose up -d then everything works as expected and the document is not changed back to defaults;
3. But I was using docker-compose restart asterisk and in this case the file IS ACTUALLY rewritten with the default.

What I didn't know, and learned today, is that down+up commands works differently than restart, in docker.

I was using restart for convenience, because as I was adjusting the asterisk settings, so I wanted to restart only the Asterisk container with the new values, but without necessarily having to shut down my entire cluster, which is what happens with "down".

Here's a note for the future, if you're having the same problem, don't use docker-compose restart [...]

However, I will not close this thread (I leave that to the owner's discretion) as I believe there is room for improvement
cc: @TECH7Fox

[felipecrs]

I see. This is actually normal for this image. We use s6-overlay and the initialization scripts are executed as part of cont-init.d. cont-init.d only runs once per container, and that's why restart doesn't trigger it.

This is completely fine for add-on users, because when you click Restart, Supervisor would in fact destroy the container and create another.

And yeah, it would not hurt having this explained in the documentation.

[felipecrs]

I'm closing this for now, but PRs to improve documentation are always welcome.

[felipecrs]

by @netsoft-ruidias at #310:

I'm reopening this issue again (I can't reopen the original) because I have news and there is actually a BUG that must be fixed.

Note

For more context on what's going on, take a look at the original issue: #309

1. If I use docker-compose down and then docker-compose up -d then everything works as expected and the file is not changed back to defaults;
2. If I use docker-compose restart the file IS ACTUALLY rewritten with the default values, losing all customizations;
3. If I have a power outage, when the container starts, the file IS ACTUALLY rewritten with the default values, losing all customizations.

✔️ The first point is (obviously) not a problem because it is the expected behavior ✖️ The second point is a problem but there is a workaround, don't run that command ❌ The third point is a MAJOR problem and happens because docker compose is a service that starts at machine startup, and the container definition declares restart: unless-stopped

For context, this is my docker-compose yaml:

version: '3.9'
services:
  (...)other services(...)

  asterisk:
    container_name: asterisk
    image: ghcr.io/tech7fox/asterisk-hass-addon:main
    build:
      context: ./asterisk
    tty: true
    network_mode: host
    environment:
      TZ: 'Europe/Lisbon'
      # Required to get the list of persons from Home Assistant
      HA_TOKEN: "--REDACTED--"
      HA_URL: 'https://xxxx.xxx.com'
    dns:
      - 192.168.1.2
      - 8.8.8.8
      - 8.8.4.4
    volumes:
      - /srv/homeassistant/config/asterisk:/config
      - /srv/homeassistant/config/www/sounds:/media
      - /srv/homeassistant/config/ssl:/ssl
    restart: unless-stopped

  (...)other services(...)

[felipecrs]

I see your point.

A note to myself or anyone else looking into this: it looks like s6-overlay is not executing cont-init.d on container restart, but I don't know if this is intended or not.

[OnFreund]

I'm also seeing this - there's no way to persist my changes to manager.conf (and I'm guessing it also applies to every generated config file, with the exception of the sip configuration files that have separate -custom files).

[felipecrs]

@OnFreund workaround is to delete the container and recreate it rather than just restarting it.

[OnFreund]

Wouldn't deleting the container execute cont-init.d again and overwrite my changes?

[felipecrs]

cont-init.d will never delete /config/asterisk/custom.

[felipecrs]

If you are using docker compose, you can use docker compose up --force-recreate.

[OnFreund]

cont-init.d will never delete /config/asterisk/custom.

It does - that's exactly the problem we're describing here. I think it's because of the links - it's editing the file in /etc/asterisk/, which is a link to the file in /config/asterisk/custom/, thereby overwriting the latter.

[felipecrs]

Not sure if I understood. Deleting a symlink (/etc/asterisk/yourfile) doesn't delete the original file (/config/asterisk/custom/yourfile).

[OnFreund]

It doesn't delete the file, it overwrites it

[felipecrs]

How come? cont-init.d never writes anything to /config/asterisk/custom. It only writes to /config/asterisk/default.

[OnFreund]

How come? cont-init.d never writes anything to /config/asterisk/custom. It only writes to /config/asterisk/default.

It doesn't write to /config/asterisk/default/, it writes to /etc/asterisk/

asterisk-hass-addons/asterisk/rootfs/etc/cont-init.d/asterisk.sh

Line 110 in 9044fba

-out "${etc_asterisk}/manager.conf"

[felipecrs]

Surely it writes to /etc/asterisk, what's the problem with that?

[OnFreund]

That /etc/asterisk/manger.conf is a link to /config/asterisk/custom/manager.conf, so the latter gets overwritten.

[felipecrs]

You mean /etc/asterisk/manger.conf gets overwritten by a link to /config/asterisk/custom/manager.conf?

[OnFreund]

No no.

1. Create /config/asterisk/custom/manager.conf
2. /etc/asterisk/manger.conf gets turned to a link to /config/asterisk/custom/manager.conf
3. Restart the container
4. Tempio executes, trying to overwrite /etc/asterisk/manger.conf
5. Because it's just a link to /config/asterisk/custom/manager.conf, the latter is the file that actually gets overwritten
6. Your changes are lost

[felipecrs]

Oh, you nailed it. That's what's causing this issue then. Thank you, the fix should be simple.

Anyway, for now simply recreate the container rather than restart it. This way, there will be no symlink when tempio executes.

[OnFreund]

Oh, interesting. However, as @netsoft-ruidias mentioned, we can't control this during a reboot or restart of the docker service.
I can avoid calling docker compose restart, but I can't avoid the other scenarios, and the impact is quite severe - you lose all of your custom config.

[OnFreund]

I think a solution could be:

1. The target for tempio is always /config/asterisk/default/
2. /etc/asterisk/manager.conf (and same goes for other files) symlinks to /config/asterisk/custom/manager.conf if it exists, otherwise to /config/asterisk/default/manager.conf

[felipecrs]

I think #323 is a simpler solution.

[OnFreund]

Cool. Hope we can get a release out soon

[felipecrs]

@OnFreund @netsoft-ruidias please try again with 4.2.1.