Fix the init and set sane logical defaults

[uniquePWD]

I'm trying to run apprise-api via Docker and it should be incredibly simple and yet it's anything but because there's a bunch of behaviours that are hardcoded wrong.

First of all. In the apprise_api/core/settings/__init__.py

Why is the BASE_DIR a bunch of nested functions, you literally have environment variables. Use them.

The same goes for APPRISE_CONFIG_DIR and APPRISE_ATTACH_DIR in making the assumption that apprise is running in the var directory, things become needlessly complicated and break. For all of these, there should be a condition to full back to the var directory, but not the assumption it's in there.

[caronc]

I'm trying to run apprise-api via Docker and it should be incredibly simple and yet it's anything but because there's a bunch of behaviours that are hardcoded wrong.

You're entitled to your opinion. If you want to get support from an open source platform that costs you nothing, you certainly don't have a very nice way of going about it. :confused:

Why is the BASE_DIR a bunch of nested functions

Because the Django launches it's settings during initialization only; __init__.py is started up per worker thread once. The overhead to dynamically determine the root directory of all the internal files associated with the module certainly won't interfere with anything you're building/developing. It's incredibly useful for development and testing purposes. Simply calling django runserver and all of the attachment, config and working directories the tool relies on run relative to your environment. A production environment may experience an additional 0.000003 second initialiation/startup delay which I do not feel warrants concern.

... you literally have environment variables. Use them

The same goes for APPRISE_CONFIG_DIR and APPRISE_ATTACH_DIR in making the assumption that apprise is running in the var directory, things become needlessly complicated and break. For all of these, there should be a condition to full back to the var directory, but not the assumption it's in there.

Have a look at the Dockerfile shipped with the Apprise API and see that I am using the environment variables. It would more appear that you may be using another custom build, or are attempting to construct your own Dockerfile prior to reading the documentation or look at the provided example.

Reguardless, please submit a PR to how you feel the system should behave. I welcome anything you can provide to improve the overall architecture and design. I look forward to merging your ideas.

[uniquePWD]

You're right, my tone wasn't polite enough nor conducive in requesting help and that's not good enough from me, I'm sorry about that. I took my frustration out on this project and subsequently you and you didn't deserve that.

So just to be clear. I attempted to run the Linux Server version, it didn't work. Then I attempted to run your version and encountered problems still.

Looking at the Dockerfile and comparing it to that of other projects I'm running, I believe that the problems are created by those last ten lines.

I'm confused because you set the environment variables in lines 9-14 and then never use said variables?

[caronc]

Just for test purposes, try this and see if it works for you:

# Let's clone the repo in question
git clone git@github.com:caronc/apprise-api.git test-apprise

# let's change into it
cd test-apprise

# Let's build our container (and label it apprise-api:edge)
docker build -t apprise-api:edge .

# Now let's create some directories we can cross reference inside the container:
mkdir -p {config,attach}

# And deploy! :)
docker run -d \
  --name=apprise-api \
  -p 8000:8000 \
  -v ./config:/config \
  -v ./attach:/attach \
  --restart unless-stopped \
  apprise-api:edge

Now visit http://localhost:8000 and see how it looks

In the above example it mapped the config, and attach directories are located locally to you right out of the gate.

Now today (i intend to fix this); there cna be permission issues. For the purpose of just getting you working (for now), just type chmod 777 attach config and we can go more into permissions after you get up and running.

[uniquePWD]

So I had some problems with your commands and so ended up tweaking them

# Let's clone the repo in question
git clone https://github.com/caronc/apprise-api.git test-apprise

# let's change into it
cd test-apprise

# Let's build our container (and label it apprise-api:edge)
docker build -t apprise-api:edge .

# Now let's create some directories we can cross reference inside the container:
mkdir -p {config,attach}

# And deploy! :)
docker run -d \
  --name=apprise-api \
  -p 7978:8000 \
  -v ./config:/config \
  -v ./attach:/attach \
  --restart unless-stopped \
  apprise-api:edge

Sadly, I'm still getting CONFIG_PERMISSION_ISSUE,ATTACH_PERMISSION_ISSUE at http://localhost:7978

[caronc]

You're getting closer which is great.

The error is related to the container not being able to write to your configuration directory.

Perhaps if the chmod didn't work (this is surprising), you're running selinux? The following will turn it off it it is. setenforce 0

[uniquePWD]

Is there another way to test? I'm not comfortable disabling my selinux.

[caronc]

You need to leverage semanage to grant access to docker so that it has permission to write in the directories you've mapped into external volumes.

Different (Linux) distributions may be set up (for SELinux) to allow Docker writing to specific directories out of the box. My knowledge with SELinux is limited; but that's likely your issue right now.

You can look at /var/log/audit and get the actions that SELinux is blocking. There are tools to generate custom policies from that

[uniquePWD]

That doesn't sound right. Other things are managing to write to their directories just fine. Currently I'm running

Duplicati Gotify Heimdall Home Assistant Immich Jellyfin Kavita Miniflux Mosquitto Navidrome N8N NextCloud Paperless-NGX Portainer Zigbee2MQTT

And more. All write to their directories just fine.

[caronc]

You listed open sourced containers that get a lot of funding. I am not at the tier (no funding; just a fun hobby). They may be added into the SELinux polices.

Are you exposing any volumes with them? You could try exposing the /config path in one of those areas and maybe you'll get around your SELinux block. If the chmod 777 didn't work, that's the only other blocker.

Again, have a look at your /var/log/audit and see if there are entries being generated with the current setup to confirm

[caronc]

I did some pretty heavy re-factoring and included some updates relative to what you shared in your PR #197 . But i could not accept your file just due to the changes in the one i submitted today (conflicting with it). Also the additional backslash escaping in your PR \\ is not required. I still really (,really) apprecate you providing it!

I greatly improved the README on the main page of this project, and also added the PUID, and PGID variables which i think may fix your SELinux issue (not sure here though). It should resolve all permission issues for others though as this was one part of the Apprise API that always needed improvement.

[uniquePWD]

I would like to extend a massive thank you. I ran the latest iteration and now the status is saying okay, rather than giving permission errors. Everything seems to be working. Thank you again.

[caronc]

Very glad to hear you're up and running! 🚀

I'll close if off this ticket.