Only problem is it will run headless but I cannot get Boinc Tasks to connect.
Any help with that would be welcome.

Bernie,
That's the one thing I had no problem with. If you're not already, I would suggest you use MAC address rather than machine name or IP address in the "Computers" definition tab. I've found that the most reliable, as opposed to machine names which is flaky at best, and IP addresses which can be an issue with DHCP.
Other then that, the basics:
1) In cc_config.xml: <allow_remote_gui_rpc>1</allow_remote_gui_rpc>
2) In BOINC directory:
a) gui_rpc_auth.cfg is present and contains password identical to that defined in "Computers" definition of BOINCTasks
b) remote_hosts.cfg is present and contains name of machine running BOINCTasks.
NOTE: On startup I get an error in the BOINC log complaining that it can't resolve the machine name contained in remote_hosts.cfg, but it doesn't seem to prevent the connection. Haven't troubleshot that yet, but will probably involve replacing the Windows machine name with something like a MAC or IP address. Might also be an upper case / lower case issue, given that Win doesn't care and Linux does. Or perhaps since it works anyway the remote_hosts file isn't critical in linux as it is in Windows.
l8r, Jim ...

---

Good point Jimbocous. I forgot to mention the use of the MAC address as a surefire way to identify the host. If you don't have a hosts file that defines the common names of your hosts on your network, then then IP address may not work as well. I have hosts files on all my computers that simplifies identifying them on the network and makes it easier to map their resources to the File Manager for simple access of shares.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Thank for the suggestions, I have done everything suggested, twice possibly 3 times, and nothing works.

If I do the "find computer" by ip address, it never finds it, finds the other 2 but not the new one.

I have added the MAC address, still does not connect.

Thank for the suggestions, I have done everything suggested, twice possibly 3 times, and nothing works.

If I do the "find computer" by ip address, it never finds it, finds the other 2 but not the new one.

I have added the MAC address, still does not connect.

Can you ping the Linux box's IP address from the Win box?

---

Never shows up in the list? Or never changes status from Not Connected to Connected?

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Can you ping the Linux box's IP address from the Win box?

Yes from both my Windows machines.

I can also ping the Win box from the Linux one.

Never shows up in the list? Or never changes status from Not Connected to Connected?

It never shows in the “scan” list and always shows not connected.

It never shows in the “scan” list and always shows not connected.

This statement seems contradictory to me. If it shows in the Computers list but just with status of Not Connected. The computer is "found".
It is just not able to make the connection from the BT host computer to the target computer because of a password issue or for some reason BT can't detect the BOINC client running.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Can you ping the Linux box's IP address from the Win box?

Yes from both my Windows machines.

I can also ping the Win box from the Linux one.

Never shows up in the list? Or never changes status from Not Connected to Connected?

It never shows in the “scan” list and always shows not connected.

OK, so it sees it but can't log in.
Sure sounds like a password problem. Stick with the MAC address scheme, and try one more time of deleting and recreating the password, using a text editor on the Linux side.

---

Can you ping the Linux box's IP address from the Win box?

Yes from both my Windows machines.

I can also ping the Win box from the Linux one.

Never shows up in the list? Or never changes status from Not Connected to Connected?

It never shows in the “scan” list and always shows not connected.

OK, so it sees it but can't log in.
Sure sounds like a password problem. Stick with the MAC address scheme, and try one more time of deleting and recreating the password, using a text editor on the Linux side.

One other note, Bernie. With cc_config set up to allow any host, you'll see a "Config: GUI RPC allowed from any host" in the BOINC event log. One of the last messages in the boot up portion of the event log was "Setting up GUI RPC socket". as well.
Seems like it takes several minutes for the socket to actually connect, after seeing that message. Definitely longer that I'm used to with windows boxes.

---

It never shows in the “scan” list and always shows not connected.

This statement seems contradictory to me. If it shows in the Computers list but just with status of Not Connected. The computer is "found".
It is just not able to make the connection from the BT host computer to the target computer because of a password issue or for some reason BT can't detect the BOINC client running.

Sorry I should have explained, I added the machine manually as I have always done in the past with no problems. When that failed I used the "find computers" option, which finds all the other machines but not this one!

I have just deleted the machine from BT and tried all the steps listed and still it will not connect.

I have put Boinc in the "home" folder as it says, I assume that this does not affect it?

There was no "remote_host.cfg" file and I had to create one using commands which I assume I did correctly as it appeared OK.

Totally out of ideas now!!

No it doesn't matter where you put the BOINC folder. I had another thought. Could it be you have a firewall running on the host you can't connect to? You need to pass port 31416 for BT to be able to "see" the BOINC client.

