wninput

title: wninput(5)

text:
# wninput(5)

## NAME
noun.suffix, verb.suffix, adj.suffix, adv.suffix - WordNet lexicographer files that are input to grind(1)

## DESCRIPTION
WordNet's source files are written by lexicographers. They are the product of a detailed relational analysis of lexical semantics: a variety of lexical and semantic relations are used to represent the organization of lexical knowledge. Two kinds of building blocks are distinguished in the source files: word forms and word meanings. Word forms are represented in their familiar orthography; word meanings are represented by synonym sets (synsets) - lists of synonymous word forms that are interchangeable in some context. Two kinds of relations are recognized: lexical and semantic. Lexical relations hold between word forms; semantic relations hold between word meanings.

Lexicographer files correspond to the syntactic categories implemented in WordNet - noun, verb, adjective and adverb. All of the synsets in a lexicographer file are in the same syntactic category. Each synset consists of a list of synonymous words or collocations (eg. "fountain pen", "take in"), and pointers that describe the relations between this synset and other synsets. These relations include (but are not limited to) hypernymy/hyponymy, antonymy, entailment, and meronymy/holonymy. A word or collocation may appear in more than one synset, and in more than one part of speech. Each use of a word in a synset represents a sense of that word in the part of speech corresponding to the synset.

Adjectives may be organized into clusters containing head synsets and satellite synsets. Adverbs generally point to the adjectives from which they are derived.

See wngloss(7) for a glossary of WordNet terminology and a discussion of the database's content and logical organization.

### Lexicographer File Names
The names of the lexicographer files are of the form:

pos.suffix

where pos is either noun, verb, adj or adv. suffix may be used to organize groups of synsets into different files, for example noun.animal and noun.plant. See lexnames(5) for a list of lexicographer file names that are used in building WordNet.

### Pointers
Pointers are used to represent the relations between the words in one synset and another. Semantic pointers represent relations between word meanings, and therefore pertain to all of the words in the source and target synsets. Lexical pointers represent relations between word forms, and pertain only to specific words in the source and target synsets. The following pointer types are usually used to indicate lexical relations: Antonym, Pertainym, Participle, Also See, Derivationally Related. The remaining pointer types are generally used to represent semantic relations.

A relation from a source to a target synset is formed by specifying a word from the target synset in the source synset, followed by the pointer_symbol indicating the pointer type. The location of a pointer within a synset defines it as either lexical or semantic. The Lexicographer File Format section describes the syntax for entering a semantic pointer, and Word Syntax describes the syntax for entering a lexical pointer.

Although there are many pointer types, only certain types of relations are permitted between synsets of each syntactic category.

The pointer_symbols for nouns are:

```
! 	Antonym
@	Hypernym
@i	Instance Hypernym
∼	Hyponym
∼i	Instance Hyponym
#m	Member holonym
#s	Substance holonym
#p	Part holonym
%m	Member meronym
%s	Substance meronym
%p	Part meronym
=	Attribute
+	Derivationally related form
;c	Domain of synset - TOPIC
-c	Member of this domain - TOPIC
;r	Domain of synset - REGION
-r	Member of this domain - REGION
;u	Domain of synset - USAGE
-u	Member of this domain - USAGE
```

```

```

The pointer_symbols for verbs are:

```
! 	Antonym
@	Hypernym
∼	Hyponym
*	Entailment
>	Cause
^	Also see
$	Verb Group
+	Derivationally related form
;c	Domain of synset - TOPIC
;r	Domain of synset - REGION
;u	Domain of synset - USAGE
```

The pointer_symbols for adjectives are:

```
!	Antonym
&	Similar to
<	Participle of verb
\	Pertainym (pertains to noun)
=	Attribute
^	Also see
;c	Domain of synset - TOPIC
;r	Domain of synset - REGION
;u	Domain of synset - USAGE
```

The pointer_symbols for adverbs are:

```
!	Antonym
\	Derived from adjective
;c	Domain of synset - TOPIC
;r	Domain of synset - REGION
;u	Domain of synset - USAGE
```

Many pointer types are reflexive, meaning that if a synset contains a pointer to another synset, the other synset should contain a corresponding reflexive pointer. grind(1) automatically inserts missing reflexive pointers for the following pointer types:

Pointer

Reflect

Antonym

Antonym

Hyponym

Hypernym

Hypernym

Hyponym

Instance Hyponym

Instance Hypernym

Instance Hypernym

Instance Hyponym

Holonym

Meronym

Meronym

Holonym

Similar to

Similar to

Attribute

Attribute

Verb Group

Verb Group

Derivationally Related

Derivationally Related

Domain of synset

Member of Doman

### Verb Frames
Each verb synset contains a list of generic sentence frames illustrating the types of simple sentences in which the verbs in the synset can be used. For some verb senses, example sentences illustrating actual uses of the verb are provided. (See Verb Example Sentences in wndb(5).) Whenever there is no example sentence, the generic sentence frames specified by the lexicographer are used. The generic sentence frames are entered in a synset as a comma-separated list of integer frame numbers. The following list is the text of the generic frames, preceded by their frame numbers:

```
1	Something ----s
2	Somebody ----s
3	It is ----ing
4	Something is ----ing PP
5	Something ----s something Adjective/Noun
6	Something ----s Adjective/Noun
7	Somebody ----s Adjective
8	Somebody ----s something
9	Somebody ----s somebody
10	Something ----s somebody
11	Something ----s something
12	Something ----s to somebody
13	Somebody ----s on something
14	Somebody ----s somebody something
15	Somebody ----s something to somebody
16	Somebody ----s something from somebody
17	Somebody ----s somebody with something
18	Somebody ----s somebody of something
19	Somebody ----s something on somebody
20	Somebody ----s somebody PP
21	Somebody ----s something PP
22	Somebody ----s PP
23	Somebody's (body part) ----s
24	Somebody ----s somebody to INFINITIVE
25	Somebody ----s somebody INFINITIVE
26	Somebody ----s that CLAUSE
27	Somebody ----s to somebody
28	Somebody ----s to INFINITIVE
29	Somebody ----s whether INFINITIVE
30	Somebody ----s somebody into V-ing something
31	Somebody ----s something with something
32	Somebody ----s INFINITIVE
33	Somebody ----s VERB-ing
34	It ----s that CLAUSE
35	Something ----s INFINITIVE
```

### Lexicographer File Format
Synsets are entered one per line, and each line is terminated with a newline character. A line containing a synset may be as long as necessary, but no newlines can be entered within a synset. Within a synset, spaces or tabs may be used to separate entities. Items enclosed in italicized square brackets may not be present.

The general synset syntax is:

```
{   words  pointers   (  gloss  )  }
```

Synsets of this form are valid for all syntactic categories except verb, and are referred to as basic synsets. At least one word and a gloss are required to form a valid synset. Pointers entered following all the words in a synset represent semantic relations between all the words in the source and target synsets.

For verbs, the basic synset syntax is defined as follows:

```
{   words  pointers  frames   (  gloss  )  }
```

Adjective may be organized into clusters containing one or more head synsets and optional satellite synsets. Adjective clusters are of the form:

```
[
head synset
[satellite synsets]
[-]
[additional head/satellite synsets]
]
```

Each adjective cluster is enclosed in square brackets, and may have one or more parts. Each part consists of a head synset and optional satellite synsets that are conceptually similar to the head synset's meaning. Parts of a cluster are separated by one or more hyphens (-) on a line by themselves, with the terminating square bracket following the last synset. Head and satellite synsets follow the syntax of basic synsets, however a "Similar to" pointer must be specified in a head synset for each of its satellite synsets. Most adjective clusters contain two antonymous parts. See wngloss(7) for a discussion of adjective clusters, and Special Adjective Syntax for more information on adjective cluster syntax.

Synsets for relational adjectives (pertainyms) and participial adjectives do not adhere to the cluster structure. They use the basic synset syntax.

Comments can be entered in a lexicographer file by enclosing the text of the comment in parentheses. Note that comments cannot appear within a synset, as parentheses within a synset have an entirely different meaning (see Gloss Syntax ). However, entire synsets (or adjective clusters) can be "commented out" by enclosing them in parentheses. This is often used by the lexicographers to verify the syntax of files under development or to leave a note to oneself while working on entries.

### Word Syntax
A synset must have at least one word, and the words of a synset must appear after the opening brace and before any other synset constructs. A word may be entered in either the simple word or word/pointer syntax.

A simple word is of the form:

```
word[ ( marker ) ][lex_id] ,
```

