prunehistory

title: prunehistory(8)

summary: Remove tokens from Usenet history file

text:
# prunehistory(8)

## NAME
prunehistory - Remove tokens from Usenet history file

## SYNOPSIS
prunehistory [-p] [-f filename]

## DESCRIPTION
prunehistory modifies a history(5)-format text file to "remove" a set of tokens from it. The tokens are removed by overwriting them with spaces, so that the size and position of any following entries does not change. This has an effect similar to expiring the article, in that it is still mentioned in the history database but cannot be retrieved.

prunehistory reads the standard input. The input is taken as a set of lines. Blank lines and lines starting with a number sign ("#") are ignored. All other lines should consist of a message-ID followed by zero or more other fields (which are ignored). The message-ID is used as the dbz(3) key to get an offset into the text file. Since innd only appends to the text file, prunehistory does not need to have any interaction with it.

## OPTIONS
-p

prunehistory will normally complain about lines that do not follow the correct format. If the -p flag is used, then the program will silently print any invalid lines on its standard output. (Blank lines and comment lines are also passed through.)

-f filename

The default name of the history file is pathdb/history; to specify a different name, use the -f flag.

## HISTORY
Written by Rich $alz <rsalz@uunet.uu.net> for InterNetNews. Converted to POD by Julien Elie.

$Id: prunehistory.pod 9447 2012-12-07 19:01:45Z eagle $

## SEE ALSO
dbz(3), history(5), innd(8).


radius

package: inn

title: radius(8)

summary: nnrpd RADIUS password authenticator

text:
# radius(8)

## NAME
radius - nnrpd RADIUS password authenticator

## SYNOPSIS
radius [-h] [-f config]

## DESCRIPTION
radius is an nnrpd authenticator, accepting a username and password from nnrpd (given to nnrpd by a reader connection) and attempting to authenticate that username and password against a RADIUS server. See readers.conf(5) for more information on how to configure an nnrpd authenticator. It is useful for a site that already does user authentication via RADIUS and wants to authenticate news reading connections as well.

By default, radius reads pathetc/inn-radius.conf for configuration information, but a different configuration file can be specified with -f. See inn-radius.conf(5) for a description of the configuration file.

## OPTIONS
-f config

Read config instead of pathetc/inn-radius.conf for configuration information.

-h

Print out a usage message and exit.

## EXAMPLE
The following readers.conf(5) fragment tells nnrpd to authenticate all connections using this authenticator:

```
    auth radius {
        auth: radius
        default: <FAIL>
        default-domain: example.com
    }
```

"@example.com" will be appended to the user-supplied identity, and if RADIUS authentication fails, the user will be assigned an identity of "<FAIL>@example.com".

## BUGS
It has been reported that this authenticator doesn't work with Ascend RADIUS servers, but does work with Cistron RADIUS servers. It's also believed to work with Livingston's RADIUS server. Contributions to make it work better with different types of RADIUS servers would be gratefully accepted.

This code has not been audited against the RADIUS protocol and may not implement it correctly.

## HISTORY
The RADIUS authenticator was originally written by Aidan Cully. This documentation was written by Russ Allbery <eagle@eyrie.org>.

$Id: radius.pod 9940 2015-09-04 12:58:15Z iulius $

## SEE ALSO
inn-radius.conf(5), nnrpd(8), readers.conf(5).


rc.news

title: rc.news(8)

summary: Start or stop INN daemons

text:
# rc.news(8)

## NAME
rc.news - Start or stop INN daemons

## SYNOPSIS
rc.news ["start" | "stop"]

## DESCRIPTION
rc.news can be used to start or stop innd and supporting programs. It checks to make sure INN is not already running, handles cases of unclean shutdown, finishes up tasks which might have been interrupted by the preceding shutdown, e-mails certain boot-time warnings to newsmaster (as set in inn.conf), and is generally safer and easier than starting and stopping everything directly. It needs to be run as the news user so that files in pathrun are created with the right ownership (though this is less important for "rc.news stop").

Programs run and stopped by this script include:

- Always: innd is started or stopped.

- If doinnwatch is true in inn.conf: innwatch is started and stopped.

- If docnfsstat is true in inn.conf: cnfsstat is started and stopped.

- If ovmethod is set to "ovdb" in inn.conf: ovdb_init is run; ovdb_server and ovdb_monitor are stopped.

- If rc.news.local exists in pathbin: rc.news.local is run with argument "start" or "stop" (to perform site-specific startup or shutdown tasks).

- When started, if INN appears to have previously been shut down during its expiry process, run expirerm if there are articles to unlink.

- When started, if overview data appears to have just been rebuilt and active needs to be renumbered, then actually renumber it.

## OPTIONS
"start"

If the first argument is "start", or no first argument is given, rc.news initiates INN startup.

"stop"

If the first argument is "stop", rc.news initiates INN shutdown.

## EXAMPLES
To start INN and leave certain error messages going to the terminal:

```
       su news -s /bin/sh -c <pathbin in inn.conf>/rc.news
```

To run INN at startup time from appropriate system boot scripts:

```
       su news -s /bin/sh -c <pathbin>/rc.news >> <pathlog>/rc.news 2>&1
```

To stop INN:

```
       su news -s /bin/sh -c '<pathbin>/rc.news stop'
```

## BUGS
Running "rc.news start" as root is never the right thing to do, so we should at minimum check for this and error, or perhaps change effective user ID.

## HISTORY
// FIXME: any attribution for rc.news itself?

This manual page written by Jeffrey M. Vinocur <jeff@litech.org> for InterNetNews.

$Id: rc.news.pod 9723 2014-09-24 17:54:24Z iulius $

## SEE ALSO
ctlinnd(8), cnfsstat(8), expirerm(8), inn.conf(5), innwatch(8), ovdb(5).


scanlogs

title: scanlogs(8)

summary: Summarize and rotate INN log files

text:
# scanlogs(8)

## NAME
scanlogs - Summarize and rotate INN log files

## SYNOPSIS
scanlogs [norotate]

## DESCRIPTION
scanlogs summarizes the information recorded in the INN log files which reside in the pathlog directory set in inn.conf (see newslog(5) for further details about these log files). It is normally invoked by the news.daily(8) script which performs daily server maintenance tasks.

It invokes "ctlinnd flushlogs" to close the news and error log files, rename them to add ".old" to the file names and open fresh news and error logs; the active file is also flushed to disk, along with the history database.

By default, scanlogs rotates and cleans out the logs. It keeps up to logcycles old compressed log files in pathlog/OLD (the logcycles parameter can be set in inn.conf). scanlogs also keeps archives of the active file in this directory.

It invokes tally.control if newgroup.log or rmgroup.log exists in pathlog (see the control.log entry of newslog(5) for more information about that).

scanlogs displays the first 50 lines of errlog, news.err and news.crit, if non-empty, and runs innreport to summarize the contents of news and news.notice, and to update the unwanted.log file amongst other things (see more information about that in innreport(8)).

## OPTIONS
Only one option is currently accepted:

norotate

Using this option disables the rotating and cleaning aspect of the log processing: the logs files are only scanned for information and no contents are altered. If scanlogs is invoked more than once a day, the norotate option should be used to prevent premature log cleaning.

## FILES
See newslog(5) for the list of log files processed by scanlogs.

## HISTORY
Written by Landon Curt Noll <chongo@toad.com> and Rich $alz <rsalz@uunet.uu.net> for InterNetNews. Converted to POD by Julien Elie.

$Id: scanlogs.pod 9903 2015-06-20 17:20:46Z iulius $

## SEE ALSO
inn.conf(5), innreport(8), news.daily(8), newslog(5), shlock(1), tally.control(8).


scanspool

title: scanspool(8)

text:
# scanspool(8)

## NAME
scanspool - Perform a sanity scan over all articles in news spool

## SYNOPSIS
scanspool [-cnv] [-a active-file] [-s spool-dir]

## DESCRIPTION
scanspool is a Perl script for use with a tradspool article spool. It will scan the active file as well as all articles in the spool and report on the errors it encounters. As this may take a while, using the -v switch is recommended to see how far the program has progressed.

First, scanspool scans the active file, noting problems such as:

- malformed lines;

- newsgroups aliased to a non-existent newsgroup;

- newsgroups aliased to a newsgroup that is also aliased.

Then it will examine all articles under your news spool directory, complaining about articles that:

- have a basename that starts with a leading 0;

- have a basename that is out of range according to the active file;

- do not contain a Newsgroups: header line;

- are all header and no text;

- are in a directory for which there is no newsgroup in the active file;

- are in a newsgroup to which they do not belong.

scanspool understands aliased newsgroups. Thus, if an article is posted to foo.old.name that is aliased to foo.bar, it will be expected to be found under foo.bar and not foo.old.name.

Articles posted to a newsgroup of status "j" or "x" (the fourth field of the active file) will be expected to show up under the junk group.

scanspool assumes that the path of a valid newsgroup's directory from the root of the spool tree will not contain any "." character. Thus, directories such as out.going, tmp.dir, in.coming and news.archive will not be searched. This program also assumes that article basenames contain only decimal digits. Last, files under the top level directory lost+found are not scanned.

## OPTIONS
-a active-file

The active file to use; pathdb/active is the default.

-c

Only check article filenames. scanspool will therefore not actually scan the Newsgroups: header field of the articles.

-n

Don't throttle innd while scanning.

-s spool-dir

The root of the spool tree; patharticles is the default.

-v

Setting this flag enables a verbose mode. scanspool will then print which newsgroup is currently worked upon. It will list all the articles found in non-active directories (that is to say articles sorted into groups no longer present in the active file), rather than just printing the group once.

## DIAGNOSTICS
The output of scanspool will start with one of the following forms:

"FATAL:" (to stderr)

Fatal or internal error.

"WARN:" (to stderr)

active or article format problem, newsgroup alias problem, find(1) error, article open error.

"path/123:" (to stdout)

Issues such as:

- basename starts with 0;

- article number out of range;

- article in the wrong directory;

- article in a directory not related to an active non-aliased newsgroup.

"\t ..." (to stdout)

Verbose messages start with a tab.

## BUGS
scanspool is unable to detect and properly deal with spool formats other than tradspool. However, if the files that store your articles are named other than just all-digits, they will simply be skipped (and your active is still checked).

scanspool only considers the first line of the Newsgroups: header field. Continuation lines are not taken into account.

## HISTORY
scanspool was written by Landon Curt Noll (chongo was here /\../\).

This manual page was written by Florian Schlichting, largely based on comments in the script.

$Id: scanspool.pod 9301 2011-08-04 21:09:11Z iulius $

## SEE ALSO
active(5).


send-nntp

title: send-nntp(8)

summary: send Usenet articles to remote site

text:
# send-nntp(8)

## NAME
send-nntp, send-ihave - send Usenet articles to remote site

## SYNOPSIS
send-nntp [ -d ] sitename:hostname | sitename [ sitename:hostname | sitename .. ]

