Oracle iPlanet Web Proxy Server 4.0.14 Configuration File Reference

Chapter 7 Other Server Configuration Files

This chapter summarizes the important configuration files not discussed in other chapters. Configuration files that should never be modified are not listed in this module.

The following configuration files are described in alphabetical order:

`certmap.conf`

The certmap.conf file configures how a certificate, designated by name, is mapped to an LDAP entry, designated by issuerDN.

Location

<install-root>/bin/https/install/misc
<install-root>/userdb

Syntax

certmap name issuerDNname:property1 [value1]
name:property2 [value2]
...

The default certificate is named default, and the default issuerDN is also named default. Therefore, the first certmap defined in the file must be as follows:

certmap default default

Use # at the beginning of a line to indicate a comment.

The following table describes properties in the certmap.conf file. The left column lists the property names. The second column from the left lists allowed values. The third column from the left lists default values. The right column lists property descriptions.

Table 7–1 certmap.conf Properties


Attribute	Allowed Values	Default Value	Description
`DNComps`	See Description	Commented out	Used to form the base DN for performing an LDAP search while mapping the certificate to a user entry. Values are as follows: Commented out: takes the user’s DN from the certificate as is. Empty: searches the entire LDAP tree (DN == suffix). Comma-separated attributes: forms the DN.
`FilterComps`	See Description	Commented out	Used to form the filter for performing an LDAP search while mapping the certificate to a user entry. Values are as follows: Commented out or empty: sets the filter to `"objectclass=*"`. Comma-separated attributes: forms the filter.
`verifycert`	`on` or `off`	`off` (commented out)	Specifies whether certificates are verified.
`CmapLdapAttr`	LDAP attribute name	certSubjectDN (commented out)	Specifies the name of the attribute in the LDAP database that contains the DN of the certificate.
`library`	Path to shared lib or dll	None	Specifies the library path for custom certificate mapping code.
`InitFn`	Name of initialization function	None	Specifies the initialization function in the certificate mapping code referenced by `library`.

dbswitch.conf

Purpose

Specifies the LDAP directory that Proxy Server uses.

Location

<install-root>/userdb

Syntax

directory name LDAP_URLname:property1 [value1]
name:property2 [value2]
...

The default contents of this file are as follows:

directory default null:///none

Edit the file as follows for anonymous binding over SSL:

directory default ldaps://directory.sun.com:636:/dc%3Dcom

Edit the file as follows for anonymous binding not over SSL:

directory default ldap://directory.sun.com:389:/dc%3Dcom

The following table describes properties in the dbswitch.conf file.

Table 7–2 dbswitch.conf Properties


Property	Allowed Values	Default Value	Description
`nsessions`	A positive integer	`8`	The number of LDAP connections for the database.
`dyngroups`	`off`, `on`, `recursive`	`on`	Determines how dynamic groups are handled. If `off`, dynamic groups are not supported. If `on`, dynamic groups are supported. If `recursive`, dynamic groups can contain other groups.
`binddn`	A valid DN		The DN used for connecting to the database. If both `binddn` and `bindpw` are not present, binding is anonymous.
`bindpw`			The password used for connecting to the database. If both `binddn` and `bindpw` are not present, binding is anonymous.
`dcsuffix`	A valid DN (relative to the LDAP URL)	none	If present, the default value of the base DN for the request’s virtual server is determined by a dc tree search of the connection group’s `servername` attribute, starting at the `dcsuffix` DN. If not present, the default value of the base DN is the `base DN` value in the LDAP URL. The `basedn` attribute of a `USERDB` element in the `server.xml` file overrides this value.
`digestauth`	`off`, `on`	`off`	Specifies whether the database can perform digest authentication. If set `on`, a special Directory Server plug-in is required. For information about how to install this plug-in, see the Oracle iPlanet Web Proxy Server 4.0.14 Administration Guide.
`syntax`	`keyfile`, `digest`, `htaccess`	`keyfile`	Specifies what type of file `auth-db` will be used
`keyfile`			Specifies the path to the key file. Required, if `syntax` is set to `keyfile`.
`digestfile`			Specifies the path to the digest file. Required, if `syntax` is set to `digestfile`.
`groupfile`			Path to the `AuthGroupFile`. If the group file is the same as the user file, this file contains both user and group data. Otherwise, it contains only group data. Required if `syntax` is set to `htaccess`. For more information about the syntax of the `AuthGroupFile`, see the Oracle iPlanet Web Proxy Server 4.0.14 Administration Guide.
`userfile`			Path to the `AuthUserFile`. If the user file is the same as the group file, this file contains both user and group data. Otherwise it contains only user data. Required if `syntax` is set to `htaccess`. For more information about the syntax of the `AuthUserFile`, see the Oracle iPlanet Web Proxy Server 4.0.14 Administration Guide.

Deployment Descriptors

These files configure features specific to Proxy Server for deployed web applications.

Location

The META-INF or WEB-INF directory of a module or application.

generated.instance.acl

Sets permissions for access to the server instance. This file is the default ACL file. You can create and use other ACL file.

Location

install-root/httpacl

password.conf

By default, Proxy Server prompts the administrator for the SSL key database password before starting. If you want the Web server to be able to restart unattended, you need to save the password in a password.conf file. Be sure that your system is adequately protected so that this file and the key databases are not compromised.

Location

<instance-directory>/config

This file is not present by default. You must create it if you need it.

Syntax

PKCS#11_module_name:password

If you are using the internal PKCS#11 software encryption module that comes with the server, type the following:

internal:password

If you are using a different PKCS#11 module, for example for hardware encryption or hardware accelerators, specify the name of the PKCS#11 module, followed by the password.

*.clfilter

Purpose

The files obj.conf.clfilter, magnus.conf.clfilter, and server.xml.clfilter contain filter specifications for cluster management operations.

Location

instance-directory/config

bu.conf

The optional bu.conf file contains batch update directives. You can use these directives to update many documents at once. You can time these updates to occur during off-peak hours to minimize the effect on the efficiency of the server. The format of this file is described in this section.

Accept

A valid URL Accept filter consists of any POSIX regular expression. It is used as a filter to test URLs for retrieval in the case of internal updates, and determines whether branching occurs for external updates.

This directive may occur any number of times, as separate Accept lines or as comma-delimited or space-delimited entries on a single Accept line. These entries are applied sequentially. Default behavior is .*, letting all URLs pass.

Syntax

Accept regular expression

Connections

For the Connections directive, n is the number of simultaneous connections to be used while retrieving. This method limits the load on your machine and, more importantly, the remote servers being contacted.

This directive can occur multiple times in a valid configuration, but only the smallest value is used.

Syntax

Connections n

Count

The argument n of the Count directive specifies the total maximum number of URLs to be updated through this process. This safeguard limits the process and defaults to a value of 300. This directive can occur multiple times in a valid configuration, but only the smallest value is used.

Syntax

Count n

Depth

The Depth directive enables you to ensure that, while enumerating, all collected objects are no more than a specified number of links away from the initial URL. The default is 1.

Syntax

Depth depth

Object boundaries

The Object wrapper signifies the boundaries between individual configurations in the bupdate.conf file. It can occur any number of times, though each occurrence requires a unique name.

All other directives are only valid when inside Object boundaries.

Syntax

<Object name=name>
...
</Object>

Reject

A valid URL Reject filter consists of any POSIX regular expression. It is used as a filter to test URLs for retrieval in the case of internal updates, and determines whether branching occurs for external updates.

This directive may occur any number of times, as separate Reject lines or as comma-delimited or space-delimited entries on a single Reject line. Entries are applied sequentially. Default behavior is no rejection for internal updates and .* (no branching, get single URL) for recursive updates.

Syntax

Reject regular expression

Source

