arifer
-
Posts
18 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by arifer
-
-
On 6/2/2022 at 9:36 PM, primeval_god said:
When you say they stick do you mean a docker inspect shows that the labels are not updated or that the webui doesnt pick up the changes and modify its links? What version of unRAID are you running? The translating of labels to webui links is a feature of the unRAID os rather than this plugin specifically, if thats the issue we may have to raise this to limetech.
On 6/2/2022 at 10:28 PM, Agent531C said:As for the first part, the actual webui doesn't pick up the changes for any label changes. If I set a label for an icon, and change it, it remains the first one even through reboots, deleting the cached image, and deleting/rebuilding the stack alltogether. Same goes for the 'webui' button on the popup. If I set a 'webui' label, and then go change it later, it remains whatever that first label was set on.
I am on 6.10.2, but this very well could be a limetech issue with the way labels work at an OS level as opposed to the compose plugin.
The problem is indeed in the OS's docker manager plugin. It stores all the information in RAM and only supports changes to the XML template file. An quick and easy fix would be to delete `/usr/local/emhttp/state/plugins/dynamix.docker.manager/docker.json` and have it build again on reload every time you make a change to the compose file. Another approach is to include a small script within this plugin to remove the service entry from the same file every time `docker-compose down` is executed.
You can use `docker compose ps -a` to get the names of all the containers of a stack, pipe that into `jq 'del(.CONTAINER_NAME)' /usr/local/emhttp/state/plugins/dynamix.docker.manager.docker.json` to remove the entries, and then let the server build the file again once the stack is spun up.
-
15 minutes ago, Squid said:
I can't believe that I never bothered to check if there was a repository for this! Will put up a PR on it. Thank you ^^
-
I've put together a small patch to dockerMan so as to get the icons from compose labels working.
Solution:
The `/usr/local/emhttp/plugins/dynamix.docker.manager/include/DockerClient.php` on unRAID needs to be changed. The problem about changing this file is that it does not sustain after reboots so it has to be patched every reboot. It's always possible to use the User Scripts plugin to edit the file on reboot at least until LimeTech fixes it fully or improves on it.
Manual method
SpoilerMake a copy of the file first, just in case something goes wrong.
cp /usr/local/emhttp/plugins/dynamix.docker.manager/include/DockerClient.php /usr/local/emhttp/plugins/dynamix.docker.manager/include/DockerClient.php.old
Navigate to the comment "// read docker label for WebUI & Icon" at line 302 within the getAllInfo function. 4 lines down, change the following line:
if (!is_file($tmp['icon']) || $reload) $tmp['icon'] = $this->getIcon($image,$name);
to
if (!is_file($tmp['icon']) || $reload) $tmp['icon'] = $this->getIcon($image,$name,$tmp['icon']);
Next, navigate to the following getIcon function at line 338. Change the line from:
public function getIcon($Repository,$contName) {
to
public function getIcon($Repository,$contName,$tmpIconUrl='') {
Lastly, 2 lines down, under the following line:
$imgUrl = $this->getTemplateValue($Repository, 'Icon','all',$contName);
add
if (!$imgUrl) $imgUrl = $tmpIconUrl;Script:
SpoilerEither save this as an executable, or add it as a User script and run it on first boot.
#!/bin/bash D_FILE="/usr/local/emhttp/plugins/dynamix.docker.manager/include/DockerClient.php" sed -i "s/getIcon(\$image,\$name)/getIcon(\$image,\$name,\$tmp['icon'])/" $D_FILE sed -i "s/getIcon(\$Repository,\$contName)/getIcon(\$Repository,\$contName,\$tmpIconUrl='')/" $D_FILE sed -i "s/\$imgUrl = \$this.*/&\n\t\tif (\!\$imgUrl) \$imgUrl = \$tmpIconUrl;/" $D_FILE
Refresh your Docker page and the icon should now show up. If it does not, you may need to clear your cache.
A problem with this patch is that the icon image does not change if you change the value of the label "net.unraid.docker.icon" in the compose file. To force an update, you will have to delete the previous icon files. Suppose the service name is "foo-service", 2 icons will be made:
- /var/lib/docker/unraid/images/foo-service-icon.png
- /usr/local/emhttp/state/plugins/dynamix.docker.manager/images/foo-service-icon.png
Delete both files and refresh your page to force unRAID to pull the new icons.
Reason:
SpoilerIt seems that while web-UI links get read and parsed fine, the compose icon labels are not used all the way. You can see it from the following segment in when preparing the icon.
public function getIcon($Repository,$contName) { ... $imgUrl = $this->getTemplateValue($Repository, 'Icon','all',$contName); if (!$imgUrl || trim($imgUrl) == "/plugins/dynamix.docker.manager/images/question.png") return ''; ... }
Looking back at getAllInfo, where getIcon is called to pull the icon images, the Docker label for the icon is actually read and stored in a temporary template array. However, this information is not being passed into the getIcon function, which only searches for the icon URL from the XML template files. To bypass this, we can add an optional parameter for getIcon to take in the icon URL from the Docker label and appropriately update the local variable $imgUrl when getIcon realises that the container does not have an XML template.
public function getIcon($Repository,$contName,$tmpIconUrl='') { ... $imgUrl = $this->getTemplateValue($Repository, 'Icon','all',$contName); if (!$imgUrl) $imgUrl = $tmpIconUrl; ... }
A dirty hack, but a working hack.
-
8 hours ago, primeval_god said:
Autostart works just fine. The scripts in the event directory are triggered by unRAID system events.
Ah I see, I never knew about that. Thank you for enlightening me!
8 hours ago, primeval_god said:This is not the case. The compose.manager plugin stores stack names in a file called "Name" in each stack directory. "$(cat $dir/Name)" reads the stack name.
I find that all my stacks are written to a file titled `name` in lower case instead of being capitalised. This is also explicitly expressed in the `exec.php` file.
Adding a stack:
file_put_contents("$folder/name",$stackName);Changing the name of a stack:
file_put_contents("$compose_root/$script/name",trim($newName)); -
Hi there, I'm loving this plugin and can't wait for the next update with icon support.
I looked through the shell scripts in the `/usr/local/emhttp/plugins/compose.manager/event/` directory. I found a few oddities in the scripts that may need some looking at. The first is the hard-coding of the project names as "$dir/Name" which will not match any stack unless they are so incidentally named "Name". The second is the nested ifs that can be reduced, it's easier to read too that way. And the final oddity would be that none of these scripts are actually called anywhere. I'm guessing that this means that the auto-start feature is not in full-force yet.
In the spoiler below, I'm providing the diff to the changes to the shell scripts that I think may help with the first 2 problems mentioned. Please feel free to consider using them!
SpoilerFor the `started` script:
--- started +++ started.patched @@ -3,18 +3,15 @@ COMPOSE_ROOT=/boot/config/plugins/compose.manager/projects COMPOSE_WRAPPER=/usr/local/emhttp/plugins/compose.manager/scripts/compose.sh -for dir in $COMPOSE_ROOT/*; do - if [ -d "$dir" ]; then - if [ -f "$dir/compose.yml" ]; then - if [ -f "$dir/autostart" ]; then - if [ 'true' == "$(cat $dir/autostart)" ]; then - # echo "$dir/compose.yml" - logger "Starting compose stack: $(cat $dir/Name)" - $COMPOSE_WRAPPER up "$dir/compose.yml" "$(cat $dir/Name)" > /dev/null & - fi - fi - fi +while read AUTOSTART; do + STACK_DIR="$(dirname $AUTOSTART)" + STACK_NAME="${STACK_DIR#$COMPOSE_ROOT/}" + STACK_FILE="${STACK_DIR}/compose.yml" + + if [ "$(cat $AUTOSTART)" == "false" ] && [ -f "${STACK_FILE}" ]; then + logger "Starting compose stack: ${STACK_NAME}" + $COMPOSE_WRAPPER up "$STACK_FILE" "$STACK_NAME" > /dev/null & fi -done +done <<< $(find $COMPOSE_ROOT -type f -name autostart) waitFor the `stopping_docker` script:
--- stopping_docker +++ stopping_docker.patched @@ -3,14 +3,12 @@ COMPOSE_ROOT=/boot/config/plugins/compose.manager/projects COMPOSE_WRAPPER=/usr/local/emhttp/plugins/compose.manager/scripts/compose.sh -for dir in $COMPOSE_ROOT/*; do - if [ -d "$dir" ]; then - if [ -f "$dir/compose.yml" ]; then - # echo "$dir/compose.yml" - logger "Stopping compose stack: $(cat $dir/Name)" - $COMPOSE_WRAPPER stop "$dir/compose.yml" "$(cat $dir/Name)" > /dev/null & - fi - fi -done +while read STACK_FILE; do + STACK_DIR="$(dirname $STACK_FILE)" + STACK_NAME="${STACK_DIR#$COMPOSE_ROOT/}" + + logger "Stopping compose stack: ${STACK_NAME}" + $COMPOSE_WRAPPER stop "$STACK_FILE" "$STACK_NAME" > /dev/null & +done <<< $(find $COMPOSE_ROOT -type f -name) wait -
I only have a Home Assistant Virtual Machine running on my server with unRAID v6.9.2 and libvirt v6.5.0.
It's been working fine for the most parts. However, after waking up this morning, I found out that the virtual machine disappeared. I checked the webGUI and saw in the Virtual Machines tab a big yellow banner that said "Libvirt Service failed to start". I know that I should have taken a screenshot of the page before proceeding but I forgot to log it down.
I turned off and on the virtual machine support in the settings menu but nothing changed. I then checked the logs and it was clean, no error messages whatsoever. The last approach I took was to reboot the whole system. I rebooted it, started up the array, re-enabled VM support in the menu and now it's working fine. Checking the logs, there is an entry in it that is suspiciously foreboding.
2021-10-01 02:21:44.048+0000: 12337: info : libvirt version: 6.5.0 2021-10-01 02:21:44.048+0000: 12337: info : hostname: Babel 2021-10-01 02:21:44.048+0000: 12337: warning : networkNetworkObjTaint:5292 : Network name='default' uuid=a67b7b9b-bef4-488b-b243-c9e5f391a3b1 is tainted: hook-script 2021-10-01 02:21:44.923+0000: 12337: warning : qemuDomainObjTaint:6075 : Domain id=1 name='HomeAssistant' uuid=78b2f542-3fd7-039d-f5a5-7866d93e49d6 is tainted: high-privileges 2021-10-01 02:21:44.923+0000: 12337: warning : qemuDomainObjTaint:6075 : Domain id=1 name='HomeAssistant' uuid=78b2f542-3fd7-039d-f5a5-7866d93e49d6 is tainted: host-cpu 2021-10-01 02:21:45.764+0000: 12321: error : virNetSocketReadWire:1826 : End of file while reading data: Input/output errorIt raises an EoF error message. The first guess I have is that it might have something to do with the fact that my libvirt.img file is hosted on my cache drive but then I would also expect a similar issue with my docker containers which are also running on the same cache drive, which is not the case! I'm posting this here in hope that someone out there may shed some light on this issue.
-
After it initialises the issue should sort itself out. I believe I faced some permissions issue in my appdata share so I fixed it through the Docker New Permissions tool and my reboots from then on had no hiccups.
Tapatalk を使用して私の XQ-AS72 から送信 -
I faced this issue once and I managed to get it fixed by turning off docker and VMs in the settings before starting up the array. I suggest you stop the array and try that out to see if it works.
Tapatalk を使用して私の XQ-AS72 から送信 -
Thank you for the hard work. The connection is finally going through and I'm seeing myself online and accessible through the internet now. Actually, it seems as if the my-servers page retrieves the connection information a lot faster than it used to! This is great! I'll mark this thread as closed.
-
1
-
-
I got back and saw this in the debug logs for `unraid-api`
ws:closed 1006 closed automatically, restarting ws:closed 1006 closed automatically, restarting ☁️ RELAY:DISCONNECTED ws:closed 1006 closed automatically, restarting ws:closed 1006 closed automatically, restarting ws:closed 1006 closed automatically, restarting ws:closed 1006 closed automatically, restarting ws:closed 1006 closed automatically, restarting ☁️ RELAY:DISCONNECTED ⌨️ INTERNAL:CONNECTED Error: WebSocket is not open: readyState 0 (CONNECTING) at WebSocket2.send (/usr/local/bin/unraid-api/node_modules/graceful-ws/dist/graceful-ws.js:1649:17) at GracefulWebSocket.send (/usr/local/bin/unraid-api/node_modules/graceful-ws/dist/graceful-ws.js:2458:39) at GracefulWebSocket.<anonymous> (/usr/local/bin/unraid-api/dist/index.js:32254:55) at GracefulWebSocket.emit (events.js:315:20) at GracefulWebSocket.EventEmitter.emit (domain.js:467:12) at WebSocket2.<anonymous> (/usr/local/bin/unraid-api/node_modules/graceful-ws/dist/graceful-ws.js:2479:12) at WebSocket2.onOpen (/usr/local/bin/unraid-api/node_modules/graceful-ws/dist/graceful-ws.js:1109:20) at WebSocket2.emit (events.js:315:20) at WebSocket2.EventEmitter.emit (domain.js:467:12) at WebSocket2.setSocket (/usr/local/bin/unraid-api/node_modules/graceful-ws/dist/graceful-ws.js:1566:14)
Not sure if this helps but I hope it shed some light into why the connection keeps failing to sustain.
-
Actually, it seems that it's starting to fail to connect again. I'm getting a flurry of reconnecting issues in the debug.
libvirt: No changes detected. libvirt: No changes detected. ☁️ RELAY:Too Many Requests:RECONNECTING:NOW ☁️ RELAY:Too Many Requests:RECONNECTING:NOW ☁️ RELAY:429:Too Many Requests:RECONNECTING:30_000 ... libvirt: No changes detected. libvirt: No changes detected. ☁️ RELAY:Too Many Requests:RECONNECTING:NOW ☁️ RELAY:Too Many Requests:RECONNECTING:NOW libvirt: No changes detected. ☁️ RELAY:Too Many Requests:RECONNECTING:NOW -
I updated to v2021.09.15.1853 last night. I noticed when I was out today that I could not access it from the internet. When I got home, it first raised the error that Graphql was offline so I tried using `unraid-api restart` to get it running since I had encountered this issue before. However, it continued to fail to connect to the mothership no matter how long I wait or how many times I tried. I referenced this post and re-installed the plugin twice but that also did not make a difference.
Once all the dry methods had failed, I tried to debug the issue. I ran `unraid-api --debug restart` and lo and behold, connection to the mothership is made and sustained. Right now I'm running that in a tmux session so that it remains online for as long as the server stays online. It also gives me a good log of what's happening just in case something fails.
-
@iker 's solution worked for me on SWAG. I also had to include the following lines in my configuration.yaml file for the Hassio VM.
http: use_x_forwarded_for: true trusted_proxies: - XXX.XXX.XXX.XXX # IP address of my unRAID boxIf you're facing problems getting the right IP address, try accessing the web app through the site you have set up the CNAME for like homeassistant.domain.host and search your Home Assistant logs under "Configuration >> Logs" for the following entry:
Quote"A request from a reverse proxy was received from XXX.XXX.XXX.XXX, but your HTTP integration is not set-up for reverse proxies"
where the IP address shown is what you need to insert into the code block above.
-
2
-
-
@bigbangus
You would need to add the following lines to the configuration.yaml file:
http: use_x_forwarded_for: true trusted_proxies: - 172.XX.XX.XX # The SWAG docker IP address
You can always check for your SWAG docker IP address by checking it in the port mappings column of the Dockers tab.
-
I can't seem to add any podcasts by URL. The Uncast one in particular.
https://feeds.buzzsprout.com/1746902.rss
Is there anybody else facing the same issue?
-
On 3/28/2021 at 8:23 PM, luisalrp said:
Hello,
I'm trying to run tubesync behind swag, but I'm getting the following error:
The config file is pretty simple, but there is something I'm missing:
server { listen 443 ssl; listen [::]:443 ssl; server_name ts.*; include /config/nginx/ssl.conf; client_max_body_size 0; # enable for Authelia include /config/nginx/authelia-server.conf; location / { # enable for Authelia include /config/nginx/authelia-location.conf; include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_app tubesync; set $upstream_port 4848; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } }Any ideas? Thanks!
You'd need to add the following to the `location` block.
proxy_set_header X-Forwarded-Proto http; proxy_set_header X-Forwarded-Ssl off; -
On 10/28/2020 at 6:03 AM, Stalkkaaja said:
Hey guys! How can I get custom fonts working for Plex docker? I have many shows with .ass subtitles and TrueType font files to go with them but no idea where to copy them.
I doubt that this is configurable from the server side since the clients need to have the fonts installed to be able to have it displayed accurately.
If you are on Linux, there are many different methods that you can employ to install fonts, graphical and console alike. A quick google search will lead you the right way. If you just want to get it done fast, one mostly distro-agnostic method would be to move the .ttf into `/usr/local/share/fonts/ttf/` and then running `fc-cache -fs` to install the font.
If you are on Mac, IIRC you just need to double click on the font and there should be a button to install the font: https://support.apple.com/en-us/HT201749
As for Windows, you should be able to install it by picking the appropriate context after right-clicking the font: https://www.fontspring.com/support/how-do-i-install-fonts-on-my-windows-pc
However, if you are in a case where you cannot enforce the fonts to be installed on all the clients you wish to play the media on, you're in bad luck then. There's a request upstream to get something like this added to Plex so maybe you can add a vote to it: https://forums.plex.tv/t/subtitles-settings-font-color-offset-time-position/232538
[Plugin] Docker Compose Manager
in Plugin Support
Posted · Edited by arifer
Clarity
Adding the following snippet under the "up" and "down" lines in "/usr/local/emhttp/plugins/compose.manager/scripts/compose.sh" successfully settled the problem raised by @Agent531C for the case of updating the web UI label. I can get the same result by first spinning down a stack, editing it, and then spinning it back up; as well as editing a stack and then recreating it by clicking on the "compose up" button on the web GUI.
docker compose -f "$2" -p "$3" ps -a | awk '{if (NR!=1) {printf("%s.\"%s\"", sep, $1); sep=", "}}' | xargs -0 -I {} jq 'del({})' $DOCKER_JSON > $DOCKER_JSON docker compose -f "$2" -p "$3" up -d 2>&1The following snippet is a cheap and dirty way of forcing unRAID to delete cached icons and retrieve them from the `net.unraid.docker.icon` label. I placed this udner the "up" "down" lines in the same file above.
docker compose -f "$2" -p "$3" ps -a | awk '{if (NR!=1) {print $1}}' | xargs -I {} find $DOCKER_IMAGES $UNRAID_IMAGES -name {}.png -deleteThe environments used in the snippets are declared at the top of the file: