radvd.conf

package: radvd

title: radvd.conf(5)

text:
# radvd.conf(5)

## NAME
radvd.conf - configuration file of the router advertisement daemon radvd

## DESCRIPTION
This file describes the information which is included in the router advertisement (RA) of a specific interface.

The file contains one or more interface definitions of the form:

```
interface name {
	list of interface specific options
	list of prefix definitions
	list of clients (IPv6 addresses) to advertise to
	list of route definitions
	list of RDNSS definitions
	list of DNSSL definitions
	list of ABRO definitions
	list of NAT64 pref64 definitions
	list of auto-ignore prefixes
	list of acceptable RA source addresses
};
```

All the possible interface specific options are detailed below. Each option has to be terminated by a semicolon. Options are not case sensitive.

Prefix definitions are of the form:

```
prefix prefix/length {
	list of prefix specific options
};
```

Prefix can be network prefix or the address of the interface. The address of interface should be used when using Mobile IPv6 extensions.

Special prefix "::/64" is also supported on systems that implement getifaddrs() (on other systems, configuration activation fails and radvd exits). When configured, radvd picks all non-link-local prefix assigned to the interface and starts advertising it (unless ignored with autoignoreprefixes). This may be applicable in non-6to4 scenarios where the upstream prefix might change. This option is incompatible with Base6to4Interface option. AdvRouterAddr option is always enabled when this configuration is used.

All the possible prefix specific options are described below. Each option has to be terminated by a semicolon.

Decimal values are allowed only for MinDelayBetweenRAs, MaxRtrAdvInterval and MinRtrAdvInterval. Decimal values should be used only when using Mobile IPv6 extensions.

Route definitions are of the form:

```
route prefix/length {
	list of route specific options
};
```

The prefix of a route definition should be network prefix; it can be used to advertise more specific routes to the hosts.

RDNSS (Recursive DNS server) definitions are of the form:

```
RDNSS ip [ip] [ip] {
	list of rdnss specific options
};
```

Each RDNSS definition block has a maximum length of 2040 bytes including the header, this accomodates up to 127 addresses.

If the length is exceeded, radvd will log a non-fatal error instead of sending the option.

DNSSL (DNS Search List) definitions are of the form:

```
DNSSL suffix [suffix] [suffix] [...] {
	list of dnssl specific options
};
```

Each DNSSL definition block has a maximum length of 2040 bytes including the header, applied after the suffixes are encoded per RFC1035, section 3.1.

If the length is exceeded, radvd will log a non-fatal error instead of sending the option.

By default radvd will send multicast route advertisements so that every node on the link can use them. The list of clients (IPv6 address) to advertise to, and accept route solicitations from can be configured. If done, radvd does not send messages to the multicast addresses but to the configured unicast addresses only. Solicitations from other addresses are refused unless UnrestrictedUnicast is enabled. This is similar to UnicastOnly but includes periodic messages and incoming client access configuration. See examples section for a use case of this.

The definitions are of the form:

```
clients {

        list of IPv6 addresses
};
```

Clients can be prefixed with "!" to ignore them completely and never send advertisements to them.

By default radvd will use the first link-local address for the interface as the source address for route advertisements. This can be overwritten by manually setting the list of acceptable source addresses. If done, radvd will use the first address from the interface that is present in the configured source addresses only. This functionality will NOT spoof the source address, but may be useful in combination with VRRP or other functionality that do a virtual/failover MAC.

```
AdvRASrcAddress {

        list of IPv6 addresses
};
```

ABRO (Authoritative Border Router Option) definitions are of the form:

```
abro IPv6-address {

        list of abro specific options
};
```

NAT64 pref64 (the NAT64 prefix included in the router advertisements):

```
nat64prefix prefix/length {
	list of NAT64 prefix specific options
};
```

The value of length can only be one of /32, /40, /48, /56, /64, or /96.

When using the special prefix "::/64" this option forms an ignore list for prefixes that should not be automatically generated and advertised. Has no effect on any other prefix definition.

The definitions are of the form:

```
autoignoreprefixes {

        list of IPv6 prefixes
};
```

## INTERFACE SPECIFIC OPTIONS
IgnoreIfMissing on|off

A flag indicating whether or not the interface is ignored if it does not exist at start-up.

This is useful for dynamic interfaces which are not active when radvd starts or which are dynamically disabled and re-enabled during the time radvd runs.

Current versions of radvd automatically try to re-enable interfaces.

Enabling IgnoreIfMissing also quenches certain warnings in log messages relating to missing interfaces.

Default: on

AdvSendAdvert on|off

A flag indicating whether or not the router sends periodic router advertisements and responds to router solicitations.

This option no longer has to be specified first, but it needs to be on to enable advertisement on this interface.

Default: off

UnicastOnly on|off

Indicates that the interface link type only supports unicast. This will prevent unsolicited advertisements from being sent, and will cause solicited advertisements to be unicast to the soliciting node. This option is necessary for non-broadcast, multiple-access links, such as ISATAP.

Default: off

UnrestrictedUnicast on|off

A flag indicating whether or not to respond to router solicitations when there is a list of clients configured.

This allows regular unsolicited advertisements to be sent to some clients without ignoring router solicitations from unknown clients.

Default: off

AdvRASolicitedUnicast on|off

Indicates that router solicitations will be responded to with unicast router advertisements, as recommended by RFC7772. Large networks with a high concentration of mobile devices might experience like battery depletion, when solicited Router Advertisement messages are multicast.

This corresponds to the Cisco IOS option ipv6 nd ra solicited unicast

Default: on

MaxRtrAdvInterval seconds

The maximum time allowed between sending unsolicited multicast router advertisements from the interface, in seconds.

Must be no less than 4 seconds and no greater than 65535 seconds.

Minimum when using Mobile IPv6 extensions: 0.07.

For values less than 0.2 seconds, 0.02 seconds is added to account for scheduling granularities as specified in RFC3775.

Default: 600 seconds

MinRtrAdvInterval seconds

The minimum time allowed between sending unsolicited multicast router advertisements from the interface, in seconds.

Must be no less than 3 seconds and no greater than 0.75 * MaxRtrAdvInterval.

Minimum when using Mobile IPv6 extensions: 0.03.

Default: 0.33 * MaxRtrAdvInterval

MinDelayBetweenRAs seconds

The minimum time allowed between sending multicast router advertisements from the interface, in seconds.

This applies to solicited multicast RAs. This is defined as the protocol constant MIN_DELAY_BETWEEN_RAS in RFC4861. MIPv6 redefines this parameter to have a minimum of 0.03 seconds.

Minimum when using Mobile IPv6 extensions: 0.03.

Default: 3

AdvManagedFlag on|off

When set, hosts use the administered (stateful) protocol for address autoconfiguration in addition to any addresses autoconfigured using stateless address autoconfiguration. The use of this flag is described in RFC 4862.

Default: off

AdvOtherConfigFlag on|off

When set, hosts use the administered (stateful) protocol for autoconfiguration of other (non-address) information. The use of this flag is described in RFC 4862.

Default: off

AdvLinkMTU integer

The MTU option is used in router advertisement messages to ensure that all nodes on a link use the same MTU value in those cases where the link MTU is not well known.

If specified, i.e. not 0, must not be smaller than 1280 and not greater than the maximum MTU allowed for this link (e.g. ethernet has a maximum MTU of 1500. See RFC 4864).

Default: 0

AdvReachableTime milliseconds

The time, in milliseconds, that a node assumes a neighbor is reachable after having received a reachability confirmation. Used by the Neighbor Unreachability Detection algorithm (see Section 7.3 of RFC 4861). A value of zero means unspecified (by this router).

Must be no greater than 3,600,000 milliseconds (1 hour).

Default: 0

AdvRetransTimer milliseconds

The time, in milliseconds, between retransmitted Neighbor Solicitation messages. Used by address resolution and the Neighbor Unreachability Detection algorithm (see Sections 7.2 and 7.3 of RFC 4861). A value of zero means unspecified (by this router).

Default: 0

AdvCurHopLimit integer

The default value that should be placed in the Hop Count field of the IP header for outgoing (unicast) IP packets. The value should be set to the current diameter of the Internet. The value zero means unspecified (by this router).

Default: 64

AdvDefaultLifetime seconds