In the Source directive. The argument keyword internal specifies batch updates are done only on objects currently in the cache. A directive of Depth 1 is assumed. For recursive enumeration, specify the name of a URL.

This directive can occur only once in a valid configuration.

Syntax

Source internal
Source URL

Type

The Type function lets you control the updating of mime types that the proxy caches. This directive can occur any number of times, in any order.

Syntax

Type ignore
Type inline
Type mime_type

Parameters

ignore means that updates will act on all MIME types that the proxy currently caches. This default behavior supersedes all other Type directives if specified.

inline means that in line data is updated as a special type, regardless of any later MIME type exclusions. These updates are meaningful only when doing recursive updates.

mime-type is assumed to be a valid entry from the system mime-types file, and is included in the list of MIME types to be updated. If the proxy doesn’t currently cache the given MIME type, the object may be retrieved but is not cached.

`icp.conf`

This file is used to configure the Internet Cache Protocol (ICP) feature of the server. The three functions in the icp.conf file are add_parent, add_sibling, and server. Each function can be called as many times as necessary. Each should be on a separate line.

add_parent

The add_parent function identifies and configures a parent server in an ICP neighborhood.

Syntax

add_parent name=name icp_port=port number proxy_port=port number 
	mcast_address=IP address ttl=number round=1|2

Note –

The above text should be on one line in the icp.conf file.

Parameters

name specifies the name of the parent server. This value can be a DNS name or an IP address.

icp_port specifies the port on which the parent listens for ICP messages.

proxy_port specifies the port for the proxy on the parent.

mcast_address specifies the multicast address the parent listens to. A multicast address is an IP address to which multiple servers can listen. Using a multicast address enables a proxy to send one query to the network that all neighbors listening to that multicast address can receive. This process eliminates the need to send a query to each neighbor separately.

ttl specifies the time to live for a message sent to the multicast address. ttl controls the number of subnets a multicast message will be forwarded to. If the ttl is set to 1, the multicast message will only be forwarded to the local subnet. If the ttl is set to 2, the message will go to all subnets that are one hop away.

round specifies in which polling ro-und the parent will be queried. A polling round is an ICP query cycle. Possible values are:

1 - The parent will be queried in the first query cycle with all other round one neighbors.
2 - The parent will only be queried if none of the neighbors in polling round one return a HIT.

Example

add_parent name=proxy1 icp_port=5151 proxy_port=3333 
	mcast_address=189.98.3.33 ttl=3 round=2

add_sibling

The add_sibling function identifies and configures a sibling server in an ICP neighborhood.

Syntax

add_sibling name=name icp_port=port number proxy_port=port number 
	mcast_address=IP address ttl=number round=1|2

Note –

The above text will all be on one line in the icp.conf file.

Parameters

name specifies the name of the sibling server, which can be a DNS name or an IP address.

icp_port specifies the port on which the sibling listens for ICP messages.

proxy_port specifies the port for the proxy on the sibling.

mcast_address specifies the multicast address the sibling listens to. A multicast address is an IP address to which multiple servers can listen. Using a multicast address enables a proxy to send one query to the network that all neighbors listening to that multicast address can receive. This process eliminates the need to send a query to each neighbor separately.

round specifies in which polling round the sibling will be queried. A polling round is an ICP query cycle. Possible values are:

1 - The sibling will be queried in the first query cycle with all other round one neighbors. This is the default polling round value.
2 - The sibling will only be queried if none of the neighbors in polling round one return a HIT.

Example

add_sibling name=proxy2 icp_port=5151 proxy_port=3333 
	mcast_address=190.99.2.11 ttl=2 round=1

Note –

The above text will all be on one line in the icp.conf file.

server

The server function identifies and configures the local proxy in an ICP neighborhood.

Syntax

server bind_address=IP-address mcast=IP-address num_servers=number 
	icp_port=port-number default_route=name 
default_route_port=port number 
no_hit_behavior=fastest_parent|default timeout=seconds

