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.

The BOINC port is 31416.

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.

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

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?

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.

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?

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.

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.