I'm about to add a few minor features to the client's GUI RPC code, and I have a few questions. Basically I'd like to know how people are using the remote access features so I avoid adding things that very few people need and would confuse users who don't :P

Do you remotely control your BOINC clients, be it with BOINC Manager, BoincTasks, BOINCView, or even boinccmd?

Are you using --allow_remote_gui_rpc, or are you using a remote_hosts.cfg file to say what computer(s) can connect?

If you're using remote_hosts.cfg:
- How many lines do you have in the file?
- Do you have any hostname, or only IP addresses? did you even know you can put hostnames in remote_hosts.cfg?
- Do you have a large number of IPs in remote_hosts.cfg to represent a single computer, just because that computer changes its IP address often (due to DHCP or otherwise)?
- Do you think it would be useful if you could type a range of IP addresses in the file, such as 192.168.1.1 - 192.168.1.50 (begin-end) or "192.168.0.0/24" (CIDR)?

---

1) Yes, I've used BoincView for years. I've also written my own homebrew application which displays, logs and optionally resets individual debt values (I don't think the new v6.10 'top limited' debt system is working properly yet). The RPC for setting GPU_STD doesn't exist yet - if you happen to be passing through......?

2) remote_hosts.cfg

3) Four

4) Started with two names only, later added matching IP addresses as a fallback (had some resolving issues on my network)

5) I've been pleasantly surprised that my DHCP addresses have never 'wandered', so no, I've not needed lots of entries. DHCP is by a Draytek Vigor 2600 small-office class router.

6) Sounds logical, but perhaps even more of a minority interest than the present system. From my personal perspective, not a high priority, but nice.

Do you remotely control your BOINC clients, be it with BOINC Manager, BoincTasks, BOINCView, or even boinccmd?

Yes.

[Are you using --allow_remote_gui_rpc, or are you using a remote_hosts.cfg file to say what computer(s) can connect?

remote_hosts.cfg

If you're using remote_hosts.cfg:
- How many lines do you have in the file?

4.

- Do you have any hostname, or only IP addresses? did you even know you can put hostnames in remote_hosts.cfg?

I know, but since someone in this flat changes her hostname about every 4 months, it's useless. So I added all 4 first IP addresses instead.

- Do you have a large number of IPs in remote_hosts.cfg to represent a single computer, just because that computer changes its IP address often (due to DHCP or otherwise)?

Not large, just the first 4 as that's what the router seems to switch between.

- Do you think it would be useful if you could type a range of IP addresses in the file, such as 192.168.1.1 - 192.168.1.50 (begin-end) or "192.168.0.0/24" (CIDR)?

That would be useful and less typo prone. :-/

---

Do you remotely control your BOINC clients, be it with BOINC Manager, BoincTasks, BOINCView, or even boinccmd?

Right now, no. But in the past just using BOINC Manager. I think there was a KBOINC Manager or something of that nature that I tried a few times.

Are you using --allow_remote_gui_rpc, or are you using a remote_hosts.cfg file to say what computer(s) can connect?

remote_hosts.cfg

If you're using remote_hosts.cfg:
- How many lines do you have in the file?

About 20. But it still has stuff for very old, no longer used computers as well as comments.

- Do you have any hostname, or only IP addresses?

IP addy. But the host name is in a comment.

did you even know you can put hostnames in remote_hosts.cfg?

Nope.

- Do you have a large number of IPs in remote_hosts.cfg to represent a single computer, just because that computer changes its IP address often (due to DHCP or otherwise)?

Nope. Just because of various computers and computers with multiple OSes.

- Do you think it would be useful if you could type a range of IP addresses in the file, such as 192.168.1.1 - 192.168.1.50 (begin-end) or "192.168.0.0/24" (CIDR)?

Yes!

---

Kathryn :o)

Never paid attention to the cc_config.xml option <allow_remote_gui_rpc>1</allow_remote_gui_rpc> if that cuts the maintenance i.e. creates transparent connection will be trying it out and temp rename the remote_hosts files.

It's a command-line switch; I didn't even know it was also available in cc_config.xml (since 6.10.46).

It's a bad idea to use it; it allows connections from any computer at all...

---

Richard wrote:

4) Started with two names only, later added matching IP addresses as a fallback (had some resolving issues on my network)

Sekerob wrote:

- Do you have any hostname, or only IP addresses? BOTH

Ageless wrote:

I know, but since someone in this flat changes her hostname about every 4 months, it's useless. So I added all 4 first IP addresses instead.

KSMarksPsych wrote:

IP addy. But the host name is in a comment.