The lifetime associated with the default router in units of seconds. The maximum value corresponds to 18.2 hours. A lifetime of 0 indicates that the router is not a default router and should not appear on the default router list. The router lifetime applies only to the router's usefulness as a default router; it does not apply to information contained in other message fields or options. Options that need time limits for their information include their own lifetime fields.

Must be either zero or between MaxRtrAdvInterval and 65535 seconds.

Default: 3 * MaxRtrAdvInterval (Minimum 1 second).

AdvDefaultPreference low|medium|high

The preference associated with the default router, as either "low", "medium", or "high".

Default: medium

AdvSourceLLAddress on|off

When set, the link-layer address of the outgoing interface is included in the RA.

Default: on

RemoveAdvOnExit on|off

Upon shutdown, send a final advertisement with zero Router Lifetime. This should cause the router and routes to be immediately removed from the receiving end-nodes' route table. This may need to be disabled ("off") in an vrrp or carp setup.

Default: on

AdvHomeAgentFlag on|off

When set, indicates that sending router is able to serve as Mobile IPv6 Home Agent. When set, minimum limits specified by Mobile IPv6 are used for MinRtrAdvInterval and MaxRtrAdvInterval.

Default: off

AdvHomeAgentInfo on|off

When set, Home Agent Information Option (specified by Mobile IPv6) is included in Router Advertisements. AdvHomeAgentFlag must also be set when using this option.

Default: off

HomeAgentLifetime seconds

The length of time in seconds (relative to the time the packet is sent) that the router is offering Mobile IPv6 Home Agent services. A value 0 must not be used. The maximum lifetime is 65520 seconds (18.2 hours). This option is ignored, if AdvHomeAgentInfo is not set.

If both HomeAgentLifetime and HomeAgentPreference are set to their default values, Home Agent Information Option will not be sent.

Default: AdvDefaultLifetime

HomeAgentPreference integer

The preference for the Home Agent sending this Router Advertisement. Values greater than 0 indicate more preferable Home Agent, values less than 0 indicate less preferable Home Agent. This option is ignored, if AdvHomeAgentInfo is not set.

If both HomeAgentLifetime and HomeAgentPreference are set to their default values, Home Agent Information Option will not be sent.

Default: 0

AdvMobRtrSupportFlag on|off

When set, the Home Agent signals it supports Mobile Router registrations (specified by NEMO Basic). AdvHomeAgentInfo must also be set when using this option.

Default: off

AdvIntervalOpt on|off

When set, Advertisement Interval Option (specified by Mobile IPv6) is included in Router Advertisements. When set, minimum limits specified by Mobile IPv6 are used for MinRtrAdvInterval and MaxRtrAdvInterval.

The advertisement interval is based on the configured MaxRtrAdvInterval parameter except where this is less than 200ms. In this case, the advertised interval is ( MaxRtrAdvInterval + 20ms ).

Default: off

AdvCaptivePortalAPI "URL"

When set, advertise RFC8908 Captive-Portal API URL.

See RFC8952 Captive Portal Architecture, RFC8910 Captive-Portal Identification in DHCP and Router Advertisements (RAs) and RFC8908 Captive Portal API for more information.

Most likely you do not need this.

Default: not included

## PREFIX SPECIFIC OPTIONS
AdvOnLink on|off

When set, indicates that this prefix can be used for on-link determination. When not set the advertisement makes no statement about on-link or off-link properties of the prefix. For instance, the prefix might be used for address configuration with some of the addresses belonging to the prefix being on-link and others being off-link.

Default: on

AdvAutonomous on|off

When set, indicates that this prefix can be used for autonomous address configuration as specified in RFC 4862.

Default: on

AdvRouterAddr on|off

When set, indicates that the address of interface is sent instead of network prefix, as is required by Mobile IPv6. When set, minimum limits specified by Mobile IPv6 are used for MinRtrAdvInterval and MaxRtrAdvInterval.

Default: off

AdvDHCPv6PDPreferred on|off

When set, indicates that the network prefers that clients use prefix delegation instead of acquiring individual addresses via SLAAC or DHCPv6 aaddress assignment.

See RFC 9762, "Using Router Advertisements to Signal the Availability of DHCPv6 Prefix Delegation to Clients"

Default: off

AdvValidLifetime seconds|infinity

The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for the purpose of on-link determination. The symbolic value infinity represents infinity (i.e. a value of all one bits (0xffffffff)). The valid lifetime is also used by RFC 4862.

Note that clients will ignore AdvValidLifetime of an existing prefix if the lifetime is below two hours, as required in RFC 4862 Section 5.5.3 point e).

Note: RFC4861's suggested default value is significantly longer: 30 days.

Default: 86400 seconds (1 day)

AdvPreferredLifetime seconds|infinity

The length of time in seconds (relative to the time the packet is sent) that addresses generated from the prefix via stateless address autoconfiguration remain preferred. The symbolic value infinity represents infinity (i.e. a value of all one bits (0xffffffff)). See RFC 4862.

Note: RFC4861's suggested default value is significantly longer: 7 days.

Default: 14400 seconds (4 hours)

DeprecatePrefix on|off

Upon shutdown, this option will cause radvd to deprecate the prefix by announcing it in the radvd shutdown RA with a zero preferred lifetime and a valid lifetime slightly greater than 2 hours. This will encourage end-nodes using this prefix to deprecate any associated addresses immediately. Note that this option should only be used when only one router is announcing the prefix onto the link, otherwise end-nodes will deprecate associated addresses despite the prefix still being valid for preferred use.

See RFC4862, section 5.5.3., "Router Advertisement Processing", part (e).

Default: off

DecrementLifetimes on|off

This option causes radvd to decrement the values of the preferred and valid lifetimes for the prefix over time. The lifetimes are decremented by the number of seconds since the last RA. If radvd receives a SIGUSR1 signal, it will reset the values of the preferred and valid lifetimes back to the initial values used by radvd when it started. If radvd never receives a SIGUSR1 signal, it will continue to decrement the lifetimes until the preferred lifetime reaches zero. After a final RA with a zero value preferred lifetime, radvd will cease to announce the prefix. If a SIGUSR1 signal then causes the lifetimes to be reset, the prefix will then re-appear in the RAs.

This option is intended to be used in conjunction with a DHCPv6 client that is using the Identity Association for Prefix Delegation (IA_PD) option to acquire a prefix from a Delegating Router for use by a Requesting Router. In this scenario, the prefix(es) from within the delegated prefix that are announced by radvd would age in parallel with and at the same rate as the delegated prefix, and expire at approximately the same time, if the delegated prefix's life isn't extended.

See RFC3633, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6".

Default: off

Base6Interface name

If this options is specified, this prefix will be combined with the IPv6 address of the interface specified by name. The resulting prefix length will be 64.

Base6to4Interface name

If this option is specified, this prefix will be combined with the IPv4 address of interface name to produce a valid 6to4 prefix. The first 16 bits of this prefix will be replaced by 2002 and the next 32 bits of this prefix will be replaced by the IPv4 address assigned to interface name at configuration time. The remaining 80 bits of the prefix (including the SLA ID) will be advertised as specified in the configuration file. See the next section for an example.

If interface name is not available at configuration time, a warning will be written to the log and this prefix will be disabled until radvd is reconfigured.

This option enables systems with dynamic IPv4 addresses to update their advertised 6to4 prefixes simply by restarting radvd or sending a SIGHUP signal to cause radvd to reconfigure itself.

Note that 6to4 prefixes derived from dynamically-assigned IPv4 addresses should be advertised with a significantly shorter lifetime (see the AdvValidLifetime and AdvPreferredLifetime options).

For more information on 6to4, see RFC 3056.

Default: 6to4 is not used

## ROUTE SPECIFIC OPTIONS
AdvRouteLifetime seconds|infinity

The lifetime associated with the route in units of seconds. The symbolic value infinity represents infinity (i.e. a value of all one bits (0xffffffff)).

Default: 3 * MaxRtrAdvInterval

AdvRoutePreference low|medium|high

The preference associated with the default router, as either "low", "medium", or "high".

Default: medium

RemoveRoute on|off

Upon shutdown, announce this route with a zero second lifetime. This should cause the route to be immediately removed from the receiving end-nodes' route table.

Default: on

## RDNSS SPECIFIC OPTIONS
AdvRDNSSLifetime seconds|infinity

The maximum duration how long the RDNSS entries are used for name resolution. A value of 0 means the nameserver must no longer be used. As described in RFC8106, the use of default value or a larger value ensures the reliability of an entry even under the loss of RAs on links with a relatively high rate of packet loss. Default: 3*MaxRtrAdvInterval

