cvs

package: cvs

title: cvs(5)

text:
# cvs(5)

## NAME
cvs - Concurrent Versions System support files

## NOTE
This documentation may no longer be up to date. Please consult the Cederqvist (CVS Manual) as specified in cvs(1).

## SYNOPSIS
$CVSROOT/CVSROOT/commitinfo,v

$CVSROOT/CVSROOT/cvsignore,v

$CVSROOT/CVSROOT/cvswrappers,v

$CVSROOT/CVSROOT/editinfo,v

$CVSROOT/CVSROOT/history

$CVSROOT/CVSROOT/loginfo,v

$CVSROOT/CVSROOT/modules,v

$CVSROOT/CVSROOT/rcsinfo,v

$CVSROOT/CVSROOT/taginfo,v

## DESCRIPTION
cvs is a system for providing source control to hierarchical collections of source directories. Commands and procedures for using cvs are described in cvs(1).

cvs manages source repositories, the directories containing master copies of the revision-controlled files, by copying particular revisions of the files to (and modifications back from) developers' private working directories. In terms of file structure, each individual source repository is an immediate subdirectory of $CVSROOT.

The files described here are supporting files; they do not have to exist for cvs to operate, but they allow you to make cvs operation more flexible.

You can use the `modules' file to define symbolic names for collections of source maintained with cvs. If there is no `modules' file, developers must specify complete path names (absolute, or relative to $CVSROOT) for the files they wish to manage with cvs commands.

You can use the `commitinfo' file to define programs to execute whenever `cvs commit' is about to execute. These programs are used for ``pre-commit'' checking to verify that the modified, added, and removed files are really ready to be committed. Some uses for this check might be to turn off a portion (or all) of the source repository from a particular person or group. Or, perhaps, to verify that the changed files conform to the site's standards for coding practice.

You can use the `cvswrappers' file to record cvs wrapper commands to be used when checking files into and out of the repository. Wrappers allow the file or directory to be processed on the way in and out of CVS. The intended uses are many, one possible use would be to reformat a C file before the file is checked in, so all of the code in the repository looks the same.

You can use the `loginfo' file to define programs to execute after any commit, which writes a log entry for changes in the repository. These logging programs might be used to append the log message to a file. Or send the log message through electronic mail to a group of developers. Or, perhaps, post the log message to a particular newsgroup.

You can use the `taginfo' file to define programs to execute after any tagorrtag operation. These programs might be used to append a message to a file listing the new tag name and the programmer who created it, or send mail to a group of developers, or, perhaps, post a message to a particular newsgroup.

You can use the `rcsinfo' file to define forms for log messages.

You can use the `editinfo' file to define a program to execute for editing/validating `cvs commit' log entries. This is most useful when used with a `rcsinfo' forms specification, as it can verify that the proper fields of the form have been filled in by the user committing the change.

You can use the `cvsignore' file to specify the default list of files to ignore during update.

You can use the `history' file to record the cvs commands that affect the repository. The creation of this file enables history logging.

## FILES
modules

The `modules' file records your definitions of names for collections of source code. cvs will use these definitions if you use cvs to check in a file with the right format to `$CVSROOT/CVSROOT/modules,v'. The `modules' file may contain blank lines and comments (lines beginning with `#') as well as module definitions. Long lines can be continued on the next line by specifying a backslash (``\'') as the last character on the line.

A module definition is a single line of the `modules' file, in either of two formats. In both cases, mname represents the symbolic module name, and the remainder of the line is its definition.

mname -a aliases...

This represents the simplest way of defining a module mname. The `-a' flags the definition as a simple alias: cvs will treat any use of mname (as a command argument) as if the list of names aliases had been specified instead. aliases may contain either other module names or paths. When you use paths in aliases, `cvs checkout' creates all intermediate directories in the working directory, just as if the path had been specified explicitly in the cvs arguments.

```
mname [ options ] dir [ files... ] [ &module... ]
```

In the simplest case, this form of module definition reduces to `mname dir'. This defines all the files in directory dir as module mname. dir is a relative path (from $CVSROOT) to a directory of source in one of the source repositories. In this case, on checkout, a single directory called mname is created as a working directory; no intermediate directory levels are used by default, even if dir was a path involving several directory levels.

By explicitly specifying files in the module definition after dir, you can select particular files from directory dir. The sample definition for modules is an example of a module defined with a single file from a particular directory. Here is another example:

```
m4test  unsupported/gnu/m4 foreach.m4 forloop.m4

```

With this definition, executing `cvs checkout m4test' will create a single working directory `m4test' containing the two files listed, which both come from a common directory several levels deep in the cvs source repository.

A module definition can refer to other modules by including `&module' in its definition. checkout creates a subdirectory for each such module, in your working directory.

New in cvs 1.3; avoid this feature if sharing module definitions with older versions of cvs.

Finally, you can use one or more of the following options in module definitions:

`-d name', to name the working directory something other than the module name.

New in cvs 1.3; avoid this feature if sharing module definitions with older versions of cvs.

`-i prog' allows you to specify a program prog to run whenever files in a module are committed. prog runs with a single argument, the full pathname of the affected directory in a source repository. The `commitinfo', `loginfo', and `editinfo' files provide other ways to call a program on commit.

`-o prog' allows you to specify a program prog to run whenever files in a module are checked out. prog runs with a single argument, the module name.

`-e prog' allows you to specify a program prog to run whenever files in a module are exported. prog runs with a single argument, the module name.

`-t prog' allows you to specify a program prog to run whenever files in a module are tagged. prog runs with two arguments: the module name and the symbolic tag specified to rtag.

`-u prog' allows you to specify a program prog to run whenever `cvs update' is executed from the top-level directory of the checked-out module. prog runs with a single argument, the full path to the source repository for this module.

commitinfo, loginfo, rcsinfo, editinfo

These files all specify programs to call at different points in the `cvs commit' process. They have a common structure. Each line is a pair of fields: a regular expression, separated by whitespace from a filename or command-line template. Whenever one of the regular expression matches a directory name in the repository, the rest of the line is used. If the line begins with a # character, the entire line is considered a comment and is ignored. Whitespace between the fields is also ignored. For `loginfo', the rest of the line is a command-line template to execute. The templates can include not only a program name, but whatever list of arguments you wish. If you write `%s' somewhere on the argument list, cvs supplies, at that point, the list of files affected by the commit. The first entry in the list is the relative path within the source repository where the change is being made. The remaining arguments list the files that are being modified, added, or removed by this commit invocation.

For `taginfo', the rest of the line is a command-line template to execute. The arguments passed to the command are, in order, the tagname , operation (i.e. add for `tag', mov for `tag -F', and del for `tag -d`), repository , and any remaining are pairs of filename revision . A non-zero exit of the filter program will cause the tag to be aborted.

For `commitinfo', the rest of the line is a command-line template to execute. The template can include not only a program name, but whatever list of arguments you wish. The full path to the current source repository is appended to the template, followed by the file names of any files involved in the commit (added, removed, and modified files).

For `rcsinfo', the rest of the line is the full path to a file that should be loaded into the log message template.

For `editinfo', the rest of the line is a command-line template to execute. The template can include not only a program name, but whatever list of arguments you wish. The full path to the current log message template file is appended to the template.

You can use one of two special strings instead of a regular expression: `ALL' specifies a command line template that must always be executed, and `DEFAULT' specifies a command line template to use if no regular expression is a match.

The `commitinfo' file contains commands to execute before any other commit activity, to allow you to check any conditions that must be satisfied before commit can proceed. The rest of the commit will execute only if all selected commands from this file exit with exit status 0.

The `rcsinfo' file allows you to specify log templates for the commit logging session; you can use this to provide a form to edit when filling out the commit log. The field after the regular expression, in this file, contains filenames (of files containing the logging forms) rather than command templates.

The `editinfo' file allows you to execute a script before the commit starts, but after the log information is recorded. These "edit" scripts can verify information recorded in the log file. If the edit script exits with a non-zero exit status, the commit is aborted.

The `loginfo' file contains commands to execute at the end of a commit. The text specified as a commit log message is piped through the command; typical uses include sending mail, filing an article in a newsgroup, or appending to a central file.

cvsignore, .cvsignore

The default list of files (or sh(1) file name patterns) to ignore during `cvs update'. At startup time, cvs loads the compiled in default list of file name patterns (see cvs(1)). Then the per-repository list included in $CVSROOT/CVSROOT/cvsignore is loaded, if it exists. Then the per-user list is loaded from `$HOME/.cvsignore'. Finally, as cvs traverses through your directories, it will load any per-directory `.cvsignore' files whenever it finds one. These per-directory files are only valid for exactly the directory that contains them, not for any sub-directories.

history

