OMV6 With qbittorrent and wireguard?

Not seeing what you are looking for.

fred@omv:~$ bashin qbt
root@0f789432cdcb:/opt# ps -aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.0   4412  2876 ?        Ss   05:04   0:01 /bin/bash /etc/qbittorrent/start.sh
qbittor+     205  0.0  0.0   3896  2004 ?        S    05:04   0:00 /bin/bash -c /usr/local/bin/qbittorrent-nox --profile=/config >> /config/qBittorrent/data/logs/qbittorren
qbittor+     207 12.1  9.3 4354548 3063688 ?     Sl   05:04  89:34 /usr/local/bin/qbittorrent-nox --profile=/config
root        4114  0.0  0.0   2392   564 ?        S    17:23   0:00 sleep 30
root        4115  0.3  0.0   4160  3336 pts/0    Ss   17:23   0:00 bash
root        4121  0.0  0.0   6756  2856 pts/0    R+   17:24   0:00 ps -aux
root@0f789432cdcb:/opt# 

Zitat von gderf

Code

fred@omv:~$ bashin qbt

how did you get the bashin command? seems alot easier than exc

Zitat von BlueCoffee

how did you get the bashin command? seems alot easier than exc

Add this code to the end of your ~/.bashrc file:

dexec() {
    docker exec -it "$1" bash
    echo "$1"
}

Then create an alias in your ~/.bash_aliases file:

alias bashin='dexec'

To use, type this in a bash shell on your omv machine:

bashin <container_name>

This will open a bash shell in the container, assuming the container image was created with the bash shell available.

I guess try ps -e .. :-/ Does wireguard distinguish a process name?

Zitat von olduser

I guess try ps -e .. :-/ Does wireguard distinguish a process name?

Not on the container since I don't use it but on host CLI:

pi@panela:~ $ sudo ps -e | grep wg
1248 ?        00:00:00 wg-crypt-wgnet1

Zitat von Soma

Not on the container since I don't use it but on host CLI:

Thanks. I currently can't use wireguard with that container.

gderf I accidentally sent a PR because I was on the wrong page :-/. I'm using the githubs web ui, it can be confusing. I'll message you later today with what I have.

Zitat von olduser

I guess try ps -e .. :-/ Does wireguard distinguish a process name?

Zitat von olduser

gderf I accidentally sent a PR because I was on the wrong page :-/. I'm using the githubs web ui, it can be confusing. I'll message you later today with what I have.

You do plan building your own images from your own github page, right?

Zitat von gderf

You do plan building your own images from your own github page, right?

No, I was just adding to yours, I guess Ignore that conversation I sent you. If I knew you weren't going to maintain it, I probably wouldn't of added anything. I feel dumb, I guess a huge clue should of been that you didn't bother updating the readme.md.

My effort to "maintain it" post DyonR halting his efforts is to provide the image with the current version of Qbt. If the small changes I made don't interest someone (aliases for easy exit and IP check, and binary for Oookla speedtest), they can always build themselves a new image from the DyonR sources on his github page. It's a one liner in the shell:

docker build --no-cache -t qbittorrentvpn:latest https://github.com/DyonR/docker-qbittorrentvpn.git

So long as this continues to work by pulling the latest Qbt sources from their project page and nothing in the build process breaks, anyone can do this themselves as long as their Linux or OMV is set up to compile code. I think that just means adding the build-essential package.

However, if anything in the image build process breaks, I doubt I would be able to fix it as I am not a coder. At that point I would freeze the effort with the last successful build and start looking elsewhere for a replacement.

I think you should attempt an image build from your github page, and if it works, why not keep going, continue to improve it, and offer it up?

