gui_rpc_auth.cfg exists but can't be read. Check the file permissions.

[endolith]

Describe the bug BOINC Manager - Connection Error gui_rpc_auth.cfg exists but can't be read. Check the file permissions.

Steps To Reproduce

1. Install Ubuntu
2. Install BOINC
3. Try to run BOINC Manager

Expected behavior I would expect it to work like it did on my previous install.

Screenshots

System Information

• OS: Linux 5.8.0-44-generic Ubuntu SMP Tue Feb 9 06:29:41 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
• BOINC Version: 7.16.11 x86_64-pc-linux-gnu

Additional context BOINC Manager was working fine on this machine, but I reinstalled Ubuntu and on a fresh install it gives this error

[CharlieFenton]

Sorry, I meant: Note in your diagram that nothing is ever merged (or even cherry-picked) from master into a release branch.

[AenBleidd]

A new revision includes only bug fixes to that major and minor release version. For a new revision, you cherry-pick only bug fixes from master into the release branch from master.

Looking at our releases, I'd not say that's true: we have feature releases between revisions too. I see that in our release document it's said: The release branch is feature frozen.

Do you agree?

If we agree to increment minor version when we have any new feature appears and keep revision change for bugfix only - that's fine for me.

Ok, my bad. I missed this completely somehow.

I suggest then to start with 7.18 branch now (use it for the next Android) and every other release (OSX, Windows, whatever) start with greater minor version (7.20, etc)

What you illustration calls "hot fix" I have been calling "bug fix."

In this case this is just a question of terminology, but it's about the same

Sorry, I meant: Note in your diagram that nothing is ever merged (or even cherry-picked) from master into a release branch.

Their master - our release, then it become more correct.

But again, it's my fault, I missed that we never add any features to already created release branch.

[CharlieFenton]

Usually changes we do are quite minor, so the testing of one or two people is definitely enough.

I completely disagree. I have been doing this for over 60 years and I can't tell you how often a bug doesn't even get discovered until after a public release. Extensive testing is needed on every change, no matter how minor or innocuous it appears to be.

[AenBleidd]

Extensive testing is needed on every change, no matter how minor or innocuous it appears to be.

That's why people invented automation testing ;)

[CharlieFenton]

I suggest then to start with 7.18 branch now

Yes, thank you. That is one of the t things I've been saying. I'm glad we finally understand each other. I know we are all trying to do what is right.

and every other release (OSX, Windows, whatever) start with greater minor version (7.20, etc)

I don't know if that is necessary. Historically, we've always alpha tested and released the desktop clients together in one minor version, because their code base is largely the same. It might make sense to use different minor versions for Android, though, because (as I understand) it has a substantially different code base.

(use it for the next Android) and every other release (OSX, Windows, whatever) start with greater minor version (7.20, etc)

[CharlieFenton]

That's why people invented automation testing ;)

Now what we need is automated bug fixing, then we can all relax on the beach. ;)

[CharlieFenton]

their master -> our release their develop -> our master

I am still unclear about one thing. As I wrote

When one creates a Pull Request from a new feature branch, GitHub automatically sets it up to be merged into master once the author of the PR declares it ready.

How does one get GitHub to automatically set up new Pull Requests to be merged into a separate development branch instead of master?

[AenBleidd]

It might make sense to use different minor versions for Android, though, because (as I understand) it has a substantially different code base.

That's exactly I wanted to say.

How does one get GitHub to automatically set up new Pull Requests to be merged into a separate development branch instead of master?

There is an option in Settings Not sure we should change it

[CharlieFenton]

Thanks. It might also be automatic if we create each new feature branch as a branch off the development branch rather than a branch off master.

[CharlieFenton]

I have opened issue #4412 to advance discussion on our development workflow and Client Release Procedure.

[morphemes]

@aravindvnair99 - thanks for the update and confirming that your issue is resolved.

Notes to someone in the future who has a similar problem and reads this. The changes that likely resolved this issue are the following. Please try these and then respond to this thread with the outcome (since this will confirm our understanding of the problem).

Open a terminal window and run the following commands:

sudo chmod 755 /etc/boinc-client
sudo chmod 644 /etc/boinc-client/config.properties
sudo chown -R boinc:boinc /etc/boinc-client

sudo chmod 750 /var/lib/boinc-client
sudo chmod 640 /var/lib/boinc-client/gui_rpc_auth.cfg
sudo chown boinc:boinc /var/lib/boinc-client
sudo chown boinc:boinc /var/lib/boinc-client/gui_rpc_auth.cfg

sudo usermod -a -G boinc $USER

and then reboot.

Lastly - please respond with the outcome of you trying this. Thank you.

After doing the standard install procedure, copy/pasting this into terminal and rebooting worked. I tried this on a Impish Indri dev build a while back, and the recent final release. Thanks so much for your help.

[RolandHughes]

Having been through this and many other issues with BOINC in the more than decade I've been running, Here's a post about Gecko Linux NVidia and BOINC that should help a lot.

What you have to understand is that the Linux world is complete anarchy. If the "powers that be" over a distro don't actually use something themselves, it never gets tested. Lots of people, who, if they had ten more years of experience, might qualify as a Junior developer look to stroke their egos by getting some distro to list them as the "package maintainer" even though all they do is set up an automated build. They don't actually test anything and have zero skills when it comes to packaging.

