-
Posts
10 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by letri
-
-
I've been seeing the same issue for the past month. It looks like my Docker containers are updating and, for some reason, things are not getting cleaned up properly afterwards. Here's my diagnostics: https://powellhouse-my.sharepoint.com/:u:/g/personal/richard_powell_dev/ESHiz0oJllVHrlR5_kHuamMBmbdiXpNKFEfKQic8cJcwWA?e=D2xmjM
-
2 hours ago, dprus said:
I'm also having the same issue.
I was able to figure out the issue by downloading the plugin locally and using the commandline "installplg" to try and install it. This allowed me to easily edit the script and add logging (it badly needs logging). I found out it was failing to download putty. Some observations:
- It tries to download Putty 0.64. That's a very old version of Putty. So instead of trying to make this work I went ahead and installed the latest Putty 0.73 package instead:
# Slackbuilds doesn't send the full Letsencrypt certificate chain and wget doesn't know how to handle this. So we'll help it... wget https://letsencrypt.org/certs/letsencryptauthorityx3.pem.txt -O /tmp/letsencryptauthorityx3.pem wget --ca-certificate=/tmp/letsencryptauthorityx3.pem https://slack.conraid.net/repository/slackware64-current/putty/putty-0.73-x86_64-1cf.txz rm /tmp/letsencryptauthorityx3.pem
- When it decides whether or not Putty is installed it does a check for that very specific old version of Putty. So even after I'd installed the newer version of Putty the script still failed. I ended up having to comment out the section that downloads and installs Putty to get the script to install. I would recommend the script instead check for Putty >= 0.64.
- Also, above, instead of using '--no-check-certificate' with wget I'd recommend the approach of using wget to download the intermediate from letsencrypt's website and then passing the intermediate to wget. This will allow wget to succeed when downloading from websites that don't provide wget with a full chain without having to tell wget to completely ignore all certificate validation.
For those of you who don't want to have to workaround things and want to get the script back to "just working" you may want to try downloading and installing Putty 0.64 manually before trying to install this plugin:
- Download path: https://github.com/docgyver/unraid-v6-plugins/releases/download/ssh/putty-0.64-x86_64-1rj.txz (might need to use the same trick with passing --ca-certificate above)
- Run, from an unraid root shell: installpkg <path to the file you downloaded in the previous bullet>
After that, and assuming the script was failing in your case for the same reason it was failing for me, the plugin should install successfully again.
Good luck!
PS. If I get some spare time I will submit a PR to update the plugin to add logging, increment the Putty version and remove instances of --no-check-certificate being passed to wget.
-
1
-
I'm also having the same issue.
-
Hi,
Firstly, thanks for the plug-in. Things were definitely getting quite messy for me with my docker-compose setup. Really appreciate the hard work.
I am seeing one issue that I'm hoping you can help me with. I have configured 8 containers in a docker-compose and after I "docker-compose up -d" and then put all the containers in a folder using your plug-in the plugin shows the group as "8/9 folder" with a yellow box alongside it. This is even though all the docker containers are running fine (individually they all show green triangles alongside them and say "started". I can access them all and they are all functional).
I have included a screenshot of what I'm seeing. Can you help me figure out what's going on? Thanks.
Nevermind - as soon as I posted this I figured it out. It appears I had a defuct container named "nginx" that had the same name as the folder that was causing the confusion. As soon as I went to the commandline and deleted the defunct underlying docker container things fixed themselves. Posting this here in case any one else hits the same issue.
-
Well - turns out the solution was to reboot
After rebooting everything now works as expected.
-
I recently had an issue with my cache drive and lost all my docker container configurations. So I've had to start over.
I previously had a custom docker network defined and a number of my docker containers connected to that network and things worked great. All those containers could connect to one another using internal IP addresses and the docker containers could connect to the outside world (internet) as well.
However, now that I'm trying to set everything up from scratch again it seems like no matter how I define the custom network in docker any docker containers running using that network have no internet access. For example, I'm defining the network using: "docker network create --subnet=172.1.0.0/24 letsencrypt-nginx"
Then if I run any docker container and have it run on that network and give it an ip in that subnet (say, 172.1.0.20), that container cannot connect to the internet. This has been frustrating me to no end for 2 hours now so I decided to resort to asking for help here in the forums.
If anyone can tell me how I can allow my containers connected to my custom network access to the internet I'd appreciate it!
-
I like that unRAID allows me to have redundant disk arrays using disks of various sizes so I don't have to throw away old smaller disks I have.
I would like to see built-in unRAID support for letsencrypt certificates.
-
Hi all,
I'm having issues where the rTorrent process is failing to start. I've enabled the debug log and I just see multiple:
2019-12-22 18:52:27,735 DEBG 'watchdog-script' stdout output: [debug] Waiting for rTorrent process to start... 2019-12-22 18:52:28,744 DEBG 'watchdog-script' stdout output: [debug] Waiting for rTorrent process to start... 2019-12-22 18:52:29,760 DEBG 'watchdog-script' stdout output: [debug] Waiting for rTorrent process to start...And then:
2019-12-22 18:52:34,820 DEBG 'watchdog-script' stdout output: [warn] Wait for rTorrent process to start aborted, too many retries 2019-12-22 18:52:34,827 DEBG 'watchdog-script' stdout output: [info] Autodl-irssi not enabled, skipping startup 2019-12-22 18:52:34,828 DEBG 'watchdog-script' stdout output: [info] Initialising ruTorrent plugins (checking rTorrent is running)...I've created a bash shell into the running Docker container and verified my VPN connection to AirVPN is running correctly and I can ping google.com successfully. Also, if I go into /home/nobody and:
export vpn_ip=x.x.x.x export external_ip=y.y.y.y ./rtorrent.shThen rTorrent launches and everything seems fine. But, then after that if I restart the container the rTorrent process will again fail to start.
It's not immediately clear to me where I can see log files to tell why rTorrent is failing to start so I'm a bit stuck right now. Would appreciate some help at this point. Thanks!
-
On 3/6/2018 at 7:20 PM, c0nfuzed said:
I just found a bug, it only appears to have started recently so I suspect something changed at my VPN provider.
The script that detects my public IP fails about 90% of the time because ...
# from /root/getvpnextip.sh $(dig -b ${vpn_ip} TXT +short o-o.myaddr.l.google.com @${pri_ns} 2> /dev/null | tr -d '"')returns a IPv6 address rather than IPv4 as expected by the script.
Additionally, and I'm not sure why, but when it does return an IPV4 address it is always different than what I get from
curl ipinfo.io/ipby exactly 1... so if google's dns is reporting my IP is 1.1.1.1 then ipinfo.io/ip is reporting that it's 1.1.1.2... I don't fully understand why they would be different, but I fear that googles dns is wrong... might explain why I am not seeding as well as I would like.
Were you ever able to solve this issue? I'm also using Mullvad and I'm having the exact same issue...
Strange Dockers? Anyone know what these are?
in General Support
Posted
here you go
unraid-diagnostics-20211115-0926.zip