Problems with remote client control

Message boards : Questions and problems : Problems with remote client control
Message board moderation

To post messages, you must log in.

AuthorMessage
richard636

Send message
Joined: 17 Dec 18
Posts: 8
Italy
Message 89833 - Posted: 29 Jan 2019, 19:49:24 UTC

Hi everyone, I am running a BOINC client on a headless pc, BOINC version is 7.14.2 and the os is CentOS 7.
I wanted to try controlling the client remotely from my pc with Manjaro Linux and BOINC Manager version 7.12.1.

I looked up online how to do this and on the headless pc I created the file remote_hosts.cfg in the BOINC data directory which for my CentOS machine is /var/lib/boinc that contains the IP address of the Manjaro pc.

Then on the Manjaro pc I try File->Select computer and I input the host name of the headless machine and the password that is in the gui_rpc_auth.cfg file but the manager keeps saying that it is connecting to the specified host name but nothing happens.

I rebooted both machines and just to be clear they don't have a connection problem because they can talk through SSH with each other.

Now I'm not sure if I'm making a mistake here but I don't know what's wrong. I'm thinking maybe it's the port being blocked, what is the default port that is used for remote control? If it's not the port what could it be?
Thanks to everyone that helps me.
ID: 89833 · Report as offensive
Profile Keith Myers
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 17 Nov 16
Posts: 863
United States
Message 89852 - Posted: 30 Jan 2019, 4:12:44 UTC - in response to Message 89833.  

The BOINC port is 31416.
ID: 89852 · Report as offensive
richard636

Send message
Joined: 17 Dec 18
Posts: 8
Italy
Message 89856 - Posted: 30 Jan 2019, 8:37:55 UTC - in response to Message 89852.  

I checked with nmap and I get:

PORT STATE SERVICE
31416/tcp open boinc

on both computers, I also tried using another pc to control the boinc client but the manager still says "connecting to hostname" but it doesn't do anything.
ID: 89856 · Report as offensive
MarkJ
Volunteer tester
Help desk expert

Send message
Joined: 5 Mar 08
Posts: 272
Australia
Message 89857 - Posted: 30 Jan 2019, 10:11:55 UTC

Have you got an IP address or host name in remote_hosts.cfg that allows the host you are connecting from?

Have you entered the password that is in gui_rpc_auth.cfg (on the host you are connecting to) into the BOINC manager that is trying to connect?

You need both of these as well as the port being open. If you update these files you need to restart the core client to pickup the changes.
MarkJ
ID: 89857 · Report as offensive
richard636

Send message
Joined: 17 Dec 18
Posts: 8
Italy
Message 89858 - Posted: 30 Jan 2019, 10:34:16 UTC - in response to Message 89857.  

Have you got an IP address or host name in remote_hosts.cfg that allows the host you are connecting from?

Have you entered the password that is in gui_rpc_auth.cfg (on the host you are connecting to) into the BOINC manager that is trying to connect?

You need both of these as well as the port being open. If you update these files you need to restart the core client to pickup the changes.


Yes I actually said that in the beginning, to be more clear:

on the headless pc I have the file remote_hosts.cfg in /var/lib/boinc that contains the IP address of the computer I want to use to connect to the headless pc, in particular the file has written inside:

192.168.178.26
192.168.178.21

which are the IP addresses of 2 machines I want to connect from; I also used the password in gui_rpc_auth.cfg of the headless pc; computers have been rebooted after changes so the client has been restarted. It doesn't work. Do I need to put more info in the remote_hosts.cfg file?
ID: 89858 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 5078
United Kingdom
Message 89859 - Posted: 30 Jan 2019, 11:28:47 UTC

Purely for testing purposes while you try to sort this out, are you able to verify independently that the BOINC client is actually running on the headless machine? Probably 90% of the "can't connect to client" problems we investigate turn out to be "client wasn't running, so there's nothing to connect to".

If the client is actually running, the next stage would be to try to locate the persistent Event Log file (stdoutdae) on the headless machine, and see if that contains any clues.
ID: 89859 · Report as offensive
richard636