I had another thought. Have you tried to run the auxiliary program BoincToolbox64.exe? That is the one always suggested by Fred to diagnose why BT can't see a computer to connect. The program is in the eFMer/BoincTasks folder in /home/{username}/.wine/drive_c/Program Files/eFMer/BoincTasks. Why don't you try running that? Or try the AddtoGroup.exe application.

Either of those programs should be able to brute force the host into recognition by BoincTasks.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

There was no "remote_host.cfg" file and I had to create one using commands which I assume I did correctly as it appeared OK.

Totally out of ideas now!!

1. Create a remote_hosts.cfg to tell BOINC which machines are allowed to connect to it The BOINC event log will show you at startup if it found it and what machines you specified.

2. Create a gui_rpc_auth.cfg with some value in it - Put this value into the password column in BT. BOINC will mention if you don't have one in the event log as part of the startup messages.

3. Make sure the BOINC machine isn't blocking port 31416. A ping from the BT machine should prove if its blocked (ping will use port 80 by default). If it seems blocked try the following command on the BOINC machine "sudo iptables -L" (without the quotes and yes thats an uppercase L) and see what it lists. The computers tab in BT will tell you if it thinks its a password issue under the status column.

4. The manager needs to be given the password (the one in gui_rpc_auth). When I add a desktop launcher I have to add "--password xxx" to the end of the command. After that it will be able to connect to the core client. I am not using the all-in-one version so your mileage might vary.

---

BOINC blog

If it seems blocked try the following command on the BOINC machine "sudo iptables -L" (without the quotes and yes thats an uppercase L) and see what it lists. The computers tab in BT will tell you if it thinks its a password issue under the status column.

Well that showed

Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT tcp -- 192.168.1.10 anywhere tcp dpt:31416
ACCEPT udp -- 192.168.1.10 anywhere udp dpt:31416
ACCEPT tcp -- 192.168.1.11 anywhere tcp dpt:31416
ACCEPT udp -- 192.168.1.11 anywhere udp dpt:31416

Those 2 ip's are my two Win machines with BT installed, and it seems that it allows connection via 31416 the BT port.

Makes no sense.

The computers tab in BT just says "not connected."

I just tried to install Wine so I could install BT on the Linux machine, but all that does is say Wine installed but it never appears and won't run.

There is just too much "advice" on the internet about how to do things in Linux.

Even when you have the same version (Ubuntu 18.04) and copy paste a command it often produces a different result.

I think I will crate a separate thread for this as it is a bit off topic.

I have moved most of the post to here so as not to "clutter up" the other thread.

So mentioned both topics so they were left.

If it seems blocked try the following command on the BOINC machine "sudo iptables -L" (without the quotes and yes thats an uppercase L) and see what it lists. The computers tab in BT will tell you if it thinks its a password issue under the status column.

Well that showed

Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT tcp -- 192.168.1.10 anywhere tcp dpt:31416
ACCEPT udp -- 192.168.1.10 anywhere udp dpt:31416
ACCEPT tcp -- 192.168.1.11 anywhere tcp dpt:31416
ACCEPT udp -- 192.168.1.11 anywhere udp dpt:31416

Those 2 ip's are my two Win machines with BT installed, and it seems that it allows connection via 31416 the BT port.

Makes no sense.

The computers tab in BT just says "not connected."

I just tried to install Wine so I could install BT on the Linux machine, but all that does is say Wine installed but it never appears and won't run.

There is just too much "advice" on the internet about how to do things in Linux.

Even when you have the same version (Ubuntu 18.04) and copy paste a command it often produces a different result.

I think I will crate a separate thread for this as it is a bit off topic.

Hi Bernie,

You only need BT on one PC, the one you want to use to control the remote PCs. I have BT on my Windows PC and connect to my Linux box, my Android tablet and my 3 Pis. The other 4 do not have BT installed on them. Try BT just on one PC and see what you get.

Have a great day! :)

Siran

---

CAPT Siran d'Vel'nahr - L L & P _\\//
Winders 11 OS? "What a piece of junk!" - L. Skywalker
"Logic is the cement of our civilization with which we ascend from chaos using reason as our guide." - T'Plana-hath

You only need BT on one PC,

I am aware of that. I have BT on my main PC, however if I am gaming I then like to be able to view Boinc on my second PC, which has a screen next to me.

I have had this set up for years. Initially I only put this new machine on BT on my main. I subsequently added it to my no 2 machine after I could not get it to work on main.

As I have my original Linux machine and my Raspberry Pi on both machines BT, I cannot see how this is problem.

I am pretty sure is something to do with the fact it is not a normal "install" all I did was unzipped the files to the home directory so I suspect BT cannot see them.

