[Config] Add custom config location

[Bockiii]

I assume this is going to cause some discussion but I wanted to present my solution to the problem with mounting local configs for whitelist, config.ini and custom bridges. This should solve all three issues.

What this does:

• Add a script that runs after the container was built
• This script copies bridges, whitelist.txt and config.ini.php files (if existing) to their respective paths in the app folder.
• Then starts the apache process as usual

What this accomplishes:

• If the user mounts the /config folder to a local folder, the user can add whitelist.txt, config.ini.php and additional bridges (following all the same rules as rss-bridge for naming etc) to the config folder or even sub folders for organization. This means, a flat structure works the same as a structure with subfolders.

/mylocalconfigfolder/whitelist.txt
/mylocalconfigfolder/config.ini.php
/mylocalconfigfolder/MyGreatBridge.php
/mylocalconfigfolder/MyOtherGreatBridge.php

will work the same as

/mylocalconfigfolder/config/whitelist/whitelist.txt
/mylocalconfigfolder/phpstuff/config.ini.php
/mylocalconfigfolder/MyGreatBridge.php
/mylocalconfigfolder/bridges/MyOtherGreatBridge.php

All the logic checks and merges of rss-bridge still apply, as this basically just adds files to paths where rss-bridge would expect the files to be anyways.

Impact on existing installations: None!
If you haven't mounted the /config folder, nothing will change. If you have mounted the whitelist.txt directly, nothing will change (as long as you dont try to do both at the same time, but that would mean you are aware of the change and you mount the config folder...).

Useability impact on new users:

• A new user can now just create a local folder, add his whitelist and custom bridges and mount it into the container with no further actions needed. This means a much easier usage for everyone that controlls docker containers via a UI (like NAS systems, unraid etc).

I have tested this with multiple bridges, non-valid files and folders and so on and I wasn't able to break it, so please, test if you are able to.

I will tag all the previous issues and discussions about this topic to get more brains on this.

Greetings

[Bockiii]

#1955

[ikajdan]

Missing newline. Also wouldn't it be better to rename this script to something like docker-entrypoint.sh, to indicate that it's related to Docker image?

[Bockiii]

sure, no problem

[ikajdan]

While bridges' names don't contain spaces, it's better to quote these anyway.

[ikajdan]

Also, wouldn't it be better if these files were soft-linked?

Suggested change

	*Bridge.php) yes | cp $f /app/bridges/ ;
	*Bridge.php) ln -s "$f" /app/bridges/ ;

[ikajdan]

Something like this should do.

#!/bin/sh

# Find custom files in the '/config' directory and symlink them to their
# respective folders in '/app'.
# Look for '*Bridge.php', 'whitelist.txt' and 'config.ini.php' files.
# Everything else is ignored.
# This will overwrite previous configs and bridges. It also uses the default
# paths of the configs and bridges, so if there is no file that matches,
# RSS-Bridge works like default.

for file in /config/*; do
    file_name="$(basename "$file")" # Strip leading path
    case "$file_name" in
        *Bridge.php)
            ln -sf "$file" /app/bridges && \
            printf 'Custom Bridge %s added.\n' "$file_name"
        ;;
        config.ini.php)
            ln -s "$file" /app/ && \
            printf 'Custom config.ini.php added.\n'
        ;;
        whitelist.txt)
            ln -s "$file" /app/ && \
            printf 'Custom whitelist.txt added.\n'
        ;;
    esac
done

# Start Apache
apache2-foreground

[Bockiii]

Wouldn't softlinking the file make it possible to change the content during runtime? I dont know if that has implications on the stability. If you remove a bridge from the config folder while the app is running, it will break the rss-bridge.

I see no downside of copying the content to the /app/bridges path since that is in the container and not mapped anyways. So it will always be container-default at the start. Also, what happens if you customize one of the already-present bridges? Pretty sure linking a file to an existing file will cause an error (which could be solved by just overwriting it).

So about the quoting: I would do a different change: Check the filename for spaces and log out an error message before the case.

if [[ $file_name= *" "* ]]; then
  printf 'Custom Bridge %s has a space in the name and will be skipped.\n' "$file_name"
  break
fi

Because copying the file (or symlinking) wont help the user at all, since it wont show up.

So how about I add the check and not do the change about linking?

[ikajdan]

Wouldn't softlinking the file make it possible to change the content during runtime? I dont know if that has implications on the stability. If you remove a bridge from the config folder while the app is running, it will break the rss-bridge.

I haven't considered that. Symlinking seemed more elegant to me.

I see no downside of copying the content to the /app/bridges path since that is in the container and not mapped anyways. So it will always be container-default at the start. Also, what happens if you customize one of the already-present bridges? Pretty sure linking a file to an existing file will cause an error (which could be solved by just overwriting it).

Yeah, I have added -f switch switch, so it should work.

So about the quoting: I would do a different change: Check the filename for spaces and log out an error message before the case.

My point was, that it is a good idea to quote every variable in Bash to prevent accidental splitting. Adding that additional check might be a good idea, though.

[Bockiii]

How about now?

[ikajdan]

Seems good. Although you might want to run shellcheck on it, as it still complains about some stuff. Also it seems, that they require max. 80 chars per line, so it would be good to wrap those comments.

[Bockiii]

There we go. I actually misread your comment as "spellcheck", not "shellcheck" as I didnt know about that :D

All the findings are okay for me, I wouldn't add another commit for it.

[ikajdan]

Haha. Yup, those aren't that important. Well done. Now we can only wait.

[Bockiii]

Thanks a lot for the thorough review! @em92 any more wishes?

[Bockiii]

I just tested this and noticed that the rename stripped the script of the executable flag. It now works again

[Bockiii]

Great.. there seem to be more issues. @em92 wait with the merge. I will do more testing and then do a new PR, doing all the commits in one, as this is already 6 commits deep for a feature. I will reference this pr in the new one.