send-ihave [ -d ] sitename:hostname | sitename [ sitename:hostname | sitename .. ]

## DESCRIPTION
The send-* utilities are scripts that process the batch files written by innd(8) to send Usenet articles to a remote NNTP site.

The sites to be fed may be specified by giving sitename hostname pairs on the command line.

The sitename is the label the site has in the newsfeeds file, the hostname is the real hostname of the remote site, a FQDN (Fully Qualified Domain Name). Normally, the sitename and the hostname are the same, and as such don't have to be specified as sitename:hostname pairs but just as a sitename.

send-nntp starts an innxmit to send the articles to the remote site.

send-ihave encapsulates the articles in an ihave control message and uses inews to send the articles to a to.sitename pseudo-group. Using send-ihave is discouraged, nobody uses it anymore and even the author of this manpage is unsure as to how it actually works or used to work.

send-* expect that the batchfile for a site is named <pathoutgoing in inn.conf>/sitename. To prevent batchfile corruption, shlock(1) is used to ``lock'' these files.

## OPTIONS
-d

The ``-d'' flag causes nntpsend to send output to stdout rather than the log file <pathlog in inn.conf>/<program-name>.log.

## NOTES
You should probably not use send-nntp, but innfeed, or if that is not possible, nntpsend.

The usual flags for a batch file for send-nntp are ``Tf,Wfm''.

## SEE ALSO
newsfeeds(5), nntpsend(8)


send-uucp

title: send-uucp(8)

summary: Send Usenet articles via UUCP

text:
# send-uucp(8)

## NAME
send-uucp - Send Usenet articles via UUCP

## SYNOPSIS
send-uucp [site ...]

## DESCRIPTION
The send-uucp program processes batch files written by innd(8) to send Usenet articles to UUCP sites. It reads a configuration file to control how it behaves with various sites. Normally, it is run periodically out of cron to put together batches and send them to remote UUCP sites.

It makes it possible to reduce bandwidth usage and to send news to remote UUCP sites which cannot receive a real-time feed (for instance if they are over dial-up connections).

## OPTIONS
Any arguments provided to the program are interpreted as a list of sites specified in send-uucp.cf for which batches should be generated. If no arguments are supplied then batches will be generated for all sites listed in that configuration file.

## CONFIGURATION
The sites to which articles are to be sent must be configured in the configuration file send-uucp.cf in pathetc as set in inn.conf. Each site is specified with a line of the form:

```
    site[:host[:funnel]] [compressor [maxsize [batchtime]]]
```

site

The news site name being configured. This must match a site name from newsfeeds(5).

host

The UUCP host name to which batches should be sent for this site. If omitted, the news site name will be used as the UUCP host name.

funnel

In the case of a site configured as a funnel, send-uucp needs to flush the channel (or exploder) being used as the target of the funnel instead of flushing the site. This is the way to tell send-uucp the name of the channel or exploder to flush for this site. If not specified, default to flushing the site.

compressor

The compression method to use for batches. This should be one of "bzip2", "compress", "gzip" or "none". Arguments for the compression command may be specified by using "_" instead of spaces. For example, "gzip_-9". The default value is "gzip".

maxsize

The maximum size in bytes of a single batch before compression. The default value is 500000 bytes.

batchtime

A comma separated list of hours during which batches should be generated for a given site. When send-uucp runs, a site will only be processed if the current hour matches one of the hours in batchtime. The default is no limitation on when to generate batches.

Fields are separated by spaces and only the site name needs to be specified, with defaults being used for unspecified values. If the first character on a line is a hash sign ("#") then the rest of the line is ignored.

## EXAMPLE
Here is an example for the send-uucp.cf configuration file:

```
    zoetermeer      gzip            1048576         5,18,22
    hoofddorp       gzip            1048576         5,18,22
    pa3ebv          gzip            1048576         5,18,22
    drinkel         bzip2           1048576         5,6,18,20,22,0,2
    manhole         compress        1048576         5,18,22
    owl             compress        1048576
    able
    pern::MYFUNNEL!
```

This defines eight UUCP sites. The first three and the last two use "gzip" compression, the fourth site ("drinkel") uses "bzip2" and the remaining sites ("manhole" and "owl") use "compress". The first six use a batch size of 1 MB, and the two last sites ("able" and "pern") use the default of 500,000 bytes. The "zoetermeer", "hoofddorp", "pa3ebv", and "manhole" sites will only have batches generated for them during the hours of 05:00, 18:00, and 22:00, and the "drinkel" site will only have batches generated during those hours and 06:00, 20:00, 00:00, and 02:00. There are no restrictions on when batches will be generated for "owl", "able" and "pern".

The "pern" site is configured as a funnel into "MYFUNNEL!". send-uucp will issue "ctlinnd flush MYFUNNEL!" instead of "ctlinnd flush pern".

As for the newsfeeds file, the usual flags used for a UUCP feed are "Tf,Wnb". Here is a typical entry for "zoetermeer", where the batching is kept between 4 KB and 1 KB:

```
    zoetermeer\
        :*,!junk,!control,!control.*/!foo\
        :Tf,Wnb,B4096/1024:
```

## FILES
pathbin/send-uucp

The Perl script itself used to create news batches from the outgoing files.

pathetc/send-uucp.cf

The configuration file which specifies a list of sites to be processed.

## HISTORY
This program was originally written by Edvard Tuinder <ed@elm.net> and then maintained and extended by Miquel van Smoorenburg <miquels@cistron.nl>. Marco d'Itri <md@linux.it> cleaned up the code for inclusion in INN. This manual page was written by Mark Brown <broonie@sirena.org.uk>.

## SEE ALSO
innd(8), newsfeeds(5), uucp(8).


sendinpaths

title: sendinpaths(8)

summary: Send Usenet Path: statistics via e\-mail

text:
# sendinpaths(8)

## NAME
sendinpaths - Send Usenet Path: statistics via e-mail

## SYNOPSIS
sendinpaths [-cdhn] [-k keep-days] [-r report-days] [address [address ...]]

## DESCRIPTION
sendinpaths checks pathlog/path for ninpaths dump files, finds dump files generated in the past report-days days, makes sure they are valid by running ninpaths on each one and making sure the exit status is zero, and passes them to ninpaths to generate a cumulative report. By default, that report is mailed to the e-mail addresses configured at the beginning of this script (by default, only one address is configured: <top1000@anthologeek.net>) in order to supply the TOP1000 project with useful statistics. See <http://top1000.anthologeek.net/> for more information.

When finished, sendinpaths deletes all dump files in pathlog/path that are older than keep-days days.

For more information on how to set up ninpaths, see ninpaths(8).

## OPTIONS
-c

When this flag is used, the report is also e-mailed, besides the default submission addresses or those given as command-line arguments, to the newsmaster's address set at configure time.

-d

Enables debug messages.

-h

Gives usage information.

-k keep-days

After having processed dump files, sendinpaths removes those that are older than keep-days days. The default is 0, that is to say to remove all dump files. Setting keep-days to another value can be useful for debugging purpose because it permits keeping a few dump files.

-n

Don't e-mail the report; instead, just print it to standard output. Don't delete old dump files.

-r report-days

Process dump files generated during the last report-days days. The default is 32, that is to say to process all the dump files that have been generated during the last 32 days (if, of course, they have not been deleted yet by a previous run of sendinpaths according to the value set by the -k flag).

address ...

E-mail the report to the mentioned address or addresses, instead of the default one. Several addresses can be used, separated by whitespace (sending the e-mail to your own e-mail address can be useful for debugging purpose, to check that everything works fine). For instance, for two addresses:

```
    sendinpaths pathsurvey@example.org top1000@anthologeek.net

```

## HISTORY
sendinpaths was written by Olaf Titz <olaf@bigred.inka.de>.

$Id: sendinpaths.pod 10283 2018-05-14 12:43:05Z iulius $

## SEE ALSO
ninpaths(8).


tally.control

title: tally.control(8)

text:
# tally.control(8)

## NAME
tally.control - Keep track of newsgroup creations and deletions

## SYNOPSIS
tally.control < logfile

## DESCRIPTION
tally.control is normally daily invoked by scanlogs. It reads its standard input, which should be the newgroup.log and rmgroup.log control log files. They contain a summary line describing the control message and the action taken by controlchan, followed by the article indented by four spaces, and a blank line. Then, tally.control updates the cumulative list of newsgroup creations and deletions which is kept in control.log.

All these log files reside in the pathlog directory set in inn.conf. In order to generate them, you need to enable control articles logging in control.ctl(5), as explained in the control.log entry of newslog(5).

## FILES
pathbin/tally.control

The Shell script itself used to tally newsgroup creations and deletions up.

pathlog/control.log

This file maintains a count of the number of newgroup and rmgroup control messages seen for each newsgroup. The count is of the number of control messages with the indicated arguments, regardless if they were actually processed. All control arguments, including invalid ones, are counted. An example of lines which can be found in that log file is:

```
    3 Control: newgroup foo.bar moderated
    3 Control: rmgroup misc.removed
    1 Control: newgroup misc.created

```

## HISTORY
Written by Landon Curt Noll <chongo@toad.com> and Rich $alz <rsalz@uunet.uu.net> for InterNetNews. Rewritten and converted to POD by Julien Elie.

$Id: tally.control.pod 8357 2009-02-27 17:56:00Z iulius $

## SEE ALSO
control.ctl(5), news.daily(8), newslog(5), scanlogs(8).


tdx-util

title: tdx-util(8)

text:
# tdx-util(8)

## NAME
tdx-util - Tradindexed overview manipulation utility

## SYNOPSIS
tdx-util [-AFcgiOo] [-a article] [-f status] [-n newsgroup] [-p path] [-R path]

## DESCRIPTION
tdx-util is an administrative interface to the tradindexed overview method for INN. It only works on tradindexed overview databases, not on any other type of INN overview. It allows the administrator to dump various information about the internal state of the overview, audit it for errors, and rebuild portions of the overview database.

The tradindexed overview method should lock properly and therefore it should be safe to run this utility and perform any operation it performs, including full repairs or per-group overview rebuilds, while the server is running. However, note that some of the operations performed by this utility can take an extended period of time and will hold locks in the overview database during that period, which depending on what the server is doing may cause the server to stall until tdx-util completes its operation.

The dump operations are -i, which dumps the master index for the overview database, -g, which dumps the index for an individual group, and -o and -O, which dump the overview information for a particular group (including the additional metadata stored in the index) in two different formats. For -g, -o, and -O, the -n option must also be given to specify a newsgroup to operate on.

To add a new newsgroup to the overview database, use -c. A group must be specified with -n. If the group status is something other than "y", it should be specified with -f, and the low and high article numbers may be specified with -a. If only one number is given rather than a range, it will be taken to be the high water mark and the low mark will be set to 1.

To audit the entire overview database for problems, use -A. Any problems found will be reported to standard error. Use -F to correct the errors found.

