boinc icon indicating copy to clipboard operation
boinc copied to clipboard

Boinc manager can't connect to client using "localhost"

Open romw opened this issue 11 years ago • 36 comments

Reported by saldsl on 10 Sep 44020772 12:41 UTC Tested on Fedora 19 x86_64 (with RPMs from repository), boinc version 7.2.33. Without linking the gui_rpc_auth.cfg file to my home directory, when I select Advanced -> Select Computer and I type "localhost" as target and put the password Boinc Manager can't connect to client. If I type "127.0.0.1" it connects.

This happens only with 7.2.33, if I downgrade boinc to 7.0.65 "localhost" works, so I don't think to a firewall/hostnames configuration problem.

[https://bugzilla.redhat.com/show_bug.cgi?id=1048545]

Migrated-From: http://boinc.berkeley.edu/trac/ticket/1335

romw avatar Feb 04 '15 06:02 romw

Tested on Windows 8.1, boinc version 7.6.69. No error, all is correct

AenBleidd avatar Sep 25 '15 21:09 AenBleidd

Same error happened to me with boinc-manager 7.0.27 (from repos) on raspian from linux remote server.

frosty00 avatar Sep 26 '15 20:09 frosty00

Confirming on Fedora 24, BOINC 7.6.22

Germano0 avatar Dec 03 '16 16:12 Germano0

Works with 7.6.33 on Debian. So it might be something Fedora (CentOS) specific. What happens if you don't enter a hostname. For me this defaults to "localhost". In the past the "could not connect to client" errors on CentOS systems could be tracked down to permission problems where the Manager couldn't access the gui_rpc_auth file. Maybe this is something along this way but where the manager can't resolve 'localhost' to '127.0.0.1'. Maybe the wrong IP is resolved. I would need to look up how the manager does the lookup. My guess is that this is done by curl.

ChristianBeer avatar Dec 03 '16 21:12 ChristianBeer

@ChristianBeer if I do not enter a username, the result is that BOINC manager remains not connected to any BOINC client.

Germano0 avatar Dec 03 '16 22:12 Germano0

I guess you mean hostname. I have the feeling that somehow the Manager can not resolve localhost or it gets a different IP than 127.0.0.1. I tracked this down to here: https://github.com/BOINC/boinc/blob/5c36ce25daae8532f44d81e9f4c5527bde5e0e51/lib/network.cpp#L171 this rang a bell and I found #1531.

You should check your /etc/hosts file on Fedora and see if there is a line that maps localhost to an IP address.

ChristianBeer avatar Dec 04 '16 21:12 ChristianBeer

# cat /etc/hosts
127.0.0.1               localhost.localdomain localhost
::1             localhost6.localdomain6 localhost6

Germano0 avatar Dec 06 '16 17:12 Germano0

Strange, I guess I have to setup a Fedora 24 VM to reproduce the problem and try to debug it some more. Did you use a standard setup or something more fancy?

ChristianBeer avatar Dec 07 '16 20:12 ChristianBeer

I see essentially the same behavior on a couple of Gentoo systems from boinccmd (I don't use boincmgr, so I can't comment on that on Gentoo), so I don't think it's GUI specific or Fedora specific. In my case, this is with a locally built version of 7.6.33, but it was happening before that with earlier local builds of 7.6 (which ironically has worked perfectly fine for me on Linux other than this since the first tag was up in the repo). I don't know when exactly this started happening for me (I don't even use boinccmd much since I track stats through BAM not locally), but it's been within the last month or two. Other than the fact that it's locally built (because Gentoo has not been great about keeping up-to-date on BOINC), I'm using an otherwise stock setup (mostly identical to the standard upstream stuff, except for custom init-scripts for Gentoo's init system).

Ferroin avatar Dec 07 '16 20:12 Ferroin

@Ferroin You mean that boinccmd also can't connect to localhost but it can to 127.0.0.1? If this only appeared within the last months than It is most likely related to a local change of the firewall or dns resolver update.

ChristianBeer avatar Dec 07 '16 20:12 ChristianBeer

Ah, I missed the part about connecting via IP working. That doesn't work in my case, so I'll do some more digging and probably open another issue under the assumption that it's an unrelated bug.

Ferroin avatar Dec 08 '16 12:12 Ferroin

The Client and Manager are communicating via TCP so there is always a possibility that a firewall is restricting access to the port the Client uses even on the loopback interface.

ChristianBeer avatar Dec 08 '16 20:12 ChristianBeer

$ boinccmd --get_state works without specifing any IP address. My system used Firewalld and should be fine.

# firewall-cmd --info-zone=public
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp6s0
  sources: 
  services: mdns ipp dhcpv6-client
  ports: *censored_for_privacy*
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

Germano0 avatar Dec 09 '16 18:12 Germano0

