Hardware/Software Servers

The current NetSolve has been modified in a way that servers can be registered as a Hardware/Software server, a Hardware server, or a Software server.

When a server is started it is by default a Hardware/Software server. It provides it's own problems to other machines of the same architecture as Software server but can also execute problems from other machines of the same architecture. But if a user wants to provide newly created functions without donating his hardware resources to a NetSolve pool he can install the new problem to a server on his machine and start it with the -s option. So the agent will add the problem to the repository and when someone wants to execute it the binary will be transfered to a Hardware server and executed there.

When a user starts a server without the -s option (the default), the machine becomes available to any NetSolve user for execution of his problem. The agent then adds this server to the database in the hardware server list. It also knows the architecture of the hardware server. Thus if the client submits a request, the agent can make a better decision whether to use this hardware server or not. If other servers are overloaded, it can select this hardware server as a potential server.

When the client makes a request, the agent creates a mapping of the software server containing the particular software with all the hardware servers with the same architecture. Thus, the return value from the agent contains a mapping of hardware and software servers.

The client then contacts the hardware server with the set of input data. The transfer of the software is done automatically. The hardware server contacts the software server and fetches the software.

The software is dynamically transferred from the software server to the hardware server. This however is done only once, when the software arrives at the hardware site, the hardware server can cache the software. The hardware server administrator decides the caching policy. Currently, the hardware server can cache a maximum of 10 problems, and after that it removes the problem on LRU basis.

To mark a problem as non-moveable, i.e., the problem cannot be moved by the Hardware/Software server feature to another server, use the:
@MOVEABLE 0
statement in the problem description file. This applies for problems which depends on specific software installed on a particular machine which may not be available on other servers - e.g., SCALAPACK.

Hardware/Software Server Security

Due to the software transfer between the Software Server to Hardware Servers there exists a need to ensure the code being transfered can be trusted. Security is important to prevent any malicious code from being executed on the Hardware Server. Keeping this in mind, the NetSolve team has implemented a security mechanism in NetSolve using GPG.

GnuPG stands for GNU Privacy Guard and is GNU's tool for secure communication and data storage. It can be used to encrypt data and to create digital signatures. It includes an advanced key management facility and is compliant with the proposed OpenPGP Internet standard as described in RFC 2440. As such, it is aimed to be compatible with PGP from NAI, Inc. For more information on GPG, consult http://www.gnupg.org

Within the scope of NetSolve, Software providers are able to sign software using keys signed by the NetSolve Admin (or others if they choose to). The Hardware Server provider would be able to specify trustworthy parties, using GPG trust framework. By default, the hardware server trusts the NetSolve Admin. Thus to take advantage of software transfer, both the parties should have GPG and should enable the software transfer. NetSolve provides a good level of flexibility in the implementation of Hardware-Software feature and GPG.

There are 2 main cases:

CASE 1: GPG is disabled

In this case, the user has GPG disabled. Hence, the software (problem) will not be transfered by the Software Server nor will the software be transfered to the Hardware Server. This is the default NetSolve mechanism.

CASE 2: GPG is enabled

In this case, the default software, provided in the original NetSolve distribution will not be transfered. (See PDFs in $NETSOLVE_ROOT/problems directory). This is done by having MOVABLE set to 0 in the PDF. However, if the server admin decides to make new software, and have that software moveable (transferable), then he needs to set MOVABLE to 1 in the PDF.
@MOVABLE 1
He also needs to sign the software with a GPG key provided by someone whom the hardware server trusts. Typically this would be the NetSolve admin. The steps required for signing software for use with NetSolve and the Harfdware/Software server are described below.

NoteNote
 

A problem with MOVABLE set to 1 must be signed to run, even on the server that it is located on.

Software Server Setup - Generating a key

In order for movable code to be accepted by Netsolve hardware servers, the code must be signed. In order to sign code you must have a GPG key that is trusted by the Netsolve hardware servers. There are three steps to getting this key

  1. generating the key

  2. getting the key signed by someone the netsolve hardware server trusts

  3. incorporating the signed key into your keyring