PS. Whilst on my walk I remembered that you can connect to another PC using the Boinc Manager, so I decided to try that, Works perfectly. So now I am even more confused. If the Boinc manager on my main machine can connect why can't BT?

OK so as soon as I connected via Boinc Manager BT connected as well!!

I am pretty sure is something to do with the fact it is not a normal "install" all I did was unzipped the files to the home directory so I suspect BT cannot see them.

BOINC Tasks doesn't need to see any files - everything is done using networking (TCP/IP) protocols.

I think MarkJ had the right idea: you need to make sure that the machine you're trying to monitor has

* A GUI PRC password
* GUI RPC authorisation for the name or (perhaps better) IP address of the machine running BT
* firewall access for port 31416

and of course the two machines need to be on the same LAN sub-net. It isn't worth attempting to fiddle with unrelated items outside that shortlist.

* A GUI PRC password

It started working after removing the PW. So it was obviously somehow different, but I could not see how or where. And I did try several different PW's
I will let it run then try a new password later.

I am pretty sure is something to do with the fact it is not a normal "install" all I did was unzipped the files to the home directory so I suspect BT cannot see them.

Sorry for all the repetition, as I know you've been through this, but ...
Doubt that's the problem, as I also installed that way, as indeed seems to be the proper way for this implementation. Further, I initially did it wrong (choosing to install elsewhere) and moved the directory and files twice to get them where they really belonged.
Only thing not totally clear, that solved a problem for me, is that you should open a terminal window, find the BOINC directory and run the binstall.sh shell script. What this does is recreate the run_client and run_manager scripts in that directory to reflect the correct file path, so you can then use these scripts to start the client/manager and have everything running in the right directory. Until I did this, even if I could get the client to start on boot-up, it was writing its files in the home directory rather than the BOINC directory. If you look in /home and there are BOINC xml files there, you're not running in the right directory and this would be an issue for you as the GUI_RPC_auth.cfg file there will contain a random generated password key rather than the password. This may be your problem, in fact. Easy to tell:
1) Shut down the client. Are there BOINC xml files in home that duplicate what's present in home/BOINC? If so, delete them.
2) Start the client, then shut it down. Are the files back in home as well as home/BOINC? If so, again delete them, then
3) View the run-client and run_manager files in /BOINC, and note the contents.
4) From a terminal go to BOINC and run binstall.sh
a) ctl-alt-t to open terminal
b)

cd /BOINC
chmod +x binstall.sh
 ./binstall.sh

5) View the run-client and run_manager files, and note the contents have changed.
In future, start the client using the run_ scripts rather than directory to ensure you're starting in the correct directory.

The only part of the process that didn't give me much trouble was the BT connection, after I fixed the GUI_RPC_auth.cfg file. I had copied it from a Win machine, and the trailing cr/lf issue was causing the client to misread it. Opened it in Linux text editor, copied only the password to a new window, and saved the new version over the old one.
I also copied over the remote_hosts.cfg file from a Win machine, but applying the same "fix" did not resolve the issue of the BM event log complaining that it could not resolve the host names contained within. That's when I discovered that with RPC GUI allowed on cc_config.xml remote_hosts is redundant and deleted it entirely so as the eliminated potential future confusion. Do note that when the GUI_RPC_auth file was a problem, that also prevented BM from connecting to the client.

Let's remember how this all interacts.
BT on the Win machine wants to connect, using the remote address in this case via a specific port designated for RPC calls.
Once it finds the destination machine, and can connect to the socket at that port address, it uses the password to request a session.
The remote client then sees the request and does the following:
1) check if RPC GUI is allowed
a) cc_config.xml has RPC GUI allowed (all hosts) and/or
b) remote_hosts.cfg exists, containing a machiine name that matched what BT presents as its name
2) check if RPC GUI is authorized
a) password exists and matches
b) if BM can connect to client with the password, file is probably OK. Remember case-sensitivity.
On BT:
Success= Connected
Failure = Not connected

So bullet points:
1) GUI RPC allowed msg in BM event log on boot-up (Y/n)
2) GUI RPC socket initialised in BM event log on boot-up (Y/n)
3) No firewall between the two machines that would block the port access.

Not sure what else to suggest here, Bernie, but hopefully it clarifies what's actually happening ... and I'm guessing this solves it.
Later, Jim ...

---

... after I fixed the GUI_RPC_auth.cfg file. I had copied it from a Win machine, and the trailing cr/lf issue was causing the client to misread it...

Which adds another bullet point. The usual advice is to ensure that the password file doesn't have a line terminator, whether cr/lf or otherwise. Think of the password as "the contents of the file", rather than "a line read from the file".