Note, you need to create an account (which is kinda hard to find).

But Dag, is there anything in the discussion page there? Or am I just being blind again?

What type of account are you talking about ? ... A BOINC account ? ... the account boinc in f9? ... my useraccount which I have added to the group boinc in f9 ? ...

I was talking about an account on the Fedora website. It was more of a comment to Dag.

---

Kathryn :o)

I just found the link to this page in my bookmarks... http://fedoraproject.org/wiki/User:Mjakubicek/HowToUseBoinc. See the Discussion link there.

If you want to set an empty password for BOINC, just paste only a newline into /var/lib/boinc/gui_rpc_auth.cfg

Maybe I have to use a empty password to solve my problem with the manager not connecting to the client automatically, like mentioned in your link ... HOW do I paste only a NEWLINE into gui_rpc_auth.cfg with gedit, or should i use another editor ( which would require which commands) ?

MfG, MEX

Open the file up in gedit. Hightlight whatever is in there and delete it. Then hit enter once and save the file.

---

Kathryn :o)

Maybe I have to use a empty password to solve my problem with the manager not connecting to the client automatically, like mentioned in your link ...

Open the file up in gedit. Hightlight whatever is in there and delete it. Then hit enter once and save the file.

Many thanks for the help :D ... but I have found the source of the problem why my manager wasn't able to connect to the client:
Now it isn't necessary anymore to compromise my security by using NL as a password, which wouldn't have helped me anyway ...

I did "link /var/lib/boinc/gui_rpc_auth.cfg $HOME/gui_rpc_auth.cfg" after performing su, and created a link to /root/gui_rpc_auth.cfg instead of /home/mex/gui_rpc_auth.cfg (silly me, I should have checked this much earlier :rollingeyes:)

This only leaves the problem that the client started as a daemon at boot isnt able to connect to the www unless i restart it as root.

MfG, MEX

PS: It is annoying, but no critical fault, that I have to restart the client as root manually ... and maybe I did something wrong myself when installing boinc or f9 which now causes this strange behavior :rollingeyes:

---

0xFF

I hope Eric or Milos will comment here because I'm stumped. I'll be installing F9 and BOINC in a few days. Hope I can offer more and better advice then but I have a feeling I'm going to run up against the same problem MEX is running into.

I got an email back from Milos last night. He's taken a quick look at the thread and will post when he gets some time. He did say that he is using the package on a couple F9 boxes without issue.

I also got an email for Eric basically saying he wasn't familiar with upstart and the init script was written for the SysV system.

Edit: I'm hoping to get my one F7 box over to F9 over my summer break next week. A lot is riding on whether or not I can find a functional video driver for it. ATI is making me want to pull my hair out.

---

Kathryn :o)

Hi, sorry for late answer, I didn't set getting e-mail from this forum unfortunately.

>Doesn't deleting gui_rpc_auth.cfg have the same effect?

No, BOINC will create a new one with randomly generated password. The only way is to insert just a newline.

>I hope Eric or Milos will comment here because I'm stumped. I'll be
>installing F9 and BOINC in a few days. Hope I can offer more and better
>advice then but I have a feeling I'm going to run up against the same problem
>MEX is running into.

I'm a bit out of the time now and do not understand what's currently the issue actually:

- The GUI RPC auth problem is hopefully clearly explained on both the wikis (we agreed on merge but I completely forgot about -- will solve this next week).

- I'm not aware of any Upstart related issues and can hardly imagine there are some concerning the BOINC init script which is really simple. Moreover if there would be some, I should experience problems on all the F9 boxes where I've BOINC installed which is not the case.

- What concerns SELinux, a quick way how to check whether SELinux is a reason of any troubles is setting it to permissive mode by typing "setenforce 0" as root and trying whether it works. If still not, then it is SElinux-unrelated for sure.

- Seeing all the hacks you tried I suggest you do a clean install of BOINC again before trying anything else. The package installs all what is needed, creates user & group correctly, sets correct permissions etc. Just remove all boinc packages, install them again, start the service, start the manager and log in using the password from /var/lib/boinc/gui_rpc_auth.cfg.

If problems still persist, post on this thread again what's going on.

Thanks,
Milos