word may be entered in any combination of upper and lower case unless it is in an adjective cluster. A collocation is entered by joining the individual words with an underscore character (_). Numbers (integer or real) may be entered, either by themselves or as part of a word string, by following the number with a double quote (").

See Special Adjective Syntax for a description of adjective clusters and markers.

word may be followed by an integer lex_id from 1 to 15. The lex_id is used to distinguish different senses of the same word within a lexicographer file. The lexicographer assigns lex_id values, usually in ascending order, although there is no requirement that the numbers be consecutive. The default is 0, and does not have to be specified. A lex_id must be used on pointers if the desired sense has a non-zero lex_id in its synset specification.

Word/pointer syntax is of the form:

```
[   word[ ( marker ) ][lex_id] ,   pointers   ]
```

This syntax is used when one or more pointers correspond only to the specific word in the word/pointer set, rather than all the words in the synset, and represents a lexical relation. Note that a word/pointer set appears within a synset, therefore the square brackets used to enclose it are treated differently from those used to define an adjective cluster. Only one word can be specified in each word/pointer set, and any number of pointers may be included. A synset can have any number of word/pointer sets. Each is treated by grind(1) essentially as a word, so they all must appear before any synset pointers representing semantic relations.

For verbs, the word/pointer syntax is extended in the following manner to allow the user to specify generic sentence frames that, like pointers, correspond only to a specific word, rather than all the words in the synset. In this case, pointers are optional.

```
[   word ,   [pointers]  frames   ]
```

### Pointer Syntax
Pointers are optional in synsets. If a pointer is specified outside of a word/pointer set, the relation is applied to all of the words in the synset, including any words specified using the word/pointer syntax. This indicates a semantic relation between the meanings of the words in the synsets. If specified within a word/pointer set, the relation corresponds only to the word in the set and represents a lexical relation.

A pointer is of the form:

```
[lex_filename: ]word[lex_id],pointer_symbol
```

or:

```
[lex_filename: ]word[lex_id]^word[lex_id],pointer_symbol
```

For pointers, word indicates a word in another synset. When the second form of a pointer is used, the first word indicates a word in a head synset, and the second is a word in a satellite of that cluster. word may be followed by a lex_id that is used to match the pointer to the correct target synset. The synset containing word may reside in another lexicographer file. In this case, word is preceded by lex_filename as shown.

See Pointers for a list of pointer_symbols and their meanings.

### Verb Frame List Syntax
Frame numbers corresponding to generic sentence frames must be entered in each verb synset. If a frame list is specified outside of a word/pointer set, the verb frames in the list apply to all of the words in the synset, including any words specified using the word/pointer syntax. If specified within a word/pointer set, the verb frames in the list correspond only to the word in the set.

A frame number list is entered as follows:

frames: f_num[,f_num...]

Where f_num specifies a generic frame number. See Verb Frames for a list of generic sentences and their corresponding frame numbers.

### Gloss Syntax
A gloss is included in all synsets. The lexicographer may enter a text string of any length desired. A gloss is simply a string enclosed in parentheses with no embedded carriage returns. It provides a definition of what the synset represents and/or example sentences.

### Special Adjective Syntax
The syntax for representing antonymous adjective synsets requires several additional conditions.

The first word of a head synset must be entered in upper case, and can be thought of as the head word of the head synset. The word part of a pointer from one head synset to another head synset within the same cluster (usually an antonym) must also be entered in upper case. Usually antonymous adjectives are entered using the word/pointer syntax described in Word Syntax to indicate a lexical relation. There is no restriction on the number of parts that a cluster may have, and some clusters have three parts, representing antonymous triplets, such as solid, liquid, and gas.

A cross-cluster pointer may be specified, allowing a head or satellite synset to point to a head synset in a different cluster. A cross-cluster pointer is indicated by entering the word part of the pointer in upper case.

An adjective may be annotated with a syntactic marker indicating a limitation on the syntactic position the adjective may have in relation to noun that it modifies. If so marked, the marker appears between the word and its following comma. If a lex_id is specified, the marker immediately follows it. The syntactic markers are:

```
(p)	predicate position
(a)	prenominal (attributive) position
(ip)	immediately postnominal position
```

## EXAMPLES
(Note that these are hypothetical examples not found in the WordNet lexicographer files.)

Sample noun synsets:

```
{ canine, [ dog1, cat,! ] pooch, canid,@ }
{ collie, dog1,@ (large multi-colored dog with pointy nose) }
{ hound, hunting_dog, pack,#m dog1,@ }
{ dog, }
```

Sample verb synsets:

```
{ [ confuse, clarify,! frames: 1 ] blur, obscure, frames: 8, 10 }
{ [ clarify, confuse,! ] make_clear, interpret,@ frames: 8 }
{ interpret, construe, understand,@ frames: 8 }
```

Sample adjective clusters:

```
[
{ [ HOT, COLD,! ] lukewarm(a), TEPID,^ (hot to the touch) }
{ warm, }
-
{ [ COLD, HOT,! ] frigid, (cold to the touch) }
{ freezing, }
]
```

Sample adverb synsets:

```
{ [ basically, adj.all:essential^basic,\ ] [ essentially, adj.all:basic^fundamental,\ ] ( by one's very nature )}
{ pointedly, adj.all:pungent^pointed,\ }
{ [ badly, adj.all:bad,\ well,! ] ill, ("He was badly prepared") }
```

## SEE ALSO
grind(1), wnintro(5), lexnames(5), wndb(5), uniqbeg(7), wngloss(7).

Fellbaum, C. (1998), ed. "WordNet: An Electronic Lexical Database". MIT Press, Cambridge, MA.


wnintro

package: wordnet-dict

title: wnintro(5)

text:
# wnintro(5)

## NAME
wnintro - introduction to descriptions of WordNet file formats

## SYNOPSIS
cntlist - format of cntlist and cntlist.rev files

lexnames - list of lexicographer file names and numbers

prologdb - description of Prolog database files

senseidx - format of sense index file

sensemap - mapping from senses in WordNet 2.1 to corresponding 3.0 senses

wndb - format of WordNet database files

wninput - format of WordNet lexicographer files

## DESCRIPTION
This section of the WordNet Reference Manual contains manual pages that describe the formats of the various files included in different WordNet 3.0 packages.

## NOMENCLATURE
All files are in ASCII. Fields are generally separated by one space, unless otherwise noted, and each line is terminated with a newline character. In the file format descriptions, terms in italics refer to field names. Characters or strings in boldface represent an actual character or string as it appears in the file. Items enclosed in italicized square brackets ([ ]) may not be present. Since several files contain fields that have the identical meaning, field names are consistently defined. For example, several WordNet files contain one or more synset_offset fields. In each case, the definition of synset_offset is identical.

## SEE ALSO
wnintro(1), wnintro(3), cntlist(5), lexnames(5), prologdb(5), senseidx(5), sensemap(5), wndb(5), wninput(5), wnintro(7), wngloss(7).

Fellbaum, C. (1998), ed. "WordNet: An Electronic Lexical Database". MIT Press, Cambridge, MA.


senseidx

package: wordnet-dict-sense-index

title: senseidx(5)

summary: WordNet's sense index

text:
# senseidx(5)

## NAME
index.sense, sense.idx - WordNet's sense index

## DESCRIPTION
The WordNet sense index provides an alternate method for accessing synsets and word senses in the WordNet database. It is useful to applications that retrieve synsets or other information related to a specific sense in WordNet, rather than all the senses of a word or collocation. It can also be used with tools like grep and Perl to find all senses of a word in one or more parts of speech. A specific WordNet sense, encoded as a sense_key, can be used as an index into this file to obtain its WordNet sense number, the database byte offset of the synset containing the sense, and the number of times it has been tagged in the semantic concordance texts.

Concatenating the lemma and lex_sense fields of a semantically tagged word (represented in a <wf ... > attribute/value pair) in a semantic concordance file, using % as the concatenation character, creates the sense_key for that sense, which can in turn be used to search the sense index file.

A sense_key is the best way to represent a sense in semantic tagging or other systems that refer to WordNet senses. sense_keys are independent of WordNet sense numbers and synset_offsets, which vary between versions of the database. Using the sense index and a sense_key, the corresponding synset (via the synset_offset) and WordNet sense number can easily be obtained. A mapping from noun sense_keys in WordNet 1.6 to corresponding 2.0 sense_keys is provided with version 2.0, and is described in sensemap(5).

See wndb(5) for a thorough discussion of the WordNet database files.

### File Format
The sense index file lists all of the senses in the WordNet database with each line representing one sense. The file is in alphabetical order, fields are separated by one space, and each line is terminated with a newline character.

Each line is of the form:

sense_key synset_offset sense_number tag_cnt

sense_key is an encoding of the word sense. Programs can construct a sense key in this format and use it as a binary search key into the sense index file. The format of a sense_key is described below.

synset_offset is the byte offset that the synset containing the sense is found at in the database "data" file corresponding to the part of speech encoded in the sense_key. synset_offset is an 8 digit, zero-filled decimal integer, and can be used with fseek(3) to read a synset from the data file. When passed to the WordNet library function read_synset() along with the syntactic category, a data structure containing the parsed synset is returned.

sense_number is a decimal integer indicating the sense number of the word, within the part of speech encoded in sense_key, in the WordNet database. See wndb(5) for information about how sense numbers are assigned.

tag_cnt represents the decimal number of times the sense is tagged in various semantic concordance texts. A tag_cnt of 0 indicates that the sense has not been semantically tagged.

### Sense Key Encoding
A sense_key is represented as:

lemma%lex_sense

where lex_sense is encoded as:

ss_type:lex_filenum:lex_id:head_word:head_id

lemma is the ASCII text of the word or collocation as found in the WordNet database index file corresponding to pos. lemma is in lower case, and collocations are formed by joining individual words with an underscore (_) character.

ss_type is a one digit decimal integer representing the synset type for the sense. See Synset Type below for a listing of the numbers corresponding to each synset type.

lex_filenum is a two digit decimal integer representing the name of the lexicographer file containing the synset for the sense. See lexnames(5) for the list of lexicographer file names and their corresponding numbers.

lex_id is a two digit decimal integer that, when appended onto lemma, uniquely identifies a sense within a lexicographer file. lex_id numbers usually start with 00, and are incremented as additional senses of the word are added to the same file, although there is no requirement that the numbers be consecutive or begin with 00. Note that a value of 00 is the default, and therefore is not present in lexicographer files. Only non-default lex_id values must be explicitly assigned in lexicographer files. See wninput(5) for information on the format of lexicographer files.

head_word is only present if the sense is in an adjective satellite synset. It is the lemma of the first word of the satellite's head synset.

head_id is a two digit decimal integer that, when appended onto head_word, uniquely identifies the sense of head_word within a lexicographer file, as described for lex_id. There is a value in this field only if head_word is present.

### Synset Type
The synset type is encoded as follows:

```
1	NOUN
2	VERB
3	ADJECTIVE
4	ADVERB
5	ADJECTIVE SATELLITE
```

## NOTES
For non-satellite senses the head_word and head_id fields have no values, however the field separator character (:) is present.

## ENVIRONMENT VARIABLES (UNIX)
WNHOME

Base directory for WordNet. Default is /usr/local/WordNet-3.0.

WNSEARCHDIR

Directory in which the WordNet database has been installed. Default is WNHOME/dict.

## REGISTRY (WINDOWS)
HKEY_LOCAL_MACHINE\SOFTWARE\WordNet\3.0\WNHome

Base directory for WordNet. Default is C:\Program Files\WordNet\3.0.

## FILES
index.sense

sense index

## SEE ALSO
binsrch(3), wnsearch(3), lexnames(5), wnintro(5), sensemap(5), wndb(5), wninput(5).


title: wpa_supplicant.conf(5)

summary: configuration file for wpa_supplicant

text:
# wpa_supplicant.conf(5)

## NAME
wpa_supplicant.conf - configuration file for wpa_supplicant

## OVERVIEW
wpa_supplicant is configured using a text file that lists all accepted networks and security policies, including pre-shared keys. See the example configuration file, probably in /usr/share/doc/wpa_supplicant/, for detailed information about the configuration format and supported fields.

All file paths in this configuration file should use full (absolute, not relative to working directory) path in order to allow working directory to be changed. This can happen if wpa_supplicant is run in the background.

Changes to configuration file can be reloaded be sending SIGHUP signal to wpa_supplicant ('killall -HUP wpa_supplicant'). Similarly, reloading can be triggered with the wpa_cli reconfigure command.

Configuration file can include one or more network blocks, e.g., one for each used SSID. wpa_supplicant will automatically select the best network based on the order of network blocks in the configuration file, network security level (WPA/WPA2 is preferred), and signal strength.

## QUICK EXAMPLES
1.

WPA-Personal (PSK) as home network and WPA-Enterprise with EAP-TLS as work network.

```
# allow frontend (e.g., wpa_cli) to be used by all users in 'wheel' group
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
#
# home network; allow all valid ciphers
network={
	ssid="home"
	scan_ssid=1
	key_mgmt=WPA-PSK
	psk="very secret passphrase"
}
#
# work network; use EAP-TLS with WPA; allow only CCMP and TKIP ciphers
network={
	ssid="work"
	scan_ssid=1
	key_mgmt=WPA-EAP
	pairwise=CCMP TKIP
	group=CCMP TKIP
	eap=TLS
	identity="user@example.com"
	ca_cert="/etc/cert/ca.pem"
	client_cert="/etc/cert/user.pem"
	private_key="/etc/cert/user.prv"
	private_key_passwd="password"
}
```

2.

WPA-RADIUS/EAP-PEAP/MSCHAPv2 with RADIUS servers that use old peaplabel (e.g., Funk Odyssey and SBR, Meetinghouse Aegis, Interlink RAD-Series)

```
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
network={
	ssid="example"
	scan_ssid=1
	key_mgmt=WPA-EAP
	eap=PEAP
	identity="user@example.com"
	password="foobar"
	ca_cert="/etc/cert/ca.pem"
	phase1="peaplabel=0"
	phase2="auth=MSCHAPV2"
}
```

3.

EAP-TTLS/EAP-MD5-Challenge configuration with anonymous identity for the unencrypted use. Real identity is sent only within an encrypted TLS tunnel.

```
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
network={
	ssid="example"
	scan_ssid=1
	key_mgmt=WPA-EAP
	eap=TTLS
	identity="user@example.com"
	anonymous_identity="anonymous@example.com"
	password="foobar"
	ca_cert="/etc/cert/ca.pem"
	phase2="auth=MD5"
}
```

4.

IEEE 802.1X (i.e., no WPA) with dynamic WEP keys (require both unicast and broadcast); use EAP-TLS for authentication

```
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
network={
	ssid="1x-test"
	scan_ssid=1
	key_mgmt=IEEE8021X
	eap=TLS
	identity="user@example.com"
	ca_cert="/etc/cert/ca.pem"
	client_cert="/etc/cert/user.pem"
	private_key="/etc/cert/user.prv"
	private_key_passwd="password"
	eapol_flags=3
}
```

5.

Catch all example that allows more or less all configuration modes. The configuration options are used based on what security policy is used in the selected SSID. This is mostly for testing and is not recommended for normal use.

```
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
network={
	ssid="example"
	scan_ssid=1
	key_mgmt=WPA-EAP WPA-PSK IEEE8021X NONE
	pairwise=CCMP TKIP
	group=CCMP TKIP WEP104 WEP40
	psk="very secret passphrase"
	eap=TTLS PEAP TLS
	identity="user@example.com"
	password="foobar"
	ca_cert="/etc/cert/ca.pem"
	client_cert="/etc/cert/user.pem"
	private_key="/etc/cert/user.prv"
	private_key_passwd="password"
	phase1="peaplabel=0"
	ca_cert2="/etc/cert/ca2.pem"
	client_cert2="/etc/cer/user.pem"
	private_key2="/etc/cer/user.prv"
	private_key2_passwd="password"
}
```

6.

Authentication for wired Ethernet. This can be used with wired or roboswitch interface (-Dwired or -Droboswitch on command line).

```
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
ap_scan=0
network={
	key_mgmt=IEEE8021X
	eap=MD5
	identity="user"
	password="password"
	eapol_flags=0
}
```

## CERTIFICATES
Some EAP authentication methods require use of certificates. EAP-TLS uses both server side and client certificates whereas EAP-PEAP and EAP-TTLS only require the server side certificate. When client certificate is used, a matching private key file has to also be included in configuration. If the private key uses a passphrase, this has to be configured in wpa_supplicant.conf ("private_key_passwd").

wpa_supplicant supports X.509 certificates in PEM and DER formats. User certificate and private key can be included in the same file.

If the user certificate and private key is received in PKCS#12/PFX format, they need to be converted to suitable PEM/DER format for wpa_supplicant. This can be done, e.g., with following commands:

```
# convert client certificate and private key to PEM format
openssl pkcs12 -in example.pfx -out user.pem -clcerts
# convert CA certificate (if included in PFX file) to PEM format
openssl pkcs12 -in example.pfx -out ca.pem -cacerts -nokeys
```

## SEE ALSO
wpa_supplicant(8) openssl(1)


wvdial.conf

package: wvdial

title: wvdial.conf(5)

summary: wvdial configuration file

text:
# wvdial.conf(5)

## NAME
wvdial.conf - wvdial configuration file

## DESCRIPTION
When wvdial starts, it first loads its configuration from /etc/wvdial.conf, which contains basic information about the modem port, speed, and init string, along with information about your Internet Service Provider (ISP), such as the phone number, your username, and your password.

The configuration file /etc/wvdial.conf is in Windows "ini" file format, with sections named in square brackets and a number of variable = value pairs within each section.

Here is a sample configuration file:

[Dialer Defaults]

Modem = /dev/ttyS2

Baud = 57600

Init = ATZ

Init2 = AT S11=50

Phone = 555-4242

Username = apenwarr

Password = my-password [Dialer phone2]

Phone = 555-4243

[Dialer shh]

Init3 = ATM0

[Dialer pulse]

Dial Command = ATDP

The sample configuration file above contains all of the options necessary to run the two sample command lines given above. Here is a complete list of settings that wvdial understands:

Modem

The location of the device that wvdial should use as your modem. The default is /dev/modem.

Baud

The speed at which wvdial will communicate with your modem. The default is 57600 baud.

Init1 ... Init9

wvdial can use up to nine initialization strings to set up your modem. Before dialing, these strings are sent to the modem in numerical order. These are particularly useful when specifying multiple sections. See above for an example that uses Init3 to turn the modem's speaker off. The default is "ATZ" for Init1.

Phone

The phone number you want wvdial to dial. You can add up to 4 other phone numbers that wvdial will dial in order, by adding:

Phone1

Phone2

Phone3

Phone4

Dial Prefix

wvdial will insert this string after the dial command and before the phone number. For example, to disable call waiting (in North America, anyway) set this to "*70,".

Dial Command

wvdial will use this string to tell the modem to dial. The default is "ATDP".

Login

You must set this to the username you use at your ISP.

Login Prompt

If your ISP has an unusual login procedure that wvdial is unable to figure out, you can use this option to specify a login prompt. When this prompt is received from your ISP, wvdial will send the Login string.

Password

You must set this to the password you use at your ISP.

Ask Password

By setting this option wvdial will prompt for your password on every dialin. Thus you don't have to save your password in /etc/wvdial.conf. (Option added by SuSE.)

Password Prompt

If your ISP has an unusual login procedure that wvdial is unable to figure out, you can use this option to specify a password prompt. When this prompt is received from you ISP, wvdial will send the Password string.

PPPD Path

If your system has pppd somewhere other than /usr/sbin/pppd, you will need to set this option.

Auto DNS

Try to get the Domain Nameserver (DNS) from the provider. This option is "on" by default. (Option added by SuSE.)

Check DNS

Check the Domain Nameserver (DNS) after the connection has been set up. This option is "on" by default. (Option added by SuSE.)

DNS Test1

First DNS lookup for DNS check. (Option added by SuSE.)

DNS Test2

Second DNS lookup for DNS check. (Option added by SuSE.)

Check Def Route

Check the default route after the connection has been set up. This option is "on" by default. (Option added by SuSE.)

Force Address

This option only applies if you have a static IP address at your ISP, and even then you probably don't need it. Some ISP's don't send the IP address as part of the PPP negotiation. This option forces pppd to use the address you give it.

Remote Name

If your ISP uses PAP or CHAP authentication, you might need to change this to your ISP's authentication name. In most cases, however, it's safe to use the default value, "*".

Carrier Check

wvdial checks your modem during the connection process to ensure that it is actually online. If you have a weird modem that insists its carrier line is always down, you can disable the carrier check by setting this option to "no".

Stupid Mode

When wvdial is in Stupid Mode, it does not attempt to interpret any prompts from the terminal server. It starts pppd immediately after the modem connects. Apparently there are ISP's that actually give you a login prompt, but work only if you start PPP, rather than logging in. Go figure. Stupid Mode is (naturally) disabled by default.

New PPPD

You need this option if you have pppd version 2.3.0 or newer, to make wvdial create the file /etc/ppp/peers/wvdial. This option is enabled by default, thus if you have older pppd you need to set it to `no' (or upgrade pppd).

Default Reply

When wvdial detects a prompt, and it hasn't seen any clues that indicate what it should send as a response to the prompt, it defaults to sending "ppp". Sometimes this is inadequate. Use this option to override wvdial's default prompt response.

Auto Reconnect

If enabled, wvdial will attempt to automatically reestablish a connection if you are randomly disconnected by the other side. This option is "on" by default.

Idle Seconds

Set the hangup timeout in seconds. If there is inactivity for the given time the connection is shut down. A hangup timeout of 0 disables this feature.

Abort on Busy

If enabled, wvdial will not retry the connection if the modem says that the line is busy. This option is "off" by default.

Abort on No Dialtone

If enabled, wvdial will not retry the connection if the modem says that there is no dialtone. This option is "on" by default.

Dial Attempts

If value is set, wvdial will quit after that many tries .If set to 0, wvdial will happily keep dialling forever.

Dial Timeout

The maximum time in seconds that wvdial will wait for a connection to be made. Default value is 60 seconds.

The wvdialconf(1) program can be used to detect your modem and fill in the Modem, Baud, and Init/Init2 options automatically.

## AUTHORS
Dave Coombs and Avery Pennarun for Net Integration Technologies Inc. Great contributions have been made by many people, including SuSE and RedHat. Thanks guys!

## SEE ALSO
wvdial(1), wvdialconf(1), pppd(8).


title: x2goserver.conf(5)

summary: X2Go Server Main Configuration File

text:
# x2goserver.conf(5)

## NAME
x2goserver.conf - X2Go Server Main Configuration File

## SYNOPSIS

x2goserver.conf

## DESCRIPTION
x2goserver.conf is the main configuration file for X2Go Server and the X2Go::Server Perl API.

## SECTIONS
The x2goserver.conf's configuration file format is an INI-based configuration format. It falls apart into sections and options with their values.

[section1]

sec1option1 = valueA

sec1option2 = valueB

...

[section2]

sec2option1 = valueC

sec2option2 = valueD

...

## SECTION [limit users]
In this section you can list up Posix users known to the system and specify the max. number of allowed simultaneous X2Go sessions in an X2Go Server farm.

## SECTION [limit groups]
In this section you can list up Posix group names known to the system and specify the max. number of allowed simultaneous X2Go sessions in an X2Go Server farm. The session limitation applies to all users in the specified groups.

If individual users are listed in section [limit users] and some of their groups are listed in section [limit groups], then the maximum value of allowed sessions will be chosen.

If a user is a member of several of the specified groups under section [limit groups], then the number of allowed simultaneous X2Go sessions for a certain user will be derived from the group with the most allowed sessions found under this section.

## SECTION [log]
The [log]'s section only option is the loglevel option. Allowed values are:

emerg, alert, crit, err, warning, notice, info, debug.

The loglevel option controls the verbosity of the X2Go::Server Perl functions. The log output appears via LOCAL7 (normally: /var/log/syslog).

## EXAMPLE
The below configuration file is the default after installation of X2Go Server:

[limit users]

\#user-foo=1

[limit groups]

\#bar-group=1

[log]

\# possible levels are:

\# emerg, alert, crit, err, warning, notice, info, debug

loglevel=notice

## AUTHOR
This manual has been written by Mike Gabriel <mike.gabriel@das-netzwerkteam.de> for the X2Go project (https://www.x2go.org).


portals.conf

package: xdg-desktop-portal

title: portals.conf(5)

summary: XDG desktop portal configuration

text:
# portals.conf(5)

## NAME
portals.conf - XDG desktop portal configuration

## SYNOPSIS
$XDG_CONFIG_HOME/xdg-desktop-portal/{*-}portals.conf

$XDG_CONFIG_DIRS/xdg-desktop-portal/{*-}portals.conf

/etc/xdg-desktop-portal/{*-}portals.conf

$XDG_DATA_HOME/xdg-desktop-portal/{*-}portals.conf

$XDG_DATA_DIRS/xdg-desktop-portal/{*-}portals.conf

/usr/share/xdg-desktop-portal/{*-}portals.conf

## DESCRIPTION
xdg-desktop-portal uses a configuration file to determine which portal backend should be used to provide the implementation for the requested interface. This mechanism is very similar to the freedesktop.org specification for "Association between MIME types and applications" (mime-apps).

Desktop environments and OS vendors should provide a default configuration for their chosen portal backends in /usr/share/xdg-desktop-portal/DESKTOP-portals.conf, where DESKTOP is the desktop environment name as it would appear in the XDG_CURRENT_DESKTOP environment variable, after case-folding ASCII upper case to lower case. For example, KDE should provide /usr/share/xdg-desktop-portal/kde-portals.conf.

Users can override those defaults, or provide configuration for an otherwise unsupported desktop environment, by writing a file ~/.config/xdg-desktop-portal/portals.conf. Users of more than one desktop environment can use desktop-specific filenames such as kde-portals.conf which will only be used in the appropriate desktop environment.

Similarly, system administrators can provide a default configuration for all users in /etc/xdg-desktop-portal/DESKTOP-portals.conf or /etc/xdg-desktop-portal/portals.conf.

The following locations are searched for configuration, highest precedence first:

- $XDG_CONFIG_HOME, defaulting to ~/.config

- each directory in $XDG_CONFIG_DIRS, defaulting to /etc/xdg

- the build-time sysconfdir for xdg-desktop-portal, usually /etc

- $XDG_DATA_HOME, defaulting to ~/.local/share (searched only for consistency with other specifications, writing configuration here is not recommended)

- each directory in $XDG_DATA_DIRS, defaulting to /usr/local/share:/usr/share

- the build-time datadir for xdg-desktop-portal, usually /usr/share

In each of those locations, for each desktop environment name listed in the XDG_CURRENT_DESKTOP environment variable, xdg-desktop-portal checks for xdg-desktop-portal/DESKTOP-portals.conf, where DESKTOP is the desktop environment name in lower-case. If a desktop-environment-specific configuration file is not found, a non-desktop-specific file xdg-desktop-portal/portals.conf will be read. For example, if XDG_CURRENT_DESKTOP is set to Budgie:GNOME, then xdg-desktop-portal will look for xdg-desktop-portal/budgie-portals.conf, xdg-desktop-portal/gnome-portals.conf and xdg-desktop-portal/portals.conf in that order.

Only the first configuration file found is read, and lower-precedence configuration files are ignored. All possible configuration files within one directory are tried before moving on to the next directory, so for example ~/.config/xdg-desktop-portal/portals.conf is higher-precedence than /usr/share/xdg-desktop-portal/kde-portals.conf.

### FILE FORMAT
The format of the portals configuration file is the same .ini format used by systemd unit files or application desktop files.

[preferred]

The main configuration group for preferred portals.

The following keys can be present in the preferred group:

default (string)

The default portal backend to use for every interface, unless the interface is listed explicitly.

org.freedesktop.impl.portal.* (string)

One of the valid portal interface implementations exposed by xdg-desktop-portal.

Each key in the group contains a semi-colon separated list of portal backend implementation, to be searched for an implementation of the requested interface, in the same order as specified in the configuration file. Additionally, the special values none and * can be used:

none

Do not provide a portal implementation for this interface.

*

Use the first portal implementation found, in lexicographical order.

### EXAMPLE

```
[preferred]
# Use xdg-desktop-portal-gtk for every portal interface...
default=gtk
# ... except for the ScreenCast interface
org.freedesktop.impl.portal.ScreenCast=gnome
```

### ENVIRONMENT
XDG_CURRENT_DESKTOP

A colon-separated list of desktop environments, most specific first, used to choose a desktop-specific portal configuration. The default is an empty list.

XDG_CONFIG_HOME

The per-user portals.conf file is located in this directory. The default is $HOME/.config.

XDG_CONFIG_DIRS

A colon-separated list of system configuration directories and secondary per-user configuration directories. The default is /etc/xdg.

XDG_DATA_HOME

A per-user data directory, searched for consistency with other specifications. The default is $HOME/.local/share.

XDG_DATA_DIRS

A colon-separated list of system data directories and secondary per-user data directories. The default is /usr/local/share:/usr/share.

### SEE ALSO

- XDG Base Directory Specification

- XDG Desktop Entry specification

- XDG Association between MIME type and applications specification


xdg-desktop-portal-wlr

package: xdg-desktop-portal-wlr

title: xdg-desktop-portal-wlr(5)

text:
# xdg-desktop-portal-wlr(5)

## NAME
xdg-desktop-portal-wlr - an xdg-desktop-portal backend for wlroots

## DESCRIPTION
xdg-desktop-portal-wlr (or xdpw for short) allows applications to request screenshots and screencasts via xdg-desktop-portal in wlroots-based Wayland compositors.

xdpw will try to load the configuration file from these locations:

•$XDG_CONFIG_HOME/xdg-desktop-portal-wlr/$XDG_CURRENT_DESKTOP

•$XDG_CONFIG_HOME/xdg-desktop-portal-wlr/config

•/etc/xdg/xdg-desktop-portal-wlr/$XDG_CURRENT_DESKTOP

•/etc/xdg/xdg-desktop-portal-wlr/config

$XDG_CONFIG_HOME defaults to ~/.config. $XDG_CURRENT_DESKTOP can be a colon separated list. Each element of that list will be tried.

The configuration files use the INI file format. Example:

```
[screencast]
output_name=HDMI-A-1
max_fps=30
exec_before=disable_notifications.sh
exec_after=enable_notifications.sh
chooser_type=simple
chooser_cmd=slurp -f %o -or
```

## SCREENCAST OPTIONS
These options need to be placed under the [screencast] section.

output_name = name

Select which output will be screencast. This option is used with chooser_type = none. The list of available outputs can be obtained via wayland-info(1) (under the wl_output section).

max_fps = limit

Limit the number of frames per second to the provided rate. This is useful to reduce CPU usage when capturing frames at the output's refresh rate is unnecessary.

exec_before = command

Execute command before starting a screencast. The command will be executed within sh.

exec_after = command

Execute command after ending all screencasts. The command will be executed within sh.

chooser_cmd = command

Run this command to select an output. For more details see OUTPUT CHOOSER.

chooser_type = type

Specifies the input send to the chooser. The supported types are:

•default: xdpw will try to use the first chooser found in the list of hardcoded choosers (slurp, wofi, bemenu) and will fallback to an arbitrary output if none of those were found.

•none: xdpw will allow screencast either on the output given by output_name, or if empty an arbitrary output without further interaction.

•simple, dmenu: xdpw will launch the chooser given by chooser_cmd. For more details see OUTPUT CHOOSER.

force_mod_linear = bool

Force buffers with implicit modifiers to be linear (experimental) Setting this option to 1 will force xdpw to allocate dma-bufs with implicit modifier as linear. This option shouldn't be required on single gpu setups, but can increase compatibility especially on setups with multiple gpus.

This option is experimental and can be removed or replaced in future versions.

### OUTPUT CHOOSER
The chooser can be any program or script with the following behaviour:

•It returns any error code except 127. The error code 127 is internally used to signal that no command could be found and all output from it will be ignored.

•It returns the name of a valid output on stdout as given by wayland-info(1). Everything else will be handled as declined by the user.

•To signal that the user has declined screencast, the chooser should exit without anything on stdout.

Supported types of choosers via the chooser_type option:

•simple: the chooser is just called without anything further on stdin.

•dmenu: the chooser receives a newline separated list (dmenu style) of outputs on stdin.

## SEE ALSO
pipewire(1)


user-dirs.conf

package: xdg-user-dirs

title: user-dirs.conf(5)

summary: configuration for xdg\-user\-dirs\-update

text:
# user-dirs.conf(5)

## NAME
user-dirs.conf - configuration for xdg-user-dirs-update

## DESCRIPTION
The /etc/xdg/user-dirs.conf file is a text file that controls the behavior of the xdg-user-dirs-update command. Users can have their own ~/.config/user-dirs.conf file, which overrides the system-wide configuration.

The following keys are recognised:

enabled=boolean

When set to False, xdg-user-dirs-update will not change the XDG user dirs configuration.

filename_encoding=encoding

This sets the filename encoding to use. encoding can be an explicit encoding name, such as UTF-8, or "locale", which means the encoding of the users locale will be used.

Lines beginning with a # character are ignored.

## ENVIRONMENT
XDG_CONFIG_DIRS

The system-wide user-dirs.conf file is located in this directory. The default is /etc/xdg.

XDG_CONFIG_HOME

The per-user user-dirs.conf file is located in this directory. The default is $HOME/.config.

## SEE ALSO
xdg-user-dirs-update(1)


user-dirs.defaults

title: user-dirs.defaults(5)

summary: default settings for XDG user dirs

text:
# user-dirs.defaults(5)

## NAME
user-dirs.defaults - default settings for XDG user dirs

## DESCRIPTION
The /etc/xdg/user-dirs.defaults file is a text file that contains the default values for the XDG user dirs which are used by the xdg-user-dirs-update command.

This file contains lines of the form

```
NAME=VALUE
```

The following names are recognised:

DESKTOP

DOWNLOAD

TEMPLATES

PUBLICSHARE

DOCUMENTS

MUSIC

PICTURES

VIDEOS

The values are relative pathnames from the home directory and will be translated on a per-path-element basis into the users locale.

Lines beginning with a # character are ignored.

## ENVIRONMENT
XDG_CONFIG_DIRS

The user-dirs.defaults file is located in this directory. The default is /etc/xdg.

## SEE ALSO
xdg-user-dirs-update(1)


user-dirs.dirs

title: user-dirs.dirs(5)

summary: settings for XDG user dirs

text:
# user-dirs.dirs(5)

## NAME
user-dirs.dirs - settings for XDG user dirs

## DESCRIPTION
The $HOME/.config/user-dirs.dirs file is a text file that contains the user-specific values for the XDG user dirs. It is created and updated by the xdg-user-dirs-update command.

This file contains lines of the form

```
XDG_NAME_DIR=VALUE
```

The following names are recognised:

DESKTOP

DOWNLOAD

TEMPLATES

PUBLICSHARE

DOCUMENTS

MUSIC

PICTURES

VIDEOS

VALUE must be of the form "$HOME/Path" or "/Path".

Lines beginning with a # character are ignored.

The format of user-dirs.dirs is designed to allow direct sourcing of this file in shell scripts.

## ENVIRONMENT
XDG_CONFIG_DIRS

The user-dirs.defaults file is located in this directory. The default is /etc/xdg.

## SEE ALSO
xdg-user-dirs-update(1)


projects

package: xfsprogs

title: projects(5)

summary: persistent project root definition

text:
# projects(5)

## NAME
projects - persistent project root definition

## DESCRIPTION
The /etc/projects file provides a mapping between numeric project identifiers and those directories which are the roots of the quota tree. Its format is simply:

```
# comments are hash-prefixed
# ...
10:/export/cage
42:/var/log
```

The /etc/projects file is optional, instead xfs_quota(8) can be used with the -p argument to specify a project root directly for each operation.

## SEE ALSO
xfs_quota(8), xfsctl(3), projid(5).


projid

title: projid(5)

summary: the project name mapping file

text:
# projid(5)

## NAME
projid - the project name mapping file

## DESCRIPTION
The /etc/projid file provides a mapping between numeric project identifiers and a simple human readable name (similar relationship to the one that exists between usernames and uids). Its format is simply:

```
# comments are hash-prefixed
# ...
cage:10
logfiles:42
```

This file is optional, if a project identifier cannot be mapped to a name, it will be parsed and displayed as a numeric value.

## SEE ALSO
xfs_quota(8), xfsctl(3), projects(5).


xfs

title: xfs(5)

text:
# xfs(5)

## NAME
xfs - layout, mount options, and supported file attributes for the XFS filesystem

## DESCRIPTION
An XFS filesystem can reside on a regular disk partition or on a logical volume. An XFS filesystem has up to three parts: a data section, a log section, and a realtime section. Using the default mkfs.xfs(8) options, the realtime section is absent, and the log area is contained within the data section. The log section can be either separate from the data section or contained within it. The filesystem sections are divided into a certain number of blocks, whose size is specified at mkfs.xfs(8) time with the -b option.

The data section contains all the filesystem metadata (inodes, directories, indirect blocks) as well as the user file data for ordinary (non-realtime) files and the log area if the log is internal to the data section. The data section is divided into a number of allocation groups. The number and size of the allocation groups are chosen by mkfs.xfs(8) so that there is normally a small number of equal-sized groups. The number of allocation groups controls the amount of parallelism available in file and block allocation. It should be increased from the default if there is sufficient memory and a lot of allocation activity. The number of allocation groups should not be set very high, since this can cause large amounts of CPU time to be used by the filesystem, especially when the filesystem is nearly full. More allocation groups are added (of the original size) when xfs_growfs(8) is run.

The log section (or area, if it is internal to the data section) is used to store changes to filesystem metadata while the filesystem is running until those changes are made to the data section. It is written sequentially during normal operation and read only during mount. When mounting a filesystem after a crash, the log is read to complete operations that were in progress at the time of the crash.

The realtime section is used to store the data of realtime files. These files had an attribute bit set through xfsctl(3) after file creation, before any data was written to the file. The realtime section is divided into a number of extents of fixed size (specified at mkfs.xfs(8) time). Each file in the realtime section has an extent size that is a multiple of the realtime section extent size.

Each allocation group contains several data structures. The first sector contains the superblock. For allocation groups after the first, the superblock is just a copy and is not updated after mkfs.xfs(8). The next three sectors contain information for block and inode allocation within the allocation group. Also contained within each allocation group are data structures to locate free blocks and inodes; these are located through the header structures.

Each XFS filesystem is labeled with a Universal Unique Identifier (UUID). The UUID is stored in every allocation group header and is used to help distinguish one XFS filesystem from another, therefore you should avoid using dd(1) or other block-by-block copying programs to copy XFS filesystems. If two XFS filesystems on the same machine have the same UUID, xfsdump(8) may become confused when doing incremental and resumed dumps. xfsdump(8) and xfsrestore(8) are recommended for making copies of XFS filesystems. To mount a snapshot of an already-mounted filesystem, you may need to supply the nouuid option to mount (8).

## OPERATIONS
Some functionality specific to the XFS filesystem is accessible to applications through the xfsctl(3) and by-handle (see open_by_handle(3)) interfaces.

## MOUNT OPTIONS
The following XFS-specific mount options may be used when mounting an XFS filesystem. Other generic options may be used as well; refer to the mount(8) manual page for more details.

allocsize=size

Sets the buffered I/O end-of-file preallocation size when doing delayed allocation writeout. Valid values for this option are page size (typically 4KiB) through to 1GiB, inclusive, in power-of-2 increments. The default behavior is for dynamic end-of-file preallocation size, which uses a set of heuristics to optimise the preallocation size based on the current allocation patterns within the file and the access patterns to the file. Specifying a fixed allocsize value turns off the dynamic behavior.

attr2|noattr2

Note: These options have been deprecated as of kernel v5.10; The noattr2 option will be removed no earlier than in September 2025 and attr2 option will be immutable default. The options enable/disable an "opportunistic" improvement to be made in the way inline extended attributes are stored on-disk. When the new form is used for the first time when attr2 is selected (either when setting or removing extended attributes) the on-disk superblock feature bit field will be updated to reflect this format being in use.

The default behavior is determined by the on-disk feature bit indicating that attr2 behavior is active. If either mount option it set, then that becomes the new default used by the filesystem.

CRC enabled filesystems always use the attr2 format, and so will reject the noattr2 mount option if it is set.

dax=value

Set CPU direct access (DAX) behavior for the current filesystem. This mount option accepts the following values: "dax=inode" DAX will be enabled only on regular files with FS_XFLAG_DAX applied.

"dax=never" DAX will not be enabled for any files. FS_XFLAG_DAX will be ignored.

"dax=always" DAX will be enabled for all regular files, regardless of the FS_XFLAG_DAX state.

If no option is used when mounting a filesystem stored on a DAX capable device, dax=inode will be used as default.

For details regarding DAX behavior in kernel, please refer to kernel's documentation at filesystems/dax.txt

discard|nodiscard

Enable/disable the issuing of commands to let the block device reclaim space freed by the filesystem. This is useful for SSD devices, thinly provisioned LUNs and virtual machine images, but may have a performance impact. Note: It is currently recommended that you use the fstrim application to discard unused blocks rather than the discard mount option because the performance impact of this option is quite severe. For this reason, nodiscard is the default.

grpid|bsdgroups|nogrpid|sysvgroups

These options define what group ID a newly created file gets. When grpid is set, it takes the group ID of the directory in which it is created; otherwise it takes the fsgid of the current process, unless the directory has the setgid bit set, in which case it takes the gid from the parent directory, and also gets the setgid bit set if it is a directory itself.

filestreams

Make the data allocator use the filestreams allocation mode across the entire filesystem rather than just on directories configured to use it.

ikeep|noikeep

Note: These options have been deprecated as of kernel v5.10; The noikeep option will be removed no earlier than in September 2025 and ikeep option will be immutable default.

When ikeep is specified, XFS does not delete empty inode clusters and keeps them around on disk. When noikeep is specified, empty inode clusters are returned to the free space pool. noikeep is the default.

inode32|inode64

When inode32 is specified, it indicates that XFS limits inode creation to locations which will not result in inode numbers with more than 32 bits of significance. When inode64 is specified, it indicates that XFS is allowed to create inodes at any location in the filesystem, including those which will result in inode numbers occupying more than 32 bits of significance.

inode32 is provided for backwards compatibility with older systems and applications, since 64 bits inode numbers might cause problems for some applications that cannot handle large inode numbers. If applications are in use which do not handle inode numbers bigger than 32 bits, the inode32 option should be specified.

For kernel v3.7 and later, inode64 is the default.

largeio|nolargeio

If "nolargeio" is specified, the optimal I/O reported in st_blksize by stat(2) will be as small as possible to allow user applications to avoid inefficient read/modify/write I/O. This is typically the page size of the machine, as this is the granularity of the page cache. If "largeio" specified, a filesystem that was created with a "swidth" specified will return the "swidth" value (in bytes) in st_blksize. If the filesystem does not have a "swidth" specified but does specify an "allocsize" then "allocsize" (in bytes) will be returned instead. Otherwise the behavior is the same as if "nolargeio" was specified. nolargeio is the default.

logbufs=value

Set the number of in-memory log buffers. Valid numbers range from 2–8 inclusive. The default value is 8 buffers.

If the memory cost of 8 log buffers is too high on small systems, then it may be reduced at some cost to performance on metadata intensive workloads. The logbsize option below controls the size of each buffer and so is also relevant to this case.

logbsize=value

Set the size of each in-memory log buffer. The size may be specified in bytes, or in kibibytes (KiB) with a "k" suffix. If set manually, logbsize must be one of the specified valid sizes and a multiple of the log stripe unit - configured at mkfs time. Valid sizes for version 1 and version 2 logs are 16384 (value=16k) and 32768 (value=32k). Valid sizes for version 2 logs also include 65536 (value=64k), 131072 (value=128k) and 262144 (value=256k).

The default value for version 1 logs is 32768, while the default value for version 2 logs is max(32768, log_sunit) even if log_sunit does not match one of the valid values above.

logdev=device and rtdev=device

Use an external log (metadata journal) and/or real-time device. An XFS filesystem has up to three parts: a data section, a log section, and a real-time section. The real-time section is optional, and the log section can be separate from the data section or contained within it.

noalign

Data allocations will not be aligned at stripe unit boundaries. This is only relevant to filesystems created with non-zero data alignment parameters (sunit, swidth) by mkfs.

norecovery

The filesystem will be mounted without running log recovery. If the filesystem was not cleanly unmounted, it is likely to be inconsistent when mounted in "norecovery" mode. Some files or directories may not be accessible because of this. Filesystems mounted "norecovery" must be mounted read-only or the mount will fail.

nouuid

Don't check for double mounted file systems using the file system uuid. This is useful to mount LVM snapshot volumes, and often used in combination with "norecovery" for mounting read-only snapshots.

noquota

Forcibly turns off all quota accounting and enforcement within the filesystem.

uquota/usrquota/quota/uqnoenforce/qnoenforce

User disk quota accounting enabled, and limits (optionally) enforced. Refer to xfs_quota(8) for further details.

gquota/grpquota/gqnoenforce

Group disk quota accounting enabled and limits (optionally) enforced. Refer to xfs_quota(8) for further details.

pquota/prjquota/pqnoenforce

Project disk quota accounting enabled and limits (optionally) enforced. Refer to xfs_quota(8) for further details.

sunit=value and swidth=value

Used to specify the stripe unit and width for a RAID device or a stripe volume. "value" must be specified in 512-byte block units. These options are only relevant to filesystems that were created with non-zero data alignment parameters. The sunit and swidth parameters specified must be compatible with the existing filesystem alignment characteristics. In general, that means the only valid changes to sunit are increasing it by a power-of-2 multiple. Valid swidth values are any integer multiple of a valid sunit value.

Typically the only time these mount options are necessary if after an underlying RAID device has had it's geometry modified, such as adding a new disk to a RAID5 lun and reshaping it.

swalloc

Data allocations will be rounded up to stripe width boundaries when the current end of file is being extended and the file size is larger than the stripe width size.

wsync

When specified, all filesystem namespace operations are executed synchronously. This ensures that when the namespace operation (create, unlink, etc) completes, the change to the namespace is on stable storage. This is useful in HA setups where failover must not result in clients seeing inconsistent namespace presentation during or after a failover event.

## REMOVED MOUNT OPTIONS
The following mount options have been removed from the kernel, and will yield mount failures if specified. Mount options are deprecated for a significant period time prior to removal.

Name

Removed

----

-------

delaylog/nodelaylog

v4.0

ihashsize

v4.0

irixsgid

v4.0

osyncisdsync/osyncisosync

v4.0

barrier/nobarrier

v4.19

## FILE ATTRIBUTES
The XFS filesystem supports setting the following file attributes on Linux systems using the chattr(1) utility:

a - append only

A - no atime updates

d - no dump

i - immutable

S - synchronous updates

For descriptions of these attribute flags, please refer to the chattr(1) man page.

## SEE ALSO
chattr(1), xfsctl(3), mount(8), mkfs.xfs(8), xfs_info(8), xfs_admin(8), xfsdump(8), xfsrestore(8).


xinetd.conf

package: xinetd

title: xinetd.conf(5)

text:
# xinetd.conf(5)

## NAME
xinetd.conf - Extended Internet Services Daemon configuration file

## DESCRIPTION
xinetd.conf is the configuration file that determines the services provided by xinetd. Any line whose first non-white-space character is a '#' is considered a comment line. Empty lines are ignored.

The file contains entries of the form:

```
service <service_name>
{
```

```
<attribute> <assign_op> <value> <value> ...
...
```

```
}
```

The assignment operator, assign_op, can be one of '=', '+=', '-='. The majority of attributes support only the simple assignment operator, '='. Attributes whose value is a set of values support all assignment operators. For such attributes, '+=' means adding a value to the set and '-=' means removing a value from the set. A list of these attributes will be given after all the attributes are described.

Each entry defines a service identified by the service_name. The following is a list of available attributes:

id

This attribute is used to uniquely identify a service. This is useful because there exist services that can use different protocols and need to be described with different entries in the configuration file. By default, the service id is the same as the service name.

type

Any combination of the following values may be used:

RPC

if this is an RPC service

INTERNAL

if this is a service provided by xinetd.

TCPMUX/TCPMUXPLUS

if this is a service that will be started according to the RFC 1078 protocol on the TCPMUX well-known port. See the section describing TCPMUX services below.

UNLISTED

if this is a service not listed in a standard system file (like /etc/rpc for RPC services, or /etc/services for non-RPC services).

flags

Any combination of the following flags may be used:

INTERCEPT

Intercept packets or accepted connections in order to verify that they are coming from acceptable locations (internal or multi-threaded services cannot be intercepted).

NORETRY

Avoid retry attempts in case of fork failure.

IDONLY

Accept connections only when the remote end identifies the remote user (i.e. the remote host must run an identification server). This flag applies only to connection-based services. This flag is ineffective if the USERID log option is not used.

NAMEINARGS

This will cause the first argument in "server_args" to be argv[0] when executing the server, as specified in "server". This allows you to use tcpd by putting tcpd in "server" and the name of the server in "server_args" like in normal inetd.

NODELAY

If the service is a tcp service and the NODELAY flag is set, then the TCP_NODELAY flag will be set on the socket. If the service is not a tcp service, this option has no effect.

KEEPALIVE

If the service is a tcp service and the KEEPALIVE flag is set, then the SO_KEEPALIVE socket flag will be set on the socket. If the service is not a tcp service, this option has no effect.

NOLIBWRAP

This disables internal calling of the tcpwrap library to determine access to the service. This may be needed in order to use libwrap functionality not available to long-running processes such as xinetd; in this case, the tcpd program can be called explicitly (see also the NAMEINARGS flag). For RPC services using TCP transport, this flag is automatically turned on, because xinetd cannot get remote host address information for the rpc port.

SENSOR

This replaces the service with a sensor that detects accesses to the specified port. NOTE: It will NOT detect stealth scans. This flag should be used only on services that you know you don't need. When an access is made to this service's port, the IP Address is added to a global no_access list. This causes all subsequent accesses from the originating IP address to be denied access until the deny_time setting expires. The amount of time spent on this list is configurable as the deny_time attribute. The SENSOR flag will also cause xinetd to consider the server attribute to be INTERNAL no matter what is typed on the same line. Another important thing to remember is that if the socket_type is set to stream, then the wait attribute should be set to no.

IPv4

Sets the service to be an IPv4 service (AF_INET).

IPv6

Sets the service to be an IPv6 service (AF_INET6), if IPv6 is available on the system.

LABELED

The LABELED flag will tell xinetd to change the child processes SE Linux context to match that of the incoming connection as it starts the service. This only works for external tcp non-waiting servers and is an error if applied to an internal, udp, or tcp-wait server.

REUSE

The REUSE flag is deprecated. All services now implicitly use the REUSE flag.

disable

This is boolean "yes" or "no". This will result in the service being disabled and not starting. See the DISABLE flag description.

socket_type

Possible values for this attribute include:

stream

stream-based service

dgram

datagram-based service

raw

service that requires direct access to IP

seqpacket

service that requires reliable sequential datagram transmission

protocol

determines the protocol that is employed by the service. The protocol must exist in /etc/protocols. If this attribute is not defined, the default protocol employed by the service will be used.

wait

This attribute determines if the service is single-threaded or multi-threaded and whether or not xinetd accepts the connection or the server program accepts the connection. If its value is yes, the service is single-threaded; this means that xinetd will start the server and then it will stop handling requests for the service until the server dies and that the server software will accept the connection. If the attribute value is no, the service is multi-threaded and xinetd will keep handling new service requests and xinetd will accept the connection. It should be noted that udp/dgram services normally expect the value to be yes since udp is not connection oriented, while tcp/stream servers normally expect the value to be no.

user

determines the uid for the server process. The user attribute can either be numeric or a name. If a name is given (recommended), the user name must exist in /etc/passwd. This attribute is ineffective if the effective user ID of xinetd is not super-user.

group

determines the gid for the server process. The group attribute can either be numeric or a name. If a name is given (recommended), the group name must exist in /etc/group. If a group is not specified, the group of user will be used (from /etc/passwd). This attribute is ineffective if the effective user ID of xinetd is not super-user and if the groups attribute is not set to 'yes'.

instances

determines the number of servers that can be simultaneously active for a service (the default is no limit). The value of this attribute can be either a number or UNLIMITED which means that there is no limit.

nice

determines the server priority. Its value is a (possibly negative) number; check nice(3) for more information.

server

determines the program to execute for this service.

server_args

determines the arguments passed to the server. In contrast to inetd, the server name should not be included in server_args.

libwrap

overrides the service name passed to libwrap (which defaults to the server name, the first server_args component with NAMEINARGS, the id for internal services and the service name for redirected services). This attribute is only valid if xinetd has been configured with the libwrap option.

only_from

determines the remote hosts to which the particular service is available. Its value is a list of IP addresses which can be specified in any combination of the following ways:

a)

a numeric address in the form of %d.%d.%d.%d. If the rightmost components are 0, they are treated as wildcards (for example, 128.138.12.0 matches all hosts on the 128.138.12 subnet). 0.0.0.0 matches all Internet addresses. IPv6 hosts may be specified in the form of abcd:ef01::2345:6789. The rightmost rule for IPv4 addresses does not apply to IPv6 addresses.

b)

a factorized address in the form of %d.%d.%d.{%d,%d,...}. There is no need for all 4 components (i.e. %d.%d.{%d,%d,...%d} is also ok). However, the factorized part must be at the end of the address. This form does not work for IPv6 hosts.

c)

a network name (from /etc/networks). This form does not work for IPv6 hosts.

d)

a host name. When a connection is made to xinetd, a reverse lookup is performed, and the canonical name returned is compared to the specified host name. You may also use domain names in the form of .domain.com. If the reverse lookup of the client's IP is within .domain.com, a match occurs.

e)

an ip address/netmask range in the form of 1.2.3.4/32. IPv6 address/netmask ranges in the form of 1234::/46 are also valid.

Specifying this attribute without a value makes the service available to nobody.

no_access

determines the remote hosts to which the particular service is unavailable. Its value can be specified in the same way as the value of the only_from attribute. These two attributes determine the location access control enforced by xinetd. If none of the two is specified for a service, the service is available to anyone. If both are specified for a service, the one that is the better match for the address of the remote host determines if the service is available to that host (for example, if the only_from list contains 128.138.209.0 and the no_access list contains 128.138.209.10 then the host with the address 128.138.209.10 can not access the service).

access_times

determines the time intervals when the service is available. An interval has the form hour:min-hour:min (connections will be accepted at the bounds of an interval). Hours can range from 0 to 23 and minutes from 0 to 59.

log_type

determines where the service log output is sent. There are two formats:

SYSLOG syslog_facility [syslog_level]

The log output is sent to syslog at the specified facility. Possible facility names include: daemon, auth, authpriv, user, mail, lpr, news, uucp, ftp local0-7. Possible level names include: emerg, alert, crit, err, warning, notice, info, debug. If a level is not present, the messages will be recorded at the info level.

FILE file [soft_limit [hard_limit]]

The log output is appended to file which will be created if it does not exist. Two limits on the size of the log file can be optionally specified. The first limit is a soft one; xinetd will log a message the first time this limit is exceeded (if xinetd logs to syslog, the message will be sent at the alert priority level). The second limit is a hard limit; xinetd will stop logging for the affected service (if the log file is a common log file, then more than one service may be affected) and will log a message about this (if xinetd logs to syslog, the message will be sent at the alert priority level). If a hard limit is not specified, it defaults to the soft limit increased by 1% but the extra size must be within the parameters LOG_EXTRA_MIN and LOG_EXTRA_MAX which default to 5K and 20K respectively (these constants are defined in xconfig.h).

log_on_success

determines what information is logged when a server is started and when that server exits (the service id is always included in the log entry). Any combination of the following values may be specified:

PID

logs the server process id (if the service is implemented by xinetd without forking another process the logged process id will be 0)

HOST

logs the remote host address

USERID

logs the user id of the remote user using the RFC 1413 identification protocol. This option is available only for multi-threaded stream services.

EXIT

logs the fact that a server exited along with the exit status or the termination signal (the process id is also logged if the PID option is used)

DURATION

logs the duration of a service session

TRAFFIC

logs the total bytes in and out for a redirected service.

log_on_failure

determines what information is logged when a server cannot be started (either because of a lack of resources or because of access control restrictions). The service id is always included in the log entry along with the reason for failure. Any combination of the following values may be specified:

HOST

logs the remote host address.

USERID

logs the user id of the remote user using the RFC 1413 identification protocol. This option is available only for multi-threaded stream services.

ATTEMPT

logs the fact that a failed attempt was made (this option is implied by all others).

rpc_version

determines the RPC version for a RPC service. The version can be a single number or a range in the form number-number.

rpc_number

determines the number for an UNLISTED RPC service (this attribute is ignored if the service is not unlisted).

env

The value of this attribute is a list of strings of the form 'name=value'. These strings will be added to the environment before starting a server (therefore the server's environment will include xinetd's environment plus the specified strings).

passenv

The value of this attribute is a list of environment variables from xinetd's environment that will be passed to the server. An empty list implies passing no variables to the server except for those explicitly defined using the env attribute. (notice that you can use this attribute in conjunction with the env attribute to specify exactly what environment will be passed to the server).

port

determines the service port. If this attribute is specified for a service listed in /etc/services, it must be equal to the port number listed in that file.

redirect

Allows a tcp service to be redirected to another host. When xinetd receives a tcp connection on this port it spawns a process that establishes a connection to the host and port number specified, and forwards all data between the two hosts. This option is useful when your internal machines are not visible to the outside world. Syntax is: redirect = (ip address) (port). You can also use a hostname instead of the IP address in this field. The hostname lookup is performed only once, when xinetd is started, and the first IP address returned is the one that is used until xinetd is restarted. The "server" attribute is not required when this option is specified. If the "server" attribute is specified, this attribute takes priority.

bind

Allows a service to be bound to a specific interface on the machine. This means you can have a telnet server listening on a local, secured interface, and not on the external interface. Or one port on one interface can do something, while the same port on a different interface can do something completely different. Syntax: bind = (ip address of interface).

interface

Synonym for bind.

banner

Takes the name of a file to be splatted at the remote host when a connection to that service is established. This banner is printed regardless of access control. It should *always* be printed when a connection has been made. xinetd outputs the file as-is, so you must ensure the file is correctly formatted for the service's protocol. In paticular, if the protocol requires CR-LF pairs for line termination, you must supply them.

banner_success

Takes the name of a file to be splatted at the remote host when a connection to that service is granted. This banner is printed as soon as access is granted for the service. xinetd outputs the file as-is, so you must ensure the file is correctly formatted for the service's protocol. In paticular, if the protocol requires CR-LF pairs for line termination, you must supply them.

banner_fail

Takes the name of a file to be splatted at the remote host when a connection to that service is denied. This banner is printed immediately upon denial of access. This is useful for informing your users that they are doing something bad and they shouldn't be doing it anymore. xinetd outputs the file as-is, so you must ensure the file is correctly formatted for the service's protocol. In paticular, if the protocol requires CR-LF pairs for line termination, you must supply them.

per_source

Takes an integer or "UNLIMITED" as an argument. This specifies the maximum instances of this service per source IP address. This can also be specified in the defaults section.

cps

Limits the rate of incoming connections. Takes two arguments. The first argument is the number of connections per second to handle. If the rate of incoming connections is higher than this, the service will be temporarily disabled. The second argument is the number of seconds to wait before re-enabling the service after it has been disabled. The default for this setting is 50 incoming connections and the interval is 10 seconds.

max_load

Takes a floating point value as the load at which the service will stop accepting connections. For example: 2 or 2.5. The service will stop accepting connections at this load. This is the one minute load average. This is an OS dependent feature, and currently only Linux, Solaris, and FreeBSD are supported for this. This feature is only avaliable if xinetd was configured with the -with-loadavg option.

groups

Takes either "yes" or "no". If the groups attribute is set to "yes", then the server is executed with access to the groups that the server's effective UID has access to. Alternatively, if the group attribute is set, the server is executed with access to the groups specified. If the groups attribute is set to "no", then the server runs with no supplementary groups. This attribute must be set to "yes" for many BSD systems. This attribute can be set in the defaults section as well.

mdns

Takes either "yes" or "no". On systems that support mdns registration of services (currently only Mac OS X), this will enable or disable registration of the service. This defaults to "yes".

umask

Sets the inherited umask for the service. Expects an octal value. This option may be set in the "defaults" section to set a umask for all services. xinetd sets its own umask to the previous umask OR'd with 022. This is the umask that will be inherited by all child processes if the umask option is not used.

enabled

Takes a list of service ID's to enable. This will enable only the services listed as arguments to this attribute; the rest will be disabled. If you have 2 ftp services, you will need to list both of their ID's and not just ftp. (ftp is the service name, not the ID. It might accidentally be the ID, but you better check.) Note that the service "disable" attribute and "DISABLE" flag can prevent a service from being enabled despite being listed in this attribute.

include

Takes a filename in the form of "include /etc/xinetd/service". The file is then parsed as a new configuration file. It is not the same thing as pasting the file into xinetd.conf where the include directive is given. The included file must be in the same form as xinetd.conf. This may not be specified from within a service. It must be specified outside a service declaration.

includedir

Takes a directory name in the form of "includedir /etc/xinetd.d". Every file inside that directory, excluding files with names containing a dot ('.') or ending with a tilde ('~'), will be parsed as xinetd configuration files. The files will be parsed in alphabetical order according to the C locale. This allows you to specify services one per file within a directory. The includedir directive may not be specified from within a service declaration.

rlimit_as

Sets the Address Space resource limit for the service. One parameter is required, which is either a positive integer representing the number of bytes to set the limit to (K or M may be used to specify kilobytes/megabytes) or "UNLIMITED". Due to the way Linux's libc malloc is implemented, it is more useful to set this limit than rlimit_data, rlimit_rss and rlimit_stack. This resource limit is only implemented on Linux systems.

rlimit_cpu

Sets the maximum number of CPU seconds that the service may use. One parameter is required, which is either a positive integer representing the number of CPU seconds limit to, or "UNLIMITED".

rlimit_data

Sets the maximum data size resource limit for the service. One parameter is required, which is either a positive integer representing the number of bytes or "UNLIMITED".

rlimit_rss

Sets the maximum resident set size limit for the service. Setting this value low will make the process a likely candidate for swapping out to disk when memory is low. One parameter is required, which is either a positive integer representing the number of bytes or "UNLIMITED".

rlimit_stack

Set the maximum stack size limit for the service. One parameter is required, which is either a positive integer representing the number of bytes or "UNLIMITED".

deny_time

Sets the time span that access to all services on all IP addresses are denied to someone that sets off the SENSOR. The unit of time is in minutes. Valid options are: FOREVER, NEVER, and a numeric value. FOREVER causes the IP address not to be purged until xinetd is restarted. NEVER has the effect of just logging the offending IP address. A typical time value would be 60 minutes. This should stop most DOS attacks while allowing IP addresses that come from a pool to be recycled for legitimate purposes. This option must be used in conjunction with the SENSOR flag.

You don't need to specify all of the above attributes for each service. The necessary attributes for a service are:

socket_type

user

(non-internal services only)

server

(non-internal services only)

wait

protocol

(RPC and unlisted services only)

rpc_version

(RPC services only)

rpc_number

(unlisted RPC services only)

port

(unlisted non-RPC services only)

The following attributes support all assignment operators:

only_from

no_access

log_on_success

log_on_failure

passenv

env

(does not support the '-=' operator)

These attributes can also appear more than once in a service entry. The remaining attributes support only the '=' operator and can appear at most once in a service entry.

The configuration file may also contain a single defaults entry that has the form

```
defaults
{
```

```
<attribute> = <value> <value> ...
...
```

```
}
```

This entry provides default attribute values for service entries that don't specify those attributes. Possible default attributes:

log_type

(cumulative effect)

bind

per_source

umask

log_on_success

(cumulative effect)

log_on_failure

(cumulative effect)

only_from

(cumulative effect)

no_access

(cumulative effect)

passenv

(cumulative effect)

instances

disabled

(cumulative effect)

enabled

(cumulative effect)

banner

banner_success

banner_fail

per_source

groups

cps

max_load

Attributes with a cumulative effect can be specified multiple times with the values specified each time accumulating (i.e. '=' does the same thing as '+='). With the exception of disabled they all have the same meaning as if they were specified in a service entry. disabled determines services that are disabled even if they have entries in the configuration file. This allows for quick reconfiguration by specifying disabled services with the disabled attribute instead of commenting them out. The value of this attribute is a list of space separated service ids. enabled has the same properties as disabled. The difference being that enabled is a list of which services are to be enabled. If enabled is specified, only the services specified are available. If enabled is not specified, all services are assumed to be enabled, except those listed in disabled.

## INTERNAL SERVICES
xinetd provides the following services internally (both stream and datagram based): echo, time, daytime, chargen, and discard. These services are under the same access restrictions as all other services except for the ones that don't require xinetd to fork another process for them. Those ones (time, daytime, and the datagram-based echo, chargen, and discard) have no limitation in the number of instances.

## TCPMUX Services
xinetd supports TCPMUX services that conform to RFC 1078. These services may not have a well-known port associated with them, and can be accessed via the TCPMUX well-known port.

For each service that is to be accessed via TCPMUX, a service entry in /etc/xinetd.conf or in a configuration file in an includedir directory must exist.

The service_name field (as defined above for each service in any xinetd configuration file) must be identical to the string that is passed (according to RFC 1078 protocol) to xinetd when the remote service requestor first makes the connection on the TCPMUX well-known port. Private protocols should use a service name that has a high probability of being unique. One way is to prepend the service name with some form of organization ID.

The type field can be either TCPMUX or TCPMUXPLUS. If the type is TCPMUXPLUS, xinetd will handle the initial protocol handshake (as defined in RFC 1078) with the calling process before initiating the service. If the type is TCPMUX, the server that is started is responsible for performing the handshake.

The type field should also include UNLISTED if the service is not listed in a standard system file (like /etc/rpc for RPC services, or /etc/services for non-RPC services).

The socket_type for these services must be stream, and the protocol must be tcp.

Following is a sample TCPMUX service configuration:

```
service myorg_server
{
```

disable

```
= no
```

type

```
= TCPMUX
```

socket_type

```
= stream
```

protocol

```
= tcp
```

wait

```
= no
```

user

```
= root
```

server

```
= /usr/etc/my_server_exec
```

```
}
```

Besides a service entry for each service that can be accessed via the TCPMUX well-known port, a service entry for TCPMUX itself must also be included in the xinetd configuration. Consider the following sample:

```
service tcpmux
{
```

type

```
= INTERNAL
```

id

```
= tcpmux
```

socket_type

```
= stream
```

protocol

```
= tcp
```

user

```
= root
```

wait

```
= no
```

```
}
```

## NOTES
1.

The following service attributes cannot be changed on reconfiguration: socket_type, wait, protocol, type.

2.

When the attributes only_from and no_access are not specified for a service (either directly or via defaults) the address check is considered successful (i.e. access will not be denied).

3.

The address check is based on the IP address of the remote host and not on its domain address. We do this so that we can avoid remote name lookups which may take a long time (since xinetd is single-threaded, a name lookup will prevent the daemon from accepting any other requests until the lookup is resolved). The down side of this scheme is that if the IP address of a remote host changes, then access to that host may be denied until xinetd is reconfigured. Whether access is actually denied or not will depend on whether the new host IP address is among those allowed access. For example, if the IP address of a host changes from 1.2.3.4 to 1.2.3.5 and only_from is specified as 1.2.3.0 then access will not be denied.

4.

If the USERID log option is specified and the remote host either does not run an identification server or the server sends back a bad reply, access will not be denied unless the IDONLY service flag is used.

5.

Interception works by forking a process which acts as a filter between the remote host(s) and the local server. This obviously has a performance impact so it is up to you to make the compromise between security and performance for each service. The following tables show the overhead of interception. The first table shows the time overhead-per-datagram for a UDP-based service using various datagram sizes. For TCP-based services we measured the bandwidth reduction because of interception while sending a certain amount of data from client to server (the time overhead should the same as for UDP-based services but it is "paid" only by the first packet of a continuous data transmission). The amount of data is given in the table as system_callsxdata_sent_per_call, i.e. each send(2) system call transferred so many bytes of data. The bandwidth reduction is given in terms of bytes per second and as a percentage of the bandwidth when interception is not performed. All measurements were done on a SparcStation IPC running SunOS 4.1.

Datagram size (bytes)

Latency (msec)

---------------------

--------------

64

1.19

256

1.51

1024

1.51

4096

3.58

Bytes sent

Bandwidth reduction

----------

-------------------

10000x64

941 (1.2%)

10000x256

4,231 (1.8%)

10000x1024

319,300 (39.5%)

10000x4096

824,461 (62.1%)

## EXAMPLE

```
#
# Sample configuration file for xinetd
#
defaults
{
```

log_type

```
= FILE /var/log/servicelog
```

log_on_success

```
= PID
```

log_on_failure

```
= HOST
```

only_from

```
= 128.138.193.0 128.138.204.0
```

only_from

```
= 128.138.252.1
```

instances

```
= 10
```

disabled

```
= rstatd
```

```
}
#
# Note 1: the protocol attribute is not required
# Note 2: the instances attribute overrides the default
#
service login
{
```

socket_type

```
= stream
```

protocol

```
= tcp
```

wait

```
= no
```

user

```
= root
```

server

```
= /usr/etc/in.rlogind
```

instances

```
= UNLIMITED
```

```
}
#
# Note 1: the instances attribute overrides the default
# Note 2: the log_on_success flags are augmented
#
service shell
{
```

socket_type

```
= stream
```

wait

```
= no
```

user

```
= root
```

instances

```
= UNLIMITED
```

server

```
= /usr/etc/in.rshd
```

log_on_success

```
+= HOST
```

```
}
service ftp
{
```

socket_type

```
= stream
```

wait

```
= no
```

nice

```
= 10
```

user

```
= root
```

server

```
= /usr/etc/in.ftpd
```

server_args

```
= -l
```

instances

```
= 4
```

log_on_success

```
+= DURATION HOST USERID
```

access_times

```
= 2:00-9:00 12:00-24:00
```

```
}
# Limit telnet sessions to 8 Mbytes of memory and a total
# 20 CPU seconds for child processes.
service telnet
{
```

socket_type

```
= stream
```

wait

```
= no
```

nice

```
= 10
```

user

```
= root
```

server

```
= /usr/etc/in.telnetd
```

rlimit_as

```
= 8M
```

rlimit_cpu

```
= 20
```

```
}
#
# This entry and the next one specify internal services. Since
# this is the same service using a different socket type, the
# id attribute is used to uniquely identify each entry
#
service echo
{
```

id

```
= echo-stream
```

type

```
= INTERNAL
```

socket_type

```
= stream
```

user

```
= root
```

wait

```
= no
```

```
}
service echo
{
```

id

```
= echo-dgram
```

type

```
= INTERNAL
```

socket_type

```
= dgram
```

user

```
= root
```

wait

```
= no
```

```
}
#
# Sample RPC service
#
service rstatd
{
```

type

```
= RPC
```

socket_type

```
= dgram
```

protocol

```
= udp
```

server

```
= /usr/etc/rpc.rstatd
```

wait

```
= yes
```

user

```
= root
```

rpc_version

```
= 2-4
```

env

```
= LD_LIBRARY_PATH=/etc/securelib
```

```
}
#
# Sample unlisted service
#
service unlisted
{
```

type

```
= UNLISTED
```

socket_type

```
= stream
```

protocol

```
= tcp
```

wait

```
= no
```

server

```
= /home/user/some_server
```

port

```
= 20020
```

```
}
```

```

```

## SEE ALSO
xinetd(1L),

xinetd.log(5)

Postel J., Echo Protocol, RFC 862, May 1983

Postel J., Discard Protocol, RFC 863, May 1983

Postel J., Character Generator Protocol, RFC 864, May 1983

Postel J., Daytime Protocol, RFC 867, May 1983

Postel J., Harrenstien K., Time Protocol, RFC 868, May 1983

M. Lottor, TCP Port Service Multiplexer (TCPMUX), RFC 1078 Nov 1988

StJohns M., Identification Protocol, RFC 1413, February 1993

## BUGS
If the INTERCEPT flag is not used, access control on the address of the remote host is not performed when wait is yes and socket_type is stream.

The NOLIBWRAP flag is automatically turned on for RPC services whose socket_type is stream because xinetd cannot determine the address of the remote host.

If the INTERCEPT flag is not used, access control on the address of the remote host for services where wait is yes and socket_type is dgram is performed only on the first packet. The server may then accept packets from hosts not in the access control list. This can happen with RPC services.

There is no way to put a SPACE in an environment variable.

When wait is yes and socket_type is stream, the socket passed to the server can only accept connections.

The INTERCEPT flag is not supported for internal services or multi-threaded services.


xinetd.log

title: xinetd.log(5)

summary: xinetd service log format

text:
# xinetd.log(5)

## NAME
xinetd.log - xinetd service log format

## DESCRIPTION
A service configuration may specify various degrees of logging when attempts are made to access the service. When logging for a service is enabled, xinetd will generate one-line log entries which have the following format (all entries have a timestamp as a prefix):

entry: service-id data

The data depends on the entry. Possible entry types include:

START

generated when a server is started

EXIT

generated when a server exits

FAIL

generated when it is not possible to start a server

USERID

generated if the USERID log option is used.

NOID

generated if the USERID log option is used, and the IDONLY service flag is used, and the remote end does not identify who is trying to access the service.

In the following, the information enclosed in brackets appears if the appropriate log option is used.

A START entry has the format:

START: service-id [pid=%d] [from=%d.%d.%d.%d]

An EXIT entry has the format:

EXIT: service-id [type=%d] [pid=%d] [duration=%d(sec)]

type can be either status or signal. The number is either the exit status or the signal that caused process termination.

A FAIL entry has the format:

FAIL: service-id reason [from=%d.%d.%d.%d]

Possible reasons are:

fork

a certain number of consecutive fork attempts failed (this number is a configurable parameter)

time

the time check failed

address

the address check failed

service_limit

the allowed number of server instances for this service would be exceeded

process_limit

a limit on the number of forked processes was specified and it would be exceeded

A DATA entry has the format:

DATA: service-id data

The data logged depends on the service.

login

remote_user=%s local_user=%s tty=%s

exec

remote_user=%s verify=status command=%s

Possible status values:

ok

the password was correct

failed

the password was incorrect

baduser

no such user

shell

remote_user=%s local_user=%s command=%s

finger

received string or EMPTY-LINE

A USERID entry has the format:

USERID: service-id text

The text is the response of the identification daemon at the remote end excluding the port numbers (which are included in the response).

A NOID entry has the format:

NOID: service-id IP-address reason

## SEE ALSO
xinetd(1L), xinetd.conf(5)


title: l2tp-secrets(5)

summary: L2TPD secrets file

text:
# l2tp-secrets(5)

## NAME
l2tp-secrets - L2TPD secrets file

## DESCRIPTION
The l2tp-secrets file contains challenge-response authentication information for xl2tpd, the implementation of l2tp protocol. The format of the file is derived from the pap and chap secrets file format used in pppd.

The secrets file is composed of zero or more lines with 3 fields each. Each line represents an authentication secret. The 3 fields represent our hostname, the remote hostname and the secret used in the authentication process.

The first field is for our hostname, a "*" may be used as a wildcard.

The second field is for the remote system's hostname. Again, a "*" may be used as a wildcard.

The third field is the secret used if the previous two fields match the hostnames of the systems involved. The secret should, ideally, be at 16 characters long (the length of an MD5 digest output), and should probably be longer to ensure sufficient security. There is no minimum length requirement, however.

## FILES
/etc/xl2tpd/xl2tpd.conf

/etc/xl2tpd/l2tp-secrets

/var/run/xl2tpd/l2tp-control

## BUGS
Please send bugs and comment to xl2tpd@lists.xelerance.com

## SEE ALSO
xl2tpd(8), xl2tpd.conf(5)

## AUTHORS
Michael Richardson <mcr@xelerance.com> Paul Wouters <paul@xelerance.com>

Patched contributed by:

Jacco de Leeuw <jacco2@dds.nl>

Cedric Schieli <cschieli@gmail.com>

Previous development was hosted at sourceforge (http://www.sourceforge.net/projects/l2tpd) by:

Scott Balmos <sbalmos@iglou.com>

David Stipp <dstipp@one.net>

Jeff McAdams <jeffm@iglou.com>

Based off of l2tpd version 0.60

Copyright (C)1998 Adtran, Inc.

Mark Spencer <markster@marko.net>