Note –

The above text should be on one line in the icp.conf file.

Parameters

bind_address specifies the IP address to which the server will bind. For machines with more than one IP address, this parameter can be used to determine which address the ICP server will bind to.

mcast the multicast address to which the neighbor listens. A multicast address is an IP address to which multiple servers can listen. Using a multicast address enables a proxy to send one query to the network that all neighbors who are listening to that multicast address can see. The process eliminates the need to send a query to each neighbor separately.

If both a multicast address and bind address are specified for the neighbor, the neighbor uses the bind address to communicate with other neighbors. If neither a bind address nor a multicast address is specified, the communication subsystem will decide which address to use to send the data.

num_servers specifies the number of processes that will service ICP requests.

icp_port specifies the port number to which the server will listen.

default_route tells the proxy server where to route a request when none of the neighboring caches respond. If default_route and default_route_port are set to origin, the proxy server will route defaulted requests to the origin server. The meaning of default_route is different depending on the value of no_hit_behavior. If no_hit_behavior is set to default, the default_route is used when none of the proxy array members return a hit. If no_hit_behavior is set to fastest_parent, the default_route value is used only if no parent responds.

default_route_port specifies the port number of the machine specified as the default_route. If default_route and default_route_port are set to origin, the proxy server will route defaulted requests to the origin server.

timeout specifies the maximum number of milliseconds the proxy will wait for an ICP response.

no_hit_behavior specifies the proxy’s behavior whenever none of the neighbors returns a hit for the requested document. Possible values are:

fastest_parent - The request is routed through the first parent that returned a miss.
default - The request is routed to the machine specified as the default route.

Example

server bind_address=198.4.66.78 mcast=no num_servers=5 icp_port=5151 
	default_route=proxy1 default_route_port=8080 no_hit_behavior=fastest_parent 
	timeout=2000

Note –

The above text should be on one line in the icp.conf file.

socks5.conf

The proxy uses the <install-root>/<instance-directory>/config/socks5.conf file to control access to the SOCKS proxy server SOCKD and its services. Each line defines the behavior of the proxy when it gets a request that matches the line.

When SOCKD receives a request, it checks the request against the instructions in <install-root>/<instance-directory>/config/socks5.conf. When it finds an instruction that matches the request, the request is permitted or denied based on the first word in the instruction (permit or deny). Once it finds a matching instruction, the daemon ignores the remaining lines in the file. If no matching instructions are found, the request is denied. You can also specify actions to take if the client’s identd or user ID is incorrect by using #NO_IDENTD: or #BAD_ID as the first word of the instruction. Each line can be up to 1023 characters long.

The sections in the socks5.conf file do not have to appear in the following order. However, because the daemon uses only the first line that matches a request, the order of the lines within each section is extremely important. The five sections of the socks5.conf file are:

Ban host/authentication — Identifies the hosts from which the SOCKS daemon should not accept connections and which types of authentication the SOCKS daemon should use to authenticate these hosts
Routing — Identifies which interface the SOCKS daemon should use for particular IP addresses
Variables and flags — Identifies which logging and informational messages the SOCKS daemon should use
Proxies — Identifies the IP addresses that are accessible through another SOCKS server and whether that SOCKS server connects directly to the host
Access control — Specifies whether the SOCKS daemon should permit or deny a request

When the SOCKS daemon receives a request, it sequentially reads the lines in each of these five sections to check for a match to the request. When it finds a line that matches the request, it reads the line to determine whether to permit or deny the request. If there are no matching lines, the request is denied.

Authentication/Ban Host Entries

There are two lines in authentication/ban host entries. The first line is the authentication line. The second line is the ban host line.

Syntax

auth source-hostmask source-portrange auth-methods

Parameters

source-hostmask identifies which hosts the SOCKS server will authenticate.

source-portrange identifies which ports the SOCKS server will authenticate.