I'm almost wondering if it would be a good idea to stop supporting hostnames in remote_hosts.cfg... People often report it doesn't resolve properly anyway (so they can't connect).

There is also a significant but hard-to-fix problem: when you connect, the client resolves all hostnames in remote_hosts.cfg before deciding if it will let you in. If DNS is down, the client may get stuck in that process for up to 30 seconds per hostname. While it's doing that, it doesn't answer science app heartbeats, so apps may quit. But it can't be changed to only resolve hostnames on startup, because if the corresponding IPs change later, it wouldn't let you connect...

---

There is also a significant but hard-to-fix problem: when you connect, the client resolves all hostnames in remote_hosts.cfg before deciding if it will let you in. If DNS is down, the client may get stuck in that process for up to 30 seconds per hostname. While it's doing that, it doesn't answer science app heartbeats, so apps may quit. But it can't be changed to only resolve hostnames on startup, because if the corresponding IPs change later, it wouldn't let you connect...

In my case, it's a small home Windows-only network, with a mixture of most versions of Windows from 98 to Vista. There's no Active Directory involved, so the question of name resolution is separate and distinct from any possible DNS issues. I think my issue started with the increased security on NETBIOS these days.

At this domestic level, there's always a tension between plug'n'play simplicity and educating users into why and when proper security is necessary. For example, I recently changed ISP at another location. The new ISP supplied a free router: I unboxed it, connected power, DSL and ethernet, and I was online. No fuss, no configuration, no loading software, no username/password/IP (they all exist, of course, and I've been notified of them - but the autoconfig 'just worked'). That's the way the future is moving.

Given that remote_hosts.cfg only gives access to BOINC RPC calls, and (until the first virus@home project is launched) doesn't compromise the rest of the host, I think most home users would be satisfied with "private" or "shared", without knowing the arcana of precisely how the sharing is achieved or controlled. Would it be possible to define a keyword for remote_hosts, or a switch for cc_config, which permitted access from "this subnet only" - without forcing people to even look up their IP address/subnet mask?

I'm about to add a few minor features to the client's GUI RPC code, and I have a few questions. Basically I'd like to know how people are using the remote access features so I avoid adding things that very few people need and would confuse users who don't :P

Do you remotely control your BOINC clients, be it with BOINC Manager, BoincTasks, BOINCView, or even boinccmd?

0) Are you using --allow_remote_gui_rpc, or are you using a remote_hosts.cfg file to say what computer(s) can connect?

1) If you're using remote_hosts.cfg:
- How many lines do you have in the file?
- Do you have any hostname, or only IP addresses? did you even know you can put hostnames in remote_hosts.cfg?
- Do you have a large number of IPs in remote_hosts.cfg to represent a single computer, just because that computer changes its IP address often (due to DHCP or otherwise)?
2) - Do you think it would be useful if you could type a range of IP addresses in the file, such as 192.168.1.1 - 192.168.1.50 (begin-end) or "192.168.0.0/24" (CIDR)?

0) The list.
1) 4 lines with only the ip address, the hostnames sometimes work sometimes not.
DHCP is not an option because you never know host<->IP.
2) A range would be easier that a list.
Getting rid of warnings of unresolved IP address would be nice.

A better way to handle DHCP, so a better way to resolve the hostname would be a great thing. A way that really works.

---

TThrottle The way to control your CPU and GPU temperature.
BoincTasks The best view of BOINC.
My other activities

A better way to handle DHCP, so a better way to resolve the hostname would be a great thing. A way that really works.

Do you have any suggestions? I think using hostnames in a whitelist like this is *inherently* flawed, I don't know any way that would work well...

---

A better way to handle DHCP, so a better way to resolve the hostname would be a great thing. A way that really works.

Do you have any suggestions? I think using hostnames in a whitelist like this is *inherently* flawed, I don't know any way that would work well...

Do your own check.
A program like BoincTasks could check a range or addresses where the client would be. Should be easily read somewhere from the system, Windows knows......

The BOINC client should respond with telling BoincTasks who he is, so give out a name would be nice.
This would allow a connection with host names, over an ever rotation IP range.
And it would allow BoincTasks to scan for clients and let you choose them.
Making it more or less automatic and simple for everybody.

And adding the IP address of the computer running BoincTask, to the trusted list would be nice. When BoincTasks provides the valid key for that remote computer.

As most networks have automatic IP address assignments, the current system with fixed addresses is unnecessary complicated.

---

TThrottle The way to control your CPU and GPU temperature.
BoincTasks The best view of BOINC.
My other activities

A better way to handle DHCP, so a better way to resolve the hostname would be a great thing. A way that really works.

Do you have any suggestions? I think using hostnames in a whitelist like this is *inherently* flawed, I don't know any way that would work well...

Do your own check.
A program like BoincTasks could check a range or addresses where the client would be. Should be easily read somewhere from the system, Windows knows......