FlushRDNSS on|off

Upon shutdown, announce the RDNSS entries with a zero second lifetime. This should cause the RDNSS addresses to be immediately removed from the end-nodes' list of Recursive DNS Servers.

Default: on

## DNSSL SPECIFIC OPTIONS
AdvDNSSLLifetime seconds|infinity;

The maximum duration how long the DNSSL entries are used for name resolution. A value of 0 means the suffix should no longer be used. As described in RFC8106, the use of default value or a larger value ensures the reliability of an entry even under the loss of RAs on links with a relatively high rate of packet loss. Default: 3*MaxRtrAdvInterval

FlushDNSSL on|off

Upon shutdown, announce the DNSSL entries with a zero second lifetime. This should cause the DNSSL entries to be immediately removed from the end-nodes' DNS search list.

Default: on

## ABRO SPECIFIC OPTIONS
AdvValidLifetime seconds

The time in units of that the set of border router information is valid. A value of all zero bits assumes a default value of 10,000(~one week).

AdvVersionLow, AdvVersionHigh unsignedinteger

Both forms 32-bit unsigned version number corresponding to the set of information contained in RA message.

## NAT64 PREF64 SPECIFIC OPTIONS
AdvValidLifetime seconds

The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for the purpose of NAT64 existence determination. In case the value is not a multiple of 8, the validity is rounded up to the next multiple of 8. The maximum is 65528 seconds.

Default: the lesser value of 3 * MaxRtrAdvInterval, or 65528

## EXAMPLES

```
interface eth0
{

        AdvSendAdvert on;

        prefix 2001:db8:0:1::/64

        {

                AdvOnLink on;

                AdvAutonomous on;

        };
};
```

It says that router advertisement daemon should advertise (AdvSendAdvert on;) the prefix 2001:db8:0:1:: which has a length of 64 on the interface eth0. Also the prefix should be marked as autonomous (AdvAutonomous on;) and as on-link (AdvOnLink on;). All the other options are left on their default values.

To support movement detection of Mobile IPv6 Mobile Nodes, the address of interface should be used instead of network prefix:

```
interface eth0
{

        AdvSendAdvert on;

        prefix 2001:db8:0:1::4/64

        {

                AdvOnLink on;

                AdvAutonomous on;

                AdvRouterAddr on;

        };
};
```

For 6to4 support, include the Base6to4Interface option in each prefix section. When using a dynamic IPv4 address, set small prefix lifetimes to prevent hosts from retaining unreachable prefixes after a new IPv4 address has been assigned. When advertising to on a dynamic interface (e.g., Bluetooth), skip the interface if it is not active yet.

```
interface bnep0
{

        IgnoreIfMissing on;

        AdvSendAdvert on;

        # Advertise at least every 30 seconds

        MaxRtrAdvInterval 30;

        prefix 0:0:0:5678::/64

        {

                AdvOnLink on;

                AdvAutonomous on;

                Base6to4Interface ppp0;

                # Very short lifetimes for dynamic addresses

                AdvValidLifetime 300;

                AdvPreferredLifetime 120;

        };
};
```

Since 6to4 is enabled, the prefix will be advertised as 2002:WWXX:YYZZ:5678::/64, where WW.XX.YY.ZZ is the IPv4 address of ppp0 at configuration time. (IPv6 addresses are written in hexadecimal whereas IPv4 addresses are written in decimal, so the IPv4 address WW.XX.YY.ZZ in the 6to4 prefix will be represented in hex.)

In this specific case, the configuration scripts may send HUP signal to radvd when taking bnep0 up or down to notify about the status; in the current radvd releases, sending HUP is no longer mandatory when the link comes back up.

```
interface eth0
{

        AdvSendAdvert on;

        prefix 2001:db8:0:1::/64

        {

                AdvOnLink on;

                AdvAutonomous on;

        };

        clients

        {

                fe80::21f:16ff:fe06:3aab;

                fe80::21d:72ff:fe96:aaff;

        };
};
```

This configuration would only announce the prefix to fe80::21f:16ff:fe06:3aab and fe80::21d:72ff:fe96:aaff. Furthermore, all RA requests of other clients are denied.

This may come in handy if you want to roll out IPv6 only partially because some clients are broken or untested.

For ABRO support

```
interface lowpan0
{
	AdvSendAdvert on;
	UnicastOnly on;
	AdvCurHopLimit 255;
	prefix 2001:0db8:0100:f101::/64 {
		AdvOnLink on;
		AdvAutonomous on;
		AdvRouterAddr on;
	};
	abro fe80::a200:0:0:1/64 {
		AdvVersionLow 10;
		AdvVersionHigh 2;
		AdvValidLifetime 2;
	};
};
The NAT64 pref64 support

interface eth0
{
	prefix 2001:db8:100::/64 {
		AdvOnLink on;
		AdvAutonomous on;
		AdvRouterAddr on;
	};
	nat64prefix 64:ff9b::/96 {
		AdvValidLifetime 1800;
	};
	RDNSS 2001:db8:100::64 {
		AdvRDNSSLifetime 1800;
	};
};
```

## FILES

```
/usr/sbin/radvd
/etc/radvd.conf
/run/radvd/radvd.pid
/var/log/radvd.log
```

## CREDIT
The description of the different flags and variables is in large parts taken from RFC 4861.

## RFCS
Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 2007.

Thomson, S., Narten, T., T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.

Deering, S., and R. Hinden, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.

Conta, A., Deering, S., and M. Gupta "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 4443, March 2006.

Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.

Carpenter B., K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. (6to4 specification)

Draves, R., D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.

Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.

Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.

Z. Shelby, S. Chakrabarti, E. Nordmark and C. Bormann " Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, November 2012.

Gont, F. "Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery", RFC 6980, August 2013.

Yourtchenko, A. and Colitti, L. "Reducing Energy Consumption of Router Advertisements", RFC 7772, February 2016.

J. Jeong, S. Park, L. Beloeil, and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 8106, March 2017.

L. Colitti, and J. Linkova, "Discovering PREF64 in Router Advertisements", RFC 8781, April 2020.

## SEE ALSO
radvd(8), radvdump(8)

## AUTHORS

```
See radvd.8 manpage for authors
```


cloginrc

package: rancid

title: cloginrc(5)

summary: clogin configuration file

text:
# cloginrc(5)

## NAME

.cloginrc - clogin configuration file

## DESCRIPTION
.cloginrc contains configuration information for alogin(1), blogin(1), clogin(1), elogin(1), flogin(1), hlogin(1), htlogin(1), jlogin(1), nlogin(1), nslogin(1), rivlogin(1), and tntlogin(1), such as usernames, passwords, ssh encryption type, etc., and is read at run-time.

Each line contains either white-space (blank line), a comment which begins with the comment character '#' and may be preceded by white-space, or one of the directives listed below.

Each line containing a directive is of the form:

```
add <directive> <hostname glob> {<value>} [{<value>} ...]

or

include {<file>}
```

Note: the braces ({}) surrounding the values is significant when the values include TCL meta-characters. Best common practice is to always enclose the values in braces. If a value includes a (left or right) brace or space character, it must be backslash-escaped, as in:

```
add user <hostname glob> {foo\}bar}
add user <hostname glob> {foo\ bar}
```

As .cloginrc is searched for a directive matching a hostname, it is always the first matching instance of a directive, one whose hostname glob expression matches the hostname, which is used. For example; looking up the "password" directive for hostname foo in a .cloginrc file containing

```
add password *   {bar} {table}
add password foo {bar} {table}
```

would return the first line, even though the second is an exact match.

.cloginrc is expected to exist in the user's home directory and must not be readable, writable, or executable by "others". .cloginrc should be mode 0600, or 0640 if it is to be shared with other users who are members of the same unix group. See chgrp(1) and chmod(1) for more information on ownership and file modes.

## DIRECTIVES
The accepted directives are (alphabetically):

add autoenable <router name glob> {[01]}

When using locally defined usernames or AAA, it is possible to have a login which is automatically enabled. This is, that user has enable privileges without the need to execute the enable command. The router's prompt is different for enabled mode, ending with a # rather than a >. Example: add autoenable * {1}

Default: 0

zero, meaning that the user is not automatically enabled and clogin should execute the enable command to gain enable privileges, unless negated by the noenable directive or -noenable command-line option.

Also see the noenable directive.

