- Oct 9, 1999
- 31,516
- 167
- 106
Created by Captain Rob/Upkept by Slahr Dzhe
RC5 Shared Network Installation.
Updated 4/21/00
Do you have a several computers on a LAN? Rather then loading dozens of individual computers with there own client, just load it on a shared drive on one computer. All the other computers can then access this one installation via a shortcut, which can be easily copied to each computer. For this example, I?m assuming all computers are Win32 GUI (Win95/98/NT).
Advantages:
Easy to update as new client versions are released.
Easy to add more computers via a single shortcut file.
Easy to implement via a domain login script. (Load on the server, modify the login scripts, and the entire network cracks codes and you never leave your desk)
Easy to stop all the clients at once. By just creating a file called exitrc5.now in the shared installation directory, all clients will gracefully exit within 30 seconds (can be changed/disabled).
Control/update all buffers from one PC (other's don't need Internet access).
Optional log file, which can be one combined log on the shared drive, or individual log files on the client systems.
Disadvantages:
Since the buffers need to be read/write accessible by all computers, a malicious user could cause problems.
If the system containing the buffers is offline, none of the other systems can save or retrieve Packets.
Plan it out 1st.
Plan ahead on a shared drive/folder that will be read/write available to all users. This drive doesn't need to be mapped to a drive letter on the remote PC's since we will set everything to access the drive via the generic "\\SystemName\SharedName\Path\". This shared drive should be available 24/7. Ideally this should be a shared drive on an NT Server.
Having one of the computers the designated Master will make things easier. By Master, I mean the system the program will be installed from, software updates run from, and also the one that will fetch/flush blocks. This computer should have some sort of Internet connection (you could also transfer the buffer files via email, or even manually via floppy). The Internet connection doesn?t need to be constant, that?s what the buffer files are all about. If you only connect once a day to check emails, you can adjust your buffer size to a larger value to hold 24 hours worth of blocks.
Loading the program
Load the program from the Master, making sure to override the default installation path. The install path will default to "C:\Program Files\distributed.net\". You can manually type in the path "\\NTSERVER1\DRIVE_C\distributed.net\" (example) to your shared path.
Configuring the program
Follow these steps closely. There are many possible ways the settings and command line options could be set. I?ll do my best to explain the features as I?ve setup and proved to work. If you vary from these directions just make sure you understand all of the effects.
When you start the program for the 1st time, it will detect there is no dnetc.ini file in the installation directory and will put you into the configuration menu (or you can just select File, Enter Configuration). Configure all the options from the Master PC, the Slave?s should not use the configuration menu. Make sure to use a valid email address for your d.net ID. Without a valid address, you will not receive a password thus not be able to join a team. I'd suggest setting the RC5 buffers to a size that would allow 1 full day worth of blocks to be buffered. As an example, with 4 systems running at 450, 300, 266, and 233Mhz, a buffer size of 250 blocks and a blocksize of 31 lasts for about a day. Any other minor differences in how the program runs from one PC to another should be controlled by command line options. For example, you should set the setups for your Internet Connection as Always Online, Lurk, or Lurk Only. You will then use the command line option, "- runoffline" on all of the Slave PC?s so they do not attempt to control the buffers. For a complete list of the .ini settings, and command line options, refer to the program?s help menu.
Editing the INI file
NOTE: The .ini file structure has changed starting with the 440 version of the clients.
You should now edited the dnetc.ini file and make sure all the paths are set to "\\SystemName\SharedName\Path\".
Example:
(43x versions and older)
in=\\NTSERVER1\DRIVE_C\distributed.net\buff-in.rc5
out=\\NTSERVER1\DRIVE_C\distributed.net\buff-out.rc5
in2=\\NTSERVER1\DRIVE_C\distributed.net\buff-in.des
out2=\\NTSERVER1\DRIVE_C\distributed.net\buff-out.des
logname=\\NTSERVER1\DRIVE_C\distributed.net\rc5.log
(440 versions and newer)
[buffers]
buffer-file-basename=\\NTSERVER1\DRIVE_C\distributed.net\buff-in
output-file-basename=\\NTSERVER1\DRIVE_C\distributed.net\buff-out
With logname= set as above, all clients will log to the same combined log file on the shared drive. This will let you see the complete history of what all your clients have done from one log. This has its good and bad points. Unfortunately, the log entry?s don?t yet include information from which client computer created the entry?s (I?ve requested d.net add the PC?s network name to the log entry?s. Maybe someday they will if they get enough requests).
The other logname= option is to point this to a directory that exists on all of the clients.
Example: logname=C:\rc5.log
Since C:\ is from the point of reference of each PC, each PC creates it?s own log file on it?s own drive. If your Master PC has file sharing rights on the Slave PC?s, you will be able to see each individual PC?s log file. You may get some strange effects if you were to set this line to C:\TEMP, and that directory doesn?t exist on some PC?s.
Test your Installation a little at a time
I'd suggest you test the Master PC?s installation 1st, then gradually add Slave's. This will allow you time to test and debug any problems. I personally have not had any problems with this setup, but I only have 4 computers on a small network. I'm not sure what the effect might be of adding hundreds of shared clients to a large and overloaded network. The risk is yours, the gain is ours.
Creating the shortcut files
You'll want to copy the existing "Distributed Computing Client" shortcut, or create a new shortcut to the executable. Make sure to edit the properties of this shortcut to point to "\\SystemName\SharedName\Path\" as the path. For all of the Slave PC?s, add a "- runoffline" option to the end of the shortcut.
Example of a Shortcut file:
Target: \\NTSERVER1\DRIVE_C\distributed.net\dnetc.exe -runoffline -quiet
Start in: \\NTSERVER1\DRIVE_C\distributed.net\
Save this shortcut file and copy it to other computers on your network. I'd suggest adding this shortcut to the StartUp folder so it starts automatically on boot up. The shortcut for the Master PC would be the same, except you?ll probably want to remove the "-runoffline" option. If you set the shortcut to Run: Minimized, in combination with the -quiet option, the client will run a stealth mode so it is completely hidden. This means you will not see a tray icon, nor will it show up in tasks (ctrl-alt-del). To terminate a client running in stealth mode, create a file called exitrc5.now in the shared installation directory, and ALL clients should gracefully exit within 30 seconds.
If you are the Administrator of an NT or NetWare network, you could also just add the above command line to the user?s login script instead of using a shortcut. I?ve been told with NetWare, you need to use the Windows "Start" command, or the program will hang. Basically, the line in the login script is:
#start \\server_name\volname\directory\dnetc -runoffline -quiet
Another option - Remote Buffers [updated 8/13/99]
One of the drawbacks of buffer sharing is if the system containing the buffers is offline, none of the other systems can save or retrieve Packets. With "Remote Buffers" setup properly, all your systems have their own local copy of the RC5 client, and their own local buffers. They all then update their own buffers to/from the "Remote Buffers". Since they only need to do this when they reach their local buffers fetch/flush limit, your network, server, and Internet connection, and keyserver/Personal Proxy (your welcome Mika
) are under much less stress.
The Remote buffers can be updated via a single client, or could even be updated manually by email and 'sneakernetting'. I look at Remote Buffers as being somewhere between a Personal Proxy, and a Buffer Sharing setup.
I'll briefly explain the way I'm currently using "Remote Buffers" on my home network of three systems. Again, this is just one of many possible ways to configure Remote Buffers. The main thing is to make sure only one system is setup to fetch/flush the buffers.
Note: All the following examples are now the CLI versions.
System #1 is the only system setup for Internet access. This system has a local RC5 client, but stores and updates its buffers in a dedicated directory on my Linux server (#2). This client is doing all the fetch/flush of the buffers for the entire network. For some basic Internet security, this system has no files shared from its local hard drive.
Example of system #1 RC5 Configuration:
DNETC Client Configuration: Buffer and Buffer Update Options
--------------------------------------------------------------------------
1) Buffer packets in RAM only? (no disk I/O) ==> no
2) In-Buffer Filename Prefix ==> //server1/public/rc5/buff-in
3) Out-Buffer Filename Prefix ==> //server1/public/rc5/buff-out
4) Checkpoint Filename ==>
5) Disable buffer updates from/to a keyserver ==> no
6) Disable buffer updates from/to remote buffers ==> yes
7) Remote buffer directory ==>
8) Frequently update empty buffers? ==> no
9) Preferred RC5 packet size (2^X keys/packet) ==> 32
10) Packet fetch/flush threshold ==> 250
System #2 has its RC5 client, and its main buffers, in its own local RC5 client directory. This is set to NOT attempt to connect to a keyserver. Instead, it updates its buffers via the Remote buffers function, from the buffers stored in the dedicated ?buffers? (the ones updated by system#1) directory only once every 5 packets.
Example of system #2 RC5 Configuration:
DNETC Client Configuration: Buffer and Buffer Update Options
--------------------------------------------------------------------------
1) Buffer packets in RAM only? (no disk I/O) ==> no
2) In-Buffer Filename Prefix ==> buff-in
3) Out-Buffer Filename Prefix ==> buff-out
4) Checkpoint Filename ==>
5) Disable buffer updates from/to a keyserver ==> yes
6) Disable buffer updates from/to remote buffers ==> no
7) Remote buffer directory ==> /share/rc5/buffers/
8) Frequently update empty buffers? ==> no
9) Preferred RC5 packet size (2^X keys/packet) ==> 32
10) Packet fetch/flush threshold ==> 5
System #3 has its main buffers in its own local client directory. This is set to NOT attempt to connect to a keyserver. Instead it updates its buffers via the Remote buffers function, from the buffers stored in the dedicated ?buffers? (the ones updated by system#1) directory only once every 5 packets.
Example of system #3 RC5 Configuration:
DNETC Client Configuration: Buffer and Buffer Update Options
--------------------------------------------------------------------------
1) Buffer packets in RAM only? (no disk I/O) ==> no
2) In-Buffer Filename Prefix ==> buff-in
3) Out-Buffer Filename Prefix ==> buff-out
4) Checkpoint Filename ==>
5) Disable buffer updates from/to a keyserver ==> yes
6) Disable buffer updates from/to remote buffers ==> no
7) Remote buffer directory ==> //server1/public/rc5/buffers/
8) Frequently update empty buffers? ==> no
9) Preferred RC5 packet size (2^X keys/packet) ==> 32
10) Packet fetch/flush threshold ==> 5
RC5 Shared Network Installation.
Updated 4/21/00
Do you have a several computers on a LAN? Rather then loading dozens of individual computers with there own client, just load it on a shared drive on one computer. All the other computers can then access this one installation via a shortcut, which can be easily copied to each computer. For this example, I?m assuming all computers are Win32 GUI (Win95/98/NT).
Advantages:
Easy to update as new client versions are released.
Easy to add more computers via a single shortcut file.
Easy to implement via a domain login script. (Load on the server, modify the login scripts, and the entire network cracks codes and you never leave your desk)
Easy to stop all the clients at once. By just creating a file called exitrc5.now in the shared installation directory, all clients will gracefully exit within 30 seconds (can be changed/disabled).
Control/update all buffers from one PC (other's don't need Internet access).
Optional log file, which can be one combined log on the shared drive, or individual log files on the client systems.
Disadvantages:
Since the buffers need to be read/write accessible by all computers, a malicious user could cause problems.
If the system containing the buffers is offline, none of the other systems can save or retrieve Packets.
Plan it out 1st.
Plan ahead on a shared drive/folder that will be read/write available to all users. This drive doesn't need to be mapped to a drive letter on the remote PC's since we will set everything to access the drive via the generic "\\SystemName\SharedName\Path\". This shared drive should be available 24/7. Ideally this should be a shared drive on an NT Server.
Having one of the computers the designated Master will make things easier. By Master, I mean the system the program will be installed from, software updates run from, and also the one that will fetch/flush blocks. This computer should have some sort of Internet connection (you could also transfer the buffer files via email, or even manually via floppy). The Internet connection doesn?t need to be constant, that?s what the buffer files are all about. If you only connect once a day to check emails, you can adjust your buffer size to a larger value to hold 24 hours worth of blocks.
Loading the program
Load the program from the Master, making sure to override the default installation path. The install path will default to "C:\Program Files\distributed.net\". You can manually type in the path "\\NTSERVER1\DRIVE_C\distributed.net\" (example) to your shared path.
Configuring the program
Follow these steps closely. There are many possible ways the settings and command line options could be set. I?ll do my best to explain the features as I?ve setup and proved to work. If you vary from these directions just make sure you understand all of the effects.
When you start the program for the 1st time, it will detect there is no dnetc.ini file in the installation directory and will put you into the configuration menu (or you can just select File, Enter Configuration). Configure all the options from the Master PC, the Slave?s should not use the configuration menu. Make sure to use a valid email address for your d.net ID. Without a valid address, you will not receive a password thus not be able to join a team. I'd suggest setting the RC5 buffers to a size that would allow 1 full day worth of blocks to be buffered. As an example, with 4 systems running at 450, 300, 266, and 233Mhz, a buffer size of 250 blocks and a blocksize of 31 lasts for about a day. Any other minor differences in how the program runs from one PC to another should be controlled by command line options. For example, you should set the setups for your Internet Connection as Always Online, Lurk, or Lurk Only. You will then use the command line option, "- runoffline" on all of the Slave PC?s so they do not attempt to control the buffers. For a complete list of the .ini settings, and command line options, refer to the program?s help menu.
Editing the INI file
NOTE: The .ini file structure has changed starting with the 440 version of the clients.
You should now edited the dnetc.ini file and make sure all the paths are set to "\\SystemName\SharedName\Path\".
Example:
(43x versions and older)
in=\\NTSERVER1\DRIVE_C\distributed.net\buff-in.rc5
out=\\NTSERVER1\DRIVE_C\distributed.net\buff-out.rc5
in2=\\NTSERVER1\DRIVE_C\distributed.net\buff-in.des
out2=\\NTSERVER1\DRIVE_C\distributed.net\buff-out.des
logname=\\NTSERVER1\DRIVE_C\distributed.net\rc5.log
(440 versions and newer)
[buffers]
buffer-file-basename=\\NTSERVER1\DRIVE_C\distributed.net\buff-in
output-file-basename=\\NTSERVER1\DRIVE_C\distributed.net\buff-out
With logname= set as above, all clients will log to the same combined log file on the shared drive. This will let you see the complete history of what all your clients have done from one log. This has its good and bad points. Unfortunately, the log entry?s don?t yet include information from which client computer created the entry?s (I?ve requested d.net add the PC?s network name to the log entry?s. Maybe someday they will if they get enough requests).
The other logname= option is to point this to a directory that exists on all of the clients.
Example: logname=C:\rc5.log
Since C:\ is from the point of reference of each PC, each PC creates it?s own log file on it?s own drive. If your Master PC has file sharing rights on the Slave PC?s, you will be able to see each individual PC?s log file. You may get some strange effects if you were to set this line to C:\TEMP, and that directory doesn?t exist on some PC?s.
Test your Installation a little at a time
I'd suggest you test the Master PC?s installation 1st, then gradually add Slave's. This will allow you time to test and debug any problems. I personally have not had any problems with this setup, but I only have 4 computers on a small network. I'm not sure what the effect might be of adding hundreds of shared clients to a large and overloaded network. The risk is yours, the gain is ours.
Creating the shortcut files
You'll want to copy the existing "Distributed Computing Client" shortcut, or create a new shortcut to the executable. Make sure to edit the properties of this shortcut to point to "\\SystemName\SharedName\Path\" as the path. For all of the Slave PC?s, add a "- runoffline" option to the end of the shortcut.
Example of a Shortcut file:
Target: \\NTSERVER1\DRIVE_C\distributed.net\dnetc.exe -runoffline -quiet
Start in: \\NTSERVER1\DRIVE_C\distributed.net\
Save this shortcut file and copy it to other computers on your network. I'd suggest adding this shortcut to the StartUp folder so it starts automatically on boot up. The shortcut for the Master PC would be the same, except you?ll probably want to remove the "-runoffline" option. If you set the shortcut to Run: Minimized, in combination with the -quiet option, the client will run a stealth mode so it is completely hidden. This means you will not see a tray icon, nor will it show up in tasks (ctrl-alt-del). To terminate a client running in stealth mode, create a file called exitrc5.now in the shared installation directory, and ALL clients should gracefully exit within 30 seconds.
If you are the Administrator of an NT or NetWare network, you could also just add the above command line to the user?s login script instead of using a shortcut. I?ve been told with NetWare, you need to use the Windows "Start" command, or the program will hang. Basically, the line in the login script is:
#start \\server_name\volname\directory\dnetc -runoffline -quiet
Another option - Remote Buffers [updated 8/13/99]
One of the drawbacks of buffer sharing is if the system containing the buffers is offline, none of the other systems can save or retrieve Packets. With "Remote Buffers" setup properly, all your systems have their own local copy of the RC5 client, and their own local buffers. They all then update their own buffers to/from the "Remote Buffers". Since they only need to do this when they reach their local buffers fetch/flush limit, your network, server, and Internet connection, and keyserver/Personal Proxy (your welcome Mika
) are under much less stress.The Remote buffers can be updated via a single client, or could even be updated manually by email and 'sneakernetting'. I look at Remote Buffers as being somewhere between a Personal Proxy, and a Buffer Sharing setup.
I'll briefly explain the way I'm currently using "Remote Buffers" on my home network of three systems. Again, this is just one of many possible ways to configure Remote Buffers. The main thing is to make sure only one system is setup to fetch/flush the buffers.
Note: All the following examples are now the CLI versions.
System #1 is the only system setup for Internet access. This system has a local RC5 client, but stores and updates its buffers in a dedicated directory on my Linux server (#2). This client is doing all the fetch/flush of the buffers for the entire network. For some basic Internet security, this system has no files shared from its local hard drive.
Example of system #1 RC5 Configuration:
DNETC Client Configuration: Buffer and Buffer Update Options
--------------------------------------------------------------------------
1) Buffer packets in RAM only? (no disk I/O) ==> no
2) In-Buffer Filename Prefix ==> //server1/public/rc5/buff-in
3) Out-Buffer Filename Prefix ==> //server1/public/rc5/buff-out
4) Checkpoint Filename ==>
5) Disable buffer updates from/to a keyserver ==> no
6) Disable buffer updates from/to remote buffers ==> yes
7) Remote buffer directory ==>
8) Frequently update empty buffers? ==> no
9) Preferred RC5 packet size (2^X keys/packet) ==> 32
10) Packet fetch/flush threshold ==> 250
System #2 has its RC5 client, and its main buffers, in its own local RC5 client directory. This is set to NOT attempt to connect to a keyserver. Instead, it updates its buffers via the Remote buffers function, from the buffers stored in the dedicated ?buffers? (the ones updated by system#1) directory only once every 5 packets.
Example of system #2 RC5 Configuration:
DNETC Client Configuration: Buffer and Buffer Update Options
--------------------------------------------------------------------------
1) Buffer packets in RAM only? (no disk I/O) ==> no
2) In-Buffer Filename Prefix ==> buff-in
3) Out-Buffer Filename Prefix ==> buff-out
4) Checkpoint Filename ==>
5) Disable buffer updates from/to a keyserver ==> yes
6) Disable buffer updates from/to remote buffers ==> no
7) Remote buffer directory ==> /share/rc5/buffers/
8) Frequently update empty buffers? ==> no
9) Preferred RC5 packet size (2^X keys/packet) ==> 32
10) Packet fetch/flush threshold ==> 5
System #3 has its main buffers in its own local client directory. This is set to NOT attempt to connect to a keyserver. Instead it updates its buffers via the Remote buffers function, from the buffers stored in the dedicated ?buffers? (the ones updated by system#1) directory only once every 5 packets.
Example of system #3 RC5 Configuration:
DNETC Client Configuration: Buffer and Buffer Update Options
--------------------------------------------------------------------------
1) Buffer packets in RAM only? (no disk I/O) ==> no
2) In-Buffer Filename Prefix ==> buff-in
3) Out-Buffer Filename Prefix ==> buff-out
4) Checkpoint Filename ==>
5) Disable buffer updates from/to a keyserver ==> yes
6) Disable buffer updates from/to remote buffers ==> no
7) Remote buffer directory ==> //server1/public/rc5/buffers/
8) Frequently update empty buffers? ==> no
9) Preferred RC5 packet size (2^X keys/packet) ==> 32
10) Packet fetch/flush threshold ==> 5
Facebook
Twitter