- What concerns SELinux, a quick way how to check whether SELinux is a reason of any troubles is setting it to permissive mode by typing "setenforce 0" as root and trying whether it works. If still not, then it is SElinux-unrelated for sure.

- Seeing all the hacks you tried I suggest you do a clean install of BOINC again before trying anything else. The package installs all what is needed, creates user & group correctly, sets correct permissions etc. Just remove all boinc packages, install them again, start the service, start the manager and log in using the password from /var/lib/boinc/gui_rpc_auth.cfg.

If problems still persist, post on this thread again what's going on.

Thanks,
Milos

Many thanks for your help Milos, I will try "setenforce 0" to deactivate SELinux later.

If this doest cure my problem, I will try to deactivate starting boinc as a demon at boot or to start it at a later time in the boot to check if this is the issue why the client doesn't get a connection to the www until I restart it manually as root.

I didn't use any hacks, except those mentioned in http://boinc.berkeley.edu/wiki/Installing_on_Linux#Fedora_7_and_up , and will try installing boinc to a clean install on my PS3 as soon as I have found and corrected the reason for the client not beeing able to connect to the www unless I restart it manually as root.

The issue with the manager not beeing able to connect automatically to localhost with a GUI_RPC_password is solved as I made the fault to create the symlink to the HOME directory as root instead of staying my user.

MfG, MEX

PS: How do I reactivate SELINUX after the test ?

---

0xFF

PS: How do I reactivate SELINUX after the test ?

Perhaps "setenforce 1"? Only a guess, since I'm out of unix for over ten years.

Gruß,
Gundolf

---

Computer sind nicht alles im Leben. (Kleiner Scherz)

PS: How do I reactivate SELINUX after the test ?

Perhaps "setenforce 1"? Only a guess, since I'm out of unix for over ten years.

Although you're out of unix for such a long time, you still have good expectations;)

Ah, I finally see what's the point, I'm replying to your e-mail on-thread:

I can only start the boinc demon as root !

That's correct -- as for any other daemon.
If you want BOINC to be started automatically at boot, type "chkconfig boinc-client on".