Generating the key

First, verify that you have gpg 1.2.3 or later installed.
UNIX>gpg --version
Next, generate a key. This can be done two ways, one using gpg directly, the other using the provided script NS_gen_key found in $NETSOLVE_ROOT/bin/$NETSOLVE_ARCH. Type either:
UNIX>NS_gen_key
Or:
UNIX>gpg --gen-key
   (1) DSA and ElGamal (default)
   (2) DSA (sign only)
   (5) RSA (sign only)
Your selection?
Select option 5 when from the choices above. You will then see the next screen.
What keysize do you want? (1024)
Selecting the default value of 1024 is fine here.
Requested keysize is 1024 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0)
Specify a reasonable expiration date here. It is recommended that you not generate a key that doesn't expire.
Real name:
Enter your real name here.
Email address:
This should be an address that is specifically associated with NetSolve rather than your normal email address, since you want to have different keys for NetSolve than for ordinary GPG signatures. If your mail server supports subaddresses, you might try using a syntax like username+netsolve@your.example.domain)
Comment:
Enter something descriptive here, such as, Netsolve key.
Enter passphrase:
Now enter a pass phrase which will be used to encrypt your private key. You will need to use your passphrase when signing a problem. Pick a phrase that you will remember but which nobody else will guess. Several nonesense words or random seeming characters are better than short easily-recognized phrases.

2. Getting the key signed

First you need to export your key. This can also be done directly using gpg or with the provided script, NS_export_key. NS_export_key takes two parameters, first your key id, you can use the email address that you entered above, followed by the name of the file you wish to export to.
UNIX>NS_export_key username+netsolve@your.example.domain yourkey.gpg
Or:
UNIX>gpg --export username+netsolve@your.example.domain > yourkey.gpg
Now mail that key in an attachment to someone who the netsolve server trusts and who is willing to sign your key. By default, netsolve servers trust the key associated with 'netsolve-master@netlib.org' but your netsolve server may trust other keys instead of, or in addition to, this key. Netsolve-master will not sign your key unless we know you and trust you. We will expect you to appear in person and verify your key fingerprint before we will sign the key - sending the key by email just gets it to our computer where we can sign it.

3. Incorporating the signed key in your keyring

Finally when you get the signed key back in the mail, save it in a file (call it signedkey.gpg) and import it into your keyring. Again, this can be done two ways, directly using gpg or with the provided script, NS_import_key. NS_import_key takes one parameter, the file containing your signed key.
UNIX>NS_import_key signedkey.gpg
UNIX>gpg --import signedkey.gpg

4. Signing problems

A script called NS_sign_problem is used to sign problems once they are compiled and linked. To use it, type
UNIX>NS_sign_problem problem-filename key-id
For instance, if you wanted to sign a problem named service-superlu, you would type
UNIX>NS_sign_problem service-superlu username+netsolve@your.example.domain
This will produce a file named superlu.nsp. This is the signed problem which can then be installed on a Netsolve software server.

Hardware Server Setup - Incorporating a key

By default, a NetSolve hardware server will not accept mobile code. In order for the server to accept mobile code it has to be configured to use gpg to verify the authenticity and integrity of code.

If you configure your hardware server to run gpg, by default the hardware server will accept any code which is either:

This section describes how to change which keys your server trusts. In order for your server to trust a signature, the following conditions are necessary

By default, NetSolve is set up to trust the following keys:

netsolve-hardware-server@example.org" is a dummy key that is used as the identity of the hardware server in the default configuration. If you wish to change the hardware server's trust parameters you will need to delete this key and create your own key.

NetSolve's copies of GPG files

The NetSolve server maintains its own copies of gpg files (pubring.gpg, secring.gpg, trustdb.gpg). It does this so that there is no conflict between NetSolve's use of gpg and ordinary personal uses of gpg. A user which is trusted to sign someone's key for email might not be trusted to sign netsolve code. These files are stored in a directory that the NetSolve server finds using the environment variable GPGHOME.