I installed the FC25 live CD in a VM with default settings. This is what I had to do to get a running client:

yum install boinc-client boinc-manager
systemctl enable boinc-client
systemctl start boinc-client

What I see now is that /var/lib/boinc/gui_rpc_auth.cfg is populated with a 32 byte random string and the file itself is owned by the user boinc and permissions 500. Starting the Manager now results in "Unable to connect to the core client" because the Manager can't read the contents of gui_rpc_auth.cfg. If I start the manager on the commandline and specify the password like this

sudo cat /var/lib/boinc/gui_rpc_auth.cfg
boinccmd -p 1234567890

it works. So the problem on Fedora is that the normal User does not have access to the file in /var/lib/boinc/ and adding the normal user to the group boinc (as is best on Debian) has no effect because only the boinc user can access the file. So we are back to a permission problem created by the Fedora package manager.

I'm not entirely sure how this ties in with the whole "localhost" thing above. I tried the following things and they work too:

boinccmd -n localhost -p 1234567890
boinccmd -n 127.0.0.1 -p 1234567890

Solutions:

  • the simple GUI should ask for a password if it detects that there is a file but it can't be accessed
  • the file could be made group readable and the user must add himself to the group after installation (seems to need some more thought as it does not work on first try)

Addendum: later discussion in this issue was about boinccmd which basically suffers from the same restriction. Here is what works:

boinccmd --passwd 1234567890 --read_cc_config
boinccmd --host localhost --passwd 1234567890 --read_cc_config
boinccmd --host 127.0.0.1 --passwd 1234567890 --read_cc_config

Here is what does not work:

boinccmd --read_cc_config --passwd 1234567890

The parameters for boinccmd are position dependent. The fact that the actual commands look like parameters and can therefore be interchanged is misleading! Also boinccmd only looks in the current working directory for gui_rpc_auth.cfg and it must be accessible to the user. So something like this worked for me:

cd /var/lib/boinc
sudo chmod o+r gui_rpc_auth.cfg
boinccmd --read_cc_config

ChristianBeer avatar Jan 06 '17 16:01 ChristianBeer

Hi @ChristianBeer , I did some tries with /var/lib/boinc/gui_rpc_auth.cfg permissions and indeed it resolves the problem on all machines except one. So I need more time to give you a stable feedback. Thank you for your support, I will let you know as soon as possible!

Germano0 avatar Jan 24 '17 19:01 Germano0

I did some tests. Note: my user always has been under boinc group.

I tried to # systemctl stop firewalld and the problem was not fixed, so it definitely should not a matter of firewall.

  1. Edited /usr/share/applications/boinc-manager.desktop adding line Path=/var/lib/boinc full file output::
[Desktop Entry]
Name=BOINC Manager
GenericName=BOINC monitor and control utility
GenericName[de]=BOINC Überwachungs- und Kontrollprogramm
GenericName[pt]=Monitorização BOINC e utilitário de controlo
GenericName[cs]=Monitorovací a ovládací nástroj pro BOINC
Comment=Configure or monitor a BOINC core client
Comment[de]=BOINC Basis Client konfigurieren oder überwachen
Comment[pt]=Configurar ou monitorizar o cliente básico do BOINC
Comment[cs]=Monitoruje a nastavuje klienta BOINC
Path=/var/lib/boinc
Exec=boincmgr
Terminal=false
Type=Application
Icon=boincmgr
Categories=System;Monitor;GTK;
X-Desktop-File-Install-Version=0.23

  1. Gave full unnecessary 777 permissions to the empty /var/lib/boinc/gui_rpc_auth.cfg and tried to let boincmgr connect to localhost user.

  2. Tried to write a password inside /var/lib/boinc/gui_rpc_auth.cfg and tried to let boincmgr connect to localhost using such password. 4-a) Tried to let boincmgr connect to 127.0.0.1 with the password and it worked 4-b) Tried to let boincmgr connect to 127.0.0.1 with a wrong password and it obviously refused to connect to BOINC

So the problem is only with localhost

Germano0 avatar Feb 12 '17 10:02 Germano0

Can you try to reproduce my working test cases with boinccmd from above on the system that does not work? Especially those three lines:

boinccmd --passwd 1234567890 --read_cc_config
boinccmd --host localhost --passwd 1234567890 --read_cc_config
boinccmd --host 127.0.0.1 --passwd 1234567890 --read_cc_config

All three should trigger a reread of local configuration files which is visible in the Client logfile. Your Client should have a problem with the one on the middle.

ChristianBeer avatar Feb 12 '17 14:02 ChristianBeer

I am sorry I have forgotten to write a part of my previous message: Any command like

boinccmd --passwd 1234567890 --read_cc_config
boinccmd --host localhost --passwd 1234567890 --read_cc_config
boinccmd --host 127.0.0.1 --passwd 1234567890 --read_cc_config