add cyphertype <router name glob> {<ssh encryption type>}

cyphertype defines which encryption algorithm is used with ssh. A device may not support the type ssh uses by default. See ssh(1)'s -c option for details. Default: {3des}

add enableprompt <router name glob> {"<enable prompt>"}

When using AAA with a Cisco router or switch, it is possible to redefine the prompt the device presents to the user for the enable password. enableprompt may be used to adjust the prompt that clogin should look for when trying to login. Note that enableprompt can be a Tcl style regular expression. Example: add enableprompt rc*.example.net {"\[Ee]nter\ the\ enable\ password:"}

Default: "\[Pp]assword:"

add enauser <router name glob> {<username>}

This is only needed if a device prompts for a username when gaining enable privileges and where this username is different from that defined by or the default of the user directive.

add identity <router name glob> {<ssh identity file path>}

May be used to specify an alternate identity file for use with ssh(1). See ssh's -i option for details. Default: your default identity file. see ssh(1).

add method <router name glob> {ssh} [{...}]

Defines, in order, the connection methods to use for a device from the set {ssh, telnet, rsh}. Method telnet may have a suffix, indicating an alternate TCP port, of the form ":port". Note: Different versions of telnet treat the specification of a port differently. In particular, BSD derived telnets do not do option negotiation when a port is given. Some devices, Extreme switches for example, have undesirable telnet default options such as linemode. In the BSD case, to enable option negotiation when specifying a port the method should be "{telnet:-23}" or you should add "mode character" to .telnetrc. See telnet(1) for more information on telnet command-line syntax, telnet options, and .telnetrc.

Example: add method * {ssh} {telnet:-3000} {rsh}

Which would cause clogin to first attempt an ssh connection to the device and if that were to fail with connection refused, a telnet connection to port 3000 would be tried, and then a rsh connection.

Note that not all platforms support all of these connection methods.

Default: {telnet} {ssh}

add noenable <router name glob> {1}

clogin will not try to gain enable privileges when noenable is matched for a device. This is equivalent to clogin's -noenable command-line option. Note that this directive is meaningless for jlogin(1), nlogin(1) and clogin(1) [for Extreme] which do not have the concept of "enabled" and/or no way to elevate privleges once logged in; a user either has the necessary privleges or doesn't.

add passphrase <router name glob> {"<SSH passphrase>"}

Specify the SSH passphrase. Note that this may be particular to an identity directive. The passphrase will default to the password for the given router. Example: add passphrase rc*.example.net {the\ bird\ goes\ tweet}

add passprompt <router name glob> {"<password prompt>"}

When using AAA with a Cisco router or switch, it is possible to redefine the prompt the device presents to the user for the password. passprompt may be used to adjust the prompt that clogin should look for when trying to login. Note that passprompt can be a Tcl style regular expression. Example: add passprompt rc*.example.net {"\[Ee]nter\ the\ password:"}

Default: "(\[Pp]assword|passwd):"

add password <router name glob> {<vty passwd>} [{<enable passwd>}]

Specifies a vty password, that which is prompted for upon the connection to the router. The last argument is the enable password and need not be specified if the device also has a matching noenable or autoenable directive or the corresponding command-line options are used.

add sshcmd <router name glob> {<ssh>}

<ssh> is the name of the ssh executable. OpenSSH uses a command-line option to specify the protocol version, but other implementations use a separate binary such as "ssh1". sshcmd allows this to be adjusted as necessary for the local environment. Default: ssh

add timeout <router name glob> {<seconds>}

Time in seconds that the login script will wait for input from the device before timeout. Default: device dependent

add user <router name glob> {<username>}

Specifies a username clogin should use if or when prompted for one. Default: $USER (or $LOGNAME), i.e.: your Unix username.

add userpassword <router name glob> {<user password>}

Specifies a password to be associated with a user, if different from that defined with the password directive.

add userprompt <router name glob> {"<username prompt>"}

When using AAA with a Cisco router or switch, it is possible to redefine the prompt the device presents to the user for the username. userprompt may be used to adjust the prompt that clogin should look for when trying to login. Note that userprompt can be a Tcl style regular expression. Example: add userprompt rc*.example.net {"\[Ee]nter\ your\ username:"}

Default: "(Username|login|user name):"

include {<file>}

<file> is the pathname of an additional .cloginrc file to include at that point. It is evaluated immediately. That is important with regard to the order of matching hostnames for a given directive, as mentioned above. This is useful if you have your own .cloginrc plus an additional .cloginrc file that is shared among a group of folks. If <file> is not a full pathname, $HOME/ will be prepended.

Example: include {.cloginrc.group}

## FILES

```
$HOME/.cloginrc               Configuration file described here.
share/rancid/cloginrc.sample  A sample .cloginrc.
```

## ERRORS
.cloginrc is interpreted directly by Tcl, so its syntax follows that of Tcl. Errors may produce quite unexpected results.

## SEE ALSO
clogin(1), glob(3), tclsh(1)


lg.conf

title: lg.conf(5)

summary: looking glass configuration file

text:
# lg.conf(5)

## NAME
lg.conf - looking glass configuration file

## DESCRIPTION
lg.conf contains configuration for the looking glass scripts.

The syntax is that of perl(1). It is used to set variables that affect run-time behavior and/or to locate resources.

## VARIABLES
The following variables are used (alphabetically):

LG_AS_REG

*** not implemented.

LG_BGP_RT

Allows show ip bgp neighbor commands that can produce heavy output, such as sh ip bgp neighbor <ip> advertised-routes for a transit customer when the neighbor address is followed by 'advertised-routes' for the sh ip bgp neighbor query.

LG_CACHE_DIR

Sets the location of the cache directory. The looking glass uses this to hold lock files, log files, and output from cached commands. Default: ./tmp

Note that the default is relative to the directory where lg.cgi runs in the server's document root (e.g.: /usr/local/www/data/lg/tmp).

LG_CACHE_TIME

Sets the number of seconds that the looking glass should cache output from commands that tend to produce a lot of output, such as 'show ip bgp dampened-paths'. Default: 600

LG_CLOGINRC

Defines the location of the cloginrc(5) that the looking glass should use. The path may be relative to the directory where the CGI scripts run in the server's document root. Default: $HOME/.cloginrc

Note that the .cloginrc must be readable by the user or group that will be running the CGI and that clogin(1) will not allow a world readable .cloginrc. The user is normally that of the http server (httpd).

LG_IMAGE

Defines a html image tag () which, if defined, will be included at the top of the looking glass pages. It may contain any html as it is simply handed off to print(). Example: $LG_IMAGE="\n FOO";

LG_INFO

Defines information in html format which, if defined, will be included at the bottom of the looking glass form page. It may contain any html as it is simply handed off to print(). Example: $LG_INFO="For Support contact webmaster";

LG_LOG

Defines the fully qualified path name (i.e.: begins with '/') for the log file or the syslog(3) facility to use for logging. For syslog, the argument is the lowercase name of a syslog facility (see syslog.h) without the 'LOG_' prefix. Example: local0

Default: $LG_CACHE_DIR/lg.log

LG_ROUTERDB

Sets the location for the router.db file in rancid's router.db(5) format. It lists the devices that should be available to the looking glass users. Only those devices of supported types and with state 'up' are made available. If not defined and the default file does not exist, the looking glass will compile a list from the router.db files of all the groups present in rancid, that is, the list will be a concatenation of the available router.db(5) files. Note that if the concatenation method is used, it may be necessary to alter the mode of the router.db files in the rancid group directories, since rancid's default umask is 027 (see rancid.conf(5)).

LG_STRIP

Causes the LG to strip login information from the looking glass results. Since Expect often munges disabling echo when passwords are entered, this is a SECURITY CONCERN! However, this output can be very useful for debugging clogin problems.

LG_STYLE

Defines the URL of a style sheet to be used for HTML formatting.

PATH

Is a colon separated list of directory pathnames in the file system where rancid's login scripts, clogin(1) etc.) and programs needed within these, such as telnet(1), are located. Its value is set by configure. Should it be necessary to modify PATH, note that it must include $BASEDIR/bin (see above).

Queries ...................................

## ENVIRONMENT
LG_CONF

Location of lg.conf file. See the FILES section for more information.

## ERRORS
lg.conf is interpreted directly by perl(1), so its syntax follows that of perl. Syntax errors may produce quite unexpected results.

## FILES
/etc/rancid/lg.conf