There is a program named ns-gpg which is used to affect keys used by the NetSolve server instead of the keys ordinarily used by gpg. It is just a shell script that calls gpg with additional options. You use it to mainipulate keys and trust parameters just like you would use gpg.

How to change the default trust parameters

If you wish to change the default trust parameters, you must go through the following steps:

1. Delete the netsolve-hardware-server key

UNIX>gpg --delete-key netsolve-hardware-server

2. Create your own key for the hardware server

UNIX>NS_gen_key
gpg will then prompt you for the name and size of the key to use(see above). We recommend RSA, sign-only keys. A key size of 1024 should be sufficient for most purposes but you may make it larger if necessary. (If you make it larger, signing and verifying will be slower).

To avoid conflicts, the name of the key should be an email address that you control. It's also occasionally handy if the person who runs the server can be reached by sending email to the address. However it might also be desirable for that address to NOT be the normal address of the user who runs the NetSolve hardware server. For example, it might be useful to set up an alias named ns-hw-server@mydomain.org that gets forwarded to joe.sysadmin@mydomain.org.

3. Decide how much to trust the netsolve-master key

If you want your hardware server to be able to accept code signed by other netsolve developers that we (the primary developers) trust, you will need to change the parameters to trust the netsolve-master key. (By default this key was trusted but that's because it was signed by the netsolve-hardware-server key, which you have deleted. Having created your own key, you now need to re-establish trust from that key in the netsolve-master key.)

If you want to trust the netsolve-master key you must do two things:

If you do not want to trust it, you should not sign the key. But you should change the parameters anyway (to indicate that you don't trust it) just to be sure. To sign the key, do:
UNIX>gpg --sign-key netsolve-master
it will prompt you for the duration of your signature and your passphrase.

To change the trust parameters, do:
UNIX>gpg --edit-key netsolve-master
At the prompt, type "trust" gpg will then display something like this:
-----------------------------------------------------------------------
pub  2048R/AABD3F7C  created: 2003-07-12 expires: never      trust: f/f
(1). NetSolve Master Key <netsolve-master@netlib.org>
-----------------------------------------------------------------------
The end of the first line shows the current trust parameters:
pub  2048R/AABD3F7C  created: 2003-07-12 expires: never      trust: f/f
                                                                    ^
                                                                    |
this says how much you trust this key ------------------------------+
- means never set
q means don't know
n means do NOT trust
m means trust marginally
f means trust fully
u means ultimate trust (i.e. this is you)
gpg goes on to print the following menu:
-----------------------------------------------------------------------
Please decide how far you trust this user to correctly
verify other users' keys (by looking at passports,
checking fingerprints from different sources...)?

 1 = Don't know
 2 = I do NOT trust
 3 = I trust marginally
 4 = I trust fully
 5 = I trust ultimately
 m = back to the main menu
-----------------------------------------------------------------------
Select "2" if you do not wish to trust the netsolve-master key to sign other keys.

Select "4" if you wish to trust problems that have been signed by people whose keys are signed by netsolve-master. (i.e. people that the netsolve developers trust)

NoteNote
 

Note that if you wish to trust code that is signed directly by netsolve-master, but NOT trust code that is signed by keys that were signed by netsolve-master, you should sign netsolve-master's key but NOT trust netsolve-master as an introducer.

How to list keys

To list the keys that the NetSolve server knows about, do:
UNIX>gpg --list-keys
This will return a list of keys along with their key-ids. You can list both keys and signatures by doing:
UNIX>gpg --list-sigs

How to add a key to NetSolve server's keyring

The person whose key you want to add needs to send it to you in a file. He can extract it into a file by doing:
UNIX>gpg --export key-id > key.gpg
Then (once you've verified that this key really belongs to that person) you can do:
UNIX>gpg --import key.gpg
Then you can sign the key and/or change its trust parameters, per the examples above.

How to delete a key

UNIX>gpg --delete-key key-id
See the gpg man page or other gpg documentation for more information.