The BOINC client should respond with telling BoincTasks who he is, so give out a name would be nice.
This would allow a connection with host names, over an ever rotation IP range.
And it would allow BoincTasks to scan for clients and let you choose them.
Making it more or less automatic and simple for everybody.

And adding the IP address of the computer running BoincTask, to the trusted list would be nice. When BoincTasks provides the valid key for that remote computer.

As most networks have automatic IP address assignments, the current system with fixed addresses is unnecessary complicated.

You're suggesting the manager searches the network for available clients, and that the client tells the manager its own hostname? I'm talking about the whitelist on the client that says what computers running the manager can connect to the client. I don't think we're talking about the same thing at all.

---

A better way to handle DHCP, so a better way to resolve the hostname would be a great thing. A way that really works.

Do you have any suggestions? I think using hostnames in a whitelist like this is *inherently* flawed, I don't know any way that would work well...

Do your own check.
A program like BoincTasks could check a range or addresses where the client would be. Should be easily read somewhere from the system, Windows knows......

The BOINC client should respond with telling BoincTasks who he is, so give out a name would be nice.
This would allow a connection with host names, over an ever rotation IP range.
And it would allow BoincTasks to scan for clients and let you choose them.
Making it more or less automatic and simple for everybody.

1) And adding the IP address of the computer running BoincTask, to the trusted list would be nice. When BoincTasks provides the valid key for that remote computer.

As most networks have automatic IP address assignments, the current system with fixed addresses is unnecessary complicated.

You're suggesting the manager searches the network for available clients, and that the client tells the manager its own hostname? I'm talking about the whitelist on the client that says what computers running the manager can connect to the client. I don't think we're talking about the same thing at all.

I was merely suggesting a better way to make a hassle free connection.
Sticking with the "old" way isn't holding us back.

Point 1 is valid here. A more automatic whitelisting.
I will request the rest someplace / someone else.

---

TThrottle The way to control your CPU and GPU temperature.
BoincTasks The best view of BOINC.
My other activities

