This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 443568 - Boinc installation bug and starting aplication errors
Boinc installation bug and starting aplication errors
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: boinc-client (Show other bugs)
8
All Linux
urgent Severity urgent
: ---
: ---
Assigned To: Milos Jakubicek
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F9Blocker
  Show dependency treegraph
 
Reported: 2008-04-22 04:36 EDT by Anton Krajcik
Modified: 2008-04-30 04:31 EDT (History)
3 users (show)

See Also:
Fixed In Version: 5.10.45-9.20080315svn
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-30 04:31:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Anton Krajcik 2008-04-22 04:36:55 EDT
Description of problem:
Impossible to install boinc-client via 'yum install boinc-client boinc-manager'
--------------------------------------------------------------------------------

I had tried to install Boinc via 'yum install boinc-client boinc-manager' I 
obtained this error message during Instalation process

Installing: boinc-client                 ######################### [1/2] 
chown: cannot access `/var/log/boinc*': No such file or directory
error: %post(boinc-client-5.10.45-8.20080315svn.fc8.i386) scriptlet failed, 
exit status 1

Concerning this problem I manually installed .rpm these packages from http://
koji.fedoraproject.org/packages/boinc-client/5.10.45/

boinc-client-debuginfo-5.10.45-5.20080315svn.fc8.i386.rpm 
boinc-client-devel-5.10.45-5.20080315svn.fc8.i386.rpm 
boinc-client-5.10.45-5.20080315svn.fc8.i386.rpm 
boinc-manager-5.10.45-5.20080315svn.fc8.i386.rpm

When I run Aplication Boinc Manager from System Tools->Boinc Manager I cannot 
connect to 'localhost' because 'boinc-client daemon' does not run past 
installation process.

I used this tutorial to start Boinc aplication correctly:
---------------------------------------------------------------
1. Run from Terminal '/sbin/chkconfig boinc-client on' as root. 
***maybe '/sbin/chkconfig boinc-client start' - will help too
Then reboot.
2. After reboot in Terminal 'ps aux | grep boinc' and check if '/usr/bin/
boinc_client --daemon' is between running processes.
3. Run Aplication Boinc Manager from System Tools->Boinc Manager
4. I switch to 'Advanced' from Boinc Manager mainscreen
5. I run in Terminal 'gedit /var/lib/boinc/gui_rpc_auth.cfg' and after that I 
copy whole content (it is password)
6. In Boinc Manager -> Advanced -> Select Computer
host name: localhost
password: content of file gui_rpc_auth.cfg
--------------------------------------------------------------
Finish.
Now I am able to connect to localhost in Boinc Manager and Attach to project.
Comment 1 Lubomir Kundrak 2008-04-22 08:23:19 EDT
Milos: do not get confused by the component of this report; Boinc has no
Bugzilla components for some reason, Toshio was pinged about the matter and
hopefully things are going to be sorted out soon.

This is clearly caused by the change you did here:
* Mon Apr 14 2008 Milos Jakubicek <xjakub@fi.muni.cz> - 5.10.45-8.20080315svn

%post
#correct wrong owner and group on files under /var/lib/boinc and log files
#caused by bug fixed in 5.10.45-8
chown --silent -R boinc:boinc %{_localstatedir}/log/boinc* \
%{_localstatedir}/lib/boinc/*

This is plain wrong. Please at the very least add "|| :" at the end so that this
evaluates to true in all cases. Also, redirect the error output to /dev/null by
2>/dev/null
Comment 2 Lubomir Kundrak 2008-04-22 08:27:54 EDT
Milos, also raising priority to urgent, since this causes the package to be
uninstallable. Please commit fix as soon as CVS gets unlocked and request freeze
break for the build as described here:

http://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy
Comment 3 Milos Jakubicek 2008-04-23 04:29:46 EDT
I see you've just committed the change, thanks...and sorry for that, I focused
on proper update and forgot to test a fresh install.

However, this is actually not a blocker bug since the package tagged as f9-final
is not boinc-client-5.10.45-8, but boinc-client-5.10.45-5, which is working
fine, however, boinc daemon is running as root instead of the boinc user. So,
Lubomir, should I still mail rel-eng and ask them for approving new build or not?

PS: I'll commit also to the F-7 branch...
Comment 4 Lubomir Kundrak 2008-04-23 04:46:21 EDT
(In reply to comment #3)
> I see you've just committed the change, thanks...and sorry for that, I focused
> on proper update and forgot to test a fresh install.
> 
> However, this is actually not a blocker bug since the package tagged as f9-final
> is not boinc-client-5.10.45-8, but boinc-client-5.10.45-5, which is working
> fine, however, boinc daemon is running as root instead of the boinc user. So,
> Lubomir, should I still mail rel-eng and ask them for approving new build or not?

Running stuff that processes potentially untrusted data as root is never a wise
thing, I'd prefer if you broke the freeze for that.

> PS: I'll commit also to the F-7 branch...

Thanks.
Comment 5 Lubomir Kundrak 2008-04-23 04:50:09 EDT
Milos: Also, please do updates for releases that include the vulnerable packages. 

I propose that the %post scriptlet goes away for f10, since there will be no
supported upgrade path from the old packages to it, and set the owner and group
for the boinc user owned directories with %attr in %files.
Comment 6 Fedora Update System 2008-04-23 05:10:03 EDT
boinc-client-5.10.45-9.20080315svn.fc7 has been submitted as an update for Fedora 7
Comment 7 Milos Jakubicek 2008-04-23 05:16:15 EDT
>I propose that the %post scriptlet goes away for f10, since there will be no
>supported upgrade path from the old packages to it, and set the owner and group
>for the boinc user owned directories with %attr in %files.

I'm not sure about this -- it will break upgrading between releases. I know that
assuming this I can never remove it...but, does it pain having the post
scriptlet there?

Concerning components: I've also mailed Toshio about two weeks ago, hopefully
the script will be fixed soon.
Comment 8 Fedora Update System 2008-04-23 05:17:21 EDT
boinc-client-5.10.45-9.20080315svn.fc8 has been submitted as an update for Fedora 8
Comment 9 Lubomir Kundrak 2008-04-23 07:08:34 EDT
(In reply to comment #7)
> >I propose that the %post scriptlet goes away for f10, since there will be no
> >supported upgrade path from the old packages to it, and set the owner and group
> >for the boinc user owned directories with %attr in %files.
> 
> I'm not sure about this -- it will break upgrading between releases. I know that
> assuming this I can never remove it...but, does it pain having the post
> scriptlet there?

That's  plain wrong assumption. After the updates are out, there won't exist any
upgrade path that would break, unless users voluntarily install broken packages.
Comment 10 Milos Jakubicek 2008-04-23 08:38:54 EDT
(In reply to comment #9)

> That's  plain wrong assumption. After the updates are out, there won't exist any
> upgrade path that would break, unless users voluntarily install broken packages.

Yes -- provided users will update the package to the most recent version.
Otherwise no. Suppose somebody has already installed the package (in F7/F8) and
won't update it until an upgrade to F10. Then it will definitely break (not the
upgrade itself, but boinc!)

However, this is a very improbable scenario...I'll remove it in F10.
Comment 11 Milos Jakubicek 2008-04-23 11:43:39 EDT
Freeze break approved by rel-eng, boinc-client-5.10.45-9.20080315svn.fc9 tagged
as f9-final.
Comment 12 Dagorath 2008-04-28 22:43:14 EDT
Earlier today I added a section to the BOINC wiki explaining how to install
BOINC on Fedora 7 and up, see
http://boinc.berkeley.edu/wiki/index.php/Installing_BOINC#Fedora_7_and_up.

Now, from messages here, I see there were possibly some bugs in the rpm package
or something.  I do not understand all the issues because I am still a Linux
newbie.  Is the material I wrote in the wiki correct?  Will the material be
correct when the fixes described in messages above are released?  Or will the
material need to be edited?

Comment 13 Milos Jakubicek 2008-04-29 07:12:08 EDT
No, the instructions are definitely not correct. BOINC shouldn't be run under
the user's account. There is a special account "boinc" for BOINC in Fedora.

Please refer to this page I created recently:
http://fedoraproject.org/wiki/MilosJakubicek/HowToUseBoinc

Probably the best solution is just link to that page.
Comment 14 Dagorath 2008-04-29 11:07:56 EDT
Milos, thank you for your quick reply and link to HowToUseBoinc :)

I think most users will not want to manually connect the manager to the client.
 Is there a reason why the manager should not be run under the user's account? 
I ask not to be argumentative, just because I'm still learning Linux.

 
Comment 15 Milos Jakubicek 2008-04-29 11:32:24 EDT
(In reply to comment #14)
> I think most users will not want to manually connect the manager to the client.
> Is there a reason why the manager should not be run under the user's account? 
> I ask not to be argumentative, just because I'm still learning Linux.

What do you mean by running the manager? Of course the manager (=the GUI app
BOINC Manager) is run under the user who ran it.

Something completely different is running the BOINC client (=the daemon, the
service). This is run under the "boinc" account. An ordinary user doesn't have
any rights to manipulate with it (start, stop, etc). Even connecting to the
client via BOINC manager needs to be authenticated using the password from
/var/lib/boinc/gui_rpc_auth.cfg because using the manager you can fully control
the client.

So the point is that normal users shouldn't be able to manipulate with
(system-wide running) services. Just ask in case of any unclarity:)


Comment 16 Dagorath 2008-04-29 12:57:26 EDT
(In reply to comment #15)
> (In reply to comment #14)
> > I think most users will not want to manually connect the manager to the client.
> > Is there a reason why the manager should not be run under the user's account? 
> > I ask not to be argumentative, just because I'm still learning Linux.
> 
> What do you mean by running the manager? Of course the manager (=the GUI app
> BOINC Manager) is run under the user who ran it.
> 
> Something completely different is running the BOINC client (=the daemon, the
> service). This is run under the "boinc" account. An ordinary user doesn't have
> any rights to manipulate with it (start, stop, etc). Even connecting to the
> client via BOINC manager needs to be authenticated using the password from
> /var/lib/boinc/gui_rpc_auth.cfg because using the manager you can fully control
> the client.
> 
> So the point is that normal users shouldn't be able to manipulate with
> (system-wide running) services. Just ask in case of any unclarity:)
> 

I thought you were going to say that.  I understand and I agree that *normal*
users should not be able to manipulate the boinc service.  Access should be
controlled via the gui_rpc password.

Conventional wisdom says the sysadmin should login as root only when necessary
and that he should have an alternate account for normal (non-administrative)
tasks. The instructions I wrote at BOINCWiki recommend that root add *only* his
alternate username to the boinc group and place a link to gui_rpc_auth.cfg
*only* in his alernate user's home directory.  That way he can connect the
manager to localhost without the gui_rpc password and he doesn't have to make
the password blank to make it easy to remember.  I think suggesting to make the
password blank like you did is a bad idea, sorry :)

Comment 17 Milos Jakubicek 2008-04-29 15:15:14 EDT
(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > I think most users will not want to manually connect the manager to the
client.
> > > Is there a reason why the manager should not be run under the user's account? 
> > > I ask not to be argumentative, just because I'm still learning Linux.
> > 
> > What do you mean by running the manager? Of course the manager (=the GUI app
> > BOINC Manager) is run under the user who ran it.
> > 
> > Something completely different is running the BOINC client (=the daemon, the
> > service). This is run under the "boinc" account. An ordinary user doesn't have
> > any rights to manipulate with it (start, stop, etc). Even connecting to the
> > client via BOINC manager needs to be authenticated using the password from
> > /var/lib/boinc/gui_rpc_auth.cfg because using the manager you can fully control
> > the client.
> > 
> > So the point is that normal users shouldn't be able to manipulate with
> > (system-wide running) services. Just ask in case of any unclarity:)
> > 
> 
> I thought you were going to say that.  I understand and I agree that *normal*
> users should not be able to manipulate the boinc service.  Access should be
> controlled via the gui_rpc password.
> 
> Conventional wisdom says the sysadmin should login as root only when necessary
> and that he should have an alternate account for normal (non-administrative)
> tasks. The instructions I wrote at BOINCWiki recommend that root add *only* his
> alternate username to the boinc group and place a link to gui_rpc_auth.cfg
> *only* in his alernate user's home directory.  That way he can connect the
> manager to localhost without the gui_rpc password and he doesn't have to make
> the password blank to make it easy to remember. 

Now I see what you intend by this, however I still do not understand your
question about not running the manager under an ordinary user, but never mind.

> I think suggesting to make the
> password blank like you did is a bad idea, sorry :)

I don't suggest anything. I only wrote that IF (and only if:) somebody wants to
set an empty password, this is the right way how to, because people usually just
delete the file which causes a new one to be created.

But fine, let's make a trade-off, we should probably merge our wiki's and let
the users decide how they arrange it for themselves, hm?
Comment 18 Fedora Update System 2008-04-29 16:57:09 EDT
boinc-client-5.10.45-9.20080315svn.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 19 Fedora Update System 2008-04-29 16:59:02 EDT
boinc-client-5.10.45-9.20080315svn.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 20 Dagorath 2008-04-29 18:16:37 EDT
(In reply to comment #17)
> (In reply to comment #16)
> > (In reply to comment #15)
> > > (In reply to comment #14)
> > > > I think most users will not want to manually connect the manager to the
> client.
> > > > Is there a reason why the manager should not be run under the user's
account? 
> > > > I ask not to be argumentative, just because I'm still learning Linux.
> > > 
> > > What do you mean by running the manager? Of course the manager (=the GUI app
> > > BOINC Manager) is run under the user who ran it.
> > > 
> > > Something completely different is running the BOINC client (=the daemon, the
> > > service). This is run under the "boinc" account. An ordinary user doesn't have
> > > any rights to manipulate with it (start, stop, etc). Even connecting to the
> > > client via BOINC manager needs to be authenticated using the password from
> > > /var/lib/boinc/gui_rpc_auth.cfg because using the manager you can fully
control
> > > the client.
> > > 
> > > So the point is that normal users shouldn't be able to manipulate with
> > > (system-wide running) services. Just ask in case of any unclarity:)
> > > 
> > 
> > I thought you were going to say that.  I understand and I agree that *normal*
> > users should not be able to manipulate the boinc service.  Access should be
> > controlled via the gui_rpc password.
> > 
> > Conventional wisdom says the sysadmin should login as root only when necessary
> > and that he should have an alternate account for normal (non-administrative)
> > tasks. The instructions I wrote at BOINCWiki recommend that root add *only* his
> > alternate username to the boinc group and place a link to gui_rpc_auth.cfg
> > *only* in his alernate user's home directory.  That way he can connect the
> > manager to localhost without the gui_rpc password and he doesn't have to make
> > the password blank to make it easy to remember. 
> 
> Now I see what you intend by this, however I still do not understand your
> question about not running the manager under an ordinary user, but never mind.
> 

I am sorry for not clarifying what I meant.  In comment #13 where you said
"BOINC should not be run under the user's account" I thought you were using
BOINC to refer to the manager.  You were actually refering to the client. So
it's not surprising my question seemed odd to you.  

> > I think suggesting to make the
> > password blank like you did is a bad idea, sorry :)
> 
> I don't suggest anything. I only wrote that IF (and only if:) somebody wants to
> set an empty password, this is the right way how to, because people usually just
> delete the file which causes a new one to be created.

I think they delete the file because they are the sysadmin and they feel the
sysadmin should not be required to type in localhost and the gui_rpc_password. 
They think if they delete the file then the password will not be required and
the connection will occur automatically.  So you suggest an empty password and
that works *but* it allows all other users to connect too.  If there is only 1
user (the administrator) then it does not matter but if the machine is on a LAN
then others could connect to the client from other machines.  I think an empty
remote_hosts.cfg might exclude connections from other hosts but I have never
tried that.     

> 
> But fine, let's make a trade-off, we should probably merge our wiki's and let
> the users decide how they arrange it for themselves, hm?

Yes, we could merge the 2 wikis.  Give me a day or 2 to investigate further. 
And I want to hear your thoughts on the other points I raised.

Thanks for discussing this with me.

Comment 21 Milos Jakubicek 2008-04-30 04:31:04 EDT
Oops, the updates haven't been set to close this bug. Resolving as CURRENTRELEASE.

Note You need to log in before you can comment on or make changes to this bug.