returns Authorization failure: -155

Germano0 avatar Feb 12 '17 14:02 Germano0

That means the supplied password is wrong. Did you check that the password you used was the same as in gui_rpc_auth.cfg on this machine? Sometimes there can be a stray blank at the end of the line.

ChristianBeer avatar Feb 12 '17 17:02 ChristianBeer

$ boinccmd --passwd 12 --read_cc_config
can't connect to local host
$ boinccmd --host localhost --passwd 12 --read_cc_config
can't connect to localhost
$ boinccmd --host 127.0.0.1 --passwd 12 --read_cc_config
can't connect to 127.0.0.1
# ls -latr /var/lib/boinc/gui_rpc_auth.cfg 
-rwxrwxrwx. 1 boinc boinc 4 12 feb 19.23 /var/lib/boinc/gui_rpc_auth.cfg
# cat /var/lib/boinc/gui_rpc_auth.cfg
12

Germano0 avatar Feb 12 '17 18:02 Germano0

Did you changed the password without restarting boinc?

sorcrosc avatar Feb 12 '17 18:02 sorcrosc

Mmh yes I changed the password without restarting boinc. Now it get

$ boinccmd --passwd 12 --read_cc_config
retval 0
$ boinccmd --host localhost --passwd 12 --read_cc_config
retval 0
$ boinccmd --host 127.0.0.1 --passwd 12 --read_cc_config
retval 0

Germano0 avatar Feb 12 '17 18:02 Germano0

So it works and the problem was that the Client was not restarted? That would close this ticket I presume?

ChristianBeer avatar Feb 13 '17 09:02 ChristianBeer

So it works and the problem was that the Client was not restarted? That would close this ticket I presume?the manager

boinc manager still does not work, only boinccmd works

Germano0 avatar Feb 13 '17 09:02 Germano0

I just started my Fedora 25 VM and tried this in a terminal:

boincmgr -n localhost -p 12346790
boincmgr -n 127.0.0.1 -p 12346790

Which both works (opens the simple GUI Manager and asks me to add a project). Next try:

boincmgr -e /var/lib/boinc/
boincmgr -n localhost -e /var/lib/boinc/
boincmgr -n 127.0.0.1 -e /var/lib/boinc/

which works if I make /var/lib/boinc/gui_rpc_auth.cfg world readable. You could make it group readable if the current user is in the boinc group (which my user is not).

For the next try I chdir into the Client directory and execute:

boincmgr
boincmgr -n localhost
boincmgr -n 127.0.0.1

which works because gui_rpc_auth.cfg is still world readable. As soon as I remove the world readable bit it does not work (as expected).

This proves that boincmgr by itself works as expected. I now applied your change to /usr/share/applications/boinc-manager.desktop which seem reasonable but to me it seems that any changes to this file are not used. I changed the name of the executable to something non existent but searching for "BOINC" in Activities and clicking on it still opened the manager with the "Unable to connect to the core client" message. I'm not sure where the gnome desktop gets its information from but /usr/share/applications/boinc-manager.desktop seems to be not the place.

ChristianBeer avatar Feb 13 '17 10:02 ChristianBeer

After some more fiddling I was able to reproduce it finally. The sequence is as follows:

  1. Open boincmgr once from commandline and switch to advanced view (password on commandline always works as demonstrated above)
  2. Close Manager (Ctrl + Q)
  3. Make sure gui_rpc_auth.cfg is not readable by the current user (and copy contents into clipboard)
  4. Open boincmgr again ( can be from commandline or through GUI) without any options
  5. Open "File" -> "Select Computer..."
  6. Try to connect to localhost using the password in gui_rpc_auth.cfg (will not work)
  7. Try to connect to 127.0.0.1 using the password and it will work

When I do the same but make gui_rpc_auth.cfg world readable in step 3 above and start the manager in /var/lib/boinc/, the Manager looks up the password and enters it into the text field after I select or enter localhost. It seems there is a bug in this lookup within this dialog that changes the password internally if the file is not readable but the user supplied a password (effectively overriding the user supplied password).

ChristianBeer avatar Feb 13 '17 10:02 ChristianBeer

It would be interesting to check if it is reproducible also on other Linux distributions

Germano0 avatar Feb 13 '17 10:02 Germano0

Yes, I could reproduce it on Debian (the bug is present on all platforms). I tracked it down to the Select dialog and I'm working on a fix. So far no luck but I'm getting close.

ChristianBeer avatar Feb 13 '17 21:02 ChristianBeer

@Germano0 could you please check my fix on your system?

ChristianBeer avatar Mar 06 '17 08:03 ChristianBeer

@ChristianBeer I should test the fix in next 7 days

Germano0 avatar Mar 06 '17 09:03 Germano0