Send message
Joined: 17 Dec 18
Posts: 8
Italy
Message 89861 - Posted: 30 Jan 2019, 12:40:22 UTC - in response to Message 89859.  
Last modified: 30 Jan 2019, 12:41:27 UTC

Purely for testing purposes while you try to sort this out, are you able to verify independently that the BOINC client is actually running on the headless machine? Probably 90% of the "can't connect to client" problems we investigate turn out to be "client wasn't running, so there's nothing to connect to".

If the client is actually running, the next stage would be to try to locate the persistent Event Log file (stdoutdae) on the headless machine, and see if that contains any clues.


The headless machine is basically just running for BOINC, so yes I always check the client status and it is always running, I usually monitor the computer with htop or glances.

I've been told that in my client version the log doesn't go in stdoutdae.txt(that doesn't exist) anymore but in a system log, I can find boinc log messages in /var/log/messages that look like this:

......
Jan 30 13:08:43 scientific-centos boinc: 30-Jan-2019 13:08:43 [GPUGRID] Scheduler request completed
Jan 30 13:11:51 scientific-centos boinc: 30-Jan-2019 13:11:51 [NFS@Home] Computation for task 7m5_329_138720_0 finished
Jan 30 13:11:51 scientific-centos boinc: 30-Jan-2019 13:11:51 [NFS@Home] Starting task C196_3366_2183_339792_0
Jan 30 13:11:53 scientific-centos boinc: 30-Jan-2019 13:11:53 [NFS@Home] Started upload of 7m5_329_138720_0_r1142676493_0
Jan 30 13:12:00 scientific-centos boinc: 30-Jan-2019 13:12:00 [NFS@Home] Finished upload of 7m5_329_138720_0_r1142676493_0
......

In this log file there is nothing that I can see that relates to remote access, is there any other log file I may not be aware of?
ID: 89861 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 5078
United Kingdom
Message 89862 - Posted: 30 Jan 2019, 13:10:30 UTC - in response to Message 89861.  

I've been told that in my client version the log doesn't go in stdoutdae.txt(that doesn't exist) anymore but in a system log, I can find boinc log messages in /var/log/messages that look like this:

......
Jan 30 13:08:43 scientific-centos boinc: 30-Jan-2019 13:08:43 [GPUGRID] Scheduler request completed
Jan 30 13:11:51 scientific-centos boinc: 30-Jan-2019 13:11:51 [NFS@Home] Computation for task 7m5_329_138720_0 finished
Jan 30 13:11:51 scientific-centos boinc: 30-Jan-2019 13:11:51 [NFS@Home] Starting task C196_3366_2183_339792_0
Jan 30 13:11:53 scientific-centos boinc: 30-Jan-2019 13:11:53 [NFS@Home] Started upload of 7m5_329_138720_0_r1142676493_0
Jan 30 13:12:00 scientific-centos boinc: 30-Jan-2019 13:12:00 [NFS@Home] Finished upload of 7m5_329_138720_0_r1142676493_0
......

In this log file there is nothing that I can see that relates to remote access, is there any other log file I may not be aware of?
OK, useful check - we can cross off some of the obvious possibilities.

BOINC does create stderr logs as well as stdout, but I doubt there will be anything of use. You can add extra reporting to the stdoutdae log by creating a cc_config.xml file and setting logging flags: the only one which might be useful here is <gui_rpc_debug>. That would at least indicate whether the remote request is reaching the client.

You should also double-check whether a firewall could be implicated, just to be on the safe side.
ID: 89862 · Report as offensive
richard636

Send message
Joined: 17 Dec 18
Posts: 8
Italy
Message 89863 - Posted: 30 Jan 2019, 13:26:55 UTC - in response to Message 89862.  

Thank you I found the problem it was actually the firewall, I didn't know how to properly configure firewalld so I checked.

Just for reference what solved my problem was this:

check zones by running this command in the terminal as root:
firewall-cmd --get-active-zones

for me there was the zone public so i ran the following commands:

firewall-cmd --zone=public --add-port=31416/tcp --permanent
firewall-cmd --reload

and the BOINC manager connected.

Thanks for the help.
ID: 89863 · Report as offensive

Message boards : Questions and problems : Problems with remote client control

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.