I'm almost wondering if it would be a good idea to stop supporting hostnames in remote_hosts.cfg... People often report it doesn't resolve properly anyway (so they can't connect).

Thinking about it some more, I take that back; I have decided removing support for hostnames in remote_hosts.cfg is not an option. I'll need to do some more research to find how to keep it but removing the current problems...

---

I'm almost wondering if it would be a good idea to stop supporting hostnames in remote_hosts.cfg... People often report it doesn't resolve properly anyway (so they can't connect).

Thinking about it some more, I take that back; I have decided removing support for hostnames in remote_hosts.cfg is not an option. I'll need to do some more research to find how to keep it but removing the current problems...

But sticking to a system that doesn't work, is that a good idea?
Because the name resolving is simply not working, one day it may work, the next now way.
So thinking about something better is alway good. Some form of authentication would be far better?

---

TThrottle The way to control your CPU and GPU temperature.
BoincTasks The best view of BOINC.
My other activities

Thinking about it some more, I take that back; I have decided removing support for hostnames in remote_hosts.cfg is not an option. I'll need to do some more research to find how to keep it but removing the current problems...

But sticking to a system that doesn't work, is that a good idea?
Because the name resolving is simply not working, one day it may work, the next now way.

I have been told (correctly) that users may not know the IP addresses of their local network, while they probably would know the computer names.

And with IPv6, hostnames would be more important than ever, for two reasons. First, the addresses are longer. Second, even your local network will use an address block given by your ISP, not fixed private addresses like 192.168.*.*. I don't remember that my computer's IP is 2001:470:1f05:a58::2 without looking it up...

So, as much as I would like to drop support for hostnames in remote_hosts.cfg and be done with it, that's just not acceptable :P I need to find a way to keep it, but remote the current problems (such as hanging the client).

One possibility is to do a reverse lookup on the incoming connection (resolve the IP into a hostname), and compare it to the allowed hostnames; instead of resolving the allowed hostnames into IPs and comparing them to the incoming connection's IP. But I'm still testing if this works fine on a typical Windows-based home network.

So thinking about something better is alway good. Some form of authentication would be far better?

Huh? Password authentication has always been there (ever heard of gui_rpc_auth.cfg?)

---

Huh? Password authentication has always been there (ever heard of gui_rpc_auth.cfg?)

What has this to do with the other thing, I know a thing or two about how this works.

The problem is the second layer of protection the ip blocking / allowing, that isn't working.
Because there is so much protection on most computers that the names don't get resolved properly. And when then do it's not reliable.

The remote client knows who he is and can tell the host name to the client.
That's about safe as it is now, because an IP address can easily be faked.

But safer would be to allow only computers that have a proper group key, allowing all computers with that, to authenticate themselves.

---

TThrottle The way to control your CPU and GPU temperature.
BoincTasks The best view of BOINC.
My other activities

I use boinctasks for remote control and, except for debugging, I rarely use boincmgr any more. Since this is essentially a boinc farm, I do not do any graphics.

I used to list the complete range of ip addresss because my linux systems dont understand netbios and that ubuntu network manager on several systems seems broken to where only dhcp works. ie: there is a problem setting static IP's. I also swap flash drives in and out and the linux hostname and ip, especially, changes when I do that.

On all linux systems I have set my daemon for --allow_remote_gui_rpc
It would be helpful if the default password was "boinc" at gui_rpc_auth.cfg which is what Dotsch_UX uses.

On all vista & 7 systems I have replaced "boincmgr" at HKLM/Wow6432Node/Microsoft/Windows/CurrentVersion/Run
(the normal install place) with "boincclient" and
"C:\Program Files\BOINC\boinc.exe" --detach --allow_remote_gui_rpc
and got rid of that tray applet.

Unfortunately, I have to do this after every new install (get rid of boincmgr)

On my one xp pro system I use the service mode and the -allow_remote_gui_rpc but again, i have to edit that back in after every new install.

If you are going to change the manager code you might want to remove the message that " /b --boincargs " can be used to pass arguments to boinc. I looked at the code and boincmgr parses its arguments using some type of template scheme and does not have access to the set of rules that boinc uses. ie: no args to boinc are valid since they are parsed by boincmgr for boincmgr and will fail boincmgr rules. (Unless there has been a change since I last looked about 9 months ago)

It would be nice if " /b ' -allow_remote_gui_rpc ' " could pass that
-allow_remote_gui_rpc to boinc

On all vista & 7 systems I have replaced "boincmgr" at HKLM/Wow6432Node/Microsoft/Windows/CurrentVersion/Run
(the normal install place) with "boincclient" and
"C:\Program Files\BOINC\boinc.exe" --detach --allow_remote_gui_rpc
and got rid of that tray applet.

Unfortunately, I have to do this after every new install (get rid of boincmgr)

Then change that to a batchfile that runs from the StartUp folder under Programs.

Boinc.bat

@ECHO OFF
C:
cd\Program Files\BOINC
boinc.exe --detach --allow_remote_gui_rpc

Or run a shortcut from the same place.
Make it the following way:

1. Right click on an empty space on the desktop to open the context menu
2. Select New
3. Select Shortcut with a left-click
4. In the location box type cmd /k plus whatever command you want.
(So in your case it's cmd /k "C:\Program Files\BOINC\boinc.exe" --detach --allow_remote_gui_rpc)
5. Select Next
6. Name your shortcut and push Finish

Move the shortcut to the StartUp folder in Programs.

Neither the batchfile, nor the shortcut will be removed on a BOINC uninstall/upgrade install.

On my one xp pro system I use the service mode and the -allow_remote_gui_rpc but again, i have to edit that back in after every new install.

Run it with a cc_config.xml file that has the following in it:

<cc_config>
<options>
<allow_remote_gui_rpc>1</allow_remote_gui_rpc> 
</options>
</cc_config>

You can add that into an existing cc_config.xml file. Since the file is saved in your BOINC Data directory, it won't be removed on a BOINC uninstall/upgrade install.

---

Run it with a cc_config.xml file that has the following in it:

<cc_config>
<options>
<allow_remote_gui_rpc>1</allow_remote_gui_rpc> 
</options>
</cc_config>

You can add that into an existing cc_config.xml file. Since the file is saved in your BOINC Data directory, it won't be removed on a BOINC uninstall/upgrade install.

Thanks, I was not aware of that cc_config option.

I have had problems with boinc or boincmgr being started both in the registry and in the startup folder. That was some time ago and perhaps it was caused by some other problem. I may look at doing that again.

I do have two desktop tasks that I use. One starts boinc just like you suggeseted, the other runs boinccmd and issues the --quit. I needed these two since boinctasks does not have a way to stop and restart boinc like boincmgr does. I do not use the suspend on %25 property. Rarely (ie: whenever netflick arrives) I burn a dvd and that generally requires that I terminate all boinc tasks. Opening too many windows and applications such as MSVS can require that all boinc tasking exit.

I do have two desktop tasks that I use. One starts boinc just like you suggeseted, the other runs boinccmd and issues the --quit. I needed these two since boinctasks does not have a way to stop and restart boinc like boincmgr does.

In BoincTasks File->Stop en File->Start.
And a start in the Settings menu, tab General "Start BOINC client at login"

---

TThrottle The way to control your CPU and GPU temperature.
BoincTasks The best view of BOINC.
My other activities