Here's a fork of gderf 's qbittorrent image that adds a VPN conf switcher. I didn't add/change much so I'm pretty sure I didn't break anything. I don't plan to update it often and if I ever do, it might be to bring libtorrent from 1.2.x to a 2.x version (2.x apparently isn't stable right now).

I updated the README.md and it's now written to "/config/README.md" on container start. Besides the VPN conf switcher for free/unstable VPNs, I changed the default password back to "adminadmin". There's also a vpn_up.sh and a vpn_down.sh option for health check successes and failures.

The conf switcher is enabled by default, which means there will be an extra directory along side your current VPN directory ending with "_confs". So if you already have /config/openvpn, there will now also be a /config/openvpn_confs. When a health check fails, it will look for a extra conf file (by any filename) in that new directory and swap it out with your current active one. If you use openvpn, make sure the file is named "default.ovpn". Wireguard still has to be "wg0.conf". If you delete this new "_confs" directory or leave it empty, only a message is printed, nothing breaks.

** Note: There's 1 notable change. OpenVPN would get stuck in a loop of failure or exit if it was started with a conf file that had a typo or a bad VPN or something that made it exit or loop. This condition required you to manually restart the container, so there's now a specific option (read README.md) enable by default that will kill -9 it after n seconds and restart it. If you were dependent on that functionality for OpenVPN, set the OpenVPN specific variable to 0, eg. VPN_CONF_SWITCH_OPENVPN_AT_START=0. Wireguard doesn't do that or need that change. (I tested it with free OpenVPN confs and hit 13 bad confs in a row!!! So I had to change that).

GitHub - coldsilk/docker-qbittorrentvpn: Docker container which runs a qBittorent-nox client with an optional WireGuard or OpenVPN connection

Docker container which runs a qBittorent-nox client with an optional WireGuard or OpenVPN connection - coldsilk/docker-qbittorrentvpn

github.com

Use for run/pull: coldsilk/docker-qbittorrent:latest

Nice job with this. Thanks.

Zitat von gderf

Add this code to the end of your ~/.bashrc file:

You can alias the whole thing if you call the function last. Also make sure to semi-colon every new line inside the function and don't use one at the very very end. eg:

alias bashin="docker_bash_into() { sudo docker exec -it "\$1" bash; echo "\$1"; };docker_bash_into" # notice no ';' here at the end

You can use this to truncate/clear logs (I know of no other way):

alias dlogc="docker_log_clear() { sudo truncate -s 0 \$(sudo docker inspect --format='{{.LogPath}}' \$1); };docker_log_clear"

Updated the image a little today, most notably added a HEALTH_CHECK_FAILURES option. It's on by default, set to 3. I was getting "qBittorrent client is not reachable" a little too much.

With HEALTH_CHECK_FAILURES set to 3 and HEALTH_CHECK_INTERVAL set to 30, it will take at least 90 seconds to out right fail and trigger a restart. However, it will be a little longer per interval since the ping command will take time _PER_ host. If ping takes 4 seconds and you're using both of the default hosts "one.one.one.one,8.8.8.8", that will be +8 seconds per interval. Thus, with all defaults, 3 * ( 30 + 8 ) = 114 seconds. Also, the total pings sent per ping is now 3 (HEALTH_CHECK_AMOUNT). If you want more accurate times you will have to test it.

• Added HEALTH_CHECK_FAILURES to check more than once if ping fails on the host(s). I was getting a little too much of red text in the bottom left stating "qBittorrent client is not reachable" only to have the container restart on the same .conf and connect just fine.
• Changed HEALTH_CHECK_HOST to allow for a comma separated list of hosts to ping. All hosts must fail to count as a failure for HEALTH_CHECK_FAILURES. Default is now 2 hosts, "one.one.one.one,8.8.8.8".
• SIGABRT is now sent with a 20 second timeout before restarting. However, I'm not sure it wasn't sent before before but, it definitely is now. This might help save some data/resume data before exiting.
• When installing python, the sleep delay is now set to 5 right before apt update. This gives enough time for the tunnels to come up and help negate connection failures. It was improbable to happen before but, it's now very, very, very improbable. The print for installing python is a lot more noticeable. If it fails to install, it should be easily noticed using docker logs.

• Fixed a bug where $qbittorrentpid's PID was actually the PID of the bash process spawning it.
• Added netcat to the image.
• Updated README.md

I had included python into the image build so that there was no need to install it via an environment variable. Did you undo that?

Zitat von gderf

I had included python into the image build so that there was no need to install it via an environment variable. Did you undo that?

I don't believe so. You've only accepted 2 of my pull requests, both of which went to the same file: qbittorrent/start.sh. The prior editor of that file goes all the way back to DyonR and there the python variable check is also present.

The next modifications I make won't be additions but a break in the fork for quick rewrite. It's pretty obvious that DyonR didn't really care about this image. There's nearly no error checking and it certainly wasn't tested thoroughly with OpenVPN. The health check is clearly in the wrong spot, PID 1 wasn't locked down and the fact that the wrong PID was captured for qbittorrent kind of tells the whole story :-/.

Update:

Qbittorrent has been updated to Release 4.6.4

Release announcement:https://www.qbittorrent.org/news

I have updated the gderf/qbittorrentvpn docker image to this latest version of Qbittorrent.

You can see the list of all my images and their tags, and pull statements here:

https://hub.docker.com/repository/docker/gderf/qbittorrentvpn/tags?page=1&ordering=last_updated

If you pull using the :latest tag in your compose file, you will be upgraded to 4.6.4. If you want to stick with some other release, please use the appropriate tag from the above source.

Zitat von gderf

If you pull using the :latest tag in your compose file, you will be upgraded to 4.6.4.

You mean without any actions? Or does anything need to be restarted?

Zitat von ErikDB

You mean without any actions? Or does anything need to be restarted?

You have to do whatever your use case requires to recreate the container.

Zitat von gderf

You have to do whatever your use case requires to recreate the container.

I'm not really sure what "my use case requires"... I'm on OMV7, so using Compose.

I just tried clicking "down" and "stop" under the "Files" tab. But I assume that wasn't enough:

Do I need to remove the yaml file and recreate it? That doesn't seem like the right answer...?