To rebuild the database for a particular newsgroup, use -R. The -R option takes a path to a directory which contains all of the articles for that newsgroup, one per file. The names of the files must be the numbers of the articles in that group. (In other words, this directory must be a traditional spool directory for that group.) The -n option must also be given to specify the newsgroup for which the overview is being rebuilt.

For all operations performed by tdx-util, a different overview database than the one specified in inn.conf may be specified using the -p option.

## OPTIONS
-A

Audit the entire overview database for problems. This runs the internal consistency checks built into the tradindexed overview implementation, checking such things as the validity and reachability of all group index entries, the format of the individual overview entries, the correspondence of index entries to overview data, and similar such things. No changes will be made to the database, but problems will be reported to standard error.

-a article

The article number or numbers to act on. article is a valid NNTP range, meaning that it can be either a single article number or a range of article numbers (like "1-5"). Either the start or the end (or both) of the range may be omitted, in which case they will be set to the first or last article number in the group. Passing "-" for article is therefore equivalent to not using the -a option at all. Only useful in combination with the -o option to dump overview information or with -c to specify the low and high article numbers when creating a group.

-c

Create a new group in the overview database. The group must be specified with -n. The newsgroup status defaults to "y" but may be set with -f. The low and high article numbers default to 1 and 0 respectively, but may be set with -a. If only one number is given to -a, it is taken as the high article number.

-F

Audit the entire overview database for problems, fixing them as they're detected where possible. This runs the internal consistency checks built into the tradindexed overview implementation, checking such things as the validity and reachability of all group index entries, the format of the individual overview entries, the correspondence of index entries to overview data, and similar such things. The strategy used when fixing problems is to throw away data that's unrecoverable, so be warned that using this option may result in inaccessible articles if their overview data has been corrupted. To see what would be changed by -F, run tdx-util with -A first.

-f status

When creating a newsgroup with -c, set the status of the newly created group to status instead of "y". Only useful with -c.

-g

Dump the index of a particular group. The fields are, in order, the article number, the offset of the data for that article in the overview data file for that group, the length of the overview data, the time (in seconds since epoch) when the article arrived on the server, the time (in seconds since epoch) when the article should expire based on its Expires: header (or 0 if there is no Expires: header), and the storage API token of the article. If this option is given, the -n option must also be given to specify the newsgroup on which to act.

-i

Dump the master index of the overview database. This contains similar information to the server active file, such as high and low water marks and moderation status, and is the information that nnrpd hands out to clients. The fields are, in order, the newsgroup name, the high water mark, the low water mark, the base article number (the point at which the group index begins), the count of articles in the group, the group status, the time (in seconds since epoch) when that newsgroup was deleted or 0 if it hasn't been, and the inode of the index file for that group.

A particular newsgroup can be specified with the -n option. If -n is not given, the entire master index will be dumped.

-n newsgroup

Specify the newsgroup on which to act, required for the -i, -o, and -R options.

-O

Dump the overview information for a newsgroup in the format used by overchan as input. Each line will start with the storage API token, the arrival timestamp in seconds since epoch, the expires timestamp in the same format (or 0 if there is no Expires: header), and then the overview data. If this option is given, the -n option must also be given to specify the newsgroup on which to act. By default, all of the overview information for that newsgroup is dumped, but the -a option may be given to restrict the dump to the information for a single article.

-o

Dump the overview information for a newsgroup, in the same format as it would be returned to clients but with one modification. Appended to the end of each entry will be four additional pieces of data: the article number according to the index file for that group labelled with "Article:", the storage API token for that article labelled with "Token:", the arrival date for that article on the server in RFC 5322 date format labelled with "Arrived:", and the expiration date for that article (from the Expires: header) in RFC 5322 date format if there is any, labelled with "Expires:". If this option is given, the -n option must also be given to specify the newsgroup on which to act. By default, all of the overview information for that newsgroup is dumped, but the -a option may be given to restrict the dump to the information for a single article.

-p path

Act on the overview database rooted in path, overriding the overview path specified in inn.conf.

-R path

Rebuild the overview for a given group from the articles stored in path. The articles must be in the form of a traditional spool directory; in other words, each article must be in a separate file and the name of the file must match the article number of the article. If this option is given, the -n option must also be given to specify the newsgroup on which to act.

## EXAMPLES
Dump the master index for the overview database in /news/overview, regardless of the overview path specified in inn.conf:

```
    tdx-util -i -p /news/overview
```

Dump the group index for example.test:

```
    tdx-util -g -n example.test
```

Dump the complete overview information for example.test:

```
    tdx-util -o -n example.test
```

Dump the overview information for articles 45 and higher in example.test:

```
    tdx-util -o -n example.test -a 45-
```

Create an entry for example.test with mode m and low and high article numbers of 4 and 23, respectively.

```
    tdx-util -c -n example.test -f m -a 4-23
```

Audit the entire overview database for any problems:

```
    tdx-util -A
```

Rebuild the overview information for example.test from a traditional spool directory:

```
    tdx-util -R <patharticles in inn.conf>/example/test -n example.test
```

The last command may be useful for recovering from a bad crash or corrupted overview information for a particular group, if you are also using the tradspool article storage method.

## HISTORY
Written by Russ Allbery <eagle@eyrie.org> for InterNetNews.

$Id: tdx-util.pod 9767 2014-12-07 21:13:43Z iulius $

## SEE ALSO
makehistory(8), nnrpd(8).


tinyleaf

title: tinyleaf(8)

summary: Very simple IHAVE\-only NNTP server

text:
# tinyleaf(8)

## NAME
tinyleaf - Very simple IHAVE-only NNTP server

## SYNOPSIS
tinyleaf spool [processor]

## DESCRIPTION
tinyleaf is intended to be the simplest possible transit news server that still does something useful. It must be run under inetd(8) or some equivalent, and only implements three commands (HELP, IHAVE, and QUIT). When it receives an article, it saves it into the directory spool and, if processor is given, passes information about the article to processor via a pipe. The file name of the article will be the MD5 hash of its message-ID, and if a file by that name already exists, tinyleaf will refuse the article, reporting it as a duplicate.

If processor is given, it should specify the path to a program. That program is started when tinyleaf starts, and its current working directory will be spool. For each article received by tinyleaf, a single line will be sent to standard input of processor. That line will consist of the file name of the received article (relative to spool), a single space, and the message-ID of the received article. Note that the message-ID will be taken from the argument to the IHAVE command and may not match the Message-ID: header in the article. When tinyleaf shuts down, standard input to processor will be closed.

tinyleaf does no syntax verification of received articles whatsoever; it just stores them and optionally passes them off to processor. It also never deletes articles; normally, processor should do that when it's finished doing whatever it needs to with the article.

tinyleaf expects NNTP commands on standard input and replies on standard output. Status information and any error messages are sent to standard error. It does no authentication; any authentication must be done by inetd(8) or by a wrapper program. (One simple authentication mechanism is to invoke tinyleaf via tcpd(8) from TCP wrappers and use /etc/hosts.allow and /etc/hosts.deny to restrict who can talk to the server.)

tinyleaf has a (currently hard-coded) maximum message size of 1 MB and a (similarly hard-coded) timeout of ten minutes for each command or chunk of article data.

## EXAMPLE
Suppose that you want to archive news articles on a particular host (like the FTP server for a newsgroup archive) where you don't want the overhead of running a full-blown news server. Write a program that reads one line at a time from standard input and treats everything before the first space as the filename of a news article to archive. Each time the program reads a line, it should archive that file and then delete it, and it should exit when it gets end of file on standard input.

Then, add a line like:

```
    nntp stream tcp nowait archive /usr/sbin/tcpd \
      <pathbin>/tinyleaf <pathspool>/tinyleaf <pathbin>/archive
```

(all on one line -- the backslash and split in this line is just for readability) where "archive" is the user that owns the archive, /usr/sbin/tcpd is the path to tcpd(8), pathbin/tinyleaf is the path to this program, pathspool/tinyleaf is some scratch directory that the user "archive" has write access to, and pathbin/archive is the path to your archive script.

You can now restrict access to tinyleaf to just your local news server with "/etc/hosts.allow" and "/etc/hosts.deny" and set up an ordinary feed from the server to the archive host, just like you would to any other news server, of only the newsgroup that you want to archive.

Note that the archiving script should probably perform basic syntax and validity checks on the input, since tinyleaf doesn't.

This is the application that motivated the original development of this program.

## BUGS
The timeout and maximum message size should really be configurable. tinyleaf should also probably not just respond 500 to every command other than HELP, IHAVE, and QUIT; there are more useful (and more expected) error codes that could be returned.

An option to scan the spool directory for any left-over files and pass them to the processor when starting up would be useful.

## HISTORY
Written by Russ Allbery <eagle@eyrie.org> for InterNetNews.

$Id: tinyleaf.pod 9767 2014-12-07 21:13:43Z iulius $

## SEE ALSO
hosts_access(5), inetd(8), tcpd(8).


writelog

title: writelog(8)

summary: add a entry to an INN log file.

text:
# writelog(8)

## NAME
writelog - add a entry to an INN log file.

## SYNOPSIS
writelog name text...

## DESCRIPTION
The writelog script is used to write a log entry or send it as mail. The name parameter specifies the name of the log file where the entry should be written. If it is the word ``mail'' then the entry is mailed to the news administrator, <USER specified with --with-news-master at configure>. The data that is written or sent consists of the text given on the command line, followed by standard input indented by four spaces. Shlock(1) is used to avoid simultaneous updates to a single log file.

## HISTORY
Written by Landon Curt Noll <chongo@toad.com> and Rich $alz <rsalz@uunet.uu.net> for InterNetNews. This is revision 5909, dated 2002-12-03.

## SEE ALSO
innd(8), innstat(8), news.daily(8), newslog(5), nnrpd(8), scanlogs(8).


input-events

package: input-utils

title: input-events(8)

summary: list input devices

text:
# input-events(8)

## NAME
input-events - list input devices

## SYNOPSIS
input-events [-t sec] [-g] devnr

## DESCRIPTION
input-events listens for events on kernel input device devnr and prints them.

## OPTIONS
devnr

The index of the input device to use (0 for /dev/input/event0 and so on).

-g

Grab device using EVIOCGRAB, i.e., get exclusive access to the device.

-t sec

Set the timeout. The program will quit after sec seconds without activity.

## SEE ALSO
lsinput(8)

## AUTHOR
Gerd Knorr.


input-kbd

title: input-kbd(8)

text:
# input-kbd(8)

## NAME
input-kbd - print or modify keyboard maps for input devices

## SYNOPSIS
input-kbd num

input-kbd [-f file] devnr

## DESCRIPTION
input-kbd prints the keyboard map of kernel input device devnr on stdout. The keyboard map maps scancodes to keycodes.

If the device supports a keyboard map, it is printed in the following format (from the output for an AT keyboard):

0x0001 = 67 # KEY_F9

0x0002 = 65 # KEY_F7

0x0003 = 63 # KEY_F5

0x0004 = 61 # KEY_F3

