Messages

Hi there, Fred!    I ran across a bug in 1.30 yesterday night just after installing it, thought I'd let you know.

In 1.25, I previously had BT set to contact six machines using an IP address of localhost. One of them really was the localhost, and five of them were SSH tunnel endpoints to a remote site. And that worked just fine.

After upgrade to 1.30, those six machines had their IP addresses changed to localhost, localhost2, localhost3, etc. This does not seem to be an issue for the SSH endpoints, but the actual local client would not connect for anything. I tried setting all six machines back to "localhost" without any numbers, but BT immediately re-numbered them.

I'm using Windows 7 Professional x64 SP1. And I remembered that Windows can be very finickety about allowing localhost connections (since XP SP2 came out, anyways). So, I tried setting the actual local client manually to "localhost" (it was previously "localhost6") and re-numbering the other SSH endpoints accordingly. It worked!

My suggested fix: add a bit of code to detect which machine is the local machine, and set that one first to "localhost". All my SSH endpoints happened to be listed in name order before my local desktop, and so they received the lower numbers. But if you set the local client first, and then re-numbered all the other "localhost" connections, you might avoid an issue where the local client no longer connects, with no reasons immediately apparent.

Thoughts on what code could be used to detect the local client: compare hostname to computer name in BT, compare local gui_rpc_auth contents to listed contents in BT, compare hostname to hostname reported by the BOINC clients attached to BT... It's possible none of these would be 100% accurate, but it would probably give you a good guess, I'm thinking.

Anyways, there it is!  Thanks again for writing such an excellent program, Fred!

The problem is, this would involve a couple of months of work.

Well, that's fair. After all, I'm not the one doing the coding. I was thinking that it could be a relatively simple manner of establishing a second web server on the remote ends, passwording it, and then streaming raw data wrapped in an HTTP response, with commands being sent back in the GET requests. Or something of that nature, something that would take advantage of the web display you've already got.

But like I say, I'm not the one doing the coding. What I think should be simple might actually be, as you say, a couple of months of work. And if that's the case, then I'm certainly not going to sit here and arrogantly demand that you put in that much time for just one person.  That doesn't make sense.

Once again, awesome program you've written! I'm looking forward to seeing how it continues to improve, in whatever and all aspects that may be! 

Final report (for now):

I have established connectivity to both remote sites. To one, I have created an IPSec site-to-site tunnel. At the other, I have set up a small virtual Ubuntu server to run OpenSSH.

The VPN tunnel works perfectly. The OpenSSH tunnel also works perfectly with multiple connections, validating my earlier supposition that it was the KpyM server that was failing to forward the connections correctly.

Now that I've got those established, setting up the one SSH tunnel to come up as a service should be a trivial matter, and I will not be reporting further on my progress. I still think that the native ability to chain multiple copies of BOINCtasks together as a proxy would be a useful feature, but this will work for me. If anybody would like more details on the setup I have established, please feel free to contact me.

Well, that didn't last long.

When I forward the tunnel to one client at a time, it works fine. But when I use a single tunnel to open connections to multiple remote hosts, something goes sideways, and I can only connect to one client at a time.

Possibly opening multiple SSH tunnels to each remote site would work, but that seems like a real hassle. Opening seven SSH tunnels to one site and five to another? And I'm going to make all of these come up automatically as a service? That's twelve new services?

No, I don't think that's a wonderful solution. My next step, if I want this to work, is probably to try installing OpenSSH (either through Cygwin or a purpose-built *nix virtual server) and see if that can handle multiple ports any better. Probably it would, but I guess we'll find out. VPN tunnels would also work, but that's not an option at one of the current remote sites.

OK, so after doing some searching and evaluating, I'm working with KpyM to provide SSH access to my bridgehead server. There's some quirks to work around there--such as the whitelist/blacklist logins section of the INI no longer being functional. There's also a potential issue with the number of simultaneous port forwards being limited? I haven't bumped my head against it yet. Further testing tomorrow will tell me if this is an issue or not.

Fundamentally, however, it seems to work. At least, I was able to communicate with one of my remote clients over the SSH tunnel. However, making this automatic is going to be an absolute beast as I continue to grow my remote farms.

Each remote site needs a tunnel established at boot time (using something like plink + srvany). Each client at the remote site needs a unique port forward created in the plink command line. If I have twenty clients, that's twenty port forwards I need to define on the command line for that site. Then all the other port forwards for the other sites. And all the tunnels need to be up by the time BOINCtasks comes online and starts polling.

I guess I'm not sure how scalable this solution will be, in the long-run. But for now, it looks like it will work, at least after a fashion.

I do already have LogMeIn installed on the proxy machines; that's how I'm currently accessing BOINCtasks when I'm not at the site. Which is even more time-consuming than using the web interface would be.

I think I see what you're getting at by suggesting SSH port forwarding, but I'm not sure how well that's going to work. Still, it's worth investigating. I have no *nix servers at the remote sites, but I suppose I could set up a little virtual *nix to do port forwarding if necessary. I'll look into what Windows can offer first, though--these are both domain environments, so WinSSHD is not suited for my needs.

You can't access the computers on the remote sites directly from your computer?

Well, I tried that when I set up the first remote client, and for whatever reason it never seemed to connect. I figured either it didn't work the way I thought it did, or I was missing something. Now that I have five remote clients at one site and seven at another, I figured it might be a decent feature to collect tasks data through a single open port (to the BOINCtasks proxy) instead of through five or seven open ports--or more (one for each client).

Unless, like I said, I'm missing something about how it would work. Can you elaborate for me? (Though I still think it would be nice to be able to use one connection to a site proxy instead of managing each computer through a separate port.)

I currently have three sites where I run several BOINC clients, and I use BOINCtasks at each one. I know I can use the webserver in BOINCtasks to view the two remote sites in my browser, but I'd really love the ability to view them in the same console as my local site.

Perhaps this could be added simply by having an option to point BOINCtasks to a remote BOINCtasks' webserver? Or it might be better to cut out the extra encoding and just use the remote BOINCtasks as a sort of "status proxy" to gather the information from the remote site and forward it on so that the requesting copy of BOINCtasks can display it however the user wishes? I'm not particular about it.

Love the program, by the way. Makes administering all my clients much easier! Thank you so much for your time and effort invested in this program!