Configuration file described here. lg.conf is located by the value of the environment variable LG_CONF, in the CWD (current working directory), or the sysconfdir defined when rancid was installed, in that order.

## SEE ALSO
cloginrc(5), lg_intro(1), router.db(5)

## HISTORY
In RANCID releases prior to 2.3, lg.conf was located in the util/lg sub-directory of the install path. This was changed to be more consistent with common file location practices.


rancid.conf

title: rancid.conf(5)

summary: rancid environment configuration file

text:
# rancid.conf(5)

## NAME
rancid.conf - rancid environment configuration file

## DESCRIPTION
rancid.conf contains environment configuration information for rancid-run(1) and rancid-cvs(1), including shell PATH, list of rancid groups, etc. It is read by several scripts at run-time and others inherit the configration from a parent process which has read it.

The syntax of rancid.conf is that of sh(1). rancid.conf is used to set environment variables used by other rancid scripts to effect their run-time behavior or to enable them to find their resources.

## VARIABLES
The following variables are used (listed alphabetically):

ACLSORT

Permits disabling of access-list sorting, which could alter statement order that had been cleverly crafted by the administrator for optimal performance, thus making recovery and comparsion more difficult. Default: YES

BASEDIR

BASEDIR is the directory where rancid-run's log directory, the revision control system's repository, and rancid group directories will be placed. Its value is configure's localstatedir and should be modified if rancid is moved to a new location in the file system without re-installing from the distribution.

Default: /var/lib

CVSROOT

cvs(1) and rancid-cvs(1) use this environment variable to locate the CVS repository. In some cases, and for Subversion, it is used as an argument to commands. It should not be necessary to alter it. Default: $BASEDIR/CVS

FILTER_PWDS

Determines which passwords will be filtered from configs. The value may be "NO", "YES", or "ALL" to filter none of the passwords, only those which are reversable or plain-text, or all (plus ssh keys, etc), respectively. Default: YES

Note: a value of "NO" could be a security issue since diffs are sent via e-mail. A value of "ALL" is encouraged.

Note: FILTER_PWDS does not affect the handling of SNMP community strings. see NOCOMMSTR below.

Note: passwords whose value cycles and would produce erroneous diffs are always filtered (e.g.: Alteon passwords).

LIST_OF_GROUPS

Defines a list of group names of routers separated by white-space. These names become the directory names in $BASEDIR which contain the data for that set of devices. rancid-run(1) also uses this variable to determine which device groups it should collect. Choose these names to be descriptive of the set of devices and do not use spaces, unprintable characters, etc. Example: LIST_OF_GROUPS="UofO USFS"

Two groups are defined; UofO (University of Oregon) and USFS (US Forest Service). Each will have a directory created (see rancid-cvs(1)) $BASEDIR/UofO and $BASEDIR/USFS respectively, which will contain their data.

Each group must also have aliases for the administrative and diff recipients set-up in /etc/aliases. For example:

```
rancid-uofo:            frank
rancid-admin-uofo:      joe,bob
rancid-usfs:            frank
rancid-admin-usfs:      joe,bob
```

LOCKTIME

Defines the number of hours a group's lock file may age before rancid starts to complain about a hung collection. The default is 4 hours.

LOGDIR

Directory where rancid-run places log files. Default: $BASEDIR/logs

MAILDOMAIN

Define the domain part of addresses for administrative and diff e-mail. The value of this variable is simply appended to the normal mail addresses. For example rancid-usfs@example.com, if MAILDOMAIN had been set to "@example.com".

MAILHEADERS

Define additional mail headers to be added to rancid mail, such as Precedence or X- style headers. Individual headers must be separated by a \n (new line). Default: Precedence: bulk

Example: Precedence: bulk\nX-clamation: beef cake

MAX_ROUNDS

Defines how many times rancid should retry collection of devices that fail. The minimum is 1. Default: 4.

NOCOMMSTR

If set, rancid(1) will filter SNMP community strings from configs. Otherwise, they will be retained and may appear in clear-text in e-mail diffs. By default, this is not set.

NOPIPE

If set, rancid(1) will use temporary files to save the output from the router and then read these to build the file which will be saved in CVS (or Subversion). Otherwise, an IPC pipe will be used. We have found that the buffering mechanisms used in perl and expect are heinous. Using temporary files may result in a noticeable improvement in speed. By default, this is not set.

OLDTIME

Specified as a number of hours, OLDTIME defines how many hours should pass since a successful collection of a device's configuration and when control_rancid(1) should start complaining about failures. The value should be greater than the number of hours between rancid-run cron runs. Default: 24

PAR_COUNT

Defines the number of rancid processes that par(1) will start simultaneously as control_rancid(1) attempts to perform collections. Raising this value will decrease the amount of time necessary for a complete collection of a (or all) rancid groups at the expense of system load. The default is relatively cautious. If collections are not completing quickly enough for users, use trial and error of speed versus system load to find a suitable value. Default: 5

PATH

Is a colon separate list of directory pathnames in the the file system where rancid's sh(1) and perl(1) scripts should look for the programs that it needs, such as telnet(1). Its value is set by configure. Should it be necessary to modify PATH, note that it must include /usr/lib/rancid.

RCSSYS

Sets which revision control system is in use. Valid values are cvs for CVS or svn for Subversion. Default: cvs

TERM

Some Unix utilities require TERM, the terminal type, to be set to a sane value. Some clients, such as telnet(1) and ssh(1), communicate this to the server (i.e.: the remote device), thus this can affect the behavior of login sessions on a device. The default should suffice. Default: network

TMPDIR

Some Unix utilities recognize TMPDIR as a directory where temporary files can be stored. In some cases, rancid utilizes this directory for lock files and other temporary files. Default: /tmp

Each of these are simply environment variables. In order for them to be present in the environment of child processes, each must be exported. See sh(1) for more information on the built-in command export.

## ERRORS
rancid.conf is interpreted directly by sh(1), so its syntax follows that of the bourne shell. Errors may produce quite unexpected results.

## FILES
/etc/rancid/rancid.conf

Configuration file described here.

## SEE ALSO
control_rancid(1), rancid(1), rancid-cvs(1), rancid-run(1)

## HISTORY
In RANCID releases prior to 2.3, rancid.conf was named env and located in the bin directory. This was changed to be more consistent with common file location practices.


router.db

title: router.db(5)

summary: rancid group configuration file

text:
# router.db(5)

## NAME
router.db - rancid group configuration file

## DESCRIPTION
router.db contains information for devices which are members of a rancid group. control_rancid(1) reads this file to compile a list of devices which it should collect.

## SYNTAX
One device is listed per-line, where the syntax is:

```
<device_name>:<device_type>:<state>[:comments]
```

For example:

```
scooby.shrubbery.net:cisco:up
```

The fields are as follows:

<device_name>

The name of the device, which must resolve via gethostbyname, used as the argument to telnet(1), rsh(1), or ssh(1), to connect to the device. Once converted to lower-case, this also becomes the name of the file used to store the configuration under $BASEDIR/<group>/configs. Experience has shown that using the device's FQDN (Fully Qualified Domain Name) works best, as in the example above.

<device_type>

The type of device from the set:

agm

A Cisco Anomoly Guard Module (aka Riverhead). Suspect that at some point the UI will become more cisco-like and it can be merged with the IOS rancid module.

alteon

An Alteon WebOS switches.

arista

An Arista Networks device.

avocent

An Avocent Cyclades console server.

baynet

A Bay Networks router.

cat5

A Cisco catalyst series 5000 and 4000 switches (i.e.: running the catalyst OS, not IOS).

cisco

A Cisco router, PIX, or switch such as the 3500XL or 6000 running IOS (or IOS-like) OS, but not IOS-XR.

cisco-nx

A Cisco Nexus switch/router.

cisco-xr

A Cisco device running IOS-XR.

css

A Cisco content services switch.

enterasys

An enterasys NAS. This is currently an alias for the riverstone device type.

erx

A Juniper E-series edge router.

extreme

An Extreme switch.

ezt3

An ADC-Kentrox EZ-T3 mux.

f5

A F5 BigIP switch.

force10

A Force10 router.

fortigate

A Fortinet firewall.

foundry

A Foundry router, switch, or router-switch. This includes HP Procurve switches that are OEMs of Foundry products, such as the HP9304M.

hitachi

A Hitachi router.

hp

A HP Procurve switch such as the 2524 or 4108 procurve switches. Also see the foundry type.

