Restriction scripts can be very useful in managing sitewide installations of the Wolfram System. They can be used to prevent access to the Wolfram System by unauthorized users on the network and to guarantee license availability to particular users. Restriction scripts are cross-platform compatible, support both IPv4 and IPv6, provide unambiguous control, and require no programming experience to write. The syntax of the restriction scripts is very similar to that of the .htaccess files used in web servers for controlling access to HTML files.

Reserved licenses are always reserved. They are inaccessible to all other users or machines, regardless of whether they are in use. Even if none of the specified users or machines are running the Wolfram System, the license pool for all other users and machines is effectively reduced by the number of reserved licenses.

The layout of a typical restriction script is as follows. Sample restriction scripts follow the definitions.

AuthName Sample
AuthGroupFile mathlmgroup.txt

# Precedence
order ( allow,deny | deny,allow )

# Machine restriction 
allow from ( all | machines ... )
allow hostgroup machinegroups ... 
deny from ( all | machines ... )
deny hostgroup machinegroups ... 

# User restriction 
allow user ( all | users ... )
allow group usergroups ... 
deny user ( all | users ... )
deny group usergroups ... 

# License reservation 
reserve [count] from machines ... 
reserve [count] hostgroup machinegroups ...
reserve [count] user users ... 
reserve [count] group usergroups ...
reservesub [count] user users ...
reservesub [count] group usergroups ...

The following are terms for reserving and restricting Wolfram System licenses.

All the restriction script directives above automatically support IPv4 and IPv6 environments with no additional configuration required.

The reserve and reservesub directives allow you to guarantee license availability to particular users or machines. It is important to note that reserved licenses are always reserved and are inaccessible to all other users or machines.

In some situations, it may be necessary to reserve unequal numbers of front end and kernel licenses. This can be accomplished by using the following additional directives: reservefe, reservesubfe, reservekernel, and reservesubkernel. The syntax for reservefe and reservekernel is identical to the syntax for reserve and the syntax for reservesubfe and reservesubkernel is identical to the syntax for reservesub.

Sub-process reservations such as reservesub, reservesubfe, and reservesubkernel are necessary when reserving kernels and front ends for either parallel or grid computing. Suppose a user on your network requires 16 parallel kernels to model a large dataset. Use the reservesubkernel directive to prevent other users from inadvertently disrupting the modeling process.

The following examples illustrate key features of restriction scripts.

The following script will deny Wolfram System license requests from user1 and hostname1. License requests from all other users and machines will be allowed.

AuthName Sample1

order allow,deny
allow from all
deny from hostname1
allow user all
deny user user1

The following script will only allow license requests from users user1 through user5 in the range of 192.168.2.1 to 192.168.2.12, as well as 192.168.0.1 and 192.168.0.5. License requests from any other users or machines will be denied.

AuthName Sample2

order deny,allow
deny from all
allow from [192.168.2.1 192.168.2.12] 192.168.0.1 192.168.0.5 
deny user all
allow user user1 user2 user3 user4 user5

The following script imposes the same restrictions as the preceding script, but the users and machines are specified via groups and hostgroups.

AuthName Sample3
AuthGroupFile mathlmgroup1.txt

order deny,allow
deny from all
allow hostgroup group1
deny user all
allow group group2 group3

This is the file mathlmgroup1.txt. It defines one machine group and two user groups.

group1: 192.168.0.1 192.168.0.5 [192.168.2.1 192.168.2.12]
group2: user1 user2 user3
group3: user4 user5

The following script will allow license requests from all users and all machines except host1. If user1 requests a license while logged on to host1, the request will be allowed. This request matches both rules in this script, but the value of the order directive specifies that the allow directive has precedence. Note that a license request from user2 logged on to host1 would be denied.

AuthName Sample4

order deny,allow
deny from host1
allow user user1

The value of the order directive is the only difference between the preceding script and the following script, but the meaning of the script is reversed. This script only allows license requests from user1. A license request from user1 logged on to host1 will be denied. Such a request matches both rules, but the request is denied because the deny rule has precedence.

AuthName Sample5

order allow,deny
deny from host1
allow user user1

The following script will allow all license requests. It reserves three kernel licenses for the address 192.168.0.1, and one front end license and one kernel license for user1. These licenses are always reserved and inaccessible to all other machines or users.

AuthName Sample6

order allow,deny
allow from all
allow user all
reservekernel 3 from 192.168.0.1
reserve user user1

The following script will allow all license requests. It reserves two front end licenses, two kernel licenses, and four kernel subprocess licenses for user1. This will guarantee user1 the necessary resources for parallel computations. For more information on parallel computing see the "Parallel Computing Tools User Guide".

AuthName Sample7

order allow,deny
allow from all
allow user all
reservefe 2 user user1
reservekernel 2 user user1
reservesubkernel 4 user user1

The following script will only allow license requests from user1, user2, hostname1, hostname2, domain1.com, and addresses in the range 192.168.1.1 through 192.168.2.9. It reserves three kernel licenses and three front end licenses for hostname2, another three kernel licenses and three front end licenses for the addresses from 192.168.1.1 to 192.168.2.9, one kernel license and one front end license for user1, and one kernel license and one front end license for user2. In this script, a total of eight front end licenses and eight kernel licenses are reserved.

AuthName Sample8

order deny,allow
deny from all
allow from hostname1 hostname2 .domain1.com [192.168.1.1 192.168.2.9]
deny user all
allow user user1 user2

reserve 3 from hostname2 [192.168.1.1 192.168.2.9]
reserve user user1 user2

It may be easier to visualize the number of licenses being restricted in Sample8 if you notice that the first instance of reserve can also be written in the following form.

reserve 3 from hostname2
reserve 3 from [192.168.1.1 192.168.2.9]

The following script imposes the same restrictions and reservations as the Sample8 script, but the users and machines are specified via groups and hostgroups.

AuthName Sample9
AuthGroupFile mathlmgroup2.txt

order deny,allow
deny from all
allow hostgroup group1 group2
deny user all
allow group group3

reservekernel 3 hostgroup group2
reserve group group3

This is the file mathlmgroup2.txt. It defines two machine groups and one user group.

group1: hostname1 .domain1.com
group2: hostname2 [192.168.1.1 192.168.2.9]
group3: user1 user2

To use a restriction script, run MathLM with the option -restrict followed by the pathname of the script. You can give the restriction script any file name (and extension) that you want. See "Launching MathLM" for details about command-line options.

MathLM must be restarted if the restriction script or AuthGroupFile is changed.