auth-methods are the methods to be used for authentication. You can list multiple authentication methods in order of your preference. In other words, if the client does not support the first authentication method listed, the second method will be used instead. If the client does not support any of the authentication methods listed, the SOCKS server will disconnect without accepting a request. Separate multiple authentication methods by commas with no spaces in between. Possible authentication methods are:

n — No authentication required
u — User name and password required
- — Any type of authentication

The second line in the authentication/ban host entry is the ban host line.

Syntax

ban source-hostmask source-portrange

Parameters

source-hostmask identifies which hosts are banned from the SOCKS server.

source-portrange identifies the ports from which the SOCKS server will not accept requests.

Example

auth 127.27.27.127 1024 u,-ban 127.27.27.127 1024

Routing Entries

Syntax

route dest-hostmask dest-portrange interface/address

Parameters

dest-hostmask indicates the hosts for which incoming and outgoing connections must go through the specified interface.

dest-portrange indicates the ports for which incoming and outgoing connections must go through the specified interface.

interface/address indicates the IP address or name of the interface through which incoming and outgoing connections must pass. IP addresses are preferred.

Example

route 127.27.27.127 1024 le0

Variables and Flags

Syntax

set variable value

Parameters

variable indicates the name of the variable to be initialized.

value is the value to set the variable to.

Example

set SOCKS5_BINDPORT 1080

Available Settings

The following settings are those that can be inserted into the variables and flags section of the socks5.conf file. These settings will be taken from the administration forms, but they can be added, changed, or removed manually as well.

SOCKS5_BINDPORT

The SOCKS5_BINDPORT setting sets the port at which the SOCKS server will listen. This setting cannot be changed during rehash.

Syntax

set SOCKS5_BINDPORT port-number

Parameters

port-number is the port at which the SOCKS server will listen.

Example

set SOCKS5_BINDPORT 1080

SOCKS5_PWDFILE

The SOCKS5_PWDFILE setting is used to look up user name/password pairs for user name/password authentication.

Syntax

set SOCKS5_PWDFILE full-pathname

Parameters

full-pathname is the location and name of the user name/password file.

Example

set SOCKS5_PWDFILE /etc/socks5.passwd

SOCKS5_LOGFILE

The SOCKS5_LOGFILE setting is used to determine where to write log entries.

Syntax

set SOCKS5_LOGFILE full-pathname

Parameters

full-pathname is the location and name of the SOCKS logfile.

Example

set SOCKS-5_LOGFILE /var/log/socks5.log

SOCKS5_NOIDENT

THe SOCKS5_NOIDENT setting disables Ident so that SOCKS does not try to determine the user name of clients. Most servers should use this setting unless they will be acting mostly as a SOCKS4 server. SOCKS4 uses ident as authentication.

Syntax

set SOCKS5_NOIDENT

Parameters

None.

SOCKS5_DEMAND_IDENT

The SOCKS5_DEMAND_IDENT setting sets the Ident level to “require an ident response for every request.” Using Ident in this way dramatically affects the performance of your SOCKS server. If neither SOCKS5_NOIDENT or SOCKS5_DEMAND_IDENT is set, then the SOCKS server will make an Ident check for each request. The server will fulfill requests regardless of whether an Ident response is received.

Syntax

set SOCSK5_DEMAND_IDENT

Parameters

None.

SOCKS5_DEBUG

The SOCKS5_DEBUG setting causes the SOCKS server to log debug messages. You can specify the type of logging your SOCKS server will use.

If it’s not a debug build of the SOCKS server, only the value 1 is valid.

Syntax

set SOCSK5_DEBUG number

Parameters

number determines the number of the type of logging your server will use. Possible values are:

1 — Log normal debugging messages. (the default)
2 — Log extensive debugging, especially related to configuration file settings.
3 — Log all network traffic

Example

set SOCKS5_DEBUG 2

SOCKS5_USER

The SOCKS5_USER setting specifies the user name to use when authenticating to another SOCKS server. This is used when the SOCKS server is routed through another downstream SOCKS server which requires authentication.

