iXNyNe

https://github.com/dcflachs/compose_plugin/pull/34 will fix it if merged (or if the author fixes it separately).

I think the new SSO support that was announced is a great step forward. I do wonder if there will be the ability to require logging in via SSO. I'd be perfectly happy with the absense of native 2FA/MFA if SSO could be required and the SSO provider used supports requiring 2FA/MFA. I am pretty sure Unraid.net does support 2FA/MFA but I don't recall being prompted for it anytime recently (I don't really log in often, it's just remembered in cookies).

I am guessing the original comment about the router is maybe trying to say that if someone gains access to your local network (already an issue) and unraid is only accessible locally, then having 2fa on the unraid web UI login would be an additional protection that would be appreciated. There are still many other concerns in that scenario. In a previous post, I described a different scenario where local security (router, etc) are not the concern, but rather the concern with exposing the unraid web UI to the internet means having a login with no 2fa. Additionally, anyone using unraid connect is (whether they know it or not) exposing their unraid web UI to the internet if they enable the remote access feature. This is functionality that is clearly intended and wanted, but the lack of 2fa on the web UI login is a concern, even with unraid connect's remote access URLs being fairly long and random.

Your script was super helpful for me. I ended up writing a script to follow up and act on (delete) duplicates. #!/bin/bash dupeList=( ) remove_dupes() { dupe="$1" dupePaths=$(find /mnt/disk*/"${dupe}") dupeCount=$(echo "${dupePaths}" | wc -l) if [[ "${dupeCount}" -gt 1 ]]; then removeFiles=$(echo "${dupePaths}" | sort -R | tail -n +2) keepFile=$(grep -v -F -x -f <(echo "${removeFiles}") <(echo "${dupePaths}")) echo "------------------------------------" echo "Found ${dupeCount} duplicates for:" echo "${dupe}" echo "" echo "Keeping one file:" echo "${keepFile}" echo "" echo "Removing duplicate file(s):" echo "${removeFiles}" # rm "${removeFiles}" echo "" echo "Remaining files (confirmation):" find /mnt/disk*/"${dupe}" echo "------------------------------------" fi } for dupe in "${dupeList[@]}"; do remove_dupes "${dupe}" done The rm line in the above is commented out. If anyone decides to use this script, be sure you know what you're doing (or run it first with the rm commented). Also the dupeList variable is empty. It doesn't detect the /boot/duplicates.txt, I am just taking the output from there and copying it into the script (with quotes) so it looks like this: dupeList=( "file1.txt" "file2.txt" "file3.txt" "file4.txt" "file5.txt" "file6.txt" "file7.txt" "file8.txt" "file9.txt" "file10.txt" # Add more files as needed ) It could probably be easily modified to actually read from /boot/duplicates.txt but having to manually copy keeps the use of this script very intentional. One last note, it decides which file to keep randomly and deletes the rest. The point isn't to gather/scatter line unbalanced, or keep files together on specific disks, just to get rid of duplicates to recover space.