(reading http://fedoraproject.org/wiki/User:Mjakubicek/HowToUseBoinc someone may think that his user rights are good enough for starting boinc)

Hm, I'd have never thought that it can lead to such presumption, but anyway I'll edit the wiki accordingly.

[mex@localhost ~]$ service boinc-client start
bash: service: command not found

Correct, /sbin is not in $PATH on Fedora for regular users.

[mex@localhost ~]$ /sbin/service boinc-client start
Starting BOINC client as a daemon: /etc/init.d/boinc-client: line 165: /var/log/boincerr.log: Keine Berechtigung

Correct too, the only odd thing I see right now is that it should return 4 instead of 0 (which is confusing -- I'll fix that of course and release an update occasionally).

---

Milos Jakubicek

I can only start the boinc demon as root !

That's correct -- as for any other daemon.
If you want BOINC to be started automatically at boot, type "chkconfig boinc-client on".

As mentioned in http://boinc.berkeley.edu/wiki/Installing_on_Linux#Fedora_7_and_up I did of course use "/sbin/chkconfig boinc-client on" to tell Linux to auto-start the boinc-client daemon at boot time.

But the result didn't seem to work as expected. The boinc-client is indeed started during the boot, but it isnt able to connect to the www unless I manually restart it with "/sbin/service boinc-client restart".

[mex@localhost ~]$ /sbin/service boinc-client start
Starting BOINC client as a daemon:  /etc/init.d/boinc-client: line 165:
/var/log/boincerr.log: Keine Berechtigung

Correct too, the only odd thing I see right now is that it should return 4 instead of 0 (which is confusing -- I'll fix that of course and release an update occasionally).

Can you please check /etc/init.d/boinc-client too if it is started at the right time (after access to the www is possible) and check if the user and/or group boinc has the necessary rights to access the www ?

MfG, MEX

PS: I too expected that "setenforce 1" will reverse the setting you suggested, as I had my first contact with Unix in the 80ies (I even bought MINIX 1.2 during this time for my PC after reading the book about OS from A.Tanenbaum !), I just wanted to be sure ...

As there is a GUI to be found at SYSTEM > ADMINISTRATION > SELinux Management, I will try now to set "System Default Enforcing Mode" in "Status" to "Permissive" or "Disabled" ... 2 reboots later I can tell you now that neither "Permissive" nor "Disabled" has solved my problem.
I still get the Messages

...
Die 22 Jul 2008 23:38:52 CEST|SETI@home Beta Test|Restarting task ap_23ap08ab_B1_P0_00015_20080715_06439.wu_1 using astropulse version 434
Die 22 Jul 2008 23:40:28 CEST|orbit@home|Sending scheduler request: Requested by user.  Requesting 666 seconds of work, reporting 0 completed tasks
Die 22 Jul 2008 23:40:29 CEST||Project communication failed: attempting access to reference site
Die 22 Jul 2008 23:40:30 CEST||Access to reference site failed - check network connection or proxy configuration.
Die 22 Jul 2008 23:40:33 CEST|orbit@home|Scheduler request failed: Couldn't resolve host name
Die 22 Jul 2008 23:41:33 CEST|orbit@home|Fetching scheduler list
Die 22 Jul 2008 23:42:39 CEST|orbit@home|Sending scheduler request: Requested by user.  Requesting 666 seconds of work, reporting 0 completed tasks
Die 22 Jul 2008 23:42:44 CEST|orbit@home|Scheduler request failed: Couldn't resolve host name
Die 22 Jul 2008 23:43:44 CEST|orbit@home|Sending scheduler request: Requested by user.  Requesting 666 seconds of work, reporting 0 completed tasks
Die 22 Jul 2008 23:43:49 CEST|orbit@home|Scheduler request failed: Couldn't resolve host name
...

until I restart the client as root :(

I am rebooting now to set "Enforcing" for SELinux again ...

---

0xFF

If you want BOINC to be started automatically at boot, type "chkconfig boinc-client on".

(reading http://fedoraproject.org/wiki/User:Mjakubicek/HowToUseBoinc someone may think that his user rights are good enough for starting boinc)

That's why I suggest to put your own username in the boinc group and create a symlink in your HOME dir. That way you can have full control over starting/stopping/pausing/resuming the daemon even when you're not root. Plus you don't have to give the password when you start the manager. That works on Fedora 7 and 8 and I hope it works on 9 as well.

I have now created the correct symlink and my own username is in the boinc group, but I still don't have full control over the client from the manager !

I can only STOP the client from the manager, but I cant RESTART or START the client :(

To RESTART the client I still have to use su to become root, and even worse: when the client is started at boot it isnt able to connect to the www unless I manually RESTART the client as root :(

MfG, MEX

---

0xFF

To RESTART the client I still have to use su to become root, and even worse: when the client is started at boot it isnt able to connect to the www unless I manually RESTART the client as root :(

MfG, MEX

I'm getting confused here...

How exactly are you starting the client? Take us through what you do, step by step.

---

Kathryn :o)

To RESTART the client I still have to use su to become root, and even worse: when the client is started at boot it isnt able to connect to the www unless I manually RESTART the client as root :(

MfG, MEX

What project? Isn't it World Community Grid?

---

Milos Jakubicek

I think that link was created by the installer but I'm not sure, it's been a long time since I installed BOINC, maybe I created that link.

The link is created by the package.

I just stumbled across some old notes I made. Those notes mention it's necessary to enable port 31416 to allow remote hosts to connect to the client. Sorry for all the confusion. It's been so long since I installed it and since it's worked trouble free I've never had to review the topic to make repairs.

One thing is the RPC connection, another then the connection to the project website.

---

Milos Jakubicek

One thing is the RPC connection, another then the connection to the project website.

After I discovered my fault (creating the symlink for root and not for my user mex) RPC connection to localhost is working flawlessly.
But I still have the problem that the client started during boot by f9 isn't able to connect to ANY projects website (until I restart the client manually as root)

I just stumbled across some old notes I made. Those notes mention it's necessary to enable port 31416 to allow remote hosts to connect to the client. Sorry for all the confusion. It's been so long since I installed it and since it's worked trouble free I've never had to review the topic to make repairs.

Currently I only want to connect to the client at localhost, so enabling port 31416 isn't a problem currently ... until I install boinc at my PS3 too and want to communicate with my PS3boinc using the manager on my notebook.
How do I enable port 31416 in SELinux ?

What project? Isn't it World Community Grid?

Currently I am participating in 7 projects:
Mit 23 Jul 2008 08:18:40 CEST|Einstein@Home|URL: http://einstein.phys.uwm.edu/; Computer ID: 1482516; location: home; project prefs: default
Mit 23 Jul 2008 08:18:40 CEST|SHA-1 Collision Search Graz|URL: http://boinc.iaik.tugraz.at/sha1_coll_search/; Computer ID: 31994; location: (none); project prefs: default
Mit 23 Jul 2008 08:18:40 CEST|Rectilinear Crossing Numbers|URL: http://dist.ist.tugraz.at/cape5/; Computer ID: 39216; location: home; project prefs: default
Mit 23 Jul 2008 08:18:40 CEST|lhcathome|URL: http://lhcathome.cern.ch/lhcathome/; Computer ID: 9703324; location: home; project prefs: default
Mit 23 Jul 2008 08:18:40 CEST|orbit@home|URL: http://orbit.psi.edu/oah/; Computer ID: 8705; location: (none); project prefs: default
Mit 23 Jul 2008 08:18:40 CEST|SETI@home Beta Test|URL: http://setiweb.ssl.berkeley.edu/beta/; Computer ID: 29977; location: home; project prefs: default
Mit 23 Jul 2008 08:18:40 CEST|SETI@home|URL: http://setiathome.berkeley.edu/; Computer ID: 4482760; location: home; project prefs: default

To RESTART the client I still have to use su to become root, and even worse: when the client is started at boot it isn't able to connect to the www unless I manually RESTART the client as root :(

I'm getting confused here...

How exactly are you starting the client? Take us through what you do, step by step.

I don't start the client, but f9 does during boot !
But then the problem is that this client can't connect to the www and is unable to communicate with projects, download WU or upload results.

A normal user ( like me working with my username mex at my V5535 notebook from FSC ) is not able to restart or start the client, as you need to become su for these tasks. The only option a normal user has is to deactivate the client from the EXTRAS of the manager (version 5.10.45).

MfG, MEX

PS: Of course I know the password for su, as i have installed f9 myself on my notebook.
But I can't take you step by step through how f9 is starting the client during boot as I am not f9, or the maintainer of the RPM boinc-client which I installed with yum on a fresh installation of f9 at my FSC ESPRIMO Mobile V5535

The point is a normal user can't solve this problem without knowing the root password, and I don't want to restart the client as su whenever I boot f9 anyway (it is the job of f9 to start the client during boot, why should I do it when my OS should be able to do it ? :rollingeyes: )

---

0xFF

But then the problem is that this client can't connect to the www and is unable to communicate with projects, download WU or upload results.

What are the error messages? I.e. if you try to attach to a project (e.g. via the manager), what is the output on the messages tab?

---

Milos Jakubicek

But then the problem is that this client can't connect to the www and is unable to communicate with projects, download WU or upload results.

What are the error messages? I.e. if you try to attach to a project (e.g. via the manager), what is the output on the messages tab?

Still the same as in http://boinc.berkeley.edu/dev/forum_thread.php?id=2896&nowrap=true#18725:
"...Scheduler request failed: Couldn't resolve host name"

MfG, MEX

PS: This happens when I try to attach a new project:

Mit 23 Jul 2008 17:10:18 CEST|SETI@home Beta Test|Restarting task ap_23ap08ab_B1_P0_00015_20080715_06439.wu_1 using astropulse version 434
Mit 23 Jul 2008 17:10:18 CEST|orbit@home|Sending scheduler request: To fetch work.  Requesting 665 seconds of work, reporting 0 completed tasks
Mit 23 Jul 2008 17:10:23 CEST|orbit@home|Scheduler request failed: Couldn't resolve host name
Mit 23 Jul 2008 17:11:39 CEST|orbit@home|Sending scheduler request: To fetch work.  Requesting 665 seconds of work, reporting 0 completed tasks
Mit 23 Jul 2008 17:11:40 CEST||Project communication failed: attempting access to reference site
Mit 23 Jul 2008 17:11:41 CEST||Access to reference site failed - check network connection or proxy configuration.
Mit 23 Jul 2008 17:11:44 CEST|orbit@home|Scheduler request failed: Couldn't resolve host name
Mit 23 Jul 2008 17:12:08 CEST||Fetching configuration file from http://www.chess960athome.org/alpha/get_project_config.php
Mit 23 Jul 2008 17:14:00 CEST|orbit@home|Sending scheduler request: To fetch work.  Requesting 665 seconds of work, reporting 0 completed tasks
Mit 23 Jul 2008 17:14:05 CEST|orbit@home|Scheduler request failed: Couldn't resolve host name
Mit 23 Jul 2008 17:16:01 CEST|orbit@home|Sending scheduler request: To fetch work.  Requesting 665 seconds of work, reporting 0 completed tasks
Mit 23 Jul 2008 17:16:06 CEST|orbit@home|Scheduler request failed: Couldn't resolve host name

---

0xFF

Still the same as in http://boinc.berkeley.edu/dev/forum_thread.php?id=2896&nowrap=true#18725:
"...Scheduler request failed: Couldn't resolve host name"

Ah, sorry, I missed that.

Anyway it seems to be a networking problem. What's the output of "host orbit.psi.edu", for example?

What about the iptables and SELinux? Try stopping iptables ("service iptables stop"), setting SELinux to permissive (as I've already mentioned).

I've also found this thread:
http://setiathome.berkeley.edu/forum_thread.php?id=47663
where someone had similar problem which has been "solved" by setting more verbose debugging output. Could you try the same (see http://boinc.berkeley.edu/trac/wiki/ClientMessages for details how to set other debugging messages) and post the output again?

---

Milos Jakubicek

Anyway it seems to be a networking problem. What's the output of "host orbit.psi.edu", for example?

What about the iptables and SELinux? Try stopping iptables ("service iptables stop"), setting SELinux to permissive (as I've already mentioned).

I have already tried disabling SELinux or settig it to permissive, which didn't help.

I assume stopping iptables wont help too, as RESTARTING the boinc-client manually after logging in with my username solves the problem.

Something must be different at the time boinc is started during booting f9 and when I restart it later ... but as I am no expert for Linux I don't have any idea what that could be :rollingeyes:

MfG, MEX

PS: Next thing I try is installing BOINC on my PS3 with f9, if I have the same problems with my PS3 I can be sure that it is a problem of the RPM or the f9 release ... otherwise the hardware of my FSC ESPRIMO Mobile V5535 might be the source of my problem :(

PPS:

[mex@localhost ~]$ host orbit.psi.edu
orbit.psi.edu has address 204.17.38.37
[mex@localhost ~]$

But this doesn't say anything, as surfing with Firefox was always possible while the client still couldn't resolve the host name until I restarted it ( it seems that the client remembers some faulty status from the time when it is started during boot until it is ordered to restart )

---

0xFF

I've also found this thread:
http://setiathome.berkeley.edu/forum_thread.php?id=47663
where someone had similar problem which has been "solved" by setting more verbose debugging output. Could you try the same (see http://boinc.berkeley.edu/trac/wiki/ClientMessages for details how to set other debugging messages) and post the output again?

The configuration is read from a file cc_config.xml.
If this file is absent, the default configuration is used.
This file has the following format:

<cc_config>
    <log_flags>
        [ flags ]
    </log_flags>
    <options>
        [ options ]
    </options>
</cc_config>

For example, if you want to see messages about CPU scheduling,
use a text editor (such as Notepad) to create the following file,
and save it as cc_config.xml in your BOINC directory.

<cc_config>
    <log_flags>
        <cpu_sched>1</cpu_sched>
    </log_flags>
</cc_config>

That looks very interesting !

I will try the following cc_config.xml :

<cc_config>
    <log_flags>
        <http_debug>
        <http_xfer_debug>
        <network_status_debug>
        <proxy_debug>
    </log_flags>
    <options>
        [ <http_1_0> ]
        [ <start_delay>X</start_delay> ]
    </options>
</cc_config>

If the debug info doesn't help, maybe the option to delay the start of applications and/or updating to the new client 6.1.6 might help.

MfG, MEX

---

0xFF