11:17 a.m.
I'm actually embarrassed to be asking this, because the answer must be
so obvious that I can't see it. Fresh eyes will no doubt see the
problem immediately.
I've set up a small Fedora server instance in a KVM/QEMU guest. There's
no DE because I want to use it to run qbittorrent-nox (i.e. headless)
in an isolated environment. I've enabled HTTP using firewall-cmd. Ssh
into the guest works. General net access out of the guest works (e.g.
dnf, ping, nfs client etc.). Qbittorrent-nox runs in daemon mode with
no complaints. However trying to access it from a browser on the host
returns "connection refused". I can't even telnet to port 8080 (the
default). I've turned off SElinux just in case, but it makes no
difference.
A gentle hint would be welcome.
poc
11:21 a.m.
On 09/06/2018 09:17 AM, Patrick O'Callaghan wrote:
I'm actually embarrassed to be asking this, because the answer
must be
so obvious that I can't see it. Fresh eyes will no doubt see the
problem immediately.
I've set up a small Fedora server instance in a KVM/QEMU guest. There's
no DE because I want to use it to run qbittorrent-nox (i.e. headless)
in an isolated environment. I've enabled HTTP using firewall-cmd. Ssh
into the guest works. General net access out of the guest works (e.g.
dnf, ping, nfs client etc.). Qbittorrent-nox runs in daemon mode with
no complaints. However trying to access it from a browser on the host
returns "connection refused". I can't even telnet to port 8080 (the
default). I've turned off SElinux just in case, but it makes no
difference.
A gentle hint would be welcome.
Uhm, HTTP is port 80, not port 8080. You'd need to permit TCP/8080 in
firewall-cmd:
firewall-cmd --permanent --add-port=8080/tcp
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- Denial. It ain't just a river in Egypt anymore! -
----------------------------------------------------------------------
11:52 a.m.
On Thu, 2018-09-06 at 09:21 -0700, Rick Stevens wrote:
On 09/06/2018 09:17 AM, Patrick O'Callaghan wrote:
> I'm actually embarrassed to be asking this, because the answer must be
> so obvious that I can't see it. Fresh eyes will no doubt see the
> problem immediately.
>
> I've set up a small Fedora server instance in a KVM/QEMU guest. There's
> no DE because I want to use it to run qbittorrent-nox (i.e. headless)
> in an isolated environment. I've enabled HTTP using firewall-cmd. Ssh
> into the guest works. General net access out of the guest works (e.g.
> dnf, ping, nfs client etc.). Qbittorrent-nox runs in daemon mode with
> no complaints. However trying to access it from a browser on the host
> returns "connection refused". I can't even telnet to port 8080 (the
> default). I've turned off SElinux just in case, but it makes no
> difference.
>
> A gentle hint would be welcome.
Uhm, HTTP is port 80, not port 8080. You'd need to permit TCP/8080 in
firewall-cmd:
firewall-cmd --permanent --add-port=8080/tcp
I meant the default port for qbittorrent-nox. I already enabled 8080 as
you say.
poc
5:02 a.m.
On Fri, 2018-09-07 at 00:01 +0200, Ulf Volmer wrote:
On 06.09.2018 23:51, Patrick O'Callaghan wrote:
> On Thu, 2018-09-06 at 18:58 +0200, Ulf Volmer wrote:
> > ss -anlt | grep 8080
> >
> > executed in the guest?
>
> LISTEN 0 50 0.0.0.42:8080 0.0.0.0:*
0.0.0.42? honestly?
Yes, definitely. Just ran it again to verify.
poc
6:34 a.m.
On 09/07/18 18:02, Patrick O'Callaghan wrote:
On Fri, 2018-09-07 at 00:01 +0200, Ulf Volmer wrote:
> On 06.09.2018 23:51, Patrick O'Callaghan wrote:
>> On Thu, 2018-09-06 at 18:58 +0200, Ulf Volmer wrote:
>>> ss -anlt | grep 8080
>>>
>>> executed in the guest?
>> LISTEN 0 50 0.0.0.42:8080 0.0.0.0:*
> 0.0.0.42? honestly?
Yes, definitely. Just ran it again to verify.
Have you tried what I did to resolve the problem?
I had the same results as the above on a VBox VM
Downgrading to qbittorrent-nox-4.1.1-1.fc28
Fixed it for me....
--
Conjecture is just a conclusion based on incomplete information. It isn't a fact.
10:38 a.m.
On Fri, 2018-09-07 at 19:34 +0800, Ed Greshko wrote:
On 09/07/18 18:02, Patrick O'Callaghan wrote:
> On Fri, 2018-09-07 at 00:01 +0200, Ulf Volmer wrote:
> > On 06.09.2018 23:51, Patrick O'Callaghan wrote:
> > > On Thu, 2018-09-06 at 18:58 +0200, Ulf Volmer wrote:
> > > > ss -anlt | grep 8080
> > > >
> > > > executed in the guest?
> > >
> > > LISTEN 0 50 0.0.0.42:8080 0.0.0.0:*
> >
> > 0.0.0.42? honestly?
>
> Yes, definitely. Just ran it again to verify.
Have you tried what I did to resolve the problem?
I had the same results as the above on a VBox VM
Downgrading to qbittorrent-nox-4.1.1-1.fc28
Fixed it for me....
I confirm, that fixed it.
Thanks Ed and all who chipped in.
poc
6:44 a.m.
On 07.09.2018 12:02, Patrick O'Callaghan wrote:
On Fri, 2018-09-07 at 00:01 +0200, Ulf Volmer wrote:
> On 06.09.2018 23:51, Patrick O'Callaghan wrote:
>> On Thu, 2018-09-06 at 18:58 +0200, Ulf Volmer wrote:
>>> ss -anlt | grep 8080
>>>
>>> executed in the guest?
>>
>> LISTEN 0 50 0.0.0.42:8080 0.0.0.0:*
>
> 0.0.0.42? honestly?
Yes, definitely. Just ran it again to verify.
That is totally broken from my point of view. 0.0.0.42 is not a valid ip
address.
Maybe
https://www.reddit.com/r/qBittorrent/comments/99vzfk/new_nox_install_list...
is related.
best regards
Ulf
10:16 a.m.
On Fri, 2018-09-07 at 13:44 +0200, Ulf Volmer wrote:
On 07.09.2018 12:02, Patrick O'Callaghan wrote:
> On Fri, 2018-09-07 at 00:01 +0200, Ulf Volmer wrote:
> > On 06.09.2018 23:51, Patrick O'Callaghan wrote:
> > > On Thu, 2018-09-06 at 18:58 +0200, Ulf Volmer wrote:
> > > > ss -anlt | grep 8080
> > > >
> > > > executed in the guest?
> > >
> > > LISTEN 0 50 0.0.0.42:8080 0.0.0.0:*
> >
> > 0.0.0.42? honestly?
>
> Yes, definitely. Just ran it again to verify.
That is totally broken from my point of view. 0.0.0.42 is not a valid ip
address.
Maybe
https://www.reddit.com/r/qBittorrent/comments/99vzfk/new_nox_install_list...
is related.
Yes, that is clearly the same issue and was introduced in version
4.1.2. Apparently version 4.1.3 fixes it (or going back to 4.1.1 as Ed
says).
poc
12:22 p.m.
On Thu, 06 Sep 2018 17:17:21 +0100
Patrick O'Callaghan wrote:
A gentle hint would be welcome.
Unless you are using an honest to gosh bridge, the network
on the VMs is not accessible to the host (at least that's
what I've read). Using Mactavish networking (or whatever
the heck it is called) don't work for host access.
(OK, macvtap, no mactavish :-).
12:54 p.m.
On 09/06/2018 10:22 AM, Tom Horsley wrote:
On Thu, 06 Sep 2018 17:17:21 +0100
Patrick O'Callaghan wrote:
> A gentle hint would be welcome.
Unless you are using an honest to gosh bridge, the network
on the VMs is not accessible to the host (at least that's
what I've read). Using Mactavish networking (or whatever
the heck it is called) don't work for host access.
No, the 192.168.122.0/24 should be available from the host machine.
You DO have to hit the VM's 192.168.122.* address from the host.
If you want the VM to be available from the outside world, then
yeah, you need a full-up bridge and not a NAT.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- Let us think the unthinkable. Let us do the undoable. Let us -
- prepare to grapple with the ineffable itself, and see if we may -
- not eff it up after all. -
- -- Douglas Adams -
----------------------------------------------------------------------
4:55 p.m.
On Thu, 2018-09-06 at 10:54 -0700, Rick Stevens wrote:
On 09/06/2018 10:22 AM, Tom Horsley wrote:
> On Thu, 06 Sep 2018 17:17:21 +0100
> Patrick O'Callaghan wrote:
>
> > A gentle hint would be welcome.
>
> Unless you are using an honest to gosh bridge, the network
> on the VMs is not accessible to the host (at least that's
> what I've read). Using Mactavish networking (or whatever
> the heck it is called) don't work for host access.
No, the 192.168.122.0/24 should be available from the host machine.
You DO have to hit the VM's 192.168.122.* address from the host.
If you want the VM to be available from the outside world, then
yeah, you need a full-up bridge and not a NAT.
OK, that may be necessary for what I want to do, but it doesn't explain
why I can't reach the guest from a browser in the host.
poc
5:06 p.m.
On Thu, 2018-09-06 at 10:54 -0700, Rick Stevens wrote:
On 09/06/2018 10:22 AM, Tom Horsley wrote:
> On Thu, 06 Sep 2018 17:17:21 +0100
> Patrick O'Callaghan wrote:
>
> > A gentle hint would be welcome.
>
> Unless you are using an honest to gosh bridge, the network
> on the VMs is not accessible to the host (at least that's
> what I've read). Using Mactavish networking (or whatever
> the heck it is called) don't work for host access.
No, the 192.168.122.0/24 should be available from the host machine.
You DO have to hit the VM's 192.168.122.* address from the host.
If you want the VM to be available from the outside world, then
yeah, you need a full-up bridge and not a NAT.
When in doubt, simplify. I set up a basic web server by doing:
$ python -m SimpleHTTPServer
(which listens on 0.0.0.0:8000), opened the port in the firewall and
tried to browse from the host. Same result. So it's not a bug in
qbittorrent-nox.
poc
5:13 p.m.
On 09/06/2018 03:06 PM, Patrick O'Callaghan wrote:
On Thu, 2018-09-06 at 10:54 -0700, Rick Stevens wrote:
> On 09/06/2018 10:22 AM, Tom Horsley wrote:
>> On Thu, 06 Sep 2018 17:17:21 +0100
>> Patrick O'Callaghan wrote:
>>
>>> A gentle hint would be welcome.
>>
>> Unless you are using an honest to gosh bridge, the network
>> on the VMs is not accessible to the host (at least that's
>> what I've read). Using Mactavish networking (or whatever
>> the heck it is called) don't work for host access.
>
> No, the 192.168.122.0/24 should be available from the host machine.
> You DO have to hit the VM's 192.168.122.* address from the host.
> If you want the VM to be available from the outside world, then
> yeah, you need a full-up bridge and not a NAT.
When in doubt, simplify. I set up a basic web server by doing:
$ python -m SimpleHTTPServer
(which listens on 0.0.0.0:8000), opened the port in the firewall and
tried to browse from the host. Same result. So it's not a bug in
qbittorrent-nox.
That you can access the vm with ssh says the vm is already accessible
via the existing networking.
There's always tcpdump. On the host it would show whether traffic is
going both ways. On the guest it would show whether traffic is making
through the network and firewall.
:m
7:10 a.m.
On Thu, 2018-09-06 at 15:13 -0700, Mike Wright wrote:
On 09/06/2018 03:06 PM, Patrick O'Callaghan wrote:
> On Thu, 2018-09-06 at 10:54 -0700, Rick Stevens wrote:
> > On 09/06/2018 10:22 AM, Tom Horsley wrote:
> > > On Thu, 06 Sep 2018 17:17:21 +0100
> > > Patrick O'Callaghan wrote:
> > >
> > > > A gentle hint would be welcome.
> > >
> > > Unless you are using an honest to gosh bridge, the network
> > > on the VMs is not accessible to the host (at least that's
> > > what I've read). Using Mactavish networking (or whatever
> > > the heck it is called) don't work for host access.
> >
> > No, the 192.168.122.0/24 should be available from the host machine.
> > You DO have to hit the VM's 192.168.122.* address from the host.
> > If you want the VM to be available from the outside world, then
> > yeah, you need a full-up bridge and not a NAT.
>
> When in doubt, simplify. I set up a basic web server by doing:
>
> $ python -m SimpleHTTPServer
>
> (which listens on 0.0.0.0:8000), opened the port in the firewall and
> tried to browse from the host. Same result. So it's not a bug in
> qbittorrent-nox.
That you can access the vm with ssh says the vm is already accessible
via the existing networking.
There's always tcpdump. On the host it would show whether traffic is
going both ways. On the guest it would show whether traffic is making
through the network and firewall.
Yes, I'm leaving that (or wireshark) as a last resort.
poc
7 p.m.
On 09/06/2018 03:06 PM, Patrick O'Callaghan wrote:
On Thu, 2018-09-06 at 10:54 -0700, Rick Stevens wrote:
> On 09/06/2018 10:22 AM, Tom Horsley wrote:
>> On Thu, 06 Sep 2018 17:17:21 +0100
>> Patrick O'Callaghan wrote:
>>
>>> A gentle hint would be welcome.
>>
>> Unless you are using an honest to gosh bridge, the network
>> on the VMs is not accessible to the host (at least that's
>> what I've read). Using Mactavish networking (or whatever
>> the heck it is called) don't work for host access.
>
> No, the 192.168.122.0/24 should be available from the host machine.
> You DO have to hit the VM's 192.168.122.* address from the host.
> If you want the VM to be available from the outside world, then
> yeah, you need a full-up bridge and not a NAT.
When in doubt, simplify. I set up a basic web server by doing:
$ python -m SimpleHTTPServer
(which listens on 0.0.0.0:8000), opened the port in the firewall and
tried to browse from the host. Same result. So it's not a bug in
qbittorrent-nox.
You said you can ssh to it from the host. Are you doing that via IP
address or what? And how are you browsing from the host? Are you using
the 192.168.122 network? Is DNS resolving it to some other address?
Did you clear the browser's cache?
The simplest way would be to install the telnet client on the host, then
telnet 192.168.122.whatever 8000
and see if it connects.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- Change is inevitable, except from a vending machine. -
----------------------------------------------------------------------
7:08 a.m.
On Thu, 2018-09-06 at 17:00 -0700, Rick Stevens wrote:
On 09/06/2018 03:06 PM, Patrick O'Callaghan wrote:
> On Thu, 2018-09-06 at 10:54 -0700, Rick Stevens wrote:
> > On 09/06/2018 10:22 AM, Tom Horsley wrote:
> > > On Thu, 06 Sep 2018 17:17:21 +0100
> > > Patrick O'Callaghan wrote:
> > >
> > > > A gentle hint would be welcome.
> > >
> > > Unless you are using an honest to gosh bridge, the network
> > > on the VMs is not accessible to the host (at least that's
> > > what I've read). Using Mactavish networking (or whatever
> > > the heck it is called) don't work for host access.
> >
> > No, the 192.168.122.0/24 should be available from the host machine.
> > You DO have to hit the VM's 192.168.122.* address from the host.
> > If you want the VM to be available from the outside world, then
> > yeah, you need a full-up bridge and not a NAT.
>
> When in doubt, simplify. I set up a basic web server by doing:
>
> $ python -m SimpleHTTPServer
>
> (which listens on 0.0.0.0:8000), opened the port in the firewall and
> tried to browse from the host. Same result. So it's not a bug in
> qbittorrent-nox.
You said you can ssh to it from the host. Are you doing that via IP
address or what?
IP address (via /etc/hosts).
And how are you browsing from the host? Are you using
the 192.168.122 network?
Using the explicit IP address and port.
Is DNS resolving it to some other address?
Did you clear the browser's cache?
The simplest way would be to install the telnet client on the host, then
telnet 192.168.122.whatever 8000
and see if it connects.
I'd need to enable a telnet server on the guest, but I don't see what
that would shows as ssh already works. IOW there is definitely two-way
communication between host and guest.
poc
8:30 a.m.
On 09/07/18 20:08, Patrick O'Callaghan wrote:
On Thu, 2018-09-06 at 17:00 -0700, Rick Stevens wrote:
> On 09/06/2018 03:06 PM, Patrick O'Callaghan wrote:
>> On Thu, 2018-09-06 at 10:54 -0700, Rick Stevens wrote:
>>> On 09/06/2018 10:22 AM, Tom Horsley wrote:
>>>> On Thu, 06 Sep 2018 17:17:21 +0100
>>>> Patrick O'Callaghan wrote:
>>>>
>>>>> A gentle hint would be welcome.
>>>> Unless you are using an honest to gosh bridge, the network
>>>> on the VMs is not accessible to the host (at least that's
>>>> what I've read). Using Mactavish networking (or whatever
>>>> the heck it is called) don't work for host access.
>>> No, the 192.168.122.0/24 should be available from the host machine.
>>> You DO have to hit the VM's 192.168.122.* address from the host.
>>> If you want the VM to be available from the outside world, then
>>> yeah, you need a full-up bridge and not a NAT.
>> When in doubt, simplify. I set up a basic web server by doing:
>>
>> $ python -m SimpleHTTPServer
>>
>> (which listens on 0.0.0.0:8000), opened the port in the firewall and
>> tried to browse from the host. Same result. So it's not a bug in
>> qbittorrent-nox.
> You said you can ssh to it from the host. Are you doing that via IP
> address or what?
IP address (via /etc/hosts).
> And how are you browsing from the host? Are you using
> the 192.168.122 network?
Using the explicit IP address and port.
> Is DNS resolving it to some other address?
> Did you clear the browser's cache?
>
> The simplest way would be to install the telnet client on the host, then
>
> telnet 192.168.122.whatever 8000
>
> and see if it connects.
I'd need to enable a telnet server on the guest, but I don't see what
that would shows as ssh already works. IOW there is definitely two-way
communication between host and guest.
Why would you need a telnet server?
--
Conjecture is just a conclusion based on incomplete information. It isn't a fact.
10:26 a.m.
On Fri, 2018-09-07 at 21:30 +0800, Ed Greshko wrote:
> I'd need to enable a telnet server on the guest, but I
don't see what
> that would shows as ssh already works. IOW there is definitely two-way
> communication between host and guest.
>
Why would you need a telnet server?
Brain-freeze, forget it.
poc
7:16 a.m.
On 09/07/18 06:06, Patrick O'Callaghan wrote:
On Thu, 2018-09-06 at 10:54 -0700, Rick Stevens wrote:
> On 09/06/2018 10:22 AM, Tom Horsley wrote:
>> On Thu, 06 Sep 2018 17:17:21 +0100
>> Patrick O'Callaghan wrote:
>>
>>> A gentle hint would be welcome.
>> Unless you are using an honest to gosh bridge, the network
>> on the VMs is not accessible to the host (at least that's
>> what I've read). Using Mactavish networking (or whatever
>> the heck it is called) don't work for host access.
> No, the 192.168.122.0/24 should be available from the host machine.
> You DO have to hit the VM's 192.168.122.* address from the host.
> If you want the VM to be available from the outside world, then
> yeah, you need a full-up bridge and not a NAT.
When in doubt, simplify. I set up a basic web server by doing:
$ python -m SimpleHTTPServer
(which listens on 0.0.0.0:8000), opened the port in the firewall and
tried to browse from the host. Same result. So it's not a bug in
qbittorrent-nox.
Works fine for me....
[egreshko@f28efi ~]$ python -m SimpleHTTPServer &
[1] 5056
[egreshko@f28efi ~]$ Serving HTTP on 0.0.0.0 port 8000 ...
[egreshko@f28efi ~]$ telnet localhost 8000
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
^]
telnet> close
Connection closed.
Wonder why the author didn't also bind to IPv6. :-)
--
Conjecture is just a conclusion based on incomplete information. It isn't a fact.
10:26 a.m.
On Fri, 2018-09-07 at 20:16 +0800, Ed Greshko wrote:
On 09/07/18 06:06, Patrick O'Callaghan wrote:
> On Thu, 2018-09-06 at 10:54 -0700, Rick Stevens wrote:
> > On 09/06/2018 10:22 AM, Tom Horsley wrote:
> > > On Thu, 06 Sep 2018 17:17:21 +0100
> > > Patrick O'Callaghan wrote:
> > >
> > > > A gentle hint would be welcome.
> > >
> > > Unless you are using an honest to gosh bridge, the network
> > > on the VMs is not accessible to the host (at least that's
> > > what I've read). Using Mactavish networking (or whatever
> > > the heck it is called) don't work for host access.
> >
> > No, the 192.168.122.0/24 should be available from the host machine.
> > You DO have to hit the VM's 192.168.122.* address from the host.
> > If you want the VM to be available from the outside world, then
> > yeah, you need a full-up bridge and not a NAT.
>
> When in doubt, simplify. I set up a basic web server by doing:
>
> $ python -m SimpleHTTPServer
>
> (which listens on 0.0.0.0:8000), opened the port in the firewall and
> tried to browse from the host. Same result. So it's not a bug in
> qbittorrent-nox.
Works fine for me....
[egreshko@f28efi ~]$ python -m SimpleHTTPServer &
[1] 5056
[egreshko@f28efi ~]$ Serving HTTP on 0.0.0.0 port 8000 ...
[egreshko@f28efi ~]$ telnet localhost 8000
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
^]
telnet> close
Connection closed.
Wonder why the author didn't also bind to IPv6. :-)
It works locally, but that wasn't the test. I wanted to try an HTTP
session from the host to the guest so as to remove qbt as a factor.
poc
4:52 p.m.
On Thu, 2018-09-06 at 13:22 -0400, Tom Horsley wrote:
On Thu, 06 Sep 2018 17:17:21 +0100
Patrick O'Callaghan wrote:
> A gentle hint would be welcome.
Unless you are using an honest to gosh bridge, the network
on the VMs is not accessible to the host (at least that's
what I've read). Using Mactavish networking (or whatever
the heck it is called) don't work for host access.
I can ssh into the guest from the host. Since I didn't do anything
special when setting up the VM, I assume it's using bridged networking.
poc
7:11 p.m.
On 09/07/18 00:17, Patrick O'Callaghan wrote:
I'm actually embarrassed to be asking this, because the answer
must be
so obvious that I can't see it. Fresh eyes will no doubt see the
problem immediately.
I've set up a small Fedora server instance in a KVM/QEMU guest. There's
no DE because I want to use it to run qbittorrent-nox (i.e. headless)
in an isolated environment. I've enabled HTTP using firewall-cmd. Ssh
into the guest works. General net access out of the guest works (e.g.
dnf, ping, nfs client etc.). Qbittorrent-nox runs in daemon mode with
no complaints. However trying to access it from a browser on the host
returns "connection refused". I can't even telnet to port 8080 (the
default). I've turned off SElinux just in case, but it makes no
difference.
A gentle hint would be welcome.
Read every post in this thread. Especially the output of....
ss -anlt | grep 8080
Installed the most recent version of qbittorrent-nox on my VBox VM and had the same
issues.
Checked the qbittorent forums, found others had a problem.
Downloaded and installed qbittorrent-nox-4.1.1-1.fc28.x86_64.rpm from koji
[egreshko@f28efi ~]$ qbittorrent-nox -d
[egreshko@f28efi ~]$ ss -anlt | grep 8080
LISTEN 0 50 *:8080 *:*
[egreshko@f28efi ~]$ telnet localhost 8080
Trying ::1...
Connected to localhost.
Escape character is '^]'.
^]
telnet> close
Connection closed.
Bugzilla time?
--
Conjecture is just a conclusion based on incomplete information. It isn't a fact.
6:56 a.m.
On Fri, 2018-09-07 at 08:11 +0800, Ed Greshko wrote:
On 09/07/18 00:17, Patrick O'Callaghan wrote:
> I'm actually embarrassed to be asking this, because the answer must be
> so obvious that I can't see it. Fresh eyes will no doubt see the
> problem immediately.
>
> I've set up a small Fedora server instance in a KVM/QEMU guest. There's
> no DE because I want to use it to run qbittorrent-nox (i.e. headless)
> in an isolated environment. I've enabled HTTP using firewall-cmd. Ssh
> into the guest works. General net access out of the guest works (e.g.
> dnf, ping, nfs client etc.). Qbittorrent-nox runs in daemon mode with
> no complaints. However trying to access it from a browser on the host
> returns "connection refused". I can't even telnet to port 8080 (the
> default). I've turned off SElinux just in case, but it makes no
> difference.
>
> A gentle hint would be welcome.
Read every post in this thread. Especially the output of....
ss -anlt | grep 8080
Installed the most recent version of qbittorrent-nox on my VBox VM and had the same
issues.
Checked the qbittorent forums, found others had a problem.
Downloaded and installed qbittorrent-nox-4.1.1-1.fc28.x86_64.rpm from koji
I'm not seeing any qbt-nox packages on Koji, just qbt itself. They must
be there but the search shows up empty.
[egreshko@f28efi ~]$ qbittorrent-nox -d
[egreshko@f28efi ~]$ ss -anlt | grep 8080
LISTEN 0 50 *:8080 *:*
[egreshko@f28efi ~]$ telnet localhost 8080
Trying ::1...
Connected to localhost.
Escape character is '^]'.
^]
telnet> close
Connection closed.
Fascinating. I look forward to trying it, although I don't understand
why my 'python SimpleHTTPServer' example doesn't work either.
Bugzilla time?
In due course.
poc
7:02 a.m.
On 09/07/18 19:56, Patrick O'Callaghan wrote:
I'm not seeing any qbt-nox packages on Koji, just qbt itself.
They must
be there but the search shows up empty.
It is produced when qbittorrent it built.
Download from here....
https://koji.fedoraproject.org/koji/buildinfo?buildID=1086540
--
Conjecture is just a conclusion based on incomplete information. It isn't a fact.
10:18 a.m.
On Fri, 2018-09-07 at 20:02 +0800, Ed Greshko wrote:
On 09/07/18 19:56, Patrick O'Callaghan wrote:
> I'm not seeing any qbt-nox packages on Koji, just qbt itself. They must
> be there but the search shows up empty.
It is produced when qbittorrent it built.
Download from here....
https://koji.fedoraproject.org/koji/buildinfo?buildID=1086540
OK, thanks. A search for the RPM should show it too but that appears to
be broken (just spins endlessly with no results).
Anyway ...
poc
5:41 p.m.
Patrick O'Callaghan wrote:
On Fri, 2018-09-07 at 20:02 +0800, Ed Greshko wrote:
> On 09/07/18 19:56, Patrick O'Callaghan wrote:
>> I'm not seeing any qbt-nox packages on Koji, just qbt itself. They must
>> be there but the search shows up empty.
>
>
> It is produced when qbittorrent it built.
>
> Download from here....
>
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1086540
OK, thanks. A search for the RPM should show it too but that appears to
be broken (just spins endlessly with no results).
AFAIK, the package search in koji is for source package
names, so you don't get results searching for subpackages
(or for binary rpms where the name differs from the source
package name, like in the case of many python-$module srpms
which produce python[23]-$module rpms).
--
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Whenever you find yourself on the side of the majority, it is time to
pause and reflect.
-- Mark Twain
4:10 a.m.
On Fri, 2018-09-07 at 18:41 -0400, Todd Zullinger wrote:
Patrick O'Callaghan wrote:
> On Fri, 2018-09-07 at 20:02 +0800, Ed Greshko wrote:
> > On 09/07/18 19:56, Patrick O'Callaghan wrote:
> > > I'm not seeing any qbt-nox packages on Koji, just qbt itself. They
must
> > > be there but the search shows up empty.
> >
> >
> > It is produced when qbittorrent it built.
> >
> > Download from here....
> >
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=1086540
>
> OK, thanks. A search for the RPM should show it too but that appears to
> be broken (just spins endlessly with no results).
AFAIK, the package search in koji is for source package
names, so you don't get results searching for subpackages
(or for binary rpms where the name differs from the source
package name, like in the case of many python-$module srpms
which produce python[23]-$module rpms).
The default search is for package names. There is also an option to
search for RPMs. That doesn't appear to be working.
poc
6:47 a.m.
On Sat, 2018-09-08 at 18:17 +0800, Ed Greshko wrote:
On 9/8/18 5:10 PM, Patrick O'Callaghan wrote:
> The default search is for package names. There is also an option to
> search for RPMs. That doesn't appear to be working.
FWIW, search for qbittorrent-nox* as a regex with RPM's selected works for me.
I tried it your way and it did work, but took well over a minute.
My original search (which I just repeated) took something like 5
minutes and returned no results, so the RPM search doesn't work the
same way as the Package search. With the latter it's sufficient to give
the package base name (regex expressions also work), but apparently
with the former you must give a regex or the full name of the package.
poc
2056
days inactive
2058
days old
31 comments
7 participants
participants (7)
-
Ed Greshko -
Mike Wright -
Patrick O'Callaghan -
Rick Stevens -
Todd Zullinger -
Tom Horsley -
Ulf Volmer