gui_rpc_auth.cfg exists but can't be read

is always a packaging problem. With a Debian package, the "maintainer" they forgot the postinst step

usermod -a -G boinc $USER

No need for sudo as they are running with root privs at the time. (for RPM it is the %post step of the .spec file)

You should never ever have to touch the permissions/ownership on /var/lib/boinc-client/gui_rpc_auth.cfg or /var/lib/boinc/gui_rpc_auth.cfg (RPM based distros)

That's a hack creating far more problems than it solves.

developer@developer-hpcompaq8100elitesffpc:~> ls
 bin                gecko-nvidia-boinc.txt   RedDiamond_Backups
'BOINC Manager-developer'   gui_rpc_auth.cfg         suse-nvidia-notes.txt
 Desktop            install-samba-stuff.sh   Templates
 Documents          Music            tnas
 Downloads          Pictures             Videos
 gecko-installs.txt     Public
developer@developer-hpcompaq8100elitesffpc:~> cat gui_rpc_auth.cfg
15bd7ba9a6a7ab1a9127aba90040c25fdeveloper@developer-hpcompaq8100elitesffpc:~> 
developer@developer-hpcompaq8100elitesffpc:~> 

When you launch BOINC Manager you create that file in your $HOME directory. If you don't belong to "boinc" group boinc-client cannot read it when manager is establishing communications.

What you have is a copy of the randomly generated key from /var/lib/boinc/gui_rpc_auth.cfg or /var/lib/boinc-client/gui_rpc_auth.cfg which allows your BOINC Manager instance to communicate with that boinc-client.

Your BONIC Manager can communicate with many boinc-client instances across many machines. Hacking the privs on the main key file will let you luggie up your own system, but won't let you communicate properly with other instances.

If you are using an RPM based distro and want to use BOINC with NVidia CUDA cores, fuhgeddaboudit. That's a historically untested path through every RPM based distro.

[RolandHughes]

There are three goals here:

1. Automatically start the BOINC core client when Linux starts

2. Run securely by default

3. Allow a user to launch the BOINC manager under their account and connect to the BOINC core client started in via item 1

Due to the way apt and yum install software, I am not aware of any approach nor have I seen anyone make a proposal to make all three of the above work. The arguments have come down to whether we should favor 3 over 2.

At this time*, the BOINC installation does 1 and 2. In order to accomplish #3 you have to add your user account to the boinc group and possible change the permissions on the gui_rpc_auth.cfg file. World Community Grid's installation instructions for BOINC have documented these in our installation steps for many years (at least since 2014). See https://www.worldcommunitygrid.org/ms/viewDownloadAgain.action (and then select Debian or CentOs).

Here is WCG's full installation instructions for Ubunut/Debian. Some of these steps may not be required at this point in time but the exact installation configuration has changed over time, and these instructions make sure that everything gets set correctly.

1. In a terminal window, run the following command:

sudo apt install boinc-client boinc-manager

2. Set the BOINC client to automatically start after you restart your computer:

sudo systemctl enable boinc-client

3. Start the BOINC client:

sudo systemctl start boinc-client

4. Allow group access to client access file:

sudo chmod g+r /var/lib/boinc-client/gui_rpc_auth.cfg

5. Add your Linux user to the BOINC group to allow the BOINC Manager to communicate with the BOINC client

sudo usermod -a -G boinc $USER

6. Allow your terminal to pick up the privileges of the new group:

exec su $USER

7. In the same terminal window, start the BOINC Manager:

boincmgr -d /var/lib/boinc-client

8. When BOINC Manager opens, select World Community Grid from the list of BOINC projects then enter your World Community Grid username and password.

9. When these steps are completed, you should see a screen to confirm that you've been successfully signed up to World Community Grid.

* This is what I recall being the current configuration but I haven't tested in the past couple of months so things might have changed.

Steps 2-5 need to be in the .deb postinst step. Ideally step 1 should be in a boinc-meta package that installs both client and manager, then has steps 2-5 in the .deb postinst step.

For RPM distros %post in the .spec file

[RichardHaselgrove]

6. Allow your terminal to pick up the privileges of the new group:

exec su $USER

My experience is that this instruction needs clarification. This command allows a single, one-time, launch of the manager from that particular terminal instance (or even multiple launches during the lifetime of that instance), but wouldn't necessarily allow launches from a desktop icon (if your distro configures such a thing). However, it might allow future launches after the next login

[RolandHughes]

6. Allow your terminal to pick up the privileges of the new group:

exec su $USER

My experience is that this instruction needs clarification. This command allows a single, one-time, launch of the manager from that particular terminal instance (or even multiple launches during the lifetime of that instance), but wouldn't necessarily allow launches from a desktop icon (if your distro configures such a thing). However, it might allow future launches after the next login

That instruction isn't needed if you install a properly created package then log out/in. It's a cheat to avoid the log out/in.

[AenBleidd]

This should be already resolved with the new BOINC 8.0.2: https://boinc.berkeley.edu/linux_install.php