If the device does not support a keyboard map, input-kbd just lists the keys and buttons supported by the device, like this (for a mouse):

bits: BTN_LEFT

bits: BTN_RIGHT

bits: BTN_MIDDLE

## OPTIONS
devnr

The index of the input device to use (0 for /dev/input/event0 and so on).

-f file

Read a keyboard map from a file and reconfigure the device with this map. The map file uses the same format as the output of this command. Key names are also accepted instead of keycodes, like this:

0x0001 = KEY_F9

## AUTHOR
Gerd Knorr.


lsinput

title: lsinput(8)

summary: list input devices

text:
# lsinput(8)

## NAME
lsinput - list input devices

## SYNOPSIS
lsinput

## DESCRIPTION
lsinput displays a list of all input devices of the kernel, along with some information about each device.

## SEE ALSO
input-events(8)

## AUTHOR
Gerd Knorr.


insserv

package: insserv

title: insserv(8)

summary: Enable an installed system init script

text:
# insserv(8)

## NAME
insserv - Enable an installed system init script

## SYNOPSIS
insserv [-v] [-c <config>] [-p <path>] [-d] [-f] [[/]path/to/init.d/]script ...

insserv [-v] [-c <config>] [-p <path>] [[/]path/to/init.d/]script[,start=<lvl1,lvl2,...>,stop=<lvl1,lvl2,...>]

insserv [-v] [-c <config>] [-p <path>] -r [-d] [-f] [[/]path/to/init.d/]script ...

insserv -h

/usr/lib/lsb/install_initd [[/]path/to/init.d/script]

/usr/lib/lsb/remove_initd [[/]path/to/init.d/script]