juniper

A Juniper router.

mikrotik

A Mikrotik router.

mrtd

A host running the (Merit) MRTd daemon.

netscalar

A Netscalar load balancer.

netscreen

A Netscreen firewall.

procket

A Procket router.

redback

A Redback router, NAS, etc.

riverstone

A Riverstone NAS or Cabletron (starting with version ~9.0.3) router.

smc

A SMC switch (some Dell OEMs).

tnt

A Lucent TNT.

zebra

Zebra routing software.

<state>

The state is either "up", or some other arbitrary value, e.g. "down". If the device is not marked "up" the device's configuration will not be collected. It is highly recommended that comments are made for any router not listed as up, so as to indicate the reason a router is not to be polled, e.g.: dial1.paris:cisco:up:

core1.paris:cisco:down:in testing until 5/5/2001.

core2.paris:cisco:ticketed:Ticket 6054234, 5/3/2001

border1.paris:juniper:up:

The script "downreport" in util/ can be used to produce a report of routers in router.db that are not marked "up".

[comments]

Freeform string to describe the current state of the router.

A ``#'' at the begining of a line is a comment; the entire line is ignored.

If a device is deleted from the router.db file, then rancid will clean up by removing the device's config file from $BASEDIR/<group>/configs. The device will be removed from the revision control system. It is possible, in most cases, to resurrect or check-out copies of deleted device configurations.

## FILES
$BASEDIR/<group>/router.db

Configuration file described here, where <group> is a device group name defined in the variable LIST_OF_GROUPS within $BASEDIR/etc/rancid.conf.

## SEE ALSO
control_rancid(1), rancid(1), rancid.conf(5)


razor-agent.conf

package: razor

title: razor-agent.conf(5)

summary: Configuration file for Razor Agents

text:
# razor-agent.conf(5)

## NAME
"razor-agent.conf" - Configuration file for Razor Agents

## DESCRIPTION
"razor-agent.conf" is a configuration file read by the razor agents, which include razor-check(1), razor-admin(1), razor-report(1), and razor-revoke(1). The format is "attribute = value" pairs, one pair per line. Lines that begin with `#' are treated as comments.

## ATTRIBUTES
Following attributes can be specified:

razorhome

Directory where Razor Agents look for files. All files in "razor-agent.conf" without a full path will be relative to "razorhome". The default is "/etc/razor/" for root, and "~/.razor/" for every other user. If "razorhome" does not exist, it will be created.

logfile

Log file for the Razor Agents. The default is "razor-agent.log".

debuglevel

Controls the amount of messages written to logfile. It is an integer between 0 and 20. For Example, a value of 1 logs only startup and error messages, 5 includes every transaction with the server, and 14 is extremely verbose information intended for debugging use only. NOTE: 15 and higher create debug files on your filesystem -- do not use unless you know what you are doing. The default is 5.

identity

Specify an identify file to use for storing a newly registered identity during razor-admin(1). For razor-report(1) and razor-revoke(1), use this identity when authenticating with Razor Servers. If not specified, "<razorhome>/identity-<user>" is used.

listfile_nomination

File where Razor Nomination Servers are listed, in order of closest TCP ping time. Nomination Servers are used by razor-report(1) and razor-revoke(1). This file is created automatically. The default is "servers.nomination.lst".

listfile_catalogue

File where Razor Catalogue Servers are listed, in order of closest TCP ping time. Catalogue Servers are used by razor-check(1). This file is created automatically. The default is "servers.catalogue.lst".

listfile_discovery

File where Razor Discovery Servers are listed, in random order. This file is created automatically using DNS. The default is "servers.discovery.lst".

rediscovery_wait_dns

Max time in seconds Razor Agents will wait before computing a new "listfile_discovery" using DNS. The default is 604800, which is 7 days.

rediscovery_wait

Max time in seconds Razor Agents will wait before computing a new "listfile_nomination" and a new "listfile_catalogue". The default is 172800, which is 2 days.

turn_off_discovery

Turns off closest host discovery. When set to 1, "listfile_catalogue" and "listfile_nomination" will not be updated and "listfile_discovery" is not read or updated. The default is 0.

ignorelist

Automatically ignore mailing list posts. If set to 0, mailing list posts will be handled like all other mail. The default is 0.

whitelist

Name of whitelist file. Razor Agents can consult a whitelist of addresses and SHA1 hashes before checking a mail with Razor Servers. If the address/hash is found on the whitelist, the mail is marked `not spam', without checking against the server. The format of the whitelist can be found in razor-whitelist(5) manpage. The default is "razor-whitelist".

min_cf

When checking spam, the server optionally returns a spam confidence value ranging from 0 (not confident) to 100 (absolutely or 100% confident). To be considered spam, the server's spam confidence value must be greater than or equal to "min_cf". "min_cf" can be a number or an expression containing ac, the average confidence published by a Razor Server. Examples: 0, 60, 100, ac, ac + 10, ac - 20. If an expression evaluates to less than 0 it becomes 0, likewise those greater than 100 become 100. The default is "ac".

report_headers

When reporting spam, the entire email (headers and body) is sent to a Razor Nomination Server. When set to 0, all the headers are removed except headers beginning with "Content-" before sending, and a special header beginning with "X-Razor2" is added to note this action. The default is 1.

## AUTHORS
Vipul Ved Prakash, <mail@vipul.net> and Chad Norwood <chad@samo.org>

## SEE ALSO
razor-agents(1), razor-check(1), razor-admin(1), razor-report(1), razor-revoke(1), razor-whitelist(5)


razor-agents

title: razor-agents(5)

text:
# razor-agents(5)

## NAME
Razor-Agents - Collection of files for checking, reporting, and revoking spam

## DESCRIPTION
Vipul's Razor is a distributed, collaborative, spam detection, reporting, and filtering network. The primary focus of the system is to identify and remove all email spam from the internet. Visit the website at http://razor.sourceforge.net/.

## USAGE
First a razorhome directory should be created where log, conf, and cached server information will live. This is done via "-create" option to razor-admin(1). See man page for details.

You can immediately check spam using razor-check(1). See man page for details.

To report spam, an identity must be registered. This is done via "-register" option to razor-admin(1). After that, razor-report(1) and razor-revoke(1) will work flawlessly.

## CONFIGURATION
All Razor-Agents share a configuration file. The contents of the configuration file are detailed in the razor-agent.conf(5) manpage.

Config file is computed before razorhome, in the following order:

```
 -conf=/path/file.conf           used if readable, else
 <home>/.razor/razor-agent.conf  used if readable, else
 /etc/razor/razor-agent.conf     used if readable, else
 all defaults are used.
```

To see configuration defaults, do

razor-admin -create -conf=/tmp/razor2-defaults.conf

## RAZORHOME
All Razor-Agents also share a razorhome directory, where identity, logging, and cached information about servers is stored. Razorhome is computed after configuration file, in the following order.

```
 -home=/tmp/razor/                     used if readable, else
 'razorhome' from configuration file   used if readable, else
 <home>/.razor/                        used if readable, else
 <home>/.razor/                        is created.  if that fails,
                                       no razorhome.
 NOTE: If there is no razorhome, razor-report and razor-revoke will
       not work unless you specify  -ident=/path/identity
       razor-check will still work.
```

## FILES
Besides those listed at the end with their own manpages, Razor Agents also has the following files.

razorhome/identity

Usually a symlink to identity file containing user+pass. Used by razor-report(1) and razor-revoke(1).

razorhome/razor-agent.log

Default log file. To change, edit razor-agent.conf(5).

razorhome/servers.*.lst

Cached list of Razor Servers. If more than one, they are ordered by closest ping time.

razorhome/server.<name>.lst

Cached info for <name> server. The "srl" key in this file is compared against the server greeting, and if server's is greater, new cache info is retrieved from the server.

## EXAMPLES
razor-check -d -debuglevel=9 mbox

Checks spam in mbox. prints numbers for those found to be spam. -d logs to stdout, -debuglevel=9 is verbose logging

razor-admin -create -home=/home/chad/.razor -d -s

Creates razorhome in /home/chad/.razor, log to stdout, does not connect to server (-s simulate).

razor-report spam -debuglevel=0

sends spam to server, with no log msgs.

## AUTHORS
Vipul Ved Prakash, <mail@vipul.net> and Chad Norwood <chad@samo.org>