Create this file in $CVSROOT/CVSROOT to enable history logging (see the description of `cvs history').

## SEE ALSO
cvs(1),

## COPYING
Copyright © 1992 Cygnus Support, Brian Berliner, and Jeff Polk

Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.

Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.

Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be included in translations approved by the Free Software Foundation instead of in the original English.


cvsgraph.conf

package: cvsgraph

title: cvsgraph.conf(5)

text:
# cvsgraph.conf(5)

## NAME
cvsgraph.conf - CVS/RCS repository grapher configuration

## OVERVIEW
The configuration file is a context free grammar where empty lines and whitespace are ignored. Comments start with '#' and everything until end of line is ignored.

A configuration parameter is written as:

<keyword> = <argument> ;

Keywords are defined in PARAMETERS. The argument can be either numerical or string typed.

Numbers may be entered as octal, decimal or hex as in 0117, 79 and 0x4f respectively. Floating point numbers contain a single '.', but must start with a digit. Integer numbers are automagically converted to floats if required.

Strings are C-style strings, enclosed in double quotes in which characters may be escaped with '\' and written in octal and hex escapes. Note that '\' must be escaped if it is to be entered as a character. Escapes recognized are '\[abfnrtv]', '\[xX][0-9a-fA-F]{2}' and '\[012][0-7]{0,2}'.

Some strings are expanded with printf like conversions which start with '%'. Not all are applicable at all times, in which case they will expand to nothing.

Note that expansions of paths are available with and without trailing '/'. The distinction is required for path construction to ensure that empty expansions will not redirect the path to root and no double '/' in a path is generated.

%c

CVS root including a trailing '/' if non-empty

%C

CVS root without trailing '/', regardless of how it was entered on the command line

%m

CVS module including trailing '/' if non-empty

%M

CVS module without trailing '/', regardless of how it was entered on the command line

%f

filename without path (basename <name> functionality)

%F

filename without path and with ",v" stripped (basename <name> ,v functionality)

%p

path part of filename. This includes a trailing '/' if the path is non-empty

%r

number of revisions

%b

number of branches

%%

literal '%'

%R

the revision number (e.g. '1.2.4.4')

%P

previous revision number

%B

the branch number (e.g. '1.2.4')

%d

date of revision

%a

author of revision

%s

state of revision

%l

The log entry of the revision. You need to enable parse_logs for this to work. You may append an optional truncate length by writing '[num]' (with num the maximum length) directly after %l. If no truncation is specified, then all will be expanded. Specifying a negative truncation length means that newlines should be replaced by spaces. If truncation occurs, then "..." will be appended. The expansion is scanned for possible HTML entities and are replaced by &#...; equivalents.

For example: "%l[25]" will expand up to 25 characters of the log.

Note: This expansion is obsolete. Please use "%(%L%)"; see comment below.

%L

Same as %l, but no HTML entity translations are performed.

%t

current tag of branch or revision

%0..%9

command-line argument -0 .. -9

%(...%)

HTMLize the string withing the parenthesis. This is useful to prevent a possible cross site scripting bug when expanding tags into the map generation. For an exploit, you need to have an attack on your CVS server, or you need to be a complete idiot to enter a tag with '<', '>' or '"' characters.

Example: a string "%(%t%)", with tag ><script xxx="...">< will expand to ><script xxx="...">< and not into the execution of a script.

Note: This method is preferred to the %l expansion, because it is more generic solution (i.e. use "%(%L%)" for log expansions).

Fonts are numbered 0..4 (as defined in libgd) where 0 = tiny, 1 = small, 2 = medium (bold), 3 = large and 4 = giant.

Colors are strings, similar to HTML type colors in the form "#rrggbb" with parts written in hex, where rr = red (00-ff), gg = green (00-ff) and bb = blue (00-ff).

Colors and some strings can also be defined as conditional expressions so that revision/branch conditions can be repesented visually:

color/string = [ "key" op "content" truecase falsecase ];

Operator 'op' can be one of:

=~

contained in regex

=*

contained in regex, case insensitive

!~

not contained in regex

!*

not contained in regex, case insensitive

<

less than string, timestamp or rev/branch number

<=

less or equal than string, timestamp or rev/branch number

>

greater than string, timestamp or rev/branch number

>=

greater or equal than string, timestamp or rev/branch number

==

equal than string, timestamp or rev/branch number

!=

not equal than string, timestamp or rev/branch number

The 'content' is one of:

* POSIX 1003.2 extended regular expression

* timestamp in UTC format: YYYY[.MM[.DD[.hh[.mm[.ss]]]]]

* revision or branch number

The 'key' can be one of:

state

State of the revision

author

The auther of a revision

tag

both revision- and branch-tags

date

date of the revision

rev

numeric revision- or branch-number

Both 'truecase' and 'falsecase' can be either a (color-)string, as described above, or a new conditional expression. Examples:

rev_bgcolor = [ "state" =~ "dead" "#e08080" "#f0f0f0" ];

branch_color= [ "rev" < "2.1.2" "#000000" [ "tag" =~ "XyZ.*" "#123456" "#654321" ] ];

rev_idtext = [ "state" == "dead" "Dead %R" "%R" ]

Note that not all colors can be changed on the fly. For example, branch_color cannot be be changed based on revision identification (i.e. author, date or state). The color_bg is always unique and fixed (all expressions will evaluate to the false case). Also, only string rev_text and rev_idtext can be conditional expressions as other do not make much sense to be dynamic.

Booleans have three possible arguments: true, false and not. `Not' means inverse of what it was (logical negation) and is represented by the value -1. For the configuration file that means that the default value is negated. However, the not possibility is a very handy tool for command line overrides generated from (CGI) scripts.

There are several reserved words besides of the keywords. These additional reserved words expand to numerical values:

Booleans:

false = 0

true = 1

not = -1

Alignment specifiers:

left = 0

center = 1

right = 2

Image specifiers:

gif = 0

png = 1

jpeg = 2

Font specifiers:

tiny = 0

small = 1

medium = 2

large = 3

giant = 4

HTML level specifiers:

HTML3 = 1

HTML4 = 2

XHTML = 3

## PARAMETERS
cvsroot string

The absolute base directory where the CVS/RCS repository can be found. A '/' will be appended to the string if it is not empty and does not contain a trailing '/'.

Default is an empty string.

cvsmodule string

The module name in the CVS/RCS repository. This is converted into a subdirectory name with a trailing '/'.

Default is an empty string.

color_bg color

The background color of the image.

Default is white ("#ffffff").

transparent_bg boolean

The background color of the image is to be the transparent color. This is only useful for PNG images. Be sure to set color_bg to something reasonable to make sure that the image is viewable with programs that do not support transparency.

Default is false.

date_format string

The strftime(3) format string for date and time representation in the '%d' expansion.

Default is "%d-%b-%Y %H:%M:%S".

box_shadow boolean

A boolean whether or not to draw a shadow for the boxes of revisions and branches.

Default is false.

upside_down boolean

Draw the entire tree upside down if set. I.e. highest revisions are at the top of the image. See also cvsgraph(1) option '-u'.

Default is false.

left_right boolean

Draw the entire tree from left to right instead of top down if set. I.e. highest revisions are at the right of the image. You can also draw the tree right to left when upside_down is set too.

Default is false.

strip_untagged boolean

Omit all revisions that do not have tags and are not a branch point. This reduces the image-size, but can be confusing when looking for a specific revision. See also cvsgraph(1) option '-s'.

Default is false.

strip_first_rev boolean

Also omit the first revision in a branch if it does not have tags and is not a branch point. This has only effect if strip_untagged is set. See also cvsgraph(1) option '-S'.

Default is false.

auto_stretch boolean

Try to stretch the inter-revision spacing to move the trunks more to the left, effectively reducing the image's size. See also cvsgraph(1) option '-k'.

Default is false.

use_ttf boolean

Enable TrueType rendering of strings using the FreeType interface of libgd. Note that ttf rendering is significantly slower than libgd's bitmap fonts.

Default is false.

anti_alias boolean

Enable antialias rendering of TrueType fonts. This has only effect if use_ttf is set. Enabling anti_alias gives very nice results. However, that is at the expense of 8-bit vs. 4-bit colormap images, which can be a major drawback because the size of 8-bit images is 3..4 times that of 4-bit images (with compressed PNG as output).

Default is true.

thick_lines number

Set the thickness of connector lines between boxes. Normally, lines are drawn one pixel wide, but can look somewhat thin. Setting the thickness to anything over 5 would be plain ugly (but hey, who is to debate taste :-). Values less than 1 and over 11 are clipped.

Default is 1.

parse_logs boolean

Enable the parsing of the entire ,v file to read the log-entries between revisions. This is necessary for the %l expansion to work, but slows down parsing by a very large factor. You've been warned.

Default is false.

html_level number

Set the compliance to different types of HTML. The generated image map is slightly different for version 3.x, 4.x and XHTML. You can use the predefined identifiers (HTML3, HTML4 and XHTML) to set this value. Command line option '-x' overrides the setting.

Default is HTML3 (3.x compatibility).

branch_ttfont string

branch_tag_ttfont string

rev_ttfont string

rev_text_ttfont string

tag_ttfont string

title_ttfont string

msg_ttfont string

Set the TrueType font face or filename for the individual elements. Gd's bitmap fonts are used as a fallback if the font cannot be found or contains errors.

Default none.

branch_ttsize float

branch_tag_ttsize float

rev_ttsize float

rev_text_ttsize float

tag_ttsize float

title_ttsize float

msg_ttsize float

Set the TrueType font size for the individual elements. See also *_ttfont.

Default 0.0.

tag_font number

The font used to draw tags in the revision boxes.

Default is tiny.

tag_color color

The color used to draw tags in the revision boxes.

Default is black ("#000000").

tag_ignore string

An extended regular expression as described in regex(7) to match all tags that should not be displayed in the graph. Note that a tag will always be displayed if it matches the merge_from/merge_to expressions regardless to it being set to ignore here.

Example: tag_ignore = "(test|alpha)_release.*";

Default is empty (no matching occurs).

tag_nocase boolean

Ignore the case in regex matching in tag_ignore.

Default is false.

tag_negate boolean

Negate the matching criteria of the tag_ignore setting. If set, tags that match the tag_ignore will be shown, instead of matches being ignored. In any case, tags that match merge_from/merge_to expressions will never be suppressed.

Default is false.

tag_ignore_merge boolean

If set, then tags matched with tag_ignore will no longer be considered for matching by merge_from and merge_to.

Default is false.

rev_font number

Default is tiny.

rev_color color

The color of revision boxes, including the revision number.

Default is black ("#000000").

rev_bgcolor color

Revision box background color. This is the interior fill of the box.

Default is white ("#ffffff").

rev_separator number

Space between tags in revision boxes.

Default is 0.

rev_minline number

The minimum vertical distance between revision boxes.

Default is 0.

rev_maxline number

The maximum vertical distance between revision boxes. This has only effect if auto_stretch is set to true (or option '-k' is specified).

Default is 5 times rev_minline.

rev_lspace number

rev_rspace number

rev_tspace number

rev_bspace number

Interior spacing in revision boxes of left, right, top and bottom respectively. Note that the left right spacing is not used separately because text is center aligned.

Default is 0.

rev_idtext conditional string

The revision ID or revision number in a revision box.

Default is "%R".

rev_text conditional string

The additional text in a revision box under the revision number.

Default is "%d".

rev_text_font number

The font of the additional text in a revision box under the revision number.

Default is tiny.

rev_text_color color

The font color of the additional text in a revision box under the revision number.

Default is black ("#000000").

rev_maxtags number

Limit the number of tags in a revision box. Old trees tend to have some revisions with extremely many tags attached, which would generate a huge revision box when drawn. Limiting the number is a fair solution. Note that tag sorting is not specified in the rcsfile(7), but cvs(1) will normally have the newest tags located before older ones. Therefore, limiting the number of tags would most likely only affect older tags to be stripped. However, no guarantees are given that a specific tag is present when the limit is imposed. An ellipsis (...) is shown in the revision box when the number of tags got truncated.

Default is 0, meaning all tags shown.

rev_hidenumber boolean

If set, then no revision number is displayed in the revisionboxes. This reduces size for those graphs where the actual revision-number is irrelevant.

Default is false.

msg_font number

The font used to draw error and warning messages at the bottom of the graph.

Default is tiny.

msg_color color

The color used to draw error and warning messages.

Default is black ("#000000").

merge_color color

The color of the lines to show merges.

Default is black ("#000000").

merge_front boolean

The merge lines are drawn on top of the image if true. Otherwise, merge lines are drawn underneath.

Default is false.

merge_nocase boolean

Ignore the case in regex matching in merge_from and merge_to.

Default is false.

merge_from string

The merge_from is an extended regular expression as described in regex(7) and POSIX 1003.2 (see also Single Unix Specification at http://www.opengroup.com ). The matching tags describe source revisions of merges. Each match is subsequently used in a search for the destination tag as described by the merge_to parameter.

Note: normal string rules apply. Therefore, all backslashes '\' must be escaped, e.g. "\." must be written as "\\.".

Example: merge_from = "^from_(.*)";

Default is empty (no matching occurs).

merge_to string

The merge_to is an extended regular expression with a twist. All subexpressions from the merge_from are expanded into merge_to using %[1-9] (in contrast to \[1-9] for backreferences). Care is taken to escape the constructed expression. A '$' at the end of the merge_to expression can be important to prevent 'near match' references. Normally, you want the destination to be a good representation of the source. However, this depends on how well you defined the tags in the first place.

Example: merge_to = "^merge_%1$";

Above example, combined with the merge_from example would match a tag "from_BugFix_2002" to the merge-destination with tag "merge_BugFix_2002".

Default is empty (no matching occurs).

merge_findall boolean

Normally, merge_from/merge_to will only find the first matching tag-combination and draw a line between them, If merge_findall is set, then all matching merge_tos will result in lines from the from-tag to the to-tag.

Default is false.

merge_arrows boolean

Enable the use of arrows pointing to the merge destination.

Default is true.

merge_on_tag boolean

Draw merge lines originating from/to the actual tags that are matched when left_right is enabled. This improves the usability of the lines drawn but can under circumstances be difficult to visualize without revision boxes overlapping the lines and arrows.

Default is false.

merge_cvsnt boolean

Enable drawing of mergepoints as used by CVSNT.

Default is true.

merge_cvsnt_color color

The color of the lines to show merges from mergepoints.

Default is black ("#000000").

arrow_width number

arrow_length number

Specifies the size of the arrow pointing to the merge destination.

Default is arrow_width=3, arrow_length=12.

branch_font number

The font of the number in a branch box.

Default is tiny.

branch_tag_font number

The font of the tags in a branch box.

Default is tiny.

branch_color color

All branch element's color excluding tags.

Default is black ("#000000").

branch_bgcolor color

Branch box background color. This is the interior fill of the box.

Default is white ("#ffffff").

branch_tag_color color

All branch tags' color.

Default is black ("#000000").

branch_lspace number

branch_rspace number

branch_tspace number

branch_bspace number

Interior spacing of branch boxes.

Default is 0.

branch_margin number

Exterior spacing of branches. Each branch will be spaced with a minimum of this value.

Default is 0.

branch_connect number

Length of the vertical connector from a revision to the branch box.

Default is 0.

branch_dupbox boolean

Add an extra branch box at the end of the trunk. Useful for upside down drawn trees. If there are no commits on a branch, then no extra box is added, regardless of the setting of this option.

Default is false.

branch_fold boolean

Fold branches that have no commits into one branch-box. This helps to reduce the size of the overall image by a huge factor (5..10 in most cases). Many applications of CVS use many branches, but not all files in the repository change for each branch. Especially stable files line .cvsignore or older code tend to accumulate many empty branches at one and the same revision. Folding these branches into one box reduces the width of these images considerably.

Default is true.

branch_foldall boolean

Fold all empty branches that sprout from the save revision in one box. If this option is not set, then multiple boxes will be created if the empty branches are interspaced with ones that have revisions attached. When this option is set, then all empty branches will be collected and put into the box of the first occurring empty branch on the revision's branch point. Setting this option will reduce image size with interspaced commits to the a maximum.

Default is false.

branch_resort boolean

Resort the branches according to the number of revisions they have, where less revisions will stick closer to the sprouting trunk. This will reduce image size under circumstances where many branches have significant different number of revisions.

Default is false.

branch_subtree string

Reduce the tree only to include the subtree from the branch-number given in the argument. If the argument is a revision which is the root of branches, then all those branches will be shown. The argument can also be a symbolic tag (either a branch- or revision-tag). You normally would set this option from the command line with the -O option for interactive flexibility.

Example: branch_subtree = "1.2.4";

Default is empty (all branches shown).

title string

The title of the image.

Default is empty string.

title_x number

title_y number

Position of title.

Default is 0.

title_font number

The font of the title.

Default is tiny.

title_align number

Horizontal alignment of the title.

Default is left.

title_color color

The color of the title.

Default is black ("#000000").

margin_top number

margin_bottom number

margin_left number

margin_right number

Margins of the image. Note: the title position is not affected by the margin.

Default is 0.

image_type number

Image types are available if they can be found in the gd library. Some versions of gd do not have gif, although newer version have it implemented again. CvsGraph will automatically generate png images if gif is not available.

Default is dependent on availability and is prioritized in the order png, gif and jpeg.

image_quality number

The quality of a jpeg image (1..100)

Default is 100.

image_compress number

Set the compression level of png images (-1..9). Zero means no compression. A higher number means higher compression. Minus one selects the default library setting.

Default is -1.

image_interlace boolean

Write png and jpeg images in interlaced format. This enables progressive loading in your browser (if supported).

Default is false.

map_name string

The name= attribute in <map name="mapname">...</map> in the generated HTML map.

Default is "CvsGraphImageMap".

map_branch_href string

map_rev_href string

map_diff_href string

map_merge_href string

These are the href= attributes in the <area> tags of HTML.

Default are:

branch: "href=\"unset: conf.map_branch_href\""

revision: "href=\"unset: conf.map_rev_href\""

diff: "href=\"unset: conf.map_diff_href\""

merge: "href=\"unset: conf.map_merge_href\""

map_branch_alt string

map_rev_alt string

map_diff_alt string

map_merge_alt string

These are the alt= attributes in the <area> tags of HTML.

Default are "alt=\"%B\"", "alt=\"%R\"", "alt=\"%P <-> %R\"" and "alt=\"%P <-> %R\"" respectively.

## AUTHOR
CvsGraph is written and maintained by B. Stultiens.

Send comments and bug reports to cvsgraph@akhphd.au.dk (read the mailnote in the README file first) and visit the homepage at:

http://www.akhphd.au.dk/~bertho/cvsgraph/.

## SEE ALSO
cvsgraph(1)


cwmrc

package: cwm

title: cwmrc(5)

summary: calm window manager configuration file

text:
# cwmrc(5)

## NAME
cwmrc — calm window manager configuration file

## DESCRIPTION
This manual page describes the cwm(1) configuration file.

The current line can be extended over multiple lines using a backslash (‘\’). Comments can be put anywhere in the file using a hash mark (‘#’), and extend to the end of the current line. Care should be taken when commenting out multi-line text: the comment is effective until the end of the entire block.

Arguments containing whitespace should be surrounded by double quotes (").

The following options are accepted:

autogroup group [windowname,]windowclass

Automatically add new windows to group if their class property matches windowclass, or if their name and class properties match windowname and windowclass, respectively. The more specific last match wins. group is a number between 0 and 9. If group is 0, matching windows will not be added to any group; this may be used to override “sticky group mode”. The name and class values, respectively, for existing windows are both set in the WM_CLASS property and may be obtained using xprop(1).

bind-key key function

Bind or rebind key key to function. The modifier keys come first, followed by a ‘-’, then a keysym name, taken from /usr/X11R6/include/X11/keysymdef.h. The following modifiers are recognised:

C

Control key.

M

Meta key.

S

Shift key.

4

Mod4 (windows) key.

5

Mod5 (AltGr) key.

The function may either be one from the BIND FUNCTION LIST (see below) or the command line that is to be executed.

bind-mouse button function

Bind or rebind button button to function. The modifier keys come first, followed by a ‘-’, then the button number. The same modifiers are recognised as for key in bind-key.

The following buttons are recognised:

1

Left mouse button.

2

Middle mouse button.

3

Right mouse button.

4

Scroll up mouse button.

5

Scroll down mouse button.

The function may be taken from the BIND FUNCTION LIST (see below) or the command line that is to be executed.

borderwidth pixels

Set the window border width to pixels.

color activeborder color

Set the color of the active border.

color font color

Set menu font color.

color selfont color

Set font color for selected menu item.

color groupborder color

Set the color of the border while grouping a window.

color inactiveborder color

Set the color of the inactive border.

color menubg color

Set menu background color.

color menufg color

Set menu foreground color.

color urgencyborder color

Set the color of the border of a window indicating urgency.

color ungroupborder color

Set the color of the border while ungrouping a window.

command name path

Every name entry is shown in the application menu. When selected, the defined path is executed with execvp(3). The name entries term and lock have a special meaning. They point to the terminal and screen locking programs specified by key bindings. The defaults are xterm(1) and xlock(1), respectively.

fontname font

Change the default font for Xft(3).

gap top bottom left right

Define a “gap” in pixels at the edge of the screen, so that when a window is maximized it will not overlap this area. This “gap” can be used for applications such as xclock(1), where the user may wish to remain visible.

htile percent

Set the percentage of screen the master window should occupy after calling window-htile. If set to 0, the horizontal size of the master window will remain unchanged. The default is 50.

ignore windowname

Ignore, and do not warp to, windows with the name windowname when drawing borders and cycling through windows.

moveamount pixels

Set a default size for the keyboard movement bindings, in pixels. The default is 1.

snapdist pixels

Minimum distance to snap-to adjacent edge, in pixels. The default is 0.

sticky yes|no

Toggle sticky group mode. The default behavior for new windows is to not assign any group. By enabling sticky group mode, cwm(1) will assign new windows to the currently selected group.

unbind-key key

Unbind function bound to key. A special key keyword “all” can be used to unbind all keys.

unbind-mouse button

Unbind function bound to button. A special button keyword “all” can be used to unbind all buttons.

vtile percent

Set the percentage of screen the master window should occupy after calling window-vtile. If set to 0, the vertical size of the master window will remain unchanged. The default is 50.

wm name path

Every name entry is shown in the wm menu. When selected, the window manager is replaced by path.

## BIND FUNCTION LIST
restart

Restart the running cwm(1).

quit

Quit cwm(1).

terminal

Spawn a new terminal.

lock

Lock the screen.

menu-window

Launch window search menu.

menu-window-hidden

Launch hidden window search menu.

menu-cmd

Launch application search menu.

menu-group

Launch group search menu.

menu-exec

Launch “exec program” menu.

menu-exec-wm

Launch “exec WindowManager” menu.

menu-ssh

Launch “ssh” menu.

group-toggle-[n]

Toggle visibility of group n, where n is 1-9.

group-only-[n]

Show only group n, where n is 1-9, hiding other groups.

group-close-[n]

Close all windows in group n, where n is 1-9.

group-toggle-all

Toggle visibility of all groups.

window-group

Toggle group membership of current window.

window-movetogroup-[n]

Hide current window from display and move to group n, where n is 1-9.

group-cycle

Forward cycle through groups.

group-rcycle

Reverse cycle through groups.

window-cycle

Forward cycle through windows.

window-rcycle

Reverse cycle through windows.

window-cycle-ingroup

Forward cycle through windows in current group.

window-rcycle-ingroup

Reverse cycle through windows in current group.

window-close

Close current window.

window-hide

Hide current window.

window-lower

Lower current window.

window-raise

Raise current window.

window-menu-label

Label current window.

window-freeze

Freeze current window geometry.

window-stick

Stick current window to all groups (same as assigning to nogroup).

window-fullscreen

Full-screen current window (gap + border removed).

window-maximize

Maximize current window (gap + border honored).

window-vmaximize

Vertically maximize current window (gap + border honored).

window-hmaximize

Horizontally maximize current window (gap + border honored).

window-htile

Current window is placed at the top of the screen, maximized horizontally and resized to htile (default half) of the vertical screen space. Other windows in its group share remaining screen space.

window-vtile

Current window is placed on the left of the screen, maximized vertically and resized to vtile (default half) of the horizontal screen space. Other windows in its group share remaining screen space.

window-move

Move current window.

window-resize

Resize current window.

window-move-up

Move window moveamount pixels up.

window-move-down

Move window moveamount pixels down.

window-move-right

Move window moveamount pixels right.

window-move-left

Move window moveamount pixels left.

window-move-up-big

Move window 10 times moveamount pixels up.

window-move-down-big

Move window 10 times moveamount pixels down.

window-move-right-big

Move window 10 times moveamount pixels right.

window-move-left-big

Move window 10 times moveamount pixels left.

window-resize-up

Resize window moveamount pixels up.

window-resize-down

Resize window moveamount pixels down.

window-resize-right

Resize window moveamount pixels right.

window-resize-left

Resize window moveamount pixels left.

window-resize-up-big

Resize window 10 times moveamount pixels up.

window-resize-down-big

Resize window 10 times moveamount pixels down.

window-resize-right-big

Resize window 10 times moveamount pixels right.

window-resize-left-big

Resize window 10 times moveamount pixels left.

window-snap-up

Snap window to top edge.

window-snap-down

Snap window to bottom edge.

window-snap-right

Snap window to right edge.

window-snap-left

Snap window to left edge.

window-snap-up-right

Snap window to top-right corner.

window-snap-up-left

Snap window to top-left corner.

window-snap-down-right

Snap window to bottom-right corner.

window-snap-down-left

Snap window to bottom-left corner.

pointer-move-up

Move pointer moveamount pixels up.

pointer-move-down

Move pointer moveamount pixels down.

pointer-move-right

Move pointer moveamount pixels right.

pointer-move-left

Move pointer moveamount pixels left.

pointer-move-up-big

Move pointer 10 times moveamount pixels up.

pointer-move-down-big

Move pointer 10 times moveamount pixels down.

pointer-move-right-big

Move pointer 10 times moveamount pixels right.

pointer-move-left-big

Move pointer 10 times moveamount pixels left.

## FILES
~/.cwmrc

Default cwm(1) configuration file.

## EXAMPLES

```
# Set default Xft(3) font
fontname "sans-serif:pixelsize=14:bold"

# Turn on sticky-group mode
sticky yes

# Any entry here is shown in the application menu
command firefox		firefox
command xmms		xmms
command top		"xterm -e top"

# Autogroup definitions
autogroup 3 "aterm,XTerm"
autogroup 3 "xterm,XTerm"

# Ignore programs by that name by not drawing borders around them.
ignore XMMS
ignore xwi
ignore xapm
ignore xclock

# Key bindings
bind-key CM-r		window-menu-label
bind-key CS-Return	"xterm -e top"
bind-key C4-equal	window-vmaximize
bind-key C4S-equal	window-hmaximize
bind-key M-1		group-only-1
bind-key M-2		group-only-2
bind-key M-3		group-only-3
bind-key MS-1		window-movetogroup-1
bind-key MS-2		window-movetogroup-2
bind-key MS-3		window-movetogroup-3
unbind-key 4-o
unbind-key CM-equal
unbind-key CMS-equal

# Mouse bindings
bind-mouse M-2		window-lower
bind-mouse M-3		window-resize
```

## SEE ALSO
cwm(1)

## HISTORY
The cwmrc file format first appeared in OpenBSD 4.4.


cyclades-devices

package: cyclades-serial-client

title: cyclades-devices(5)

text:
# cyclades-devices(5)

## NAME
cyclades-devices - tables for driving cyclades-serial-client

## DESCRIPTION
The cyclades-devices file supplies all mapping between Unix device files (/dev/*) and the addresses of serial ports of Cyclades Terminal Servers. It contains one entry for each serial port, with the following format:

device:rastype:rasname:physport:type:options

Note: A # character at beginning of line indicates a comment

The entry fields are:

devname

- A full pathname of the file that will be associated to the serial port. It must start with a "/dev/" preffix. Two naming schemes may be used here: - devname does not exist, and will be linked to a free pseudo-tty. This is the default behavior of cyclades-ser-cli. - devname is the name of a valid slave pseudo-tty. In this case, the '-t 1' option must be assigned in options field. (Note: this option is not supported by this release).

rastype

- Terminal Server type: - prts, for Cyclades Pr302X/TS Terminal Servers. - path, for Cyclades PathRAS Terminal Server.

rasname

- Host Name or IP Address of the Terminal Server where the serial port resides.

physport

- Number of physical port in the Terminal Server. If treated as the IP address associated with this port, in a IP-based addressing scheme.

type

- Server type that will be contacted to handle the serial port: - rtelnet, for Remote Telnet Server - socket, for Socket Server

options

- Per-port specific options, passed to cyclades-ser-cli program.

## EXAMPLES
1. Device on a PR3020/TS Terminal Server pr3k Port 1, accessed through /dev/ctty01 device file name, using telnet protocol (remote telnet server)

/dev/ctty01:prts:pr3k:1:rtelnet:

2. The same device, but with an IP address pr3k_port1 associated to the serial port (IP-based port addressing)

/dev/ctty01:prts:pr3k_port1:0:rtelnet:

3. Device on a PathRAS Terminal Server pr3k Port 2, accessed through /dev/ctty02 device file name, using socket protocol (socket server)

/dev/ctty02:path:pr3k:2:socket:

## FILES
/etc/cyclades-devices This file

## SEE ALSO
cyclades-serial-client(1), cyclades-ser-cli(1)


socks.conf

package: dante

title: socks.conf(5)

summary: socks client configuration file syntax

text:
# socks.conf(5)

## NAME
socks.conf - socks client configuration file syntax

## DESCRIPTION
The configuration file for the socks client library allow control over logging and server selection. It is divided into two parts; global settings and routes. A line can be commented using the standard comment character #.

## FORMAT
The global settings are in the form of a keyword followed by a colon and the value.

debug

Setting this field to 1 turns on debugging.

logoutput

This value controls where the client library sends logoutput. It can be either syslog, stdout, stderr, a filename, or a combination. The default is no logging.

resolveprotocol

The protocol used to resolve hostnames. Valid values are udp, tcp and fake. The default is udp.

route.badexpire

How long the "bad" marking of a route should remain set before it is removed. Default is 300 seconds.

route.maxfail

How many times a route can fail before it is marked as bad. Default is 1.

timeout.connect

The number of seconds the client will wait for a connect to the proxy server to complete. The default is 0, indicating the client should use the systems default.

## ROUTES
The routes are specified with a route keyword. Inside a pair of parenthesis ({}) a set of keywords control the behavior of the route. Each route can contain three address specifications; from, to and via. A route is selected for a connection based on the values within the route block.

When searching for a route to match the clients request, the library will first look for a direct route. Then for a socks_v4 route, a socks_v5 route, a http route, and lastly for a upnp route.

Depending on how the library is configured and environment variables set (see the manual for socksify(1)), there may or may not be an automatic fallback to an auto-generated direct route if no other route is found.

The route block can contain the following:

ADDRESSES

Each address field can consist of a IP-address (and where meaningful, a netmask, separated from the IP-address by a '/' sign.), a hostname, a domainname (designated by the leading '.'), or an interfacename (where meaningful). Each address can be followed by a optional port specifier.

from

The route is used only by requests coming from the address given as value.

to

The route is used only by requests going to the address given as value.

via

Address of the proxy server that should be used as a gateway for the connection, or the special value direct to indicate the connection should be direct rather than go via any proxy server. In the case of upnp, the address can also be the name of the interface to use for discovering the upnp controlpoint, if the full url for the IGD is not yet known, or the special value broadcast to indicate the client should broadcast for an upnp-router on all available network interfaces.

port

Parameter to from, to and via. Accepts the keywords eq/=, ne/!=, ge/>=, le/<=, gt/>, lt/< followed by a number. A portrange can also be given as "port <start #> - <end #>", which will match all port numbers within the range <start #> and <end #>.

## Options
clientcompatibility

Enables certain options for compatibility with broken servers. Valid values are: necgssapi, for compatibility with servers implementing gssapi the NEC socks way.

command

The server supports the given commands. Valid commands are bind, bindreply, connect, udpassociate and udpreply. The default is all commands supported by the protocols set for the route. Can be used instead of, or to complement, protocol.

gssapi.enctype

Which encryption to enforce for GSSAPI-authenticated communication. Possible values are clear, integrity, or confidentiality. The default is to try for confidentially, but accept whatever the server offers except clear, as clear is not part of the SOCKS GSSAPI standard.

gssapi.servicename

Which servicename to use when involving GSSAPI. Default is "rcmd".

method

List of authentication methods the client supports and which to offer the server. Currently supported values are none, gssapi, and username. The default is all supported methods.

protocol

The protocols the server supports. Supported values are tcp and udp. The default is all supported protocols.

proxyprotocol

The proxy protocols the server supports. Currently supported values are socks_v4, socks_v5, http, and upnp. The default is socks_v4 and socks_v5. Note that if the socks server requires any form of authentication, you need to explicitly set this to to socks_v5, as v4 does not support authentication.

## EXAMPLES
See the example directory in the distribution.

## ENVIRONMENT
SOCKS_USERNAME

Use the value of SOCKS_USERNAME as the username when doing username authentication.

SOCKS_PASSWORD

Use the value of SOCKS_PASSWORD as the password when doing username authentication. Not recommended as other users on the system might be able to see your password.

SOCKS_AUTOADD_LANROUTES

If this variable is set to "no", the client will not try to auto-add direct routes for all addresses on the LAN. The default is to add them.

SOCKS_DISABLE_THREADLOCK

If this variable is set, the client will not perform threadlocking. The default is for the client to attempt to figure out for itself whether the application to socksify needs threadlocking or not.

Some additional environment variables are documented in socksify(1).

## FILES
/etc/socks.conf

## AUTHORS
For inferno Nettverk A/S:

Michael Shuldman

Karl-Andre' Skevik

## SEE ALSO
socksify(1), sockd(8), sockd.conf(5)

Information about new releases and other related issues can be found on the Dante WWW home page: http://www.inet.no/dante/

## BUGS
See the accompanying BUGS file. New ones should be reported to dante-bugs@inet.no.


sockd.conf

package: dante-server

title: sockd.conf(5)

summary: Dante server configuration file syntax

text:
# sockd.conf(5)

## NAME
sockd.conf - Dante server configuration file syntax

## DESCRIPTION
The configuration file for the Dante server controls both access controls and logging. It is divided into three parts; server settings, rules, and routes.

Note that server settings must come before rules and routes.

A line can be commented out using the standard comment character #.

## SERVER SETTINGS
The server settings control the generic behaviour of the server. Each keyword is separated from its value by a ':' character.

The following keywords are available:

clientmethod

A list of acceptable authentication methods for client-rules, listed in order of preference. These are authentication methods that are to be checked immediately after the SOCKS client has connected to Dante, and before any socks-negotiation has started. Supported values are pam.address, pam.any, none, and rfc931 .

For all methods the authentication will be based on solely on the IP-address of the client, possibly in combination with a rfc931 ("ident") lookup towards the host the client is running on.

Any credentials provided during this pass will also be available for use in later socks-rules, when the socks-request from the client is evaluated.

The default value for this keyword is all methods that may be necessary for the later socks-based authentication methods, as specified as values to the global socksmethod keyword. Normally you should not need to set this keyword, as Dante will set it to the correct value by it self.

compatibility

With the sameport keyword, the server attempts to use the same port on the server's external side as the client used on the server's internal side. This is normally the default, but when this option is given it will be done with privileged ports also, meaning if a client connects to Dante from a privileged port, Dante will attempt to connect to the target destination from a privileged port too. There can be security issues involved with this, so normally this option should not be set. The draft-5.05 keyword will enable usage of parts of the socks v5-05 draft. The only feature from this draft that Dante supports is the "USECLIENTSPORT" extension. Note that there is a conflicting interpretation of this extension, so enabling it might prevent clients using the conflicting interpretation from working correctly. Only affects UDP.

cpu

The CPU settings for the various type of Dante processes. Note that the possibility for configuring these settings depend on the platform Dante is running on. Not all platforms may provide support for these type of CPU settings. There are four process types: mother, negotiate, request, and io.

The currently supported options are:

schedule.<process type>: <scheduling policy>/<priority>.

Example: cpu.schedule.mother: SCHED_FIFO/20 The above requests that the kernel schedules the mother process(s) using a first-in, first-out policy, at priority 20.

The default is to not request any specific scheduling.

mask.<process type>: <cpu id 1> [cpu id 1 ...]/any.

Example: cpu.mask.mother: any Example: cpu.mask.io: 0 1

The mask gives control over the CPU/cores on which the different process types will run. Specifying the default (all) allows the process type to run on any CPU id. Specifying one or more numeric CPU id limits the process to that set of CPUs.

The cpu keywords (schedule and mask) should in most cases not be necessary. If they are to be used, the io processes are where most of the work is done and adjusting the priority or CPU usage is what is likely to have the most significant performance effect client performance and overhead from the server. The other processes are primarily used during connection/session establishment and changes to settings for the non-io process types will primarily affect these operations.

The default is to not limit processes to any specific cpu.

debug

Print debug info to the logs. The value sets the debug level.

errorlog

This value can be set to receive only error-related logoutput. Note that this does not include client-specific errors, but only more serious "global" errors. The possible values are the same as for the logoutput keyword mentioned below.

The intent is to have a special place that only serious errors are logged so that they can discovered quickly. The default is to not have any special place to log errors.

external

The address to be used for outgoing connections. The address given may be either a IP address or an interface name. Can be given multiple times for different addresses.

external.log.<loglevel>.error

See internal.log.<loglevel>.error. This option has an identical syntax and semantics, but applies to error related to the external interface side.

external.protocol

By default Dante will use the address families specified and available, and there is no need to set this keyword. In some cases the operator may however wish to specify an address in a form that may include more than one address family, yet not wish for Dante to use all the address families available for that address form.

This will typically happen if the operator wishes to specify that Dante should use the addresses on a network interface card which has both IPv4 and IPv6 addresses configured, yet the operator wishes Dante to only use one of these two address families. The operator can then specify the address family he wants Dante too look for when expanding the interface name for IP-addresses to use.

Valid values for this keyword are: ipv4 and ipv6, indicating that Dante should only use the IPv4 address family or only the IPv6 address family, respectively. The default is to use both families, if available.

A corresponding keyword exists for the internal side (see internal.protocol).

external.rotation

If more than one external address is given, this governs which of the given addresses is selected as the source address for outgoing connections/packets. Note that regardless of which external rotation value is used, all external addresses that are to be used must be listed via the external keyword first. Valid values are none (the default), route, and same-same.

none indicates the first address on the list of external addresses should be used.

route indicates the kernels routing table should be consulted to find out what the source address for a given destination will be, and might require you to set user.privileged to root. Note that route might create problems for ftp-clients using active ftp if the Dante bind extension is enabled for the ftp-client.

same-same indicates the source address for a given destination should be the same address as the Dante server accepted the clients connection on.

internal

The internal addresses. Connections will only be accepted on these addresses. The address given may be either a IP address or an interface name.

internal.log.<loglevel>.error

Specifies that certain system call failures, listed as symbolic errno values, or certain dns failures, listed as symbolic libresolv failure-codes, should be logged, possibly an extra time, at the log-level log-level. Note that this only applies to errors on the internal interface side only.

A corresponding keyword exists for the external side (see external.log).

In addition to the standard errno and getaddrinfo(3) error symbols, the following special symbols are accepted:

no-route

Any error related to no route.

dns-any

Any error related to DNS/hostname-resolving.

system-any

Any system error. I.e., any errno value.

internal.protocol

See external.protocol. This option has an identical syntax and semantics, but applies to the internal interface, for addresses to listen to connections from clients on.

libwrap.hosts_access

If the server is compiled with libwrap support, determines whether the hosts_access() function should be used for access control. When enabled by setting this value to yes, the libwrap library determines if TCP connections or UDP packets should be immediately dropped or not, typically by consulting /etc/hosts.allow and /etc/hosts.deny. These checks are applied to all traffic, before the rule processing starts. The default value is no (disabled).

logoutput

This value controls where the server sends logoutput. It can be set to syslog[/facility], stdout, stderr, a filename, or a combination. The default is nowhere. Note that if errorlog is also set, there will be a overlap between what is logged there (errors only), and what will be logged here (errors, and everything else).

socksmethod

A list of acceptable authentication methods for socks-rules, listed in order of preference. It is thus important that you specify these in the desired order, normally with the more secure methods first. Supported values are bsdauth, gssapi, none, pam.any, pam.address, pam.username, rfc931, and username,

If a method is not set in this list it will never be selected. The default is no methods, which means all socks-requests will be blocked.

See the section on AUTHENTICATION METHODS for an explanation of the different methods and their meaning.

srchost

This keyword allows you to configure a few options that relate to the srchost, i.e., the host the Dante server accepts the connections from. With the nodnsmismatch keyword, the server will not accept connections from addresses having a mismatch between DNS IP address and hostname. Default is to accept them.

With the nodnsunknown keyword, the server will not accept connections from addresses without a DNS record. Default is to accept them.

With the checkreplyauth keyword, the server will check that the authentication on bind-replies and udp-replies matches that which is set in the rule and global socksmethod. Normally, authentication is not desired on replies, as they are replies sent to the socks-clients from non-socks clients, and thus only a limited set of authentication methods are possible.

The methods possible for TCP are the the methods not involving the socks protocol in any way, and are listed in the clientmethod section previously mentioned. For UDP-replies, no methods can be used.

Default is not to check the authentication on replies.

timeout.connect

The number of seconds the server will wait for a connect initiated on behalf of the socks-client to complete. The default is 30. Setting it to 0 will use the systems default.

timeout.io

The number of seconds an established connection can be idle. The default is 0, meaning forever. See also the "-n" option in the sockd(8) manpage. Individual timeouts can be set for TCP and UDP by suffixing io with ".<protocolname>", i.e. timeout.io.tcp or timeout.io.udp.

Individual timeouts can also be set within rules, using the same syntax. The timeout set in the rule will then override the default timeouts for clients matching the rule.

timeout.negotiate

The number of seconds a client can spend negotiating with the Dante server for a socks session before Dante will close the connection to the client. The default is 30. Set it to 0 for forever, though that is strongly discouraged.

timeout.tcp_fin_wait

The timeout for the equivalent of TCP's FIN-WAIT-2. The default is 0, which means use the systems default (normally, no timeout).

udp.connectdst

Enables or disables whether the server should attempt connecting UDP sockets to the destination. Valid values are yes and no. The default is yes, which improves UDP performance, but may not be compatible with some UDP-based application protocols as it means the server can only receive packets from the destination address.

The socket will only remain connected as long as the client only sends UDP packets to one destination address. If packets are sent to multiple destinations the socket will no longer remain connected and replies can be received from any destination.

Userids

On platforms providing a privilege-model supported by Dante, the Dante server does not use userid-switching via the seteuid(2) system call. On other platforms, it is prudent to set the userid to be used by the Dante server to appropriate values. The Dante server can use two different userids, or three if compiled with libwrap support. They are as follows:

user.privileged

Username which will be used for doing privileged operations. If you need special privileges to read the sockd.conf file or to write the sockd.pid file (you can create it manually before starting sockd), have anything in your configuration that requires binding privileged TCP/UDP ports (ports below 1024), or use some sort of password-based authentication, this probably needs to be set to root. If not, you can probably set it to the same value as user.unprivileged.

user.unprivileged

User which the server runs as most of the time. This should be an id with as little privileges as possible. It is recommended that a separate userid is created for this purpose.

user.libwrap

User used to execute libwrap commands. Normally this should be the same as user.unprivileged

## MODULES
The following modules are supported by Dante. Modules are purchased separately from Inferno Nettverk A/S and may add extra functionality that is not needed by most users. See the Dante homepage for more information.

bandwidth

The bandwidth module gives control over how much bandwidth the Dante server uses on behalf of different clients or to different targets.

redirect

The redirect module gives you control over what addresses the server will use on behalf of the clients, as well as allowing you to redirect client requests to a different addresses.

## SOCKET OPTIONS
The server has support for setting a large number of low-level socket options on both incoming and outgoing traffic. Most users will not need to set any of these options, but some might want to do it, to enable special network features, or to perform various experiments.

Options can be set globally as defaults for all traffic, or be set in the access control rules to only affect clients and targets matching the given rule.

The socket options that are available vary between platforms, so during configuration and building of the server the options that are available will be determined. Currently, the following options should be detected, when available, for the specified protocol levels:

SOCKET

so_bindany, so_broadcast, so_debug, so_dontroute, so_jumbo, so_keepalive, so_oobinline, so_priority, so_rcvbuf, so_rcvbufforce, so_rcvlowat, so_sndbuf, so_sndbufforce, so_sndlowat, so_useloopback

TCP

tcp_cork, tcp_cwnd, tcp_init_cwnd, tcp_keepcnt, tcp_keepidle, tcp_keepintvl, tcp_linger2, tcp_maxrt, tcp_maxseg, tcp_md5sig, tcp_nodelay, tcp_noopt, tcp_nopush, tcp_sack_enable, tcp_stdurg, tcp_syncnt, tcp_window_clamp

UDP

udp_cork

IP

ip_auth_level, ip_dontfrag, ip_esp_network_level, ip_esp_trans_level, ip_freebind, ip_ipcomp_level, ip_minttl, ip_mtu_discover, ip_portrange, ip_recvtos, ip_tos, ip_ttl

The syntax for setting socket options is as follows:

<direction>.<level>.<option>: <value>

The value field corresponds to the value that the socket option should be set to. For many socket options this is an integer value. The level and option values correspond to the socket names and protocol levels listed above. Both should be in lower-case.

The direction keywords is used to specify whether the socket option should be set for traffic on the internal or the external interface and can have the values internal and external. For example, to set the IP_TOS socket option on outgoing traffic, the following syntax can be used:

external.ip.ip_tos: 0x10

In this example, the argument value (0x10) is specified as a hex value. For some of the socket options the value can also be set symbolically. Currently this is possible for the following options, with the listed values:

ip_portrange

ip_portrange_default, ip_portrange_low, ip_portrange_high

The IP_TOS socket option also supports this, but handling this option is somewhat complicated by the same bits having different meanings in different RFCs. Handling this is done with a subfield that indicates the type of argument that should be used. The following subfields are defined and should be added to the name of the socket option as specified below:

ip_tos.dscp

af11 af12 af13 af21 af22 af23 af31 af32 af33 af41 af42 af43 cs0 cs1 cs2 cs3 cs4 cs5 cs6 cs7 ef

ip_tos.prec

netcontrol internetcontrol critic_ecp flashoverride flash immediate priority routine

ip_tos.tos

lowdelay throughput reliability

When numerical arguments are given to subfields, the values are shifted to apply only to the subfield bit range. The following example shows the different ways of setting IP_TOS to lowdelay on external traffic:

```
external.ip.ip_tos:     0x10       #base value, numerically
external.ip.ip_tos.tos: 0x08       #subfield, numerically
external.ip.ip_tos.tos: lowdelay   #subfield, symbolically
```

The first value sets the value directly, the second sets only the TOS bits, which are shifted relative to the base value. The final line sets the TOS value symbolically.

This functionality gives a large amount of control over socket options, but it should not be used without some understanding of how the kernel allows the socket option to be set, and the limitations that apply when the socket options are set as either defaults or in rules.

Setting a socket option in a client pass or socks-rules will cause any defaults to be overridden. Global options are set before bind() is called on internal sockets, or before connect() is called on external sockets. Options set in client rules are also applied before bind() is called on the internal socket, but cannot be set for the external socket. For socks-rules, both external and internal options can be set, but because the socks-request must be interpreted before the rules can be evaluated, socket options can only be set on internal sockets after the connection has been received.

Some socket options must be set before a connection has been established, while others can only be set after a connection has been established. Others can be set at any time.

Socket options that are not listed above can also be set by specifying the socket option name numerically, for example:

external.ip.10: 0x12

In this example the socket option corresponding to the value 10 will be set. These numbers are platform dependent but can typically be determined by looking at the appropriate system header files. Specifying options numerically might result in some warnings, but allows any socket option to be specified, as long as it takes a numerical argument. This is not the recommended approach for setting socket options, but represents a simple way of setting socket options that are not directly supported by the server, such as local kernel extensions.

## AUTHENTICATION METHODS
The Dante server supports the following authentication methods. Some installations of Dante may support only a subset of these, depending on platform support.

none

This method requires no form of authentication.

username

This method requires the client to provide a username and password. This information must match the username and password given in the system password file.

gssapi

This method requires the setup of a Kerberos environment and can provide strong encryption and authentication, depending on the gssapi settings you choose.

rfc931

This method requires the host the socks client runs on to provide a rfc931 ("ident") username for the client. This username match a username given in the system password file.

pam.address

IP-based (rhosts) PAM authentication.

pam.any

Will try to match against any type of PAM authentication, depending on the information that is currently available. Normally of limited use, and you should instead set the pam-based method(s) you actually want.

pam.username

Username/password-based PAM authentication. Similar to the method username, but the information is passed to the PAM subsystem for authentication, rather than Dante using the system password file directly. When using PAM, be wary of memory leakages and other bugs in the external PAM library Dante will have to use on your platform.

bsdauth

This method requires the available client data to be verified by the BSD Authentication system. Similar to the method username, but passed to the BSD authentication system instead.

## ADDRESSES
Each address field can consist of an IP address (and where required, a netmask, separated from the IP address by a '/' sign), a hostname, a domainname (designated so by the leading '.'), or an interface name.

An IP address can be given on on IPv4 form, IPv6 form, or as the special value 0/0, which matches all IP addresses, be they IPv4 or IPv6. The latter is intended for use in rules that should match both IPv4 and IPv6 clients or targets.

Each address, except the external address, can include an optional port specifier.

## RULES
There are two sets of rules and they work at different levels. Rules prefixed with client are checked first and are used to see if the client is allowed to connect to the Dante server. We call them "client-rules". These rules will start with client pass for a rule that allows the client, or client block for a rule that blocks the client.

It is recommended that the client-rules do not use hostnames but only IP-addresses, both for security and performance reasons. These rules operate at the TCP level.

The other rules, which we call "socks-rules", are prefixed with socks and operate at the socks protocol level.

These rules will start with socks pass for a rule that allows the client, or socks block for a rule that blocks the client.

These rules are only checked if the client connection has been allowed by the client-rules. The socks-rules are used to evaluate the socks request that the client sends.

While it is less important that these rules use only IP-addresses, provided the client-rules have been configured to only allow access from a pre-defined range of client IP-addresses, it is still recommended.

Both set of rules include a pass or deny keyword. The pass/deny keyword determines whether connections matching the rule are to be passed through or be blocked.

Both the client-rules and the socks-rules also specify a from/to address pair which gives the addresses the rule will match.

In both contexts, from refers to the clients address, i.e., the address the client is connecting to the Dante server from. The to address however refers to different things depending on whether it is used in a client-rule or in a socks-rule.

In the client-rule context, to means the address the request is accepted on, i.e., a address the Dante server listens on.

In the socks-rule context, to means the client's destination address, as expressed in the client's socks request. I.e., the address the Dante server should connect to (for TCP sessions) or send packets to (for UDP session) on behalf of the client.

Both set of rules are evaluated on a "first match is best match" basis. That means, the first rule matched for a particular client or socks request is the rule that will be used.

In addition to the addresses there is a set of optional keywords which can be given. There are two forms of keywords; conditions and actions. For each rule, all conditions are checked and if they match the request, all actions are executed.

The list of condition keywords is: clientcompatibility, clientmethod, command, from, group, socksmethod, protocol, proxyprotocol, to, user.

The list of action keywords is: bandwidth, libwrap, log, session, redirect, timeout.connect, timeout.negotiate, timeout.io, timeout.tcp_fin_wait, and udp.portrange.

The format and content of the the keyword as used in client-rules or socks-rules is identical, but client-rules can contain only a subset of the keyword that socks-rules may contain.

The contents of a client-rule can be:

bandwidth

The clients matching this rule will all share the given amount of bandwidth, measured in bytes per second. Requires the bandwidth module.

clientcompatibility

Enables certain options for compatibility with broken clients. Valid values are: necgssapi, for compatibility with clients implementing GSSAPI the NEC socks way.

from

The rule applies to requests coming from the specified address.

group

The user must belong to one of the groups given as value. Note that if gssapi-based authentication is used, the username as provided to the Dante server normally includes the Kerberos domain. The name must be listed on the same form here and in the system groupfile (usually /etc/passwd) if it is to be used.

gssapi.enctype

Which encryption to enforce for GSSAPI-authenticated communication. Possible values are clear, integrity, or confidentiality. The default is to accept whatever the client offers except clear, as clear is not part of the SOCKS GSSAPI standard.

gssapi.keytab

Value for keytab to use. The default is "FILE:/etc/sockd.keytab".

gssapi.servicename

Which servicename to use when involving GSSAPI. Default is "rcmd".

libwrap

The server will pass the specified parameter line to libwrap for execution.

log

Used to control logging. Accepted keywords are connect, disconnect, data, error, ioop, and tcpinfo. The default is no logging.

session

Control the max number of sessions or session establishment rate. See below for details.

clientmethod

Require that the connection be "authenticated" using one of the given clientmethods.

pam.servicename

Which servicename to use when involving pam. Default is "sockd".

port

Parameter to from, to and via. Accepts the keywords eq/=, neq/!=, ge/>=, le/<=, gt/>, lt/< followed by a number. A port range can also be given as "port <start #> - <end #>", which will match all port numbers within the range <start #> and <end #>. The default is to match all ports.

redirect

The source and/or destination can be redirected using the redirect statement. Requires the redirect module. The syntax of the redirect statement is as follows:

redirect from: ADDRESS

See the redirect manual for detailed information.

socksmethod

If the client offers more than one authentication method, Dante will select the method to use based on the order the methods are listed here. Valid values are the same as in the global socksmethod line. Normally there will be no need to set this keyword in a client-rule, but if it is set and the client offers none of the methods listed, the client will be blocked at this stage.

timeout.negotiate

See the global timeout.negotiate option.

to

The rule applies to requests going to the address given as value.

user

The user must match one of the names given as value. If no user value is given for a rule requiring usernames, the effect will be the same as listing every user in the password file. Note that if gssapi-based authentication is used, the username as provided to the Dante server normally includes the Kerberos domain. The name must be listed on the same form here if it is to be used.

The contents of a socks-rule can be:

bandwidth

The clients matching this rule will all share the given amount of bandwidth, measured in bytes per second. Requires the bandwidth module.

bsdauth.stylename

The name of the BSD authentication style to use. The default is to not specify a value, causing the default system style to be used.

command

The rule applies to the given commands. Valid commands are bind, bindreply, connect, udpassociate and udpreply. Can be used instead of, or to complement, protocol. The default is all commands valid for the protocols allowed by the rule.

from

The rule applies to requests coming from the address given as value.

group

The user must belong to one of the groups given as value.

libwrap

The server will pass the line to libwrap for execution.

log

Used to control logging. Accepted keywords are connect, disconnect, data, ioop, and tcpinfo.

session

Control the max number of sessions or session establishment rate. See

socksmethod

Require that the connection be established using one of the given authentication methods. A method normally refers to the socks client part of the rule, and thus authenticates the client, and not the target destination (see checkreplyauth for information about authentication the target destination). Valid values are the same as in the global socksmethod line.

pam.servicename

What servicename to use when involving pam. Default is "sockd".

port

Parameter to from, to and via. Accepts the keywords eq/=, neq/!=, ge/>=, le/<=, gt/>, lt/< followed by a number. A portrange can also be given as "port <start #> - <end #>", which will match all port numbers within the range <start #> and <end #>. The default is all ports.

protocol

The rule applies to the given protocols. Valid values are tcp and udp. The default is all supported protocols that can apply to the given commands.

proxyprotocol

The rule applies to requests using the given proxy protocol. Valid proxy protocols are socks_v4 and socks_v5. The default is all supported proxy protocols.

redirect

The source and/or destination can be redirected using the redirect statement. Requires the redirect module. The syntax of the redirect statement is as follows:

redirect from: ADDRESS

redirect to: ADDRESS

The semantics of from and to vary according to command. See the redirect manual for detailed information.

timeout.connect

See the global timeout.connect option.

timeout.io

See the global timeout.io option.

timeout.tcp_fin_wait

See the global timeout.tcp_fin_wait option.

to

The rule applies to requests going to or using the address given as value. Note that the meaning of this address is affected by command.

udp.portrange

The argument to this keyword is two port numbers, separated by a dash ('-'). They specify the UDP port-range that will be used between the socks-client and the Dante-server for UDP packets. Note that this has no relation to the UDP port-range used between the Dante-server and external, non-socks, clients/servers.

user

The user must match one of the names given as value. If no user value is given for a rule requiring usernames, the effect will be the same as listing every user in the password file.

## SESSION
The session keyword can be used any any rule to limit the number of active sessions and the rate at which they are established. There are two main commands for this; session.max, that controls the max number of sessions that can be matched, and session.throttle, that controls the connection rate. These commands can be applied both for the total limit for all matching clients and can be set as global defaults or in any of the rule types. The session.max keyword takes a number corresponding to the highest number of allowed simultaneous connections as an argument. The session.throttle keyword takes two number separated by a slash character, with the first representing the number of connections and the latter a time duration in seconds. If more than the specified number of connections are received in the specified number of seconds, additional connections will be dropped.

Stateful session tracking on a per IP-address basis is also supported. For stateful tracking, the limits apply to each connection with a matching IP-address, with the session.state.key keyword is used to control how the IP-address is determined. Currently two values are supported, from and hostid. The former causes the limit to be applied to all hosts with the same source IP-address and the latter to all TCP connections with the same hostid value. If a hostid value is used, the session.state.key.hostindex keyword can be used to choose which of the to hostid values are used, with the first value being the default.

Limits are evaluated first for client rules, then for hostid rules, and finally for socks rules. By default, a limit set in a matching client rule will be used also any subsequent matching hostid or socks rules, unless either of these rules also have session limit keywords. This session inheritance can be disabled in client and hostid rules, causing them to only apply in the rule in which they appear. This is done by setting the session.inheritable to no.

The session keywords must be set in a rule (either client, hostid, or socks), setting them globally is not supported.

## TRAFFIC MONITORING
The Dante server can be configured to monitor the traffic passing through it, and trigger alarms based on the observed network traffic.

The alarms are specified in so-called monitors. These objects have the same general format as the rules Dante uses for access control and enable perform passive monitoring of network traffic, or the lack of network traffic.

The following example shows the general monitor syntax, specifying a monitor without any monitoring operations:

monitor {

from: 0.0.0.0/0 to: www.example.org port = 80

protocol: tcp

}

A monitor can include many of the same keywords that are available in the Dante ACL rules. The following subset is currently supported:

from

Normally specifies what SOCKS client addresses/networks to monitor.

to

Normally specifies what target addresses/networks to monitor.

protocol

Can be used to restrict monitoring to a certain protocol (TCP, UDP or both). Note: only TCP should be used for now.

hostid

Can be used to restrict monitoring to only clients with a specific hostid value set.

hostindex

Used along with the hostid keyword to control which of the two possible hostid values will be used when matching.

NOTE: It is currently recommended that the protocol keyword is always specified and set to tcp because there is currently only limited support for monitoring of UDP traffic, and testing of UDP traffic monitoring has not been done.

The main function of monitors is to provide a container for one or more alarms, which are specified using a new set of keywords not available for other rules. Alarms specify a condition that will cause Dante to log a warning if the condition is triggered.

Active TCP sessions will at most match one monitor, but multiple alarms can be specified in a single monitor. This makes it possible to specify multiple sets of conditions for the same TCP sessions, depending on what network interface the traffic is transferred on and whether the traffic is being received or transmitted.

Alarms can trigger as a result of periods of no or little data being transmitted, or a large numbers of TCP connections disconnecting during a short period of time, or for other reasons. See below for a complete list of what conditions alarms can be enabled for.

### Data alarms
Adding an alarm.data keyword to a monitor will result in warnings being logged if there are periods with too little network traffic.

Dante has four network paths and data alarms can be configured independently for each of them:

internal.alarm.data.recv

Data received on Dante's internal interface (data sent from the SOCKS clients to Dante).

internal.alarm.data.send

Data sent out on Dante's internal interface (data sent from Dante to the SOCKS clients).

external.alarm.data.recv

Data received on Dante's external interface (data sent from the target servers to Dante).

external.alarm.data.send

Data sent out on Dante's external interface (data sent from Dante to the target servers).

The data.alarm keyword takes two parameters: a byte count and a duration in seconds. The alarm will trigger if the specified number of seconds pass with only the specified number of bytes (or less) being transmitted.

The syntax is as follows:

internal.alarm.data.recv: DATALIMIT in INTERVAL

The DATALIMIT is a number that specifies the byte limit. The INTERVAL is a number that specifies the duration. If only DATALIMIT bytes (or less) have been transferred during a period of INTERVAL seconds, an alarm will trigger in Dante.

Data alarms trigger when a period of data idleness has been detected. Once a data alarm has triggered it will remain active until it is cleared. A warning will be logged when the alarm triggers and than again when the alarm condition is cleared. In between these two points no warnings related to this alarm will be logged. This avoids repeating the same alarm/warning multiple times during network problems that last for an extended amount of time. When the alarm is cleared, Dante will also include information about how long the alarm condition lasted.

A data alarm can be cleared in two ways; automatically, once enough data has been transferred in a short enough amount of time, or manually, by sending the Dante server a SIGHUP signal. A SIGHUP will cause all active alarms to be cleared. No log messages indicating that the alarms have cleared will be logged when alarms are cleared in this way.

Once an alarm has been cleared, it can trigger again if enough data is not being transferred.

Note that data alarms will trigger regardless of whether there are active sessions matching the monitor or not; if enough data is not being transmitted or received, a data alarm will trigger. Alarms will trigger also shortly after server startup, if the Dante server does not receive sufficient traffic to prevent the alarms from triggering.

Note that the message indicating that an alarm has cleared is not logged if the alarm was cleared due to a SIGHUP signal being received.

### Disconnect alarms
The disconnect alarms are related to connection disconnects and by using the alarm.disconnect keyword the Dante server can log warnings based on the number and rate of terminated connections.

There are two variants of the alarm keyword, one for the internal network interface, between the SOCKS clients and Dante, and one for the external interface, between the Dante server and the target servers:

internal.alarm.disconnect

Connections between SOCKS clients and the Dante server.

external.alarm.disconnect

Connections between the Dante server and target servers.

Each alarm keyword takes three parameters, a minimum count, a ratio value, and a time interval. The following format is used:

internal.alarm.disconnect: MINCOUNT/RATIO in INTERVAL

The MINCOUNT is the minimum number of connections that must be disconnected for the alarm to trigger. The RATIO is used together with the MINCOUNT to express the number of connections, relative to the total number of connections that have existed in the time period, that must be disconnected for the alarm to trigger. The INTERVAL is the time in seconds within which the disconnects must occur for the alarm to trigger.

To set values that are useful, some knowledge about the expected amount of network traffic and number of sessions is required. If the rate of disconnects, as a percentage, is lower than the ratio specified, an alarm will not trigger. Conversely, if the MINCOUNT is set too low, alarms might trigger too frequently because only a small number of disconnects might be sufficient to achieve the required number of disconnects and disconnect ratio at times when there are only a few active sessions.

Only connections that are terminated on the specified interface are counted, i.e., an external.alarm.disconnect alarm will only trigger for connections that are terminated on the network interface between the Dante server and the target server, either by the target server closing the connection to Dante or by Dante receiving a fatal network error from that side of the connection (e.g., a TCP RST packet).

Connections that are closed on the internal interface (by the SOCKS clients) will not count towards a disconnect alarm on the external side. Likewise, connections closed by target servers will not count towards a disconnect alarm on the internal side.

A practical consequence of this is that if a large number of connections are simultaneously closed by both the client and the target server, each connection will only be counted as a disconnect on one of the sides; either the external side or the internal side, depending on which side closes the connection first.

Alarms trigger each time a sufficient number disconnects occur. Each sufficiently large burst of disconnects will result in an alarm, but normally at most one warning per alarm will be logged during each time interval, though this might change in a later version of Dante.

Separate alarms are produced for each distinct alarm keyword when multiple alarms are specified in a monitor rule.

## ROUTES
The routes are specified with a route keyword. Inside a pair of curly braces ({}) a set of keywords control the behavior of the route. See socks.conf(5) for a description. This is used to perform so-called "server-chaining", where one socks-server connects to another socks-server further upstream.

The syntax for these routes is the same as the routes used by the client. Please see socks.conf(5) for information about the route syntax.

There are however some special things one need to be aware of regarding serverchaining and routes specified for the server:

At present serverchaining is only supported for the tcp connect command.

If the route specifies that a username/password-method should be offered to the upstream proxy, Dante will forward the username/password received from it's own client to the foreign upstream proxy, meaning the upstream proxy will receive the user's username and password in cleartext from Dante.

At present serverchaining does not scale well in Dante and should not be used for anything but minimal client loads.

## EXAMPLES
See the example/ directory in the distribution.

## FILES

```
/etc/sockd.conf   Dante server configuration file.
/etc/passwd       systemfile used when doing standard username/password

                  authentication.
```

## AUTHORS
For inferno Nettverk A/S:

Michael Shuldman

Karl-Andre' Skevik

## SEE ALSO
sockd(8), socks.conf(5), hosts_access(5)

Information about new releases and other related issues can be found on the Dante WWW home page: http://www.inet.no/dante/

Information about commercial support can be found on the Dante WWW support page: http://www.inet.no/dante/support.html