OH, I see now, yes it adds these: "com.docker.compose.config-hash": "44380e4393ba2ca58583526942ef8b33b28153062dab1f0c37c2abb727a3bb20", "com.docker.compose.container-number": "1", "com.docker.compose.depends_on": "", "com.docker.compose.image": "sha256:9c124a7cca9a1ebc1c9a6640caf17e2a0acf51082bdd44c01ebd3d922bb5c2b6", "com.docker.compose.oneoff": "False", "com.docker.compose.project": "bw_export", "com.docker.compose.project.config_files": "/boot/config/plugins/compose.manager/projects/bw-export/docker-compose.yml,/boot/config/plugins/compose.manager/projects/bw-export/docker-compose.override.yml", "com.docker.compose.project.working_dir": "/boot/config/plugins/compose.manager/projects/bw-export", "com.docker.compose.service": "bw-export", "com.docker.compose.version": "2.29.2", (potentially more depending on if there's an env file) All of that is automatic and allows compose to understand how to manage the stack after creation. It's not needed to be included in the override file created by the plugin and should pretty much be ignored.

The override file I'm seeing looks like this: services: bw-export: labels: net.unraid.docker.managed: 'composeman' net.unraid.docker.icon: 'https://github.com/0neTX/UnRAID_Template/blob/main/bw-export/icon.png?raw=true' net.unraid.docker.webui: '' net.unraid.docker.shell: '' This is basically just enough to make the container(s) appear in unraid's web UI to be managed like any other container that was added through CA. If this is NOT included (ex: in the larger loop example I posted above, in a scenario where the stack folder is not default) everything will still work fine minus the web UI management via unraid's native docker manager. Again, if the plugin were modified to store the override in the stack folder it would resolve that small issue. Also as mentioned, if the override were in the stack folder it could complicate version control, but the easy fix is to .gitignore the override, or do something more sophisticated to keep the override managed within the version control. I know I'm probably sounding like a broken record, but having the override file in the stack folder eliminates the need to specify all of the files in the compose command. I'm all for it. If people want to use version control (I do, and I absolutely recommend others at least explore it) the easiest option is to .gitignore the override file.

I also now see (I'm testing stuff) that the ability to specify an envpath adds an additional env file rather than replacing the one stored with the compose file in the stack folder. I assume the file in the envpath is variables seen inside the container rather than variables used in the compose file. Clever. It does make the loop I posted above more complex to write though. I see how version controlling the stack folder could make it difficult for the plugin to manage the override file. It looks like all of the logic to generate the override file is in the frontend javascript, so if the compose file is modified without then using the frontend to start the stack the override file would not be updated. Maybe the logic to generate the override code could be moved to a backend script so that it could be triggered by various things such as userscripts? If that were done and the override were saved in the stack folder with the compose file it would open up a lot of control via userscripts. Here is an example rewrite of the loop: source "/boot/config/plugins/compose.manager/compose.manager.cfg" export PROJECTS_FOLDER if [[ -d "${PROJECTS_FOLDER}" ]]; then for project in "${PROJECTS_FOLDER}"/*; do if [[ -d "${project}" ]]; then project_name=$(sed -E 's/\W/_/g' <<<"$(basename "${project}")") if [[ -f "${project}/name" ]]; then project_name=$(sed -E 's/\W/_/g' "${project}/name") fi project_directory=${project} if [[ -f "${project}/indirect" ]]; then project_directory=$(cat "${project}/indirect") fi project_envargs=() if [[ -f "${project}/envpath" ]]; then project_envargs+=("-e" "$(cat "${project}/envpath")") fi if [[ -f "${project}/autostart" ]]; then autostart=$(cat "${project}/autostart") if [[ "${autostart}" == "true" ]]; then # Take an action if the container is set to autostart echo "Autostarting ${project_name}..." docker compose --project-directory "${project_directory}" --project-name "${project_name}" "${project_envargs[@]}" up --pull always --wait echo "Successfully autostarted ${project_name}" fi fi # Take an action every time the script is run # echo "Starting ${project_name}..." # docker compose --project-directory "${project_directory}" --project-name "${project_name}" "${project_envargs[@]}" up --pull always --wait # echo "Successfully started ${project_name}" fi done fi It's significantly more code now (accounting for the new things I've just learned) but a big issue would be with a project using an indirect folder the override would not be included at all (because it's not stored in the stack folder). Also as mentioned above, the only way currently to update the override is via the GUI, so if the compose file is updated and adds a new container there would not be labels in the override for it.

I did indeed miss that. Is there a reason that the override and env files could not be kept together with the compose file? I see there is an option to specify the path to the env file, but if left blank it does seem to be stored in the stack folder. It also looks like there is a file named "indirect" that contains the stack folder, so that actually simplifies things quite a bit (the loop example I posted above could easily be updated to check for and use the indirect file if it exists). it could also easily read the compose.manager.cfg to find the default PROJECTS_FOLDER. So really all I'm suggesting is to keep the override file in the stack folder, which would allow simplified calls to the docker compose CLI (fewer arguments).

Here's an example of finding any project that is set to autostart true and running compose up with pull (update) and wait until the containers are reporting healthy before detaching (running in the background so the script can consider itself finished running): find /boot/config/plugins/compose.manager/projects -type f -name autostart -exec grep -l "true" {} + | while read -r autostart; do docker compose --project-directory "$(dirname "${autostart}")" --project-name "$(sed -E 's/[\.\s\-]/_/g' "$(basename "${autostart}")/name" || true)" up --pull always --wait echo "Successfully started $(sed -E 's/[\.\s\-]/_/g' "$(basename "${autostart}")/name" || true)" done Could run on a schedule or when array starts. Could be modified to do other things pretty easily.

For anyone else pulling their hair out trying to figure out how to properly schedule things with compose stacks created by this plugin, I found this to work pretty well: COMPOSE_PROJECT_DIR=/boot/config/plugins/compose.manager/projects/bw-export docker compose --project-directory "${COMPOSE_PROJECT_DIR}" --project-name "$(sed -E 's/[\.\s\-]/_/g' ${COMPOSE_PROJECT_DIR}/name || true)" up --pull always --wait I noticed the sanitize function in https://github.com/dcflachs/compose_plugin/blob/main/source/compose.manager/php/util.php replaces dots, dashes, and spaces with underscores, and as long as you set the project directory and project name correctly you can use pretty basic docker compose commands and be fully compatible with the plugin. I have the above in a user script scheduled to run daily because the one and only container in that stack exits once it finishes running (it only takes a few seconds to complete) and I want it to run once per day automatically. This pattern could easily be adapted to loop through multiple projects (ex: auto detect any projects in the /boot/config/plugins/compose.manager/projects folder) or use other compose commands like down, pull, etc. @primeval_god if you happen to see this, you might take note that the commands above are NOT adding a ton of arguments to specify the compose file, override, env, etc. It's really just the project directory and project name that's needed. The project name actually wouldn't be needed at all because compose names projects using the folder if you don't specify otherwise, but to keep the above compatible with what you've got in your repo it's needed. The code in your repo might be able to be simplified with that in mind. The compose CLI automatically knows what to do with the compose file, override file, and env file (because you happen to have them named the way compose expects, which is perfect) and you can omit the project name since compose will auto-generate that. In the case above my project name (if auto-generated) would be bw-export (with a dash) instead of how the plugin names it bw_export (with an underscore). Anyway the project name is hardly the important part. Not having all the file arguments really cleans it up.

Bit of an odd request, but would you consider changing your version numbering to use YYYY.MM.DD ? Ex: if you released today it would be 2024.12.02 (and if you released twice today your second release would be 2024.12.02a or 2024.12.02.01 or something). The reason I ask is your plugin is the only one I have installed that doesn't use this convention. The main benefit to users (myself included) is if in some distant future you stop maintaining the plugin it is easier to tell when the plugin was last updated. For example, I currently don't have any plugins installed that are older than 2023. This is mostly by chance, but occasionally I will look for plugins that haven't received an update in a long time and see if there's a fork or alternative, or if the functionality got built into the unRAID OS, or if I'm having some kind of issue updating a specific plugin for some reason. I've also seen a few cases where another dev will come along and make a fork (just mentioned that, but wanted to point out the alternate dev aspect) of a plugin that seems like it's no longer maintained. A valid argument against this is the date as a version can create a sense of "there SHOULD be an update" even if there are no issues with the plugin and it's considered feature complete. If it ain't broke, don't fix it. So I can understand if you're against it. Hopefully though, you'll consider it, again as I mentioned your plugin is the only one I have installed that doesn't use this convention, so if nothing else, maybe just to be versioning the way most other plugins version (following the crowd isn't always a bad thing). Anyway thanks for reading either way.

The version of xz in our latest release of digikam (and our kasm arch base image) is 5.6.1-3 which has been patched according to https://security.archlinux.org/AVG-2851

https://info.linuxserver.io/issues/2024-03-29-cve-2024-3094/ Tldr: lsio images are mostly unaffected. Updating to the latest images is recommended as a precaution.

Just as a clarification: I'm not advocating to require 2fa for all logins. Making it available for those who want it would be ideal. Requiring it when using https://connect.myunraid.net/ to allow remote access would also be sane.

https://connect.myunraid.net/ (an official unRAID product) seems to contradict the constant user posts on this forum saying not to expose unRAID to the internet. The entire premise of https://connect.myunraid.net/ is to expose and manage your unRAID systems remotely. This exposes the unRAID web login form to the internet. Since this seems to be officially supported behavior it would make sense for there to be a greater care for security. Another good example would be strengthening the default SSH configurations to require keypairs in order to connect to SSH by default. SSH in unRAID can be configured for proper security with SSH, making it entirely safe to expose to the internet (at least as safe as any VPS you would access via SSH), but these safer configurations are not the default. The web UI has no such configurations to improve security, such as requiring 2fa. It's fair and reasonable to tell a user that if they are not educated on the risks of exposing their system to the internet that they should not do it, but it's also fair to point out that unRAID's web UI login could be improved by adding 2fa. unRAID's login seems to be php based, and there are a handful of very good composer packages that make implementing 2fa very easy. Hopefully unRAID considers this.