## SEE ALSO
razor-agent.conf(5), razor-check(1), razor-admin(1), razor-report(1), razor-revoke(1), razor-whitelist(5)


razor-whitelist

title: razor-whitelist(5)

summary: Format for Vipul's Razor Whitelist

text:
# razor-whitelist(5)

## NAME
"razor-whitelist" - Format for Vipul's Razor Whitelist

## DESCRIPTION
The razor whitelist is a list of email addresses and body signatures. Emails that match the whitelist are not processed by any of the Razor Agents. That is, They are not checked, reported, or revoked. In the case of razor-check(1), they are instantly marked as non-spam.

## LOCATION
The razor whitelist is usually "<razorhome>/razor-whitelist". The "whitelist" parameter in razor-agent.conf(5) should point to this file. If the "whitelist" parameter in razor-agent.conf(5) is missing, "whitelist" is not used.

## FORMAT
Each whitelist rule is placed on a line of its own. Lines that begin in a `#' character are considered to be comments and are ignored by the parser. A rule contains the name of a header and the string to match against the header, separated by whitespace. Here are some examples:

```
 to bugtraq@securityfocus.com
 cc a.list@somewhere.net
```

These rules imply that when a mail contains "bugtraq@securityfocus.com" in its `to' and `cc' headers, it should be whitelisted. It's worth noting that a match occurs if the address string matches any part of the address.

```
 from @mydomain.com
```

A special rule called `sha1' can be used for whitelisting signatures. For example:

```
 sha1 75f8bcc2357366bbfa9c6ab0b6e5648ed0cf7083
```

whitelists a message with the body of `test'.

## AUTHORS
Vipul Ved Prakash <mail@vipul.net>, and Chad Norwood <chad@samo.org>

## SEE ALSO
razor-agents(1), razor-agent.conf(5), razor-check(1), razor-admin(1), razor-report(1), razor-revoke(1)

## LICENSE
This is free software, distributed under the Artistic License 2.0.


rcsfile

package: rcs

title: rcsfile(5)

summary: format of RCS file

text:
# rcsfile(5)

## NAME
rcsfile - format of RCS file

## DESCRIPTION
An RCS file's contents are described by the grammar below.

The text is free format: space, backspace, tab, newline, vertical tab, form feed, and carriage return (collectively, white space) have no significance except in strings. However, white space cannot appear within an id, num, or sym, and an RCS file must end with a newline.

Strings are enclosed by @. If a string contains a @, it must be doubled; otherwise, strings can contain arbitrary binary data.

The meta syntax uses the following conventions: `|' (bar) separates alternatives; `{' and `}' enclose optional phrases; `{' and `}*' enclose phrases that can be repeated zero or more times; `{' and '}+' enclose phrases that must appear at least once and can be repeated; Terminal symbols are in boldface; nonterminal symbols are in italics.

```
rcstext	::=	admin {delta}* desc {deltatext}*
```

```
admin	::=	head	{num};
		{ branch	{num}; }
		access	{id}*;
		symbols	{sym : num}*;
		locks	{id : num}*;  {strict  ;}
		{ comment	{string}; }
		{ expand	{string}; }
		{ newphrase }*
```

```
delta	::=	num
		date	num;
		author	id;
		state	{id};
		branches	{num}*;
		next	{num};
		{ newphrase }*
```

```
desc	::=	desc	string
```

```
deltatext	::=	num
		log	string
		{ newphrase }*
		text	string
```

```
num	::=	{digit | .}+
```

```
digit	::=	0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
```

```
id	::=	{num} idchar {idchar | num}*
```

```
sym	::=	{digit}* idchar {idchar | digit}*
```

```
idchar	::=	any visible graphic character except special
```

```
special	::=	$ | , | . | : | ; | @
```

```
string	::=	@{any character, with @ doubled}*@
```

```
newphrase	::=	id word* ;
```

```
word	::=	id | num | string | :
```

Identifiers are case sensitive. Keywords are in lower case only. The sets of keywords and identifiers can overlap. In most environments RCS uses the ISO 8859/1 encoding: visible graphic characters are codes 041-176 and 240-377, and white space characters are codes 010-015 and 040.

Dates, which appear after the date keyword, are of the form Y.mm.dd.hh.mm.ss, where Y is the year, mm the month (01-12), dd the day (01-31), hh the hour (00-23), mm the minute (00-59), and ss the second (00-60). Y contains just the last two digits of the year for years from 1900 through 1999, and all the digits of years thereafter. Dates use the Gregorian calendar; times use UTC.

The newphrase productions in the grammar are reserved for future extensions to the format of RCS files. No newphrase will begin with any keyword already in use.

The delta nodes form a tree. All nodes whose numbers consist of a single pair (e.g., 2.3, 2.1, 1.3, etc.) are on the trunk, and are linked through the next field in order of decreasing numbers. The head field in the admin node points to the head of that sequence (i.e., contains the highest pair). The branch node in the admin node indicates the default branch (or revision) for most RCS operations. If empty, the default branch is the highest branch on the trunk.

All delta nodes whose numbers consist of 2n fields (n≥2) (e.g., 3.1.1.1, 2.1.2.2, etc.) are linked as follows. All nodes whose first 2n-1 number fields are identical are linked through the next field in order of increasing numbers. For each such sequence, the delta node whose number is identical to the first 2n-2 number fields of the deltas on that sequence is called the branchpoint. The branches field of a node contains a list of the numbers of the first nodes of all sequences for which it is a branchpoint. This list is ordered in increasing numbers.

The following diagram shows an example of an RCS file's organization.

```
                           Head

                             |

                             |

                             v                        / \

                         ---------                   /   \

   / \          / \      |       |      / \         /     \

  /   \        /   \     |  2.1  |     /   \       /       \

 /     \      /     \    |       |    /     \     /         \
/1.2.1.3\    /1.3.1.1\   |       |   /1.2.2.2\   /1.2.2.1.1.1\
---------    ---------   ---------   ---------   -------------

    ^            ^           |           ^             ^

    |            |           |           |             |

    |            |           v           |             |

   / \           |       ---------      / \            |

  /   \          |       \  1.3  /     /   \           |

 /     \         ---------\     /     /     \-----------
/1.2.1.1\                  \   /     /1.2.2.1\
---------                   \ /      ---------

    ^                        |           ^

    |                        |           |

    |                        v           |

    |                    ---------       |

    |                    \  1.2  /       |

    ----------------------\     /---------

                           \   /

                            \ /

                             |

                             |

                             v

                         ---------

                         \  1.1  /

                          \     /

                           \   /

                            \ /
```

## IDENTIFICATION
Author: Walter F. Tichy, Purdue University, West Lafayette, IN, 47907.

Manual Page Revision: 5.6; Release Date: 1995/06/05.

Copyright © 1982, 1988, 1989 Walter F. Tichy.

Copyright © 1990, 1991, 1992, 1993, 1994, 1995 Paul Eggert.

## SEE ALSO
rcsintro(1), ci(1), co(1), ident(1), rcs(1), rcsclean(1), rcsdiff(1), rcsmerge(1), rlog(1)

Walter F. Tichy, RCS--A System for Version Control, Software--Practice & Experience 15, 7 (July 1985), 637-654.


realmd.conf

package: realmd

title: realmd.conf(5)

summary: Tweak behavior of realmd

text:
# realmd.conf(5)

## NAME
realmd.conf - Tweak behavior of realmd

## CONFIGURATION FILE
realmd can be tweaked by network administrators to act in specific ways. This is done by placing settings in a /etc/realmd.conf. This file does not exist by default. The syntax of this file is the same as an INI file or Desktop Entry file. If the file is changed and realmd is running realmd must be restarted to read the new values.

In general, settings in this file only apply at the point of joining a domain or realm. Once the realm has been setup the settings have no effect. You may choose to configure SSSD[1] or Winbind[2] directly.

Only specify the settings you wish to override in the /etc/realmd.conf file. Settings not specified will be loaded from their packaged defaults which can be found in /usr/lib/realmd/realmd-defaults.conf and /usr/lib/realmd/realmd-distro.conf. Only override the settings below. You may find other settings if you look through the realmd source code. However these are not guaranteed to remain stable.

There are various sections in the config file. Some sections are global topic sections, and are listed below. Other sections are specific to a given realm. These realm specific sections should always contain the domain name in lower case as their section header.

Examples of each setting is found below, including the header of the section it should be placed in. However in the resulting file only include each section once, and combine the various section setting together as lines underneath the section. For example