## DESCRIPTION
insserv enables an installed system init script (`boot script') by reading the comment header of the script, e.g.:

```
 ### BEGIN INIT INFO

 # Provides:          boot_facility_1 [ boot_facility_2 ...]

 # Required-Start:    boot_facility_1 [ boot_facility_2 ...]

 # Required-Stop:     boot_facility_1 [ boot_facility_2 ...]

 # Should-Start:      boot_facility_1 [ boot_facility_2 ...]

 # Should-Stop:       boot_facility_1 [ boot_facility_2 ...]

 # X-Start-Before:    boot_facility_1 [ boot_facility_2 ...]

 # X-Stop-After:      boot_facility_1 [ boot_facility_2 ...]

 # Default-Start:     run_level_1 [ run_level_2 ...]

 # Default-Stop:      run_level_1 [ run_level_2 ...]

 # X-Interactive:     true

 # Short-Description: single_line_description

 # Description:       multiline_description

 ### END INIT INFO
```

and calculating the dependencies between all scripts. Please note, that the Default-Stop are ignored in SuSE Linux, because the SuSE boot script concept uses a differential link scheme (see init.d(7)).

The optional X-Interactive keyword implies that the script using this keyword should be started alone in a concurrent boot configuration because it interact with the user at the console. Only the value `true' is recogniced. All other are ignored.

The optional X-Start-Before keyword implies that the script using this keyword should be started before the specified service names. Whereas the optional X-Stop-After keyword implies that the script using this keyword should be stopped after the specified service names. Both implies that those services now depend on the specifying script. With known dependencies and runlevel(s) insserv sets and reorders the corresponding symbolic links of the concerned runlevels directories (see init.d (7)). Known runlevels are:

```
 0   used for System halt

 1   used for single user mode

 2   used for local multiuser without remote network

 3   used for full multiuser with network

 4   reserved for local use

 5   used for full multiuser with network and xdm

 6   used for System reboot

 S   used during boot into single user mode

 B   used during boot before any other runlevel
```

insserv scans for System Facilities in the configuration file /etc/insserv.conf and each file in the directory /etc/insserv.conf.d/. Each line which begins with $ and a following name defines a system facility accordingly to the Linux Standard Base Specification (LSB), All names followed by such a system facility will declare the required dependencies of the facility. Here is an example for /etc/insserv.conf:

```
 # All local filesystems are mounted

 # (done during boot phase)

 $local_fs       boot

 # Low level networking

 $network        network route

 # Named is operational

 $named          named

 # All remote filesystems are mounted

 # (in some cases /usr may be remote).

 $remote_fs      $local_fs nfs

 # System logger is operational

 $syslog         syslog

 # All network daemons are running (This was removed in LSB 1.2)

 $netdaemons     portmap inetd

 # Services which need to be interactive

 <interactive>   boot.crypto
```

Names starting with a `+' sign are marked as optional. If the service with the name after the plus sign is available it will be used, if not available it is ignored silently. Words beginning with < and ending with > are keywords. Currently <interactive> is the only know keyword for marking a service as an interactive one, e.g. a service which requires a passphrase or password input during boot or runlevel change. The special facility $null is used to enforce an empty dependency in case of Should-Stop and Required-Stop otherwise insserv assumes the same dependencies as for the Start case.

In addition to the defined System Facilities in the configuration file /etc/insserv.conf, insserv also knows the special facility $all. This facility indicates that a service should be inserted at the end of all services at starting and at the very begining at stopping. Clearly all services using this facility will be grouped into one starting or stopping order.

## OPTIONS
Currently there exists nine options for insserv.

-v, --verbose

Write out what is currently going on.

-c <config>, --config <config>

Specify path to the insserv.conf file and the insserv.conf.d directory. Useful for testing.

-o <path>, --override <path>

LSB comment headers found in this path will override existing LSB comment headers of scripts in the init.d directory (default path is /etc/insserv/overrides/).

-p <path>, --path <path>

Specify path to init.d directory. Useful for testing.

-n, --dryrun

Do not update symlinks.

-s, --showall

Output runlevel and sequence information. Do not update symlinks.

-r, --remove

Remove the listed scripts from all runlevels.

-d, --default

Use default runlevels as defined in the scripts. This may restore an edited runlevel link scheme.

-f, --force

Ignore if a required service is missed. Beside this if start and or stop levels are specified on the command line the default levels of the script will be ignored.

-u <path>, --upstart-job <path>

Path to replace existing upstart job path. (default path is /lib/init/upstart-job).

-h, --help

Print out short usage message.

But you may use the argument syntax described in the following section.

## ARGUMENTS
[[/]path/to/init.d/]

Relative or absolute path to the init scripts base directory. For the SuSE Linux boot concept, this defaults to /etc/init.d/ in compliance with the LSB specification. In this case insserv does not add or remove a script to the runlevels declared in the script headers, but may re-order the runlevels if the order of the currently enabled scripts has changed (see option -d). Note that if a relative path is used insserv has to be called from the root directory.

[[/]path/to/init.d/]script ...

List of scripts which have to be added to the runlevels. If a path is used it should point to the absolute or relative location of the boot scripts. insserv checks for the existence of these scripts. For the runlevels the information found in the script is used.

[[/]path/to/init.d/]script[,start=<lvl1,lvl2,...>]

List of scripts which have to be added to the specified runlevels to be started with. You may use this extension to override the default values for start and stop runlevels of the script. Note that lvl1, lvl2, ... are the known runlevels explained above. The extension ,stop=<lvl1,lvl2,...> is also possible.

-r [[/]path/to/init.d/]script ...

List of scripts which should be removed from the runlevels. If a path is used it should point to the absolute or relative location of the boot scripts. insserv checks for the existence of these scripts.

## OVERRIDES
Beside using the extensions ,start=<lvl1,lvl2,...> and ,stop=<lvl1,lvl2,...> it is possible to use override files replace a LSB comment header or simple provide a missing LSB comment header. This can be done by placing a file with the new LSB comment header using the same name as the boot or init script in the directory /etc/insserv/overrides/. For third party boot scripts without LSB header it is possible to add a file with the same name in the directory /usr/share/insserv/overrides/ to make them completely LSB compliant.

## UPSTART JOB COMPATIBILITY
To allow upstart jobs to work as init.d scripts, insserv will recognize a symlink from path/to/init.d/script to /lib/init/upstart-job as upstart jobs, and instead of reading the header from the file will run the script with the argument lsb-header to get the script header.

## EXIT CODES
The exit codes have the following conditions:

0

Service was successfully installed or removed

1

Service was not installed or removed

## NOTE
Please be aware that the following patterns of boot script file names will be not accepted by insserv:

```
        *.local

        *.dpkg*

        *.rpm*

        *.ba*

        *.old

        *.new

        *.org

        *.orig

        *.save

        *.swp

        *.core

        *~
```

with the wildcard character *. Beside this all boot script file names beginning with one of the following characters

```
        $.#%_+-\*[]^:()~
```

will be ignored.

## BUGS
Boot scripts sometimes lack a LSB comment header. Contact a package maintainer or developer of the software which provides the script to have a LSB comment header added to it.

## FILES
/etc/insserv.conf

configuration file for insserv which defines the LSB System Facilities.

/etc/insserv.conf.d/

directory for further configuration files for declaring LSB System Facilities.

/etc/insserv/overrides/

path to replace existing LSB comment headers with the comment headers found in this path.

/etc/init.d/

path to the SuSE init script base directory as required by the Linux Standard Base Specification (LSB).

/etc/init.d/.depend.boot,

/etc/init.d/.depend.start,

/etc/init.d/.depend.stop

The make(1) like dependency files produced by insserv for booting, starting, and stopping with the help of startpar(8).

## SEE ALSO
init.d(7), init(7), startproc(8), checkproc(8), killproc(8), startpar(8).

## COPYRIGHT
2000-2009 Werner Fink,

2009 SuSE Linux Products GmbH Nuernberg, Germany.

2000-2003 SuSE GmbH Nuernberg, Germany,

2007-2009 SuSE Linux Products GmbH Nuernberg, Germany.

## AUTHOR
Werner Fink <feedback@suse.de>

## CONTRIBUTORS
Petter Reinholdtsen

Kel Modderman


genramdisk

package: installworld

title: genramdisk(8)

text:
# genramdisk(8)

## NAME
genramdisk - build RAM disk with live system from scratch

## SYNOPSIS
genramdisk <image file> <package> [package ...]

## DESCRIPTION
genramdisk is a command line tool for fully automatic unattended build of the RAM disk image containing fresh system with all dependencies resolved for running selected software.

Uses installworld and postinstall for the system installation and configuration.

Requires root privileges and access to configured repositories.

## ENVIRONMENT
$APTCONFDIR - apt configuration to copy (default: /etc/apt). $RAMDISK_SIZE - RAM disk size in Mb (default: calculate automatically)

## FILES
/etc/apt/ - default apt configuration directory.

## SEE ALSO
installworld(8) postinstall(8) apt(8)


installworld

title: installworld(8)

summary: unattended installation tool

text:
# installworld(8)

## NAME
installworld - unattended installation tool

## SYNOPSIS
installworld <target directory> <package> [package ...]

## DESCRIPTION
installworld is a command line tool for fully automatic unattended installation of fresh system with all dependencies resolved for running selected software.

Requires root privileges and access to configured repositories.

## ENVIRONMENT
$APTCONFDIR - apt configuration to copy (default: /etc/apt).

## WARNING
The content of the target directory is wiped unconditionally. This could cause a major fuqup, so think twice before running the installation process.

## FILES
/etc/apt/ - default apt configuration directory.

## SEE ALSO
apt(8)


postinstall

title: postinstall(8)

text:
# postinstall(8)

## NAME
postinstall - configure the system after unattended installation

## SYNOPSIS
postinstall <target_directory>

## DESCRIPTION
postinstall is normally executed after the installworld had finished the unattended installation and tries to do its' best in automatic system configuration.

## ENVIRONMENT
$POSTINSTALL - name of the script to execute instead of default one $ROOTDEV - block device with root filesystem (for bootloader install) $ROOT_SSH_KEY - line for adding to ~root/.ssh/authorized_keys

## SEE ALSO
installworld(8) apt(8)


intltool-extract

package: intltool

title: intltool-extract(8)

text:
# intltool-extract(8)

## NAME
intltool-extract - generate header files which can be read by gettext

## SYNOPSIS
intltool-extract [options]... SOURCE_FILE

## DESCRIPTION
intltool-extract extracts strings in the specified XML/INI type SOURCE_FILE and writes them into a C header file. Then xgettext(1) can merge these strings inside header file into po template.

intltool-extract is usually not executed manually, but called from intltool-update(8) instead.

## OPTIONS
-l

--local

Creates a subdirectory under current working directory (named "tmp/") and writes files there. This option can't be used with --update option.

--update

Writes header file into the same directory the source file is in. New file name is the source file name appending ".h" extension. This option can't be used with -l/--local option. Besides, this option is the default option if neither --local nor --update is specified.

--type=TYPE

Specify the type of source file. Currently supported types are:

"gettext/glade" (.glade, .glade2)

"gettext/gsettings" (.gschema.xml)

"gettext/ini" (Generic INI file)

"gettext/keys" (.keys)

"gettext/rfc822deb" (RFC 822 format file)

"gettext/quoted" (all strings within "")

"gettext/schemas" (.schemas)

"gettext/scheme" (.scm)

"gettext/xml" (Generic XML file)

"gettext/qtdesigner" (Qt Designer .ui files)

-v

--version

Show version information.

-h

--help

Show usage and basic help information.

-q

--quiet

Be quiet while running.

## REPORTING BUGS
Report bugs to http://bugs.launchpad.net/intltool

## AUTHOR
Darin Adler <darin@bentspoon.com>

Kenneth Christiansen <kenneth@gnu.org>

Maciej Stachowiak <mjs@eazel.com>

## SEE ALSO
intltoolize(8), intltool-prepare(8), intltool-merge(8), intltool-update(8), xgettext(1)


intltool-merge

title: intltool-merge(8)

text:
# intltool-merge(8)

## NAME
intltool-merge - merge translated strings into various types of file

## SYNOPSIS
intltool-merge [option]... PO_DIRECTORY FILENAME OUTPUT_FILE

## DESCRIPTION
Merge translated strings in po files in PO_DIRECTORY with the original application file FILENAME, and output the file OUTPUT_FILE containing both original and localized strings.

If FILENAME is an XML file, OUTPUT_FILE will contain repeated xml nodes, where each node contains one of the localized strings with "xml:lang" attribute.

## OPTIONS

### Mode of operation
-b

--ba-style

Merge files in bonobo-activation style, which is used for bonobo servers.

-d

--desktop-style

Merge files in desktop style, which is similar to the Windows .ini file format.

-k

--keys-style

Merge files in keys style, which is used for metadata.

-o

--oaf-style

(OBSOLETE) Same as -b/--ba-style.

-r

--rfc822deb-style

Merge files in RFC 822 style, which is usually used in Debian configuration files.

--quoted-style

Merge files in quoted string style, which just translates any strings within "".

-x

--xml-style

Merge files in standard XML style, both as attributes and as raw pcdata.

### Other options
-u

--utf8

Convert all strings to UTF-8 before merging.

-p

--pass-through

Use strings as is in .po files without conversion (STRONGLY unrecommended with -x).

-c

--cache

(TBD)

-q

--quiet

Be quiet while running.

-v

--version

Show version information.

-h

--help

Show usage and basic help information.

## FILES
po/.intltool-merge-cache

Cache file generated by intltool-merge, that contains all strings in all po files separated by \01.

## REPORTING BUGS
Report bugs to http://bugs.launchpad.net/intltool

## AUTHOR
Darin Adler <darin@bentspoon.com>

Kenneth Christiansen <kenneth@gnu.org>

Maciej Stachowiak <mjs@eazel.com>

## SEE ALSO
iconv(1), intltoolize(8), intltool-prepare(8), intltool-extract(8), intltool-update(8)


intltool-prepare

title: intltool-prepare(8)

text:
# intltool-prepare(8)

## NAME
intltool-prepare - Prepare software to make use of intltool

## SYNOPSIS
intltool-prepare [option] [KEYWORD]...

## DESCRIPTION
For software packages that include some specific type of translatable files (such as .desktop and .soundlist), before they make use of intltool, translators have to dig through them one by one, and add their localization into each file. This process is error prone, since translators may include typing errors, or add their localization in wrong encoding. Besides, translators may not alwas know other files (beside .po files) are translatable.

intltool avoids all the problems above by extracting strings inside those translatable files into po template (.pot) file. All translators need to care about is just translating po files. Afterwards, intltool-merge(8) will merge localized strings into those files.

Before your software becomes intltool-aware, a few issues have to be sorted out, and intltool-prepare tries to take care of all of them. intltool-prepare will:

•

Extract all localized strings in .desktop style files (including ".desktop", ".soundlist", ".keys" and ".directory") into corresponding po files.

•

Convert the translatable files into templates that don't contain any localization.

•

Add the list of template files above into POTFILES.in.

•

Add the list of old translatable files into .cvsignore (since they will be generated by intltool later).

•

Add the rules for generating these files into Makefile.am.

NOTE: You must change working directory to the top level source directory before running intltool-prepare.

## OPTIONS
KEYWORD is a list of additional keywords beside "Name", "Comment" and "description". intltool-prepare will recognize any line starting with those KEYWORD and extract localized strings after equal sign ("=").

-x

--verbose

Be verbose to give user additional feedback.

-v

--version

Show version information.

-h

--help

Show usage and basic help information.

## REPORTING BUGS
Report bugs to http://bugs.launchpad.net/intltool

## AUTHOR
Darin Adler <darin@bentspoon.com>

Kenneth Christiansen <kenneth@gnu.org>

Maciej Stachowiak <mjs@eazel.com>

## SEE ALSO
intltoolize(8), intltool-update(8), intltool-extract(8), intltool-merge(8)


intltool-update

title: intltool-update(8)

text:
# intltool-update(8)

## NAME
intltool-update - updates PO template file and merge translations with it

## SYNOPSIS
intltool-update [option]...

intltool-update LANGCODE

## DESCRIPTION
intltool-update generates new po file templates from source code, and merges existing translations with these new po templates.

You must change working directory to the subdirectory containing translations (usually "po/") before running intltool-update.

## OPTIONS
When executing intltool-update , only one mode of operation is allowed each time.

### Mode of operation
-p

--pot

Generate po template (.pot) only.

-s

--headers

Executes intltool-extract(8) to extract strings inside XML/INI style files listed in POTFILES.in, and writes the extracted strings into header files, so that the strings can be recognised by xgettext(1).

-m

--maintain

Search for left out files, which should have been listed in POTFILES.in or POTFILES.skip. A list of all these files are written into another file called "missing".

-r

--report

Display a status report for all translations in the software.

-d LANGCODE

--dist LANGCODE

Merge LANGCODE.po with existing PO template.

### Other options
-g NAME

--gettext-package=NAME

Manually specify PO template file name, instead of determining the name automatically from source. Useful with -p/--pot option. This option has an additional effect: the name of current working directory is no more limited to "po" or "po-*".

-o FILENAME

--output-file=FILENAME

Manually specify output FILENAME after merging old translation with PO template. Useful either with -d/--dist option or without any option.

-x

--verbose

Display lots of feedback.

--version

Show version information.

--help

Show usage and basic help information.

## EXAMPLES
Creates a new PO template from source code, and name it foo.pot:

```
intltool-update --pot --gettext-package=foo
```

Updates translation file xy.po using existing po template called "bar.pot", and writes output into "xy1.po":

```
intltool-update --dist --gettext-package=bar --output-file=xy1.po xy
```

Creates new PO template and updates translation file xy.po (xy.po is overwritten with new content):

```
intltool-update xy
```

(same as intltool-update --pot && intltool-update --dist xy)

## FILES
po/POTFILES.in

Contains list of source files which contain translatable strings, one file per line.

po/POTFILES.skip

po/POTFILES.ignore (obsolete)

Contains list of source files which should be ignored when searching for translatable strings.

## REPORTING BUGS
Report bugs to http://bugs.launchpad.net/intltool

## AUTHOR
Darin Adler <darin@bentspoon.com>

Kenneth Christiansen <kenneth@gnu.org>

Maciej Stachowiak <mjs@eazel.com>

## SEE ALSO
intltoolize(8), intltool-prepare(8), intltool-extract(8), intltool-merge(8), xgettext(1)


intltoolize

title: intltoolize(8)

text:
# intltoolize(8)

## NAME
intltoolize - copy intltool related files to software package

## SYNOPSIS
intltoolize [option]...

## DESCRIPTION
This prepares a package to use intltool by linking or copying various files needed by intltool into place for use when building. Note that you must change your working directory to the top level directory of the package before running intltoolize.

## OPTIONS
--automake

Work silently and assume that automake is being used in software.

-c

--copy

Copy files rather than creating symbolic links to them.

--debug

Enable verbose shell tracing.

-n

--dry-run

Print commands only, instead of executing them.

-f

--force

Replace existing files if they exist.

--help

Show usage and basic help information.

--version

Show version information.

## REPORTING BUGS
Report bugs to http://bugs.launchpad.net/intltool

## AUTHOR
Darin Adler <darin@bentspoon.com>

Kenneth Christiansen <kenneth@gnu.org>

Maciej Stachowiak <mjs@eazel.com>

## SEE ALSO
intltool-prepare(8), intltool-extract(8), intltool-merge(8), intltool-update(8)


iodine

package: iodine-client

title: iodine(8)

summary: tunnel IPv4 over DNS

text:
# iodine(8)

## NAME
iodine, iodined - tunnel IPv4 over DNS

## SYNOPSIS
iodine [-v]

iodine [-h]

iodine [-4] [-6] [-f] [-r] [-u user ] [-P password ] [-m fragsize ] [-t chrootdir ] [-d device ] [-R rdomain ] [-m fragsize ] [-M namelen ] [-z context ] [-F pidfile ] [-T dnstype ] [-O downenc ] [-L 0|1 ] [-I interval ] [ nameserver ] topdomain

iodined [-v]

iodined [-h]

iodined [-c] [-s] [-f] [-D] [-u user ] [-t chrootdir ] [-d device ] [-m mtu ] [-l listen_ip ] [-p port ] [-n ( auto | external_ip ) ] [-b dnsport ] [-P password ] [-z context ] [-F pidfile ] [-i max_idle_time ] tunnel_ip [ /netmask ] topdomain

## DESCRIPTION
iodine lets you tunnel IPv4 data through a DNS server. This can be useful in situations where Internet access is firewalled, but DNS queries are allowed. It needs a TUN/TAP device to operate. The bandwidth is asymmetrical, with a measured maximum of 680 kbit/s upstream and 2.3 Mbit/s downstream in a wired LAN test network. Realistic sustained throughput on a Wifi network using a carrier-grade DNS cache has been measured at some 50 kbit/s upstream and over 200 kbit/s downstream. iodine is the client application, iodined is the server.

Note: server and client are required to speak the exact same protocol. In most cases, this means running the same iodine version. Unfortunately, implementing backward and forward protocol compatibility is usually not feasible.

## OPTIONS

### Common Options:
-v

Print version info and exit.

-h

Print usage info and exit.

-f

Keep running in foreground.

-u user

Drop privileges and run as user 'user' after setting up tunnel.

-t chrootdir

Chroot to 'chrootdir' after setting up tunnel.

-d device

Use the TUN device 'device' instead of the normal one, which is dnsX on Linux and otherwise tunX.

-P password

Use 'password' to authenticate. If not used, stdin will be used as input. Only the first 32 characters will be used.

-z context

Apply SELinux 'context' after initialization.

-F pidfile

Create 'pidfile' and write process id in it.

### Client Options:
-4

Force IPv4 DNS queries

-6

Force IPv6 DNS queries

-r

Skip raw UDP mode. If not used, iodine will try getting the public IP address of the iodined host and test if it is reachable directly. If it is, traffic will be sent to the server instead of the DNS relay.

-R rdomain

Use OpenBSD routing domain 'rdomain' for the DNS connection.

-m fragsize

Force maximum downstream fragment size. Not setting this will cause the client to automatically probe the maximum accepted downstream fragment size.

-M namelen

Maximum length of upstream hostnames, default 255. Usable range ca. 100 to 255. Use this option to scale back upstream bandwidth in favor of downstream bandwidth. Also useful for DNS servers that perform unreliably when using full-length hostnames, noticeable when fragment size autoprobe returns very different results each time.

-T dnstype

DNS request type override. By default, autodetection will probe for working DNS request types, and will select the request type that is expected to provide the most bandwidth. However, it may turn out that a DNS relay imposes limits that skew the picture, which may lead to an "unexpected" DNS request type providing more bandwidth. In that case, use this option to override the autodetection. In (expected) decreasing bandwidth order, the supported DNS request types are: NULL, PRIVATE, TXT, SRV, MX, CNAME and A (returning CNAME). Note that SRV, MX and A may/will cause additional lookups by "smart" caching nameservers to get an actual IP address, which may either slow down or fail completely. The PRIVATE type uses value 65399 (in the 'private use' range) and requires servers implementing RFC 3597.

-O downenc

Force downstream encoding type for all query type responses except NULL. Default is autodetected, but may not spot all problems for the more advanced codecs. Use this option to override the autodetection. Base32 is the lowest-grade codec and should always work; this is used when autodetection fails. Base64 provides more bandwidth, but may not work on all nameservers. Base64u is equal to Base64 except in using underscore ('_') instead of plus sign ('+'), possibly working where Base64 does not. Base128 uses high byte values (mostly accented letters in iso8859-1), which might work with some nameservers. For TXT queries, Raw will provide maximum performance, but this will only work if the nameserver path is fully 8-bit-clean for responses that are assumed to be "legible text".

-L 0|1

Lazy-mode switch. -L1 (default): Use lazy mode for improved performance and decreased latency. A very small minority of DNS relays appears to be unable to handle the lazy mode traffic pattern, resulting in no or very little data coming through. The iodine client will detect this and try to switch back to legacy mode, but this may not always work. In these situations use -L0 to force running in legacy mode (implies -I1).

-I interval

Maximum interval between requests (pings) so that intermediate DNS servers will not time out. Default is 4 in lazy mode, which will work fine in most cases. When too many SERVFAIL errors occur, iodine will automatically reduce this to 1. To get absolute minimum DNS traffic, increase well above 4, but not so high that SERVFAIL errors start to occur. There are some DNS relays with very small timeouts, notably dnsadvantage.com (ultradns), that will give SERVFAIL errors even with -I1; data will still get trough, and these errors can be ignored. Maximum useful value is 59, since iodined will close a client's connection after 60 seconds of inactivity.

### Server Options:
-c

Disable checking the client IP address on all incoming requests. By default, requests originating from non-matching IP addresses will be rejected, however this will cause problems when requests are routed via a cluster of DNS servers.

-s

Don't try to configure IP address or MTU. This should only be used if you have already configured the device that will be used.

-D

Increase debug level. Level 1 prints info about each RX/TX packet. Implies the -f option. On level 2 (-DD) or higher, DNS queries will be printed literally. When using Base128 upstream encoding, this is best viewed as ISO Latin-1 text instead of (illegal) UTF-8. This is easily done with : "LC_ALL=C luit iodined -DD ..." (see luit(1)).

-m mtu

Set 'mtu' as mtu size for the tun device. This will be sent to the client on login, and the client will use the same mtu for its tun device. Default 1130. Note that the DNS traffic will be automatically fragmented when needed.

-l listen_ip

Make the server listen only on 'listen_ip' for incoming requests. By default, incoming requests are accepted from all interfaces.

-p port

Make the server listen on 'port' instead of 53 for traffic. If 'listen_ip' does not include localhost, this 'port' can be the same as 'dnsport'. Note: You must make sure the dns requests are forwarded to this port yourself.

-n auto|external_ip

The IP address to return in NS responses. Default is to return the address used as destination in the query. If external_ip is 'auto', iodined will use externalip.net web service to retrieve the external IP of the host and use that for NS responses.

-b dnsport

If this port is specified, all incoming requests not inside the tunnel domain will be forwarded to this port on localhost, to be handled by a real dns. If 'listen_ip' does not include localhost, this 'dnsport' can be the same as 'port'. Note: The forwarding is not fully transparent, and not advised for use in production environments.

-i max_idle_time

Make the server stop itself after max_idle_time seconds if no traffic have been received. This should be combined with systemd or upstart on demand activation for being effective.

### Client Arguments:
nameserver

The nameserver to use to relay the dns traffic. This can be any relaying nameserver or the server running iodined if reachable. This field can be given as an IPv4/IPv6 address or as a hostname. This argument is optional, and if not specified a nameserver will be read from the /etc/resolv.conf file.

topdomain

The dns traffic will be sent as queries for subdomains under ´topdomain'. This is normally a subdomain to a domain you own. Use a short domain name to get better throughput. If nameserver is the iodined server, then the topdomain can be chosen freely. This argument must be the same on both the client and the server.

### Server Arguments:
tunnel_ip[/netmask]

This is the server's ip address on the tun interface. The client will be given the next ip number in the range. It is recommended to use the 10.0.0.0 or 172.16.0.0 ranges. The default netmask is /27, can be overridden by specifying it here. Using a smaller network will limit the number of concurrent users.

topdomain

The dns traffic is expected to arrive as queries for subdomains under 'topdomain'. This is normally a subdomain to a domain you own. Use a short domain name to get better throughput. This argument must be the same on both the client and the server. Queries for domains other than 'topdomain' will be forwarded when the -b option is given, otherwise they will be dropped.

## EXAMPLES
See the README file for both a quick test scenario, and a detailed description of real-world deployment.

## SECURITY
Login is a relatively secure challenge-response MD5 hash, with the password never passing the wire. However, all other data is NOT encrypted in any way. The DNS traffic is also vulnerable to replay, injection and man-in-the-middle attacks, especially when iodined is used with the -c option. Use of ssh or vpn tunneling is strongly recommended. On both server and client, use iptables, pf or other firewalls to block all traffic coming in from the tun interfaces, except to the used ssh or vpn ports.

## ENVIRONMENT

### IODINE_PASS
If the environment variable IODINE_PASS is set, iodine will use the value it is set to as password instead of asking for one. The -P option still has precedence.

### IODINED_PASS
If the environment variable IODINED_PASS is set, iodined will use the value it is set to as password instead of asking for one. The -P option still has precedence.

## SEE ALSO
The README file in the source distribution contains some more elaborate information.

## BUGS
File bugs at http://dev.kryo.se/iodine/

## AUTHORS
Erik Ekman <yarrick@kryo.se> and Bjorn Andersson <flex@kryo.se>. Major contributions by Anne Bezemer.


iodined

package: iodine-server

title: iodined(8)

summary: tunnel IPv4 over DNS

text:
# iodined(8)

## NAME
iodine, iodined - tunnel IPv4 over DNS

## SYNOPSIS
iodine [-v]

iodine [-h]

iodine [-4] [-6] [-f] [-r] [-u user ] [-P password ] [-m fragsize ] [-t chrootdir ] [-d device ] [-R rdomain ] [-m fragsize ] [-M namelen ] [-z context ] [-F pidfile ] [-T dnstype ] [-O downenc ] [-L 0|1 ] [-I interval ] [ nameserver ] topdomain

iodined [-v]

iodined [-h]

iodined [-c] [-s] [-f] [-D] [-u user ] [-t chrootdir ] [-d device ] [-m mtu ] [-l listen_ip ] [-p port ] [-n ( auto | external_ip ) ] [-b dnsport ] [-P password ] [-z context ] [-F pidfile ] [-i max_idle_time ] tunnel_ip [ /netmask ] topdomain

## DESCRIPTION
iodine lets you tunnel IPv4 data through a DNS server. This can be useful in situations where Internet access is firewalled, but DNS queries are allowed. It needs a TUN/TAP device to operate. The bandwidth is asymmetrical, with a measured maximum of 680 kbit/s upstream and 2.3 Mbit/s downstream in a wired LAN test network. Realistic sustained throughput on a Wifi network using a carrier-grade DNS cache has been measured at some 50 kbit/s upstream and over 200 kbit/s downstream. iodine is the client application, iodined is the server.

Note: server and client are required to speak the exact same protocol. In most cases, this means running the same iodine version. Unfortunately, implementing backward and forward protocol compatibility is usually not feasible.

## OPTIONS

### Common Options:
-v

Print version info and exit.

-h

Print usage info and exit.

-f

Keep running in foreground.

-u user

Drop privileges and run as user 'user' after setting up tunnel.

-t chrootdir

Chroot to 'chrootdir' after setting up tunnel.

-d device

Use the TUN device 'device' instead of the normal one, which is dnsX on Linux and otherwise tunX.

-P password

Use 'password' to authenticate. If not used, stdin will be used as input. Only the first 32 characters will be used.

-z context

Apply SELinux 'context' after initialization.

-F pidfile

Create 'pidfile' and write process id in it.

### Client Options:
-4

Force IPv4 DNS queries

-6

Force IPv6 DNS queries

-r

Skip raw UDP mode. If not used, iodine will try getting the public IP address of the iodined host and test if it is reachable directly. If it is, traffic will be sent to the server instead of the DNS relay.

-R rdomain

Use OpenBSD routing domain 'rdomain' for the DNS connection.

-m fragsize

Force maximum downstream fragment size. Not setting this will cause the client to automatically probe the maximum accepted downstream fragment size.

-M namelen

Maximum length of upstream hostnames, default 255. Usable range ca. 100 to 255. Use this option to scale back upstream bandwidth in favor of downstream bandwidth. Also useful for DNS servers that perform unreliably when using full-length hostnames, noticeable when fragment size autoprobe returns very different results each time.

-T dnstype

DNS request type override. By default, autodetection will probe for working DNS request types, and will select the request type that is expected to provide the most bandwidth. However, it may turn out that a DNS relay imposes limits that skew the picture, which may lead to an "unexpected" DNS request type providing more bandwidth. In that case, use this option to override the autodetection. In (expected) decreasing bandwidth order, the supported DNS request types are: NULL, PRIVATE, TXT, SRV, MX, CNAME and A (returning CNAME). Note that SRV, MX and A may/will cause additional lookups by "smart" caching nameservers to get an actual IP address, which may either slow down or fail completely. The PRIVATE type uses value 65399 (in the 'private use' range) and requires servers implementing RFC 3597.

-O downenc

Force downstream encoding type for all query type responses except NULL. Default is autodetected, but may not spot all problems for the more advanced codecs. Use this option to override the autodetection. Base32 is the lowest-grade codec and should always work; this is used when autodetection fails. Base64 provides more bandwidth, but may not work on all nameservers. Base64u is equal to Base64 except in using underscore ('_') instead of plus sign ('+'), possibly working where Base64 does not. Base128 uses high byte values (mostly accented letters in iso8859-1), which might work with some nameservers. For TXT queries, Raw will provide maximum performance, but this will only work if the nameserver path is fully 8-bit-clean for responses that are assumed to be "legible text".

-L 0|1

Lazy-mode switch. -L1 (default): Use lazy mode for improved performance and decreased latency. A very small minority of DNS relays appears to be unable to handle the lazy mode traffic pattern, resulting in no or very little data coming through. The iodine client will detect this and try to switch back to legacy mode, but this may not always work. In these situations use -L0 to force running in legacy mode (implies -I1).

-I interval

Maximum interval between requests (pings) so that intermediate DNS servers will not time out. Default is 4 in lazy mode, which will work fine in most cases. When too many SERVFAIL errors occur, iodine will automatically reduce this to 1. To get absolute minimum DNS traffic, increase well above 4, but not so high that SERVFAIL errors start to occur. There are some DNS relays with very small timeouts, notably dnsadvantage.com (ultradns), that will give SERVFAIL errors even with -I1; data will still get trough, and these errors can be ignored. Maximum useful value is 59, since iodined will close a client's connection after 60 seconds of inactivity.

### Server Options:
-c

Disable checking the client IP address on all incoming requests. By default, requests originating from non-matching IP addresses will be rejected, however this will cause problems when requests are routed via a cluster of DNS servers.

-s

Don't try to configure IP address or MTU. This should only be used if you have already configured the device that will be used.

-D

Increase debug level. Level 1 prints info about each RX/TX packet. Implies the -f option. On level 2 (-DD) or higher, DNS queries will be printed literally. When using Base128 upstream encoding, this is best viewed as ISO Latin-1 text instead of (illegal) UTF-8. This is easily done with : "LC_ALL=C luit iodined -DD ..." (see luit(1)).

-m mtu

Set 'mtu' as mtu size for the tun device. This will be sent to the client on login, and the client will use the same mtu for its tun device. Default 1130. Note that the DNS traffic will be automatically fragmented when needed.

-l listen_ip

Make the server listen only on 'listen_ip' for incoming requests. By default, incoming requests are accepted from all interfaces.

-p port

Make the server listen on 'port' instead of 53 for traffic. If 'listen_ip' does not include localhost, this 'port' can be the same as 'dnsport'. Note: You must make sure the dns requests are forwarded to this port yourself.

-n auto|external_ip

The IP address to return in NS responses. Default is to return the address used as destination in the query. If external_ip is 'auto', iodined will use externalip.net web service to retrieve the external IP of the host and use that for NS responses.

-b dnsport

If this port is specified, all incoming requests not inside the tunnel domain will be forwarded to this port on localhost, to be handled by a real dns. If 'listen_ip' does not include localhost, this 'dnsport' can be the same as 'port'. Note: The forwarding is not fully transparent, and not advised for use in production environments.

-i max_idle_time

Make the server stop itself after max_idle_time seconds if no traffic have been received. This should be combined with systemd or upstart on demand activation for being effective.

### Client Arguments:
nameserver

The nameserver to use to relay the dns traffic. This can be any relaying nameserver or the server running iodined if reachable. This field can be given as an IPv4/IPv6 address or as a hostname. This argument is optional, and if not specified a nameserver will be read from the /etc/resolv.conf file.

topdomain

The dns traffic will be sent as queries for subdomains under ´topdomain'. This is normally a subdomain to a domain you own. Use a short domain name to get better throughput. If nameserver is the iodined server, then the topdomain can be chosen freely. This argument must be the same on both the client and the server.

### Server Arguments:
tunnel_ip[/netmask]

This is the server's ip address on the tun interface. The client will be given the next ip number in the range. It is recommended to use the 10.0.0.0 or 172.16.0.0 ranges. The default netmask is /27, can be overridden by specifying it here. Using a smaller network will limit the number of concurrent users.

topdomain

The dns traffic is expected to arrive as queries for subdomains under 'topdomain'. This is normally a subdomain to a domain you own. Use a short domain name to get better throughput. This argument must be the same on both the client and the server. Queries for domains other than 'topdomain' will be forwarded when the -b option is given, otherwise they will be dropped.

## EXAMPLES
See the README file for both a quick test scenario, and a detailed description of real-world deployment.

## SECURITY
Login is a relatively secure challenge-response MD5 hash, with the password never passing the wire. However, all other data is NOT encrypted in any way. The DNS traffic is also vulnerable to replay, injection and man-in-the-middle attacks, especially when iodined is used with the -c option. Use of ssh or vpn tunneling is strongly recommended. On both server and client, use iptables, pf or other firewalls to block all traffic coming in from the tun interfaces, except to the used ssh or vpn ports.

## ENVIRONMENT

### IODINE_PASS
If the environment variable IODINE_PASS is set, iodine will use the value it is set to as password instead of asking for one. The -P option still has precedence.

### IODINED_PASS
If the environment variable IODINED_PASS is set, iodined will use the value it is set to as password instead of asking for one. The -P option still has precedence.

## SEE ALSO
The README file in the source distribution contains some more elaborate information.

## BUGS
File bugs at http://dev.kryo.se/iodine/

## AUTHORS
Erik Ekman <yarrick@kryo.se> and Bjorn Andersson <flex@kryo.se>. Major contributions by Anne Bezemer.


iotop

package: iotop

title: iotop(8)

summary: simple top\-like I/O monitor

text:
# iotop(8)

## NAME
iotop - simple top-like I/O monitor

## SYNOPSIS
iotop [OPTIONS]

## DESCRIPTION
iotop watches I/O usage information output by the Linux kernel (requires 2.6.20 or later) and displays a table of current I/O usage by processes or threads on the system. At least the CONFIG_TASK_DELAY_ACCT, CONFIG_TASK_IO_ACCOUNTING, CONFIG_TASKSTATS and CONFIG_VM_EVENT_COUNTERS options need to be enabled in your Linux kernel build configuration.

iotop displays columns for the I/O bandwidth read and written by each process/thread during the sampling period. It also displays the percentage of time the thread/process spent while swapping in and while waiting on I/O. For each process, its I/O priority (class/level) is shown.

In addition, the total I/O bandwidth read and written during the sampling period is displayed at the top of the interface. Total DISK READ and Total DISK WRITE values represent total read and write bandwidth between processes and kernel threads on the one side and kernel block device subsystem on the other. While Actual DISK READ and Actual DISK WRITE values represent corresponding bandwidths for actual disk I/O between kernel block device subsystem and underlying hardware (HDD, SSD, etc.). Thus Total and Actual values may not be equal at any given moment of time due to data caching and I/O operations reordering that take place inside Linux kernel.

Use the left and right arrows to change the sorting, r to reverse the sorting order, o to toggle the --only option, p to toggle the --processes option, a to toggle the --accumulated option, q to quit or i to change the priority of a thread or a process' thread(s). Any other key will force a refresh.

## OPTIONS
--version

Show the version number and exit

-h, --help

Show usage information and exit

-o, --only

Only show processes or threads actually doing I/O, instead of showing all processes or threads. This can be dynamically toggled by pressing o.

-b, --batch

Turn on non-interactive mode. Useful for logging I/O usage over time.

-n NUM, --iter=NUM

Set the number of iterations before quitting (never quit by default). This is most useful in non-interactive mode.

-d SEC, --delay=SEC

Set the delay between iterations in seconds (1 second by default). Accepts non-integer values such as 1.1 seconds.

-p PID, --pid=PID

A list of processes/threads to monitor (all by default).

-u USER, --user=USER

A list of users to monitor (all by default)

-P, --processes

Only show processes. Normally iotop shows all threads.

-a, --accumulated

Show accumulated I/O instead of bandwidth. In this mode, iotop shows the amount of I/O processes have done since iotop started.

-k, --kilobytes

Use kilobytes instead of a human friendly unit. This mode is useful when scripting the batch mode of iotop. Instead of choosing the most appropriate unit iotop will display all sizes in kilobytes.

-t, --time

Add a timestamp on each line (implies --batch). Each line will be prefixed by the current time.

-q, --quiet

suppress some lines of header (implies --batch). This option can be specified up to three times to remove header lines.

-q

column names are only printed on the first iteration,

-qq

column names are never printed,

-qqq

the I/O summary is never printed.

## SEE ALSO
ionice(1), top(1), vmstat(1), atop(1), htop(1)

## AUTHOR
iotop was written by Guillaume Chazarain.

This manual page was started by Paul Wise for the Debian project and is placed in the public domain.


iotop-c

package: iotop-c

title: iotop-c(8)

summary: simple top\-like I/O monitor

text:
# iotop-c(8)

## NAME
iotop - simple top-like I/O monitor

## SYNOPSIS
iotop [OPTIONS]

## DESCRIPTION
iotop watches I/O usage information available in the Linux kernel (requires 2.6.20 or later) and displays a table of current I/O usage by processes or threads on the system. At least the CONFIG_TASK_DELAY_ACCT, CONFIG_TASK_IO_ACCOUNTING, CONFIG_TASKSTATS and CONFIG_VM_EVENT_COUNTERS options need to be enabled in your Linux kernel build configuration.

Running iotop as non-root user is possible by adding the NET_ADMIN capability. This can be done by e.g.:

$ sudo setcap 'cap_net_admin+eip' <path-to>/iotop

Be warned that this will also allow other users to run it and get access to information that normally should not be available to them. iotop displays columns for the I/O bandwidth read and written by each process/thread during the sampling period. It also displays the percentage of time the thread/process spent while swapping in and while waiting on I/O. For each process, its I/O priority (class/level) is shown.

In addition, the total I/O bandwidth read and written during the sampling period are displayed at the top of the interface. Total DISK READ and Total DISK WRITE values represent total read and write bandwidth between processes and kernel threads on one side and kernel block device subsystem on the other. While Current DISK READ and Current DISK WRITE values represent corresponding bandwidths for current disk I/O between the kernel block device subsystem and the underlying hardware (HDD, SSD, etc.). Thus Total and Current values may not be equal at any given moment of time due to data caching and I/O operations reordering that take place inside the Linux kernel.

Use the left and right arrows to select the sort column, r or space to reverse the sorting order, o to toggle the --only option (this uses the visible values from the GRAPH column or the IO column in case the GRAPH column is hidden), p to toggle the --processes option, a to cycle between the --accumulated, --accum-bw and normal operation, i to change the priority of a thread or a process's thread, f to change filtering by UID/PID (--user and --pid options), 1-9 to toggle the visibility of the respective column, 0 to show all columns, up/down arrows, page-up/page-down/home/end keys to scroll and q to quit. Any unrecognized key will be ignored.

All processes or threads that have exited are displayed grayed for the same time as is visible in the GRAPH column or 3 seconds when it is hidden. The invalid data points in the GRAPHS column are displayed inverse or with letter x (see option --dead-x and x shortcut). When using unicode characters each position contains two datapoints and only the positions with two invalid data points are reversed.

It is possible for threads of a process to have different priority from their main process. This is shown with ! in the PRIO column of the main process as e.g. !be/4.

Threads activity is always aggregated with and shown inside the main process.

When showing threads, they always appear below their main process and are sorted in the same way as the processes.

There are two ways to change the IO priority of a process or thread - press i and use arrows to select the process or thread from the visible ones on screen or press i and type its TID (PID and TID have the same value for the main process). Then use tab and arrows to change the priority value and confirm with enter. Shortcuts esc or q will cancel this mode.

To change the UID and PID filters, press f and use tab to select the UID or PID field, then type the numerical id or n to remove the filter and confirm with enter. Filtering is always done by TID because it is unique. Note that for the main process PID is the same as TID. Shortcuts esc or q will cancel this mode.

Starting with Linux kernel 5.14.x task_delayacct is configurable at runtime and set to off by default. This setting can be changed in interactive mode by the Ctrl-T shortcut. In batch mode a warning is printed when the setting is OFF. From the command line this can be enabled by:

$ sudo sysctl kernel.task_delayacct=1

and disabled again by: $ sudo sysctl kernel.task_delayacct=0

It is advisable to keep this option off when not using this or another monitoring program because when enabled it has some effect on system performance.

## OPTIONS
-v, --version

Show the version number and exit

-h, --help

Show usage information and exit

-H, --help-type=TYPE

Set the type of interactive help shown. Accepted values for TYPE are none, win and inline.

-o, --only

Only show processes or threads actually doing I/O, instead of showing all processes or threads. This can be dynamically toggled by pressing o

--no-only

Show all processes or threads

-b, --batch

Turn on non-interactive mode. Useful for logging I/O usage over time

-n NUM, --iter=NUM

Set the number of iterations before quitting (never quit by default). This is most useful in non-interactive mode

-d SEC, --delay=SEC

Set the delay between iterations in seconds (1 second by default). Accepts non-integer values such as 1.1 seconds

-p PID, --pid=PID

A process/thread id to monitor (all by default)

-u USER, --user=USER

A user id to monitor (all by default). The value will always be resolved first unless it is prefixed by + in which case it is treated as numeric only. Values that do not resolve but appear to be numeric are used as numeric

-P, --processes

Only show processes. Normally iotop shows processes and all threads

--no-processes

Show processes and all threads

-a, --accumulated

Show accumulated I/O instead of bandwidth. In this mode, iotop shows the amount of I/O processes have done since the process or iotop started. Note that this option and --accum-bw are exclusive and they will turn each other off

--no-accumulated

Show bandwidth (useful when changing config file with --write)

-A, --accum-bw

Show accumulated I/O as bandwidth for the whole sampling period. In this mode, iotop shows the amount of I/O per second for the whole period since the process or iotop started Note that this option and --accumulated are exclusive and they will turn each other off

--no-accum-bw

Show bandwidth (useful when changing config file with --write)

-k, --kilobytes

Use kilobytes instead of a human friendly unit. This mode is useful when scripting the batch mode of iotop. Instead of choosing the most appropriate unit iotop will display all sizes in kilobytes

--no-kilobytes

Use human friendly units

-t, --time

Add a timestamp on each line (implies --batch). Each line will be prefixed by the current time

-c, --fullcmdline

Show processes' full file path and parameters

--no-fullcmdline

Show processes' names only

-1, --hide-pid

Hide PID/TID column

--show-pid

Show PID/TID column

-2, --hide-prio

Hide PRIO column

--show-prio

Show PRIO column

-3, --hide-user

Hide USER column

--show-user

Show USER column

-4, --hide-read

Hide DISK READ column

--show-read

Show DISK READ column

-5, --hide-write

Hide DISK WRITE column

--show-write

Show DISK WRITE column

-6, --hide-swapin

Hide SWAPIN column

--show-swapin

Show SWAPIN column

-7, --hide-io

Hide IO column

--show-io

Show IO column

-8, --hide-graph

Hide GRAPH column

--show-graph

Show GRAPH column

-9, --hide-command

Hide COMMAND column

--show-command

Show COMMAND column

-g TYPE, --grtype=TYPE

Set GRAPH column data source. Accepted values for TYPE are io, r, w, rw and sw.

-R, --reverse-graph

Reverse GRAPH direction - show most recent values on the right side

--no-reverse-graph

Do not reverse GRAPH direction - show most recent values on the left side

-q, --quiet

Suppress some lines of header (implies --batch). This option can be specified up to three times to remove header lines

-q

column names are only printed on the first iteration,

-qq

column names are never printed,

-qqq

the I/O summary is never printed

-x, --dead-x

Show exited processes/threads with letter x instead of inverse background

--no-dead-x

Show exited processes/threads with inverse background

-e, --hide-exited

Hide exited processes

--show-exited

Show exited processes

-l, --no-color

Do not colorize values

--color

Colorize values. This will override the effect of the environment variable NO_COLOR when explicitly specified on the command line.

-T, --hide-time

Do not show time clock in upper right corner

--show-time

Show time clock in upper right corner

--si

Use SI units of 1000 when printing values. The default is non-SI 1024

--no-si

Use non-SI units of 1024 when printing values

--threshold=1..10

Set the threshold to switch to next unit. The default value is 2

--ascii

Disable using Unicode

--unicode

Use Unicode drawing chars

-W, --write

Merge the preceding options to the current config, save the config and exit. Note that all options after this one will be ignored.

## KEYBOARD SHORTCUTS
q, Q

Exit

W

Save current settings to configuration file in $HOME/.config/iotop/iotoprc

D

Reset all settings to their default values

<space>, r

Toggle sort order

<home>

Scroll to the top of the list

<end>

Scroll to the bottom of the list

<page-up>

Scroll one screen up

<page-down>

Scroll one screen down

<up>

Scroll one line up

<down>

Scroll one line down

<right>

Sort by next column

<left>

Sort by previous column

<esc>

Cancel ionice or filter selection. In case only the help window is open then close it

o, O

Toggle showing only processes with IO activity

p, P

Toggle showing processes/threads

a, A

Cycle showing accumulated/accum-bw/current values

?

Toggle showing inline help

h, H

Toggle showing window help

c, C

Toggle showing full command line

1, 2, 3, 4, 5, 6, 7, 8, 9

Toggle showing the column (column number corresponds to the shortcut)

0

Show all columns

g, G

Cycle GRAPH source (IO=IO, R=DISK READ , W=DISK WRITE, R+W=DISK READ+DISK WRITE, SW=SWAPIN). Using g will cycle forward and G will cycle backward.

R

Toggle reverse GRAPH direction

i, I

IOnice a process/thread (depends on process/thread display mode)

f, F

Change UID and PID filters

u, U

Toggle using Unicode/ASCII characters for pseudo graph

l, L

Toggle colorizing values

x, X

Toggle the display mode of exited processes/threads between letter x and inverse background

e, E

Toggle the display of exited processes

T

Toggle the display of time clock in upper right corner

s, S

Toggle freeze of data collection

Ctrl-B, b

Toggle SI units

Ctrl-R, t

Cycle unit threshold

Ctrl-T

Toggle task_delayacct kernel sysctl

Ctrl-L

Redraw screen

/

Change search regular expression. While the search regular expression is being edited, there is an indicator next to it that shows if the expression is valid. The search is confirmed by <enter> or cancelled by <esc>. List of shortcuts in the editor:

<esc>

Cancel editing and remove the regular expression filter

<enter>

Confirm the current regular expression and exit edit mode. In case the regular expression is empty or invalid it will match everything.

Alt/Meta-<backspace>, Ctrl-W

Delete one word from cursor to the left

Alt/Meta-D

Delete one word from cursor to the right

Alt/Meta-B, Ctrl-<left>

Move the cursor to the beginning of the word on the left

Alt/Meta-F, Ctrl-<right>

Move the cursor after the end of the word on the right

Ctrl-A, <home>

Move the cursor to the leftmost position

Ctrl-E, <end>

Move the cursor after the last character

Ctrl-B, <left>

Move the cursor to the left

Ctrl-F, <right>

Move the cursor to the right

Ctrl-H, <backspace>

Delete the character left of cursor

Ctrl-D, <del>

Delete the character under the cursor

Ctrl-K

Delete from the character under the cursor to the end of the line

Ctrl-U

Delete everything

[anything-else]

Non-printable characters are ignored. Normal characters are inserted before the character under the cursor. UTF-8 sequences are parsed and treated as a single character. Unicode combining characters will be appended to the character under the cursor.

## ENVIRONMENT
As per the recommendation of https://www.no-color.org/ iotop honors the contents of the environment variable NO_COLOR and when it is set to a non empty string, all color output is suppressed.

## SEE ALSO
ionice(1), top(1), vmstat(1), atop(1), htop(1)

## AUTHOR
The original Python iotop implementation was written by Guillaume Chazarain. This rewrite in C was started in 2014 by Vyacheslav Trushkin and reworked to include all missing features from the original Python code and several new ones from 2020 to 2024 by Boian Bonev.

This manual page was started by Paul Wise for the Debian project and is placed in the public domain.