cluster of computer
31 Dec 2006 14:43:19 UTC
Topic 192258
(moderation:
i got a couple of 3ghz computer laying around house which is not in use can i conect them in way so that can be a cluster so one computer can run boic which downloads everthing and sends them out to the other computer and i can see evething being ran on boic on one computer. so there should like 10 WU running at once so i could see them and control them from one computer
cluster of computer
)
No, it was not built that way. It was built that each computer should have it's own internet connection.
Now can it be done, kind of, but it seems like a lot of footwork to do. Hand moving directories, etc. From the descriptions I saw I would never want to even try.
RE: i got a couple of 3ghz
)
As Pooh says, BOINC can't do that. But...
If each computer is separately set up for BOINC, and are in the same subnet ie. home network, then BOINCView is a program that would help.
#1. You set that up on ( say ) your 'main' computer, probably the one with the internet connection.
#2. You're going to need some hardware to actually have a network.
- Each computer needs a network card.
- You need cabling, say CAT5 or CAT6 RJ45 type - these have telephone type connectors at the ends - to run between each computer and the .....
- network 'hub'/'switch' which is a separately powered device that links all the cabling. It co-ordinates the timing of the signals and other stuff.
#3. I assume you would 'share' that internet connection within the subnet - if Windows, run the Internet Connection Wizard on each to set that up. Make sure you have each computer with the SAME WORKGROUP name. Test the whole caboodle by say browsing the internet from each, share a few harmless folders here and there and see if you can read and write to them from another computer. Most BOINCView difficulties are related to network setup, not BOINView itself. It only uses whatever network can be visible to it via the operating system of the computer that it is on.
#4. Now when you set up BOINC on each of the computers, make sure you are logged on as an administrator for the next step ( again I'm assuming Windoze ).
#5. I recommend that you select a 'service install' mode during that setup - this will ensure that BOINC will always run pretty well regardless of any other startup activity on each of those computers.
- When BOINC is up and running, connected to project(s) etc ... for each computer find the 'gui_rpc_auth.cfg' file in the directory you installed BOINC to. You need this for later steps. The file has the same name, but different contents for each computer. It is a text file which simply contains a long and otherwise meaningless hexadecimal code. If this code is subsequently presented to that BOINC installation, then it will co-operate and allow 'remote procedure call' ( RPC ) 'graphical user interface' ( GUI ) instructions.
- In addition find ( or create ) the text file 'remote_hosts.cfg' in the install directory. It contains the network name or IP address of the computer which will control it. Either put in the network name of you main computer, or simply 192.168.0.1 - which is usually the default IP address of the 'main' computer used for private home subnets like yours. Now this BOINC installation will refer to this file to know whether a subsequent GUI/RPC call is from a correct source. Clever and secure huh?
#6. BOINView has to be linked and know of those other computers. On your 'main' computer, but FOR EACH computer in the network and INCLUDING the 'main' one, do the following through the BOINView program:
- Select the 'locations' setup function ( under the 'Options' menu ).
- Add a location ( the little green 'plus' button on bottom left )
- Name it ( the other computer's network name is fine )
- It's best to select the 'Get data via network access' choice for the 'Update mode'. This enables the full functionality of BOINView that I perceive that you are seeking.
- Under 'Setup data update via GUI RPC', and for 'HostName or IP address' click the '...' button. This opens up a browse-type window. Track down through 'My Network Places', 'Entire Network', 'Microsoft Windows Network', and the whatever you chose for the WORKGROUP name to identify the computer you are currently setting up for BOINView. I recommend selecting the computer in this fashion to re-check that the computer is actually visible to BOINView via the operating system ( don't get me started on firewalls!! ).
- Just to the right of that '...' button set the number to 31416. 1043 is OK, but I found it's easier to diagnose any later firewall problems if you choose 31416. This is the IP 'port' used.
- For security reasons, BOINView needs some extra detail, the 'BOINC password'. This ensures that the BOINC on the computer you are now setting up BOINView for will actually allow BOINCView to instruct it. BOINC has a 'remote control allowed' feature, activated by that password in 'gui_rpc_auth.cfg' mentioned above. That password needs to be entered at 'BOINC password'. Remember it will be a different password at each location.
- Set the intervals at 60 seconds or so. This stops BOINView banging your network. Your probably don't need it 'realtime'.
- Hit 'Apply' and all should be well. You should see this computer on the left-most BOINView pane under 'all locations'.
- make sure to repeat this procedure for EACH computer in the network for which you have BOINC installed.
#7. I won't describe all the BOINView features. You've probably had enough of me already today! However it will definitely do what you want plus more. Post back here with any problems. :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: - When BOINC is up
)
Very nice, Mike.
Regarding the gui_rpc_auth.cfg: you can actually replace the contents of this file with whatever you want to. This means that you can actually have a nice GUI RPC password instead of meaningless gibberish and you can have teh same password everywhere. In order to achieve this, one needs to edit the file in question. It should contain a single line with plain text password. After you edit this file, just re-start boinc CC. If BOINC is installed as service, you do it through my computer -> manage -> services and applications -> services. You can do the same excercise on all the machines you want to control via GUI RPC (either BOINC Manager of BOINCView). Instead of editing the file by hand you can copy the already edited one over BOINC created ones.
Metod ...
Of course, most "nice"
)
Of course, most "nice" passwords are easily attacked (relatively), so that gibberish is an advantage when your remote hosts aren't on a protected, trusted LAN. ;-)
Since you could use a remove storage device to store your PW's safely and use the same one for all hosts, there's no good reason to not use a good strong PW (which the default generated one is). :-)
Alinator
RE: Of course, most "nice"
)
Does anybody here know wether the GUI RPC is done through some kind of SSL or not? If not, then somebody really wanting to get your password will do it quite easily.
Metod ...
RE: RE: Of course, most
)
You know that's a good question, and I haven't researched it (give self slap on head). Since there is an SSL library included, one would think the GUI RPC operation would be done over a secured connection, or at least the authentication phase of the RPC.
If not it should be since sending even a strong PW in the clear kind of defeats the whole purpose of the PW in the first place. ;-)
Alinator
Sheesh, I just sniffed the wire on my LAN using BV and Ethereal.
AFAICT, no SSL connection is ever set up between a host and a remote agent wishing to use the RPC port. This implies either the PW would have to be encrypted and sent over the insecure channel in order to protect it, or it gets sent in the clear.
I'll have to do some anaslysis on a packet capture to determine if it's sent in the clear. I didn't have my GUI RPC PW handy so I could tell if it was encrypted or not, since it looks like gibberish anyway.
Well, as usual, a computer is
)
Well, as usual, a computer is as secure as the room that you lock it in....
So if you have a potentially insecure link in the chain/LAN, how do you manage that?
I'd guess that no amount of encryption, even of gibberish, is going to protect 100%.
Makes you long for, the totally impractical but perfectly effective, a ONE-TIME PAD* code method. It's the equivalent of -
Cheers, Mike.
* You share a file of numbers, the bigger the better, and the more 'random' the better. These were distributed securely to each computer, by 'hand' so to speak. Computer A asks Computer B a series of questions like:
- is the number in position 'x' of our common file the same as the one in position 'y'?
Do this for a while, the longer the better for security. Only openly divulge whether the series of answers as a whole is entirely correct, not each element as you go. No numbers are disclosed. The chances of random replies working for the whole series of questions rapidly diminshes with the number of questions asked ( like one over 2 to the power of n ). Don't even disclose the point at which the answers started to go wrong, by rejecting a connection - complete the series and let them waste time failing without a clue. A third party 'sniffing' a valid exchange has no hope to 'catch the drift', as the 'used' numbers are marked off, and arent' re-used, this is the 'one-time' part.
This is generally quite impractical compared to 'computed password' methods like RSA etc. Mind you the CIA has ( still? ) uses one-time techniques.
( edit ) Sorry, it isn't 100% effective as I stated. There is still dumb luck that you might throw the right sequence at it. This is a risk with any connection that you can input to. However there is no computable/deducible way to lower the odds from that scenario, using one-time methods.
You could even use 'is the number at X less than, equal to, or greater than the number at Y' - make it branch as ternary. This gives like one over 3 to the power of number of questions asked.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
LOL, I get your drift,
)
LOL, I get your drift, however since SSL is in BOINC to begin with, it would be better if the client used SSL for at least the authentication of the PW. After that there's no need to use the encrypted channel for the bulk data transfer, unless a project considered their data confidential. Although a user might not want their RPC comm traffic in the clear to remote hosts over the internet either.
Thinking about it some more, I guess that's what they we're talking about for use of high security from a project POV in the official BOINC documentation.
As I said, it's not 100 % clear what's going on, so I need to do some more research.
Alinator
RE: LOL, I get your drift,
)
I'd guess that the issue is not so much the disclosure of 'valuable' project data in the open, but whether the remote control method per se is a generic vulnerability/entrance to further mischief on the host machines. While the world keeps breeding bored, rebellious and clever 13-something year olds this WILL continue to be an issue... :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Agreed, and my recommendation
)
Agreed, and my recommendation for now is to not use remote RPC operation over an untrusted network path unless you have a VPN connection over that path.
Alinator