```
[users]
default-home = /home/%U
default-shell = /bin/bash
```

## ACTIVE-DIRECTORY
These options should go in an [active-directory] section of the /etc/realmd.conf file. Only specify the settings you wish to override.

default-client

Specify the default-client setting in order to control which client software is the preferred default for use with Active Directory.

```
[active-directory]
default-client = sssd
# default-client = winbind
```

The default setting for this is sssd which uses SSSD[1] as the Active Directory client. You can also specify winbind to use Samba Winbind[2]. Some callers of realmd such as the realm command line tool allow specifying which client software should be used. Others, such as GNOME Control Center, simplify choose the default.

You can verify the preferred default client softawre by running the following command. The realm with the preferred client software will be listed first.

```
$ realm discover domain.example.com
domain.example.com

  configured: no

  server-software: active-directory

  client-software: sssd

  type: kerberos

  realm-name: AD.THEWALTER.LAN

  domain-name: ad.thewalter.lan
domain.example.com

  configured: no

  server-software: active-directory

  client-software: winbind

  type: kerberos

  realm-name: AD.THEWALTER.LAN

  domain-name: ad.thewalter.lan
```

use-ldaps

Use the ldaps port when connecting to AD where possible. In general this option is not needed because realmd itself only read public information from the Active Directory domain controller which is available anonymously. The supported membership software products will use encrypted connections protected with GSS-SPNEGO/GSSAPI which offers a comparable level of security than ldaps. This option is only needed if the standard LDAP port (389/tcp) is blocked by a firewall and only the LDAPS port (636/tcp) is available. If this option is set to yes realmd will use the ldaps port when reading the rootDSE and call the adcli membership software with the option --use-ldaps. The Samba base membership currently offers only deprecated ways to enable ldaps. Support will be added in realmd when a new way is available.

os-name

(see below)

os-version

Specify the os-name and/or os-version settings to control the values that are placed in the computer account operatingSystem and operatingSystemVersion attributes. This is an Active Directory specific option.

It is also possible to use the --os-name or --os-version argument of the realm command to override the default values.

```
[active-directory]
os-name = Gentoo Linux
os-version = 9.9.9.9.9
```

## SERVICE
These options should go in an [service] section of the /etc/realmd.conf file. Only specify the settings you wish to override.

automatic-install

Set this to no to disable automatic installation of packages via package-kit.

```
[service]
automatic-install = no
# automatic-install = yes
```

legacy-samba-config

Set this to yes to create a Samba configuration file with id-mapping options used by Samba-3.5 and earlier version.

```
[service]
legacy-samba-config = no
# legacy-samba-config = yes
```

## USERS
These options should go in an [users] section of the /etc/realmd.conf file. Only specify the settings you wish to override.

default-home

Specify the default-home setting in order to control how to set the home directory for accounts that have no home directory explicitly set.

```
[users]
default-home = /home/%U@%D
# default-home = /nfs/home/%D-%U
# default-home = /home/%D/%U
```

The default setting for this is /home/%U@%D. The %D format is replaced by the domain name. The %U format is replaced by the user name. You can verify the home directory for a user by running the following command.

```
$ getent passwd 'DOMAIN/User'
DOMAIN\user:*:13445:13446:Name:/home/DOMAIN/user:/bin/bash
```

Note that in the case of IPA domains, most users already have a home directory configured in the domain. Therefore this configuration setting may rarely show through.

default-shell

Specify the default-shell setting in order to control how to set the Unix shell for accounts that have no shell explicitly set.

```
[users]
default-shell = /bin/bash
# default-shell = /bin/sh
```

The default setting for this is /bin/bash shell. The shell should be a valid shell if you expect the domain users be able to log in. For example it should exist in the /etc/shells file. You can verify the shell for a user by running the following command.

```
$ getent passwd 'DOMAIN/User'
DOMAIN\user:*:13445:13446:Name:/home/DOMAIN/user:/bin/bash
```

Note that in the case of IPA domains, most users already have a shell configured in the domain. Therefore this configuration setting may rarely show through.

## PATHS
These options should go in an [paths] section of the /etc/realmd.conf file. Only specify the settings you wish to override.

krb5.conf

Path to the Kerberos configuration file, typically /etc/krb5.conf. It can also be the path of a file included by /etc/krb5.conf, e.g. /etc/krb5.conf.d/realmd_settings, if the file does not exist if will be created.

```
[paths]
krb5.conf = /etc/krb5.conf.d/realmd_settings
```

When joining an Active Directory domain realmd will set the default_realm and udp_preference_limit options in the Kerberos configuration:

```
default_realm = DOMAIN.EXAMPLE.COM
udp_preference_limit = 0
```

The default_realm option is e.g. needed when trying to resolve enterprise principals and makes it more convenient to request Kerberos tickets for users of the default realm. Instead of specifying the whole principal just kinit username can be used. With udp_preference_limit = 0 always TCP will be used to send Kerberos request to domain controller. This is useful in Active Directory environments because Kerberos will typically switch to TCP after initially starting with UDP because AD Kerberos tickets are often larger than UDP can handle. Using TCP by default will avoid those extra UDP round trips. Additionally it helps to avoid issues with password changes when the DC does not reply soon enough and the client will send a second UDP request. The DC might reply with a reply error to the second request although the original password change request was successful and the client will no know if the request was successful or not. When using TCP this cannot happen because the client will never send a second request but waits on the connection until the server replies.

Please note that realmd will not remove those options while leaving the domain since they are useful in general. When joining a new domain realmd will of course overwrite default_realm.

## REALM SPECIFIC SETTINGS
These options should go in an section with the same name as the realm in the /etc/realmd.conf file. For example for the domain.example.com domain the section would be called [domain.example.com]. To figure out the canonical name for a realm use the realm command:

```
$ realm discover --name-only DOMAIN.example.com
domain.example.com
...
```

Only specify the settings you wish to override.

computer-ou

Specify this option to create directory computer accounts in a location other than the default. This currently only works with Active Directory domains.

```
[domain.example.com]
computer-ou = OU=Linux Computers,DC=domain,DC=example,DC=com
# computer-ou = OU=Linux Computers,
```

Specify the OU as an LDAP DN. It can be relative to the Root DSE, or a complete LDAP DN. Obviously the OU must exist in the directory. It is also possible to use the --computer-ou argument of the realm command to create a computer account at a specific OU.

computer-name

This option only applied to Active Directory realms. Specify this option to override the default name used when creating the computer account. The system's FQDN will still be saved in the dNSHostName attribute.

```
[domain.example.com]
computer-name = SERVER01
```

Specify the name as a string of 15 or fewer characters that is a valid NetBIOS computer name. It is also possible to use the --computer-name argument of the realm command to override the default computer account name.

user-principal

Set the user-principal to yes to create userPrincipalName attribute for the computer accounts in the realm. The exact value depends on the defaults of the used membership software. To have full control over the value please use the --user-principal option of the realm command, see realm(8) for details.

```
[domain.example.com]
user-principal = yes
```

automatic-join

This option only applies to Active Directory realms. This option is off by default. In Active Directory domains, a computer account can be preset with a known computer account password. This can be used for automatic joins without authentication. When automatic joins are used there is no mutual authentication between the machine and the domain during the join process.

```
[domain.example.com]
automatic-join = yes
```

automatic-id-mapping

This option is on by default for Active Directory realms. Turn it off to use UID and GID information stored in the directory (as-per RFC2307) rather than automatically generating UID and GID numbers. This option only makes sense for Active Directory realms.

```
[domain.example.com]
automatic-id-mapping = no
# automatic-id-mapping = yes
```

manage-system

This option is on by default. Normally joining a realm affects many aspects of the configuration and management of the system. Turning this off limits the interaction with the realm or domain to authentication and identity.

```
[domain.example.com]
manage-system = no
# manage-system = yes
```

When this option is turned on realmd defaults to using domain policy to control who can log into this machine. Further adjustments to login policy can be made with the realm permit command.

fully-qualified-names

This option is on by default. If turned off then realm user and group names are not qualified their name. This may cause them to conflict with local user and group names.

```
[domain.example.com]
fully-qualified-names = no
# fully-qualified-names = yes
```

## SEE ALSO
realm(8)

## AUTHOR
Stef Walter <stef@thewalter.net>

Maintainer

## NOTES
1.

SSSD

https://fedorahosted.org/sssd/

2.

Winbind

http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/winbind.html