Syntax

set SOCKS5_USER user-name

Parameters

user-name is the user name the SOCKS server will use when authenticating to another SOCKS server.

Example

set SOCKS5_USER mozilla

SOCKS5_PASSWD

The SOCKS5_PASSWD setting sets the password to use when authenticating to another SOCKS server. Sometimes a SOCKS server passes through another SOCKS server on its way to the Internet. If you define SOCKS5_USER, sockd will authenticate to other SOCKS servers with a user name and password.

Syntax

set SOCKS5_PASSWD password

Parameters

password is the password the SOCKS server will use when authenticating to another SOCKS server.

Example

set SOCKS5_PASSWD m!2@

SOCKS5_NOREVERSEMAP

The SOCKS5_NOREVERSEMAP setting instructs sockd not to use reverse DNS. Reverse DNS translates IP addresses into host names. Using this setting can increase the speed of the SOCKS server.

If you use domain masks in the configuration file, the SOCKS server will have to use reverse DNS, so this setting will have no effect.

Syntax

set SOCKS5_NOREVERSEMAP

Parameters

None.

SOCKS5_HONORBINDPORT

The SOCKS5_HONORBINDPORT setting allows the client to specify the port in a BIND request. If this setting is not specified, the SOCKS server ignores the client’s requested port and assigns a random port.

Syntax

set SOCKS5_HONORBINDPORT

Parameters

None.

SOCKS5_ALLOWBLANKETBIND

The SOCKS5_ALLOWBLANKETBIND setting allows the client to specify an IP address of all zeros (0.0.0.0) in a BIND request. If this setting is not specified, the client must specify the IP address that will be connecting to the bind port. An IP of all zeros is interpreted to mean that any IP address can connect.

Syntax

set SOCKS5_ALLOWBLANKETBIND

Parameters

None.

SOCKS5_WORKERS

The SOCKS5_WORKERS setting tunes the performance of the SOCKS server by adjusting the number of worker threads. Worker threads perform authentication and access control for new SOCKS connections. If the SOCKS server is too slow, you should increase the number of worker threads. If the server is unstable, decrease the number of worker threads.

The default number of worker threads is 40. The typical number of worker threads falls between 10 and 150.

Syntax

set SOCKS5_WORKERS number

Parameters

number is the number of worker threads the SOCKS server will use.

Example

set SOCKS5_WORKERS 40

SOCKS5_ACCEPTS

The SOCKS5_ACCEPTS setting tunes the performance of the SOCKS server by adjusting the number of accept threads. Accept threads sit on the SOCKS port listening for new SOCKS requests. If the SOCKS server is dropping connections, increase the number of accept threads. If it is unstable, decrease the number of accept threads.

The default number of accept threads is 1. The typical number of accept threads falls between 1 and 10.

Example

set SOCKS5_ACCEPTS number

Parameters

number is the number of accepts threads the SOCKS server will use.

Example

set SOCKS5_ACCEPTS 1

LDAP_URL

The LDAP-URL setting sets the URL for the LDAP server.

Syntax

set LDAP-URL URL

Parameters

URL is the URL for the LDAP server used by SOCKS.

Example

set LDAP-URL ldap://name:8180/0=Netscape,c=US

LDAP_USER

The LDAP-USER setting sets the user name that the SOCKS server will use when accessing the LDAP server.

Syntax

set LDAP-USER user-name

Parameters

user-name is the user name SOCKS will use when accessing the LDAP server.

Example

set LDAP-USER uid=admin

LDAP_PASSWD

The LDAP-PASSWD setting sets the password that the SOCKS server will use when accessing the LDAP server.

Syntax

set LDAP-PASSWD password

Parameters

password is the password SOCKS will use when accessing the LDAP server.

Example

set LDAP-PASSWD T$09

SOCKS5_TIMEOUT

The SOCKS5-TIMEOUT setting specifies the idle period that the SOCKS server will keep a connection alive between a client and a remote server before dropping the connection.

Syntax

set SOCKS5_TIMEOUT time

Parameters

time is the time, in minutes, that SOCKS will wait before timing out. The default value is 10. The value can range from 10 to 360, including both these values.

Example

set SOCKS5_TIMEOUT 30

Proxy Entries

Syntax

proxy-type dest-hostmask dest-portrange proxy-host proxy-port

Parameters

proxy-type indicates the type of proxy server. This value can be:

socks5 — SOCKS version 5
socks4 — SOCKS version 4
noproxy — a direct connection

dest-hostmask indicates the hosts for which the proxy entry applies.

dest-portrange indicates the ports for which the proxy entry applies.

proxy-host indicates the names or IP of the proxy servers to use.

proxy-port indicates the ports of the proxy servers to use

Example

socks5 127.27.27.127 1080 proxy1

Access Control Entries

Syntax

permit|deny auth-type connection-type source-hostmask dest-hostmask source-portrange dest-portrange 
	[LDAP-group]

Parameters

auth-type indicates the authentication method for which this access control line applies.

connection-type indicates the type of command the line matches. Possible command types are:

c — Connect
b — Bind; open a listen socket
u — UDP relay
- — any command

source-hostmask indicates the hosts for which the access control entry applies.

dest-hostmask indicates the hosts for which the access control entry applies.

source-portrange indicates the ports for which the access control entry applies.

dest-portrange is the port number of the destination.

LDAP-group is the group to deny or permit access to. This value is optional. If no LDAP group is identified, the access control entry applies to everyone.

Example

permit u c - - - [0-1023] group1

Specifying Ports

You will need to specify ports for many entries in your socks5.conf file. Ports can be identified by a name, number, or range. Ranges that are inclusive should be surrounded by square brackets ([ ]). Ranges that are not inclusive should be in parentheses.

parray.pat

The parray.pat (PAT) file describes each member in the proxy array of which the proxy you are administering is a member. The PAT file is an ASCII file used in proxy to proxy routing. It contains proxy array members’ machine names, IP addresses, ports, load factors, cache sizes, and so on.

Syntax

Proxy Array Information/1.0
ArrayEnabled: numberConfigID: ID numberArrayName: nameListTTL: minutes
name IPaddress proxyport URLforPAT infostring state time status loadfactor cachesize

Parameters

Proxy Array Information is version information.

ArrayEnabled specifies whether the proxy array is enabled or disabled. Possible values are:

0 — The array is disabled.
- 1 — The array is enabled.
  
  ConfigID is the identification number for the current version of the PAT file. The proxy server uses this number to determine whether the PAT file has changed.
  
  ArrayName is the name of the proxy array.
  
  ListTTL specifies how often the proxy should check the PAT file to see if it has changed. This value is specified in minutes.
  
  name is the name of a specific member of the proxy array.
  
  IPaddress is the IP address of the member.
  
  proxyport is the port at which the master proxy accepts HTTP requests.
  
  URLforPAT is the URL of the PAT file that the member will poll the master proxy for.
  
  infostring is version information.
  
  statetime is the amount of time the member has been in its current state.
  
  status specifies whether the member is enabled or disabled.
- on means that the member is on.
- off means that the member is off. If the member is off, its requests will be routed through another member of the array.
  
  loadfactor is an integer that reflects the number of requests that should be routed through the member.
  
  cachesize is the size of the member’s cache.

Example

Proxy Array Information/1.0
ArrayEnabled: 1
ConfigID: 1
ArrayName: parray
ListTTL: 10

proxy1 200.29.186.77 8080 http://pat iPlanetWebProxy/4 0 on 100 512
proxy2 187.21.165.22 8080 http://pat iPlanetWebProxy/4 0 on 100 512

parent.pat

The parent.pat file is the Proxy Array Table file that contains information about an upstream proxy array. This file has the same syntax as the parray.pat file.