File Formats

intro

intro—Introduction to file formats.

DESCRIPTION

This chapter describes various file formats and protocols, and the used C structures, if any.

AUTHORS

Look at the header of the manual page for the authors and copyright conditions. Note that these can be different from page to page!

Linux, 24 July 1993

active, active.times

active, active.times—List of active Usenet newsgroups.

DESCRIPTION

The file /news/lib/active lists the newsgroups that the local site receives. Each newsgroup should be listed only once. Each line specifies one group; their order in the file does not matter. Within each newsgroup, articles are assigned unique names, which are monotonically increasing numbers.

If an article is posted to newsgroups not mentioned in this file, those newsgroups are ignored. If no valid newsgroups are specified, the article is filed into the newsgroup “junk” and only propagated to sites that receive the “junk” newsgroup.

Each line consists of four fields specified by a space:

name himark lomark flags

The first field is the name of the newsgroup. Newsgroups that start with the three characters to. are treated specially; see innd(8). The second field is the highest article number that has been used in that newsgroup. The third field is the lowest article number in the group; this number is not guaranteed to be accurate and should only be taken as a hint. Note that because of article cancellations, there may be gaps in the numbering sequence. If the lowest article number is greater than the highest article number, there are no articles in the newsgroup. To make it possible to update an entry in-place without rewriting the entire file, the second and third fields are padded with leading zeros to make them a fixed width.

The fourth field can contain one of the following flags:

If a newsgroup has the j flag, then no articles will be filed into that newsgroup and local postings to that group should not be generated. If an article for such a newsgroup is received from a remote site, it will be filed into the “junk” newsgroup if it is not cross-posted. This is different from not having a newsgroup listed in the file because sites can subscribe to j newsgroups and the article will be propagated to them.

If the fourth field of a newsgroup starts with an equal sign, then the newsgroup is an alias. Articles can be posted to the group but will be treated as if they were posted to the group named after the equal sign. The second and third fields are ignored. Note that the newsgroup header is not modified (Alias groups are typically used during a transition and are typically created with ctlinnd(8)). An alias newsgroup should not point to another alias.

aliases

aliases—Aliases file for sendmail.

SYNOPSIS

aliases

DESCRIPTION

This file describes user ID aliases used by . The file resides in and is formatted as a series of lines of the form:

name: name_1, name_2, name_3, ...

The name is the name to alias, and the name_n are the aliases for that name. Lines beginning with whitespace are continuation lines. Lines beginning with # are comments.

Aliasing occurs only on local names. Loops cannot occur because no message will be sent to any person more than once.

After aliasing has been done, local and valid recipients who have a .forward file in their home directory have messages forwarded to the list of users defined in that file.

This is only the raw data file; the actual aliasing information is placed into a binary format in the files and using the program newaliases(1). A newaliases command should be executed each time the aliases file is changed for the change to take effect.

SEE ALSO

newaliases(1), dbm(3), sendmail(8), “Sendmail Installation and Operation Guide,” “Sendmail: An Internetwork Mail Router.”

BUGS

Because of restrictions in dbm(3), a single alias cannot contain more than about 1000 bytes of information. You can get longer aliases by “chaining”—that is, making the last name in the alias a dummy name that is a continuation alias.

HISTORY

The aliases file format appeared in BSD 4.0.

BSD 4, 10 May 1991

cfingerd

cfingerd—Configurable finger daemon.

SYNOPSIS

–c checks your installed configuration. This makes sure there are no existing errors in the current cfingerd.conf file.

–d runs cfingerd as a daemon. Don’t run cfingerd this way if you’re using inetd.

–e allows you to emulate a local finger on a user that exists on your system. This makes it so that you can test cfingerd on your system before installing it. Using the –e directive is the same as installing the software, typing finger username@ and getting the output. Using –e username does the same.

cfingerd 1107

–o turns off all finger queries. This makes it so that no one can finger your system—no matter what they try to do.

–v requests cfingerd version information.

DESCRIPTION

cfingerd is a totally new and totally configurable finger daemon—one of the first. It utilizes the finger port (port 79) to provide useful information on each user on your system. However, cfingerd provides a unique twist.

cfingerd was designed for the sole purpose of making output on finger queries configurable. If you want to change any text that is displayed during finger queries, you can configure the finger daemon to display just about anything you want.

cfingerd also takes into account any security breaches and attempts to close them. With .nofinger files, this is displayed instead of finger information, making it possible for users to keep themselves relatively anonymous from outside users.

WHY WAS IT DONE?

The answer is simple: security. Many sites turn off finger for the reason that they don’t want outside users to see who’s on their system or get information about a specific user on their system. This seemed unfair to the rest of the users out there, so this program was created. Those sites were waiting for this type of program. Many sites that originally had their finger turned off turned them back on because of cfingerd.

Many sites complained that they wanted the capability to create a fake user or a user that doesn’t exist but calls a prewritten shell script. cfingerd takes this into account and provides the best method possible for creating such scripts. (See cfingerd.conf(5) for more information on the configuration file.)

FEATURES cfingerd PROVIDES AND DESCRIPTIONS OF EACH

cfingerd was totally rewritten. Why is this? The older version of cfingerd had quite a few bugs, and it didn’t quite do all the things that cfingerd now does. This new version was totally revamped, and most of the bugs that were in the older version of cfingerd were removed in this one. The code is also more compact.

Header and footer displays were a big part of the original release of cfingerd and shall continue to remain in all versions. Headers and footers are only displays at the beginning and ending of all finger displays and are used as unique little advertisements.

The last time displayed is always a critical issue. It’s covered in cfingerd. cfingerd simply shows how many times this user is connected, what their idle time is on each tty they’re connected to, and whether they are accepting messages. If they’re not accepting messages, a display will be shown. This display also shows the last time mail was read and whether this user has mail.

Stand-alone and inetd support is compiled into the program, but only inetd support is given for the time being. The reason is that I have not yet added the option for stand-alone daemon mode.

.nofinger files are used when a user wants to remain anonymous. These files should be placed in their home directories and can display anything they want. There’s just a few restrictions. These .nofinger display files cannot be character devices, directories, FIFOs, soft or hard links, or anything else of that caliber. They must only be normal files.

Fake users were supported for the simple fact that many sites want to create users who don’t exist and make them execute a shell. If you want this done, install a fake user. Read cfingerd.conf(5) for more information on these useful options.

Service displays were used to show what fake users you have installed on your system. These can be formatted however you want and are explained in cfingerd.conf(5).

Searching for usernames is a powerful feature that cfingerd takes full advantage of. If you are looking for a specific username on the system or don’t know what their name is, simply use the search.username directive with cfingerd, and you can search for a user on your system.

Searching for usernames is not case sensitive. If you are searching for a specific username or part of the user’s name, chances are that it’ll be displayed.

cfingerd.conf 1109

I’ve received calls at work pertaining to the software, and although I appreciate the fact that people like the software I wrote, I’d appreciate it if you leave me e–mail and be considerate.

cfingerd is now being maintained by Michael Jarvis. Any additions after cfingerd 1.2.3 should be directed toward Michael. You can reach him at mjarvis@qns.com.

If you want to see other projects that Bitgate Software is currently developing, check out the Web page at http:// www.bitgate.com/. This will contain all the update information on the software that is being developed and that is already released.

SEE ALSO

cfingerd.conf(5), finger(1), userlist(1), syslog.conf(5)

cfingerd 1.2.3, 24 May 1996

cfingerd.conf

cfingerd.conf—Configurable finger daemon configuration file.

SYNOPSIS

/etc/cfingerd.conf

DESCRIPTION

cfingerd.conf is the configuration file for cfingerd. This has been totally rewritten to support a more readable configuration file. This version of the new configuration file is not compatible with the older versions from 1.0.3 or earlier.

Each line in the configuration file is split into three sections: FILES, CONFIG, and HOSTS. Each one of those sections is split into subsections.

Subtext of each option is either Boolean options, string options, or switchable options, all changeable by the system administrator.

Each section is split into a series of sections that resembles C-type definition; it’s not exact but close enough to be familiar. There’s only one exception: These are not case sensitive. Any casing will do as long as the option is legal.

Thus, each option is formatted like this:

OPTION sub_option_name = {

(tab/space) string_option = “string format”, (tab/space) boolean_option = [BOOL, BOOL], (tab/space) +/–internal_config_option (tab/space) host.name.here

}

This shows that string options are strings put into quotes, Boolean options are given as TRUE and FALSE, switchable options are given with the + or – directive, and hostnames are used as substrings so that wildcards are not necessary.

You can add comments using the hash mark (#) at the beginning of the line. Please note that no comments are allowed inside of an OPTION.

DISPLAY FILES SECTION (FILES display files)

Each option here is a string option. These are formatted as the example shows.

PLAN is the plan file that is used when displaying a plan. The standard here is .plan.

PROJECT is the project file that is used when displaying a project description. The standard here is .project.

PGP_KEY is the Pretty–Good–Privacy file that is shown when displaying a public or private key. The standard here is .pgpkey.

(The preceding three files must be world readable but should not be world writable. This makes sure that cfingerd can read the file once it becomes the “nobody” UID/GID. This is generally a good idea for protection.)

NO_FINGER is the file that is shown when a user wants to remain anonymous. This is usually the case with root users (which should be standard anyway). The standard here is .nofinger. This file can only be a standard displayable file.

LOGFILE is the file that is used to keep logs of everything that happens to both your system and the finger program. These logs are kept as backups for your finger file and can be used to guard against attacks against your system if a finger attack occurs. Remember, the cfingerd.conf file is root owned, so this file should be kept in a safe, hidden place.

HEADER_DISPLAY is the file that is displayed at the top of each finger display. The standard here is /etc/cfingerd/ top_finger.txt.

FOOTER_DISPLAY is the file that is displayed at the end of each finger display. The standard here is /etc/cfingerd/ bottom_finger.txt.

NO_USER_BANNER is the file that is displayed if the user doesn’t exist. The standard here is /etc/cfingerd/nouser_banner.txt.

NO_NAME_BANNER is the file that is displayed if no name was specified in a finger display. This is used in conjunction with the

SYSTEM_LIST option (explained later). The standard here is /etc/cfingerd/noname_banner.txt.

REJECTED_BANNER is the file that is displayed if a rejected host tries to finger your system for any reason. The standard here is / etc/cfingerd/rejected_banner.txt.

FINGER DISPLAY CONFIGURE SECTION (CONFIG finger display)

Each option in this section is Boolean. The way this works is as follows: The first Boolean option is the setting for a remote host or a host that fingers you from the outside. The second Boolean option is the setting for the local host or trusted host. This is what people from your own system will see.

Each option has a – or + option. This is for user–overridable options, which will be in the next release of cfingerd. These will allow users to manipulate if this information is displayed when that specific user is fingered.

HEADER_FILE displays the header file at the beginning of each finger query.

FOOTER_FILE displays the footer file at the end of each finger query.

LOGIN_ID displays the login ID of that particular user.

REAL_NAME displays the real name of that particular user.

DIRECTORY displays the user’s directory.

SHELL displays the user’s shell.

ROOM_NUMBER displays the user’s room number.

WORK_NUMBER displays the user’s work phone number.

HOME_NUMBER displays the user’s home phone number.

OTHER displays the user’s other information.

LAST_TIME_ON displays the last time the user logged into the fingered system.

IF_ONLINE displays whether the user is currently logged into the fingered system.

TIME_MAIL_READ displays the last time that the fingered user read mail.

DAY_MAIL_READ displays the last day that the fingered user read his or her mail.

ORIGINATION displays the site from which the user logged in (if applicable).

PLAN displays the user’s plan file.

PROJECT displays the user’s project file.

PGP displays the user’s Pretty–Good–Privacy key file.

cfingerd.conf 1111

NO_NAME_BANNER displays the banner if no username was given.

REJECTED_BANNER displays the rejected banner if the site fingering your system was in the banned–site listing.

SYSTEM_LIST displays the system list if one was requested.

NO_NAME displays the no–name display file if no user was selected.

INTERNAL CONFIG CONFIGURE SECTION (CONFIG internal config)

Each item in this section is a switchable option. This means that a + before the item is turned on and a – before the item is turned off.

ALLOW_MULTIPLE_FINGER_DISPLAY allows you to give a sorted output of all users on more than one specific system. This is useful when you have more than one ISP machine, located in different cities or even states.

ALLOW_SEARCHABLE_FINGER allows you to let others outside your system (or within it) to search for a specific username by using the search.username directive.

ALLOW_NO_IP_MATCH_FINGER allows you to let sites finger your system if a hostname could not be matched to their IP address successfully.

ALLOW_USER_OVERRIDE will allow your users to override specific options in the FINGER DISPLAY section that you enable.

ALLOW_USERLIST_ONLY will allow other sites that are fingering your system for a specific compiled user list to finger your system and get a user listing of who’s online. This could be a security risk, so you might want to turn this option off if you feel it’s a security risk.

ALLOW_FINGER_FORWARDING will allow other sites to forward finger requests to a different machine if the user could not be located on the current machine. (In order to use this option, you must have the HOSTS finger forward option set and have other sites in there.)

ALLOW_STRICT_FORMATTING makes the finger display remove all returns between display options. This makes the finger display look horrible (as with GNU Finger or the other generic fingers) and makes your system look, well, “generic.”

ALLOW_VERBOSE_TIMESTAMPING makes the timestamp that is displayed (at any place) very verbose. For instance, where it used to say

On since Sat Aug 12 03:43PM(PDT)

would now be shown as

On since Sat Aug 12, 1995 03:43PM(PDT)

(Basically, ALLOW_VERBOSE_TIMESTAMPING just takes up more room on the display field.)

ALLOW_NONIDENT_ACCESS lets you only allow connections from sites that run the ident daemon (or RFC 1413-compliant program.) This is for security sake and is a good measure against unknown users trying to finger your system. If this option is enabled, users who do not have identd running on their system (such as Windows users) will be able to finger your system. Systems not running identd will return unknown as the user ID and will not be permitted to finger a user on your system.

ALLOW_FINGER_LOGGING enables cfingerd to use the LOGFILE file to store any logs of activity that happen to your system via finger.

ALLOW_LINE_PARSING makes cfingerd parse each line of every display file (including the plan, project, and pgp files) for any cfingerd-specific $ commands. If any are found, cfingerd will parse these commands and display correct information accordingly. Otherwise, if this is turned off, the display will appear without parsed commands.

ALLOW_EXECUTION will allow users to execute scripts in place of their .plan, .project, and .pgp files. This is used to display the standard output of another program directly to the screen of the user. Keep in mind that this is a huge security risk if you choose to use it. It’s normally suggested that this option remain off, but you can turn it on if necessary. Nevertheless, these programs are called as nobody.nogroup.

ALLOW_FAKEUSER_FINGER turns on or off the fake user option in cfingerd. If you want fake users to be defined and available to be fingered, you will want to enable this option. This can be a security risk in some instances if you allow for searchable fingers and your script calls an execute routine on that variable. Chances are that’ll never happen.

ALLOW_USERLOG will allow users to keep track of who has fingered them and at what time. A little file called .fingerlog will appear in their directory, which they can examine to see who has fingered them. If you don’t care about this, you can disable it. Otherwise, it’s not a bad idea. (It also logs root fingers as well.)

SYSTEM LIST SITES CONFIGURE SECTION (CONFIG system list sites)

This is just a series of hostnames that you want to finger when displaying your user-list display. If you have more than one system that you want to show, simply put their hostname in this list, separated on a line by itself.

For example, if I have a separate ISP system that I’m running on the side, say chatlink.com, I would change my configuration to say

CONFIG system_list_sites = { chatlink.com, localhost }

Remember, if you are listing only a couple of sites, list the sites you will want to have listed (in order) first. The ending entry must be localhost or the finger listing will not include your site. If you include localhost anywhere else in the list, it will stop once it has reached the localhost entry, so remember to list it last!

I want to get a user listing from my own machine and from chatlink.com’s system. This would be automatically formatted nicely (sorted and parsed) and would display on the screen in sorted order. This program is usually used in tandem with the supplied userlist(1) program.

If no system list sites are specified, multiple system sites will not be specified.

TRUSTED HOST SECTION (HOSTS trusted)

This is a listing of the sites that you allow to finger your system exclusively, giving them the same access that your local users would get. In other words, they are treated as localhost users.

Each site that you list in this section should be separated by using the , directive. You can include up to 80 sites in this listing.

Wildcards are supported in this section, and you can use them in the regex format as well. Any wildcards with *, ?, or any other regex wildcard matching character will work. IP addresses will also work. Hostnames are compared case insensitive.

REJECTED HOST SECTION (HOSTS rejected)

This is a listing of the sites that you do not allow to finger your system. These sites don’t get to finger anyone (or anything for that matter) on your system, regardless of what they try to do. In essence, finger is cut off to that particular system.

Each site that you list in this section should be separated by using the , directive. You can include up to 80 sites in this listing.

Wildcards are supported in this section, and you can use them in the regex format as well. Any wildcards with *, ?, or any other regex wildcard matching character will work. IP addresses will also work. Hostnames are compared case insensitive.

FORWARDED HOST SECTION (HOSTS finger forward)

This is a listing of sites that are used to forward a finger query to when a finger request was processed but that particular user was not found on the associated system. It will step through this listing, and it will search for the user in question. If the user could not be found, then it will step through to the next host and the next, until it finds one.

Each site that you list in this section should be separated by using the , directive. You can include up to 80 sites in this listing.

Wildcards are supported in this section, and you can use them in the regex format as well. Any wildcards with *, ?, or any other regex wildcard matching character will work. Hostnames are compared case insensitive.

If you do not specify any forwarding sites in this section, finger forwarding will be disabled for your system.

cvs 1117

SYNOPSIS

$CVSROOT/CVSROOT/commitinfo,v $CVSROOT/CVSROOT/cvsignore,v $CVSROOT/CVSROOT/cvswrappers,v $CVSROOT/CVSROOT/editinfo,v $CVSROOT/CVSROOT/history $CVSROOT/CVSROOT/loginfo,v $CVSROOT/CVSROOT/modules,v $CVSROOT/CVSROOT/rcsinfo,v $CVSROOT/CVSROOT/taginfo,v

DESCRIPTION

cvs is a system for providing source control to hierarchical collections of source directories. Commands and procedures for using cvs are described in cvs(1). cvs manages source repositories, the directories containing master copies of the revisioncontrolled files, by copying particular revisions of the files to (and modifications back from) developers’ private working directories. In terms of file structure, each individual source repository is an immediate subdirectory of $CVSROOT. The files described here are supporting files; they do not have to exist for cvs to operate, but they allow you to make cvs operation more flexible.

You can use the modules file to define symbolic names for collections of source maintained with cvs. If there is no modules file, developers must specify complete pathnames (absolute or relative to $CVSROOT) for the files they want to manage with cvs commands. You can use the commitinfo file to define programs to execute whenever cvs commit is about to execute. These programs are used for “precommit” checking to verify that the modified, added, and removed files are really ready to be committed. Some uses for this check might be to turn off a portion (or all) of the source repository from a particular person or group or perhaps to verify that the changed files conform to the site’s standards for coding practice.

You can use the cvswrappers file to record cvs wrapper commands to be used when checking files into and out of the repository. Wrappers allow the file or directory to be processed on the way in and out of cvs. The intended uses are many; one possible use is to reformat a C file before the file is checked in so all the code in the repository looks the same. You can use the loginfo file to define programs to execute after any commit, which writes a log entry for changes in the repository. These logging programs might be used to append the log message to a file or send the log message through electronic mail to a group of developers. You can also post the log message to a particular newsgroup.

You can use the taginfo file to define programs to execute after any tag or rtag operation. These programs might be used to append a message to a file listing the new tag name and the programmer who created it, to send mail to a group of developers, or to post a message to a particular newsgroup. You can use the rcsinfo file to define forms for log messages. You can use the editinfo file to define a program to execute for editing or validating cvs commit log entries. This is most useful when used with a rcsinfo forms specification because it can verify that the proper fields of the form were filled in by the user committing the change. You can use the cvsignore file to specify the default list of files to ignore during update. You can use the history file to record the cvs commands that affect the repository. The creation of this file enables history logging.

FILES

contain either other module names or paths. When you use paths in aliases,cvs checkout creates all intermediate directories in the working directory, just as if the path had been specified explicitly in the cvs arguments.

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

In the simplest case, this form of module definition reduces to mname dir. This defines all the files in directory dir as module mname. dir is a relative path (from $CVSROOT) to a directory of source in one of the source repositories. In this case, on checkout, a single directory called mname is created as a working directory; no intermediate directory levels are used by default, even if dir was a path involving several directory levels. By explicitly specifying files in the module definition after dir, you can select particular files from directory dir. The sample definition for modules is an example of a module defined with a single file from a particular directory. Here is another example:

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

With this definition, executing cvs checkout m4test will create a single working directory m4test containing the two files listed, which both come from a common directory several levels deep in the cvs source repository. A module definition can refer to other modules by including &module in its definition. The checkout command creates a subdirectory for each such module in your working directory. New in cvs 1.3; avoid this feature if sharing module definitions with older versions of cvs.

Finally, you can use one or more of the following options in module definitions: –d name names the working directory something other than the module name. This option is new in cvs 1.3; avoid this feature if sharing module definitions with older versions of cvs. –i prog allows you to specify a program prog to run whenever files in a module are committed. prog runs with a single argument, the full pathname of the affected directory in a source repository. The commitinfo, loginfo, and editinfo files provide other ways to call a program on commit. –o prog allows you to specify a program prog to run whenever files in a module are checked out. prog runs with a single argument, the module name. –e prog allows you to specify a program prog to run whenever files in a module are exported. prog runs with a single argument, the module name. –t prog allows you to specify a program prog to run whenever files in a module are tagged. prog runs with two arguments: the module name and the symbolic tag specified to rtag. –u prog allows you to specify a program prog to run whenever cvs update is executed from the top-level directory of the checked-out module. prog runs with a single argument, the full path to the source repository for this module.

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

SEE ALSO

cvs(1)

COPYING

Copyright © 1992, Cygnus Support, Brian Berliner, and Jeff Polk.

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

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

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

12 February 1992

DEVINFO

DEVINFO—Device entry database.

DESCRIPTION

DEVINFO is a text file that describes all the possible devices for a system. It is used by MAKEDEV(8) to create special file entries in / dev. It may be named either /dev/DEVINFO or /etc/devinfo. Information about custom local devices, if any, should be placed in DEVINFO.local or /etc/devinfo.local, which has the same syntax.

The file format is free-form. C, C++, and shell comments are understood. There are basically four statements:

This example defines a group of devices called std, with major number 1. Running will create all the devices in the group; running, for example, would make just the one device null.

It is possible to specify, instead of just std, something like std=foo. In this case, the stuff on the right-hand side of the equals sign specifies a name from /proc/devices, and the major number will be retrieved from there if present. If an entry from / proc/devices is specified, the explicit major number may be omitted. In this case, if the number is not found in /proc/ devices, attempts to create the device will be rejected.

Inside the braces is a list of specific devices. The name in parenthesis is the “class”; this is something specified in MAKEDEV.cfg that determines the ownership and permissions of the special file created. In the preceding example, the device mem was set to have the class kmem, but null was set to be public. Ordinarily, you’d define public to be mode 666 but kmem to be mode 660 and owned by group kmem. The number after the colon is the minor number for this particular device; for instance, 3 for null.

You may also specify a symbolic link with ->. For instance, core was made a link to /proc/kcore. Note that names may contain any characters, but names that contain things other than alphanumerics, dash, and underscore should be put in double quotes.

An entire range of devices can be created. You may specify a range of numbers in brackets:

tty[1-8] (tty) : 1

This creates tty1–tty8 with minor device numbers starting with 1. If you specify the range in hex (prefixed by 0x), the device names will be created numbered in hex, as is normal for ptys. The range may appear inside the name string, but there may only be one range.

DESCRIPTION

The file /news/lib/expire.ctl is the default control file for the expire(8) program, which reads it at startup. Blank lines and lines beginning with a number sign (#) are ignored. All other lines should be in one of two formats.

The first format specifies how long to keep a record of fully expired articles. This is useful when a newsfeed intermittently offers older news that is not kept around very long. (The case of very old news is handled by the –c flag of innd(8).) There should only be one line in this format, which looks like this:

/remember/:days

Where days is a floating-point number that specifies the upper limit to remember a Message-ID, even if the article has already expired. (It does not affect article expirations.)

Most of the lines in the file will consist of five colon-separated fields, as follows:

pattern:modflag:keep:default:purge

The pattern field is comma-separated set of single wildmat(3)-style patterns that specify the newsgroups to which the rest of the line applies. Because the file is interpreted in order, the most general patterns should be specified first, and the most specific patterns should be specified last.

The modflag field can be used to further limit newsgroups to which the line applies and should be chosen from the following set:

The next three fields are used to determine how long an article should be kept. Each field should be either a number of days (fractions such as 8.5 are allowed) or the word never. The most common use is to specify the default value for how long an article should be kept. The first and third fields—keep and purge—specify the boundaries within which an Expires header will be honored. They are ignored if an article has no Expires header. The fields are specified in the file as “lower-bound default upper-bound,” and they are explained in this order. Because most articles do not have explicit expiration dates, however, the second field tends to be the most important one.

The keep field specifies how many days an article should be kept before it will be removed. No article in the newsgroup will be removed if it has been filed for less than keep days, regardless of any expiration date. If this field is the word never, then an article cannot have been kept for enough days so it will never be expired.

The default field specifies how long to keep an article if no Expires header is present. If this field is the word never, then articles without explicit expiration dates will never be expired.

The purge field specifies the upper bound on how long an article can be kept. No article will be kept longer than the number of days specified by this field. All articles will be removed after they have been kept for purge days. If purge is the word never, then the article will never be deleted.

It is often useful to honor the expiration headers in articles, especially those in moderated groups. To do this, set keep to zero, default to whatever value you want, and purge to never. To ignore any Expires header, set all three fields to the same value.

There must be exactly one line with a pattern of * and a modflags of A; this matches all groups and is used to set the expiration default. It should be the first expiration line. For example:

##How long to keep expired history /remember/:5

##Most things stay for two weeks :A:14:14:14

##Believe expiration dates in moderated groups, up to six weeks :M:1:30:42

##Keep local stuff for a long time

foo.*:A:30:30:30

exports 1123

HISTORY

Written by Rich $alz (rsalz@uunet.uu.net) for InterNetNews.

SEE ALSO

expire(8), wildmat(3)

exports

exports—NFS filesystems being exported.

SYNOPSIS

/etc/exports

DESCRIPTION

The file /etc/exports serves as the access control list for filesystems that can be exported to NFS clients. It is used by both the NFS mount daemon mountd(8) and the NFS file server daemon nfsd(8).

The file format is similar to the SunOS exports file, except that several additional options are permitted. Each line contains a mount point and a list of machine or netgroup names allowed to mount the filesystem at that point. An optional parenthesized list of mount parameters may follow each machine name. Blank lines are ignored, and a # introduces a comment to the end of the line.

GENERAL OPTIONS

USER ID MAPPING

nfsd bases its access control to files on the server machine on the UID and GID provided in each NFS RPC request. The normal behavior a user would expect is that she can access her files on the server just as she would on a normal filesystem. This requires that the same UIDs and GIDs are used on the client and the server machine. This is not always true, nor is it always desirable.

Very often, it is not desirable that the root user on a client machine is also treated as root when accessing files on the NFS server. To this end, UID 0 is normally mapped to a different ID: the so-called anonymous or nobody UID. This mode of operation (called root squashing) is the default and can be turned off with no_root_squash.

By default, nfsd tries to obtain the anonymous UID and GID by looking up user nobody in the password file at startup time. If it isn’t found, a UID and GID of -2 (65534) is used. These values can also be overridden by the anonuid and anongid options.

In addition to this, nfsd lets you specify arbitrary UIDs and GIDs that should be mapped to user nobody as well. Finally, you can map all user requests to the anonymous UID by specifying the option.

For the benefit of installations where UIDs differ between different machines, nfsd provides a way to dynamically map server UIDs to client UIDs and vice versa. This is enabled with the map daemon option and uses the UGID RPC protocol. For this to work, you have to run the ugidd(8) mapping daemon on the client host.

filesystems 1125

SEE ALSO

mountd(8), nfsd(8), nfs(5), passwd(5)

21 October 1996

filesystems

filesystems—Linux filesystem types: minix, ext, ext2, xia, msdos, umsdos, vfat, proc, nfs, iso9660, hpfs, sysv, smb, ncpfs.

DESCRIPTION

In the file /proc/filesystems, you can find which filesystems your kernel currently supports. (If you need a currently unsupported one, insert the corresponding module or recompile the kernel.)

Following is a description of the various filesystems.

proc(5), fsck(8), mkfs(8), mount(8)

25 March 1996

fstab

fstab—Static information about the filesystems.

SYNOPSIS

#include <fstab.h>

DESCRIPTION

The file fstab contains descriptive information about the various filesystems. fstab is only read by programs and not written; it is the duty of the system administrator to properly create and maintain this file. Each filesystem is described on a separate line; fields on each line are separated by tabs or spaces. The order of records in fstab is important because fsck(8), mount(8), and umount(8) sequentially iterate through fstab doing their thing.

The first field (fs_spec) describes the block special device or remote filesystem to be mounted.

The second field (fs_file) describes the mount point for the filesystem. For swap partitions, this field should be specified as none.

The third field (fs_vfstype) describes the type of the filesystem. The system currently supports three types of filesystems:

If vfs_fstype is specified as ignore, the entry is ignored. This is useful to show disk partitions that are currently unused.

The fourth field (fs_mntops) describes the mount options associated with the filesystem.

It is formatted as a comma-separated list of options. It contains at least the type of mount plus any additional options appropriate to the filesystem type. For documentation on the available options for non-NFS file systems, see mount(8). For documentation on all NFS-specific options, take a look at nfs(5). Common for all types of filesystems are the options noauto (do not mount when mount -a is given, such as at boot time) and user (allow a user to mount). For more details, see mount(8).

The fifth field (fs_freq) is used for these filesystems by the dump(8) command to determine which filesystems need to be dumped. If the fifth field is not present, a value of zero is returned and dump will assume that the filesystem does not need to be dumped.

groff_font 1127

The sixth field (fs_passno) is used by the fsck(8) program to determine the order in which filesystem checks are done at reboot time. The root filesystem should be specified with a fs_passno of 1, and other filesystems should have a fs_passno of 2. Filesystems within a drive will be checked sequentially, but filesystems on different drives will be checked at the same time to utilize parallelism available in the hardware. If the sixth field is not present or zero, a value of zero is returned and fsck will assume that the filesystem does not need to be checked.

The proper way to read records from fstab is to use the routine getmntent(3).

FILES

/etc/fstab

BUGS

The documentation in mount(8) is often more up-to-date.

SEE ALSO

getmntent(3), mount(8), swapon(8), nfs(5)

HISTORY

The fstab file format appeared in 4.0 BSD.

Linux 0.99, 27 November 1993

groff_font

groff_font—Format of groff device and font description files.

DESCRIPTION

The groff_font format is roughly a superset of the ditroff font format. Unlike the ditroff font format, there is no associated binary format. The font files for device name are stored in a directory devname. There are two types of file: a device description file called DESC and for each font F, a font file called F. These are text files; there is no associated binary format.

DESC FILE FORMAT

The DESC file can contain the following types of lines:

The res, unitwidth, fonts, and sizes lines are compulsory. Other commands are ignored by troff but may be used by postprocessors to store arbitrary information about the device in the DESC file.

FONT FILE FORMAT

A font file has two sections. The first section is a sequence of lines, each containing a sequence of blank delimited words; the first word in the line is a key, and subsequent words give a value for that key.

Other commands are ignored by troff but may be used by postprocessors to store arbitrary information about the font in the font file.

The first section can contain comments, which start with the # character and extend to the end of a line.

The second section contains one or two subsections. It must contain a charset subsection and it may also contain a kernpairs subsection. These subsections can appear in any order. Each subsection starts with a word on a line by itself.

The word charset starts the charset subsection. The charset line is followed by a sequence of lines. Each line gives information for one character. A line comprises a number of fields separated by blanks or tabs. The format is

name metrics type code comment

name identifies the character: if name is a single character c, it corresponds to the groff input character c; if it is of the form \c where c is a single character, then it corresponds to the groff input character nc; otherwise, it corresponds to the groff input character \[name] (if it is exactly two characters xx, it can be entered as \(xx). groff supports eight-bit characters; however, some utilities have difficulties with eight-bit characters. For this reason, there is a convention that the name charn is equivalent to the single character whose code is n. For example, char163 is equivalent to the character with code 163, which is the pounds sterling sign in ISO Latin-1. The name — is special and indicates that the character is unnamed; such characters can only be used by means of the \N escape sequence in troff.

The type field gives the character type:

The code field gives the code that the postprocessor uses to print the character. The character can also be input to groff using this code by means of the \N escape sequence. The code can be any integer. If it starts with a 0, it will be interpreted as octal; if it starts with 0x or 0X, it will be interpreted as hexadecimal.

Anything on the line after the code field will be ignored.

The metrics field has the form:

width[,height[,depth[,italic_correction[,left_italic_correction

[,subscript_correction]]]]]

There must not be any spaces between these subfields. Missing subfields are assumed to be 0. The subfields are all decimal integers. Because there is no associated binary format, these values are not required to fit into a variable of type char as they

groff_out 1129

are in ditroff. The width subfields gives the width of the character. The height subfield gives the height of the character (upwards is positive); if a character does not extend above the baseline, it should be given a zero height, rather than a negative height. The depth subfield gives the depth of the character, that is, the distance below the lowest point below the baseline to which the character extends (downwards is positive); if a character does not extend below above the baseline, it should be given a zero depth, rather than a negative depth. The italic_correction subfield gives the amount of space that should be added after the character when it is immediately to be followed by a character from a roman font. The left_italic_correction subfield gives the amount of space that should be added before the character when it is immediately to be preceded by a character from a roman font. The subscript_correction gives the amount of space that should be added after a character before adding a subscript. This should be less than the italic_correction.

A line in the charset section can also have the format

name “

This indicates that name is just another name for the character mentioned in the preceding line.

The word kernpairs starts the kernpairs section. This contains a sequence of lines of the form:

c1 c2 n

This means that when character c1 appears next to character c2, the space between them should be increased by n. Most entries in kernpairs section will have a negative value for n.

FILES

SEE ALSO

groff_out(5), gtroff(1)

Groff Version 1.09, 14 February 1994

groff_out

groff_out—groff intermediate output format.

DESCRIPTION

This manual page describes the format output by GNU troff. The output format used by GNU troff is very similar to that used by UNIX device-independent troff. Only the differences are documented here.

The argument to the s command is in scaled points (units of points/n, where n is the argument to the sizescale command in the DESC file.) The argument to the x Height command is also in scaled points.

The first three output commands are guaranteed to be

x T device x res n h v x init

If the tcommand line is present in the DESC file, troff will use the following two commands:

Note that single characters can have the eighth bit set, as can the names of fonts and special characters.

The names of characters and fonts can be of arbitrary length; drivers should not assume that they will be only two characters long.

When a character is to be printed, that character will always be in the current font. Unlike device-independent troff, it is not necessary for drivers to search special fonts to find a character.

The D drawing command has been extended. These extensions will not be used by GNU pic if the –n option is given.

A difficulty arises in how the current position should be changed after the execution of these commands. This is not of great importance because the code generated by GNU pic does not depend on this. Given a drawing command of the form

\Dc x1 y1 x2 y2 ... xn yn

where c is not one of c, e, l, a, or ~, UNIX troff will treat each of the xi as a horizontal quantity and each of the yi as a vertical quantity and will assume that the width of the drawn object is å ni=1 xi and that the height is å ni=1 yi. (The assumption about the height can be seen by examining the st and sb registers after using such a D command in a \w escape sequence.) This rule also holds for all the original drawing commands with the exception of De. For the sake of compatibility, GNU troff also follows this rule, even though it produces an ugly result in the case of the Df, Dt, and, to a lesser extent, DE commands. Thus after executing a D command of the form

Dc x1 y1 x2 y2 ... xn yn\n

the current position should be increased by (å ni=1 xi; å ni=1 yi).

A continuation convention permits the argument to the x X command to contain newlines: when outputting the argument to the x X command, GNU troff will follow each newline in the argument with a + character (as usual, it will terminate the entire argument with a newline); thus if the line after the line containing the x X command starts with +, then the newline ending the line containing the x X command should be treated as part of the argument to the x X command, the + should be ignored, and the part of the line following the + should be treated like the part of the line following the x X command.

history 1131

SEE ALSO

groff_font(5)

groff version 1.09, 14 February 1994

group

group—User group file.

DESCRIPTION

/etc/group is an ASCII file that defines the groups to which users belong. There is one entry per line, and each line has the format

group_name:passwd:GID:user_list

FILES

/etc/group

SEE ALSO

login(1), newgrp(1), passwd(5)

Linux, 29 December 1992

history

history—Record of current and recently expired Usenet articles.

DESCRIPTION

The file /news/lib/history keeps a record of all articles currently stored in the news system, as well as those that have been received but since expired.

The file consists of text lines. Each line corresponds to one article. The file is normally kept sorted in the order in which articles are received, although this is not a requirement. innd(8) appends a new line each time it files an article, and expire(8) builds a new version of the file by removing old articles and purging old entries.

Each line consists of two or three fields separated by a tab, shown below as \t:

<Message–ID>\t date <Message–ID>\t date \t files

The Message–ID field is the value of the article’s Message-ID header, including the angle brackets.

The date field consists of three subfields separated by a tilde. All subfields are the text representation of the number of seconds since the epoch—a time_t; see gettimeofday(2). The first subfield is the article’s arrival date. If copies of the article are still present, then the second subfield is either the value of the article’s Expires header or a hyphen if no expiration date was specified. If an article has been expired, the second subfield will be a hyphen. The third subfield is the value of the article’s Date header, recording when the article was posted.

The files field is a set of entries separated by one or more spaces. Each entry consists of the name of the newsgroup, a slash, and the article number. This field is empty if the article has been expired.

For example, an article cross-posted to comp.sources.unix and comp.sources.d that was posted on February 10, 1991, (and received three minutes later) with an expiration date of May 5, 1991, could have a history line (broken into two lines for display) like the following:

<312@litchi.foo.com> \t 666162000˜673329600˜666162180 \t comp.sources.unix/1104 comp.sources.d/7056

In addition to the text file, there is a dbz(3z) database associated with the file that uses the Message-ID field as a key to determine the offset in the text file where the associated line begins. For historical reasons, the key includes the trailing \0 byte (which is not stored in the text file).

HISTORY

Written by Rich $alz (rsalz@uunet.uu.net) for InterNetNews.

SEE ALSO

dbz(3z), expire(8), innd(8), news-recovery(8)

hosts.nntp, hosts.nntp.nolimit

hosts.nntp, hosts.nntp.nolimit—List of hosts that feed NNTP news.

DESCRIPTION

The file /news/lib/hosts.nntp is read by innd(8) to get the list of hosts that feed the local site Usenet news using the NNTP protocol. The server reads this file at startup or when directed to by ctlinnd(8). When a hosts connects to the NNTP port of the system on which innd is running, the server will do a check to see if their Internet address is the same as one of the hosts named in this file. If the host is not mentioned, then innd will spawn an nnrpd(8) to process the connection, with the accepted connection on standard input and standard output.

Comments begin with a number sign (#) and continue through the end of the line. Blank lines and comments are also ignored. All other lines should consist of two or three fields separated by a colon.

The first field should be either an Internet address in dotted-quad format or an address that can be parsed by gethostbyname(3). If a host’s entry has multiple addresses, all of them will be added to the access list. The second field, which may be blank, is the password the foreign host is required to use when first connecting. The third field, which may be omitted, is a list of newsgroups to which the host may post articles. This list is parsed as a newsfeeds(5) subscription list; groups not in the list are ignored.

Because innd is usually started at system boot time, the local nameserver may not be fully operational when innd parses this file. As a work-around, a ctlinnd reload command can be performed after a delay of an hour or so. It is also possible to provide both a host’s name and its dotted-quad address in the file.

For example:

##FOO has a password, UUNET doesn’t.

##UUNET cannot post to local groups.

##These are comment lines. news.foo.com:magic uunet.uu.net::!foo.*

If the file contains passwords, it should not be world-readable. The file /news/lib/hosts.nntp.nolimit, if it exists, is read whenever the hosts.nntp file is read. It has the same format, although only the first field is used. Any host mentioned in this file is not subject to the incoming connections limit specified by innd’s –c flag. This can be used to allow local hosts or timesensitive peers to connect regardless of the local conditions.

hosts_access 1133

HISTORY

Written by Rich $alz (rsalz@uunet.uu.net) for InterNetNews.

SEE ALSO

ctlinnd(8), innd(8), nnrpd(8)

hosts_access

hosts_access—Format of host access control files.

DESCRIPTION

This manual page describes a simple access control language that is based on client (hostname/address, username) and server (process name) patterns. Examples are given at the end. The impatient reader can skip to the “Examples” section for a quick introduction.

In the following text, daemon is the process name of a network daemon process, and client is the name or address of a host requesting service. Network daemon process names are specified in the inetd configuration file.

ACCESS CONTROL FILES

The access control software consults two files. The search stops at the first match:

Access will be granted when a (daemon,client) pair matches an entry in the /etc/hosts.allow file.

Otherwise, access will be denied when a (daemon,client) pair matches an entry in the /etc/hosts.deny file.

Otherwise, access will be granted.

A non-existing access control file is treated as if it were an empty file. Thus, access control can be turned off by providing no access control files.

ACCESS CONTROL RULES

Each access control file consists of zero or more lines of text. These lines are processed in order of appearance. The search terminates when a match is found.

A newline character is ignored when it is preceded by a backslash character.

Blank lines or lines that begin with a # character are ignored.

All other lines should satisfy the following format, things between [] being optional:

daemon_list : client_list [ : shell_command ]

daemon_list is a list of one or more daemon process names (argv[0] values) or wildcards.

client_list is a list of one or more hostnames, host addresses, patterns, or wildcards that will be matched against the remote hostname or address.

List elements should be separated by blanks or commas.

With the exception of NIS (YP) netgroup lookups, all access control checks are case insensitive.

PATTERNS

The access control language implements the following patterns:

A string that begins with a . character: A client name or address is matched if its last components match the specified pattern. For example, the pattern .tue.nl matches the hostname wzv.win.tue.nl.

A string that ends with a . character: A client name or address is matched if its first fields match the given string. For example, the pattern 131.155. matches the address of (almost) every host on the Eindhoven University network (131.155.x.x).

A string that begins with a @ character is treated as a netgroup name: Netgroups are usually supported on systems with NIS (formerly YP) databases. A client hostname is matched if it is a (host) member of the specified netgroup.

An expression of the form n.n.n.n/m.m.m.m is interpreted as a net/mask pair. A client address is matched if net is equal to the bitwise AND of the address and the mask. For example, the net/mask pattern 131.155.72.0/255.255.254.0 matches every address in the range 131.155.72.0 through 131.155.73.255.

WILDCARDS

The access control language supports explicit wildcards:

OPERATORS

SHELL COMMANDS

If the first-matched access control rule contains a shell command, that command is subjected to the following substitutions:

Characters in % expansions that may confuse the shell are replaced by underscores. The result is executed by a /bin/sh child process with standard input, output, and error connected to /dev/null. Specify an & at the end of the command if you do not want to wait until it has completed.

Shell commands should not rely on the PATH setting of the inetd. Instead, they should use absolute pathnames, or they should begin with an explicit PATH=whatever statement.

REMOTE USERNAME LOOKUP

When the client host supports the RFC 931 protocol or one of its descendants (TAP, IDENT) the wrapper programs can retrieve additional information about the owner of a connection. When available, remote username information is logged together with the client hostname and can be used to match patterns like

daemon_list : ... user_pattern@host_pattern ...

non-UNIX hosts. The time-out period is optional. If no time-out is specified, a default value is taken.

DIAGNOSTICS

When a syntax error is found in an access control rule, the error is reported to the syslog daemon; further options will be ignored, and service is denied.

SEE ALSO

hosts_access(5), the default access control language

AUTHOR

Wietse Venema (wietse@wzv.win.tue.nl), Department of Mathematics and Computing Science, Eindhoven University of Technology, Den Dolech 2, P.O. Box 513, 5600 MB Eindhoven, The Netherlands.

inittab

inittab—Format of the inittab file used by the SysV-compatible init process.

DESCRIPTION

The inittab file describes which processes are started at bootup and during normal operation (such as /etc/rc, gettys). init distinguishes multiple run levels, of which each can have its own set of processes that are started. Valid runlevels are 0–6 and A, B, and C for ondemand entries. An entry in the inittab file has the following format:

id:runlevels:action:process

Lines beginning with # are ignored.

The runlevel field may contain multiple characters for different run levels, such as 123 if the process should be started in run levels 1, 2 and 3. Ondemand entries may contain an A, B, or C. The runlevel field of sysinit, boot, and bootwait entries are ignored.

When the run level is changed, any running processes that are not specified for the new run level are killed, first with SIGTERM and then with SIGKILL.

EXAMPLES

This is an example of an inittab that resembles the old Linux inittab:

# inittab for linux id:1:initdefault: rc::bootwait:/etc/rc 1:1:respawn:/etc/getty 9600 tty1 2:1:respawn:/etc/getty 9600 tty2 3:1:respawn:/etc/getty 9600 tty3 4:1:respawn:/etc/getty 9600 tty4

This inittab file executes /etc/rc during boot and starts gettys on tty1–tty4.

A more elaborate inittab with different run levels (see the comments inside) is

#Level to run in id:4:initdefault: ud::boot:/etc/update rc::bootwait:/etc/rc cr::boot:/etc/crond

#

#level 1: getty on tty1

#level 2: getty on tty1-4

#level 3: tty1-4, dialin via modem(ttys2)

#level 4: tty1-4, ttyb

#

mr:126:once:/usr/bin/nodialin

mi:345:once:/usr/bin/dialin 1:1234:respawn:/etc/getty 9600 tty1 2:234:respawn:/etc/getty 9600 tty2 3:234:respawn:/etc/getty 9600 tty3

inn.conf 1141

4:234:respawn:/etc/getty 9600 tty4 s2:3:respawn:/etc/mgetty ttys2 19200 b:4:respawn:/etc/getty 19200L ttyb ca::ctrlaltdel:/etc/shutdown -t3 -rf now

FILES

/etc/inittab

AUTHOR

init was written by Miquel van Smoorenburg (miquels@drinkel.nl.mugnet.org). The manual page was written by Sebastian Lederer (lederer@francium.informatik.uni-bonn.de) and modified by Michael Haardt (u31b3hs@pool.informatik.rwthaachen.de).

SEE ALSO

init(8), telinit(8)

13 May 1993

inn.conf

inn.conf—Configuration data for InterNetNews programs.

DESCRIPTION

The file /news/lib/inn.conf is used to determine various parameters. Blank lines and lines starting with a number sign (#) are ignored. All other lines specify parameters that may be read and should be of the following form:

name : [optional whitespace] value

Everything after the whitespace and up to the end of the line is taken as the value; multi-word values should not be put in quotes. The case of names is significant; server is not the same as Server or SERVER.

Some parameters specified in the file may be overridden by environment variables, and some file parameters may be used to mask real data, such as when hiding a cluster of hosts behind a single electronic mail hostname. The current set of parameters is as follows:

Three parameters are used only by nnrpd when accepting postings from clients:

Note that this file can be identical on all machines in an organization.

EXAMPLE

This file is intended to be fairly static; any changes made to it are typically not reflected until a program restarts.

HISTORY

Written by Rich $alz (rsalz@uunet.uu.net) for InterNetNews.

SEE ALSO

libinn(3), moderators(5)

innwatch.ctl

innwatch.ctl—Control Usenet supervision by innwatch.

DESCRIPTION

The file /news/lib/innwatch.ctl is used to determine what actions are taken during the periodic supervisions by innwatch.

The file consists of a series of lines; blank lines and lines beginning with a number sign (#) are ignored. All other lines consist of seven fields, each preceded by a delimiting character:

:label:state:condition:test:limit:command:reason

The delimiter can be any one of several non-alphanumeric characters that does not appear elsewhere in the line; there is no way to quote it to include it in any of the fields. Any of !, ,, :, @, ;, or ? is a good choice. Each line can have a different delimiter; the first character on each line is the delimiter for that line. Whitespace surrounding delimiters, except before the first, is ignored and does not form part of the fields; whitespace within fields is permitted. All delimiters must be present.

The first field is a label for the control line. It is used as an internal state indicator and in ctlinnd messages to control the server. If omitted, the line number is used.

The second field specifies when this control line should be used. It consists of a list of labels and special indicators separated by whitespace. If the current state matches against any of the labels in this field, this line will be used as described below. The values that may be used are

innwatch.ctl 1143

The third field specifies a shell command that is invoked if this line matches. Do not use any shell filename expansion characters such as *, ?, or [ (even quoted, they’re not likely to work as intended). If the command succeeds, as indicated by its exit status, it is expected to have printed a single integer to standard output. This gives the value of this control line, to be used below. If the command fails, the line is ignored. The command is executed with its current directory set to the newsspool directory, /news/spool.

The fourth field specifies the operator to use to test the value returned above. It should be one of the two-letter numeric test operators defined in test(1) such as eq, lt, and the like. The leading dash (–) should not be included.

The fifth field specifies a constant with which to compare the value using the operator just defined. This is done by invoking the command

test value -operator constant

The line is said to “succeed” if it returns true.

The sixth field specifies what should be done if the line succeeds and in some cases if it fails. Any of the following words may be used:

The last field specifies the reason that is used in those ctlinnd commands that require one. More strictly, it is part of the reason; innwatch appends some information to it. In order to enable other sites to recognize the state of the local innd server, this field should usually be set to one of several standard values. Use No space if the server is rejecting articles because of a lack of filesystem resources. Use loadav if the server is rejecting articles because of a lack of CPU resources.

Once innwatch has taken some action as a consequence of its control line, it skips the rest of the control file for this pass. If the action was to restart the server (that is, issue a go command), then the next pass will commence almost immediately so that innwatch can discover any other condition that may mean that the server should be suspended again.

EXAMPLES

@@@df .|awk ‘NR==2 {print $4}’@lt@10000@throttle@No space

@@@df -i .|awk ‘NR==2 {print $4}’@lt@1000@throttle@No space (inodes)

The first line causes the server to be throttled if the free space drops below 10000 units (using whatever units df uses) and restarted again when free space increases above the threshold.

The second line does the same for inodes.

The next three lines act as a group and should appear in the following order. It is easier to explain them, however, if they are described from the last up.

lilo.conf 1147

DESCRIPTION

The file /etc/issue is a text file that contains a message or system identification to be printed before the login prompt. It may contain various @char and \char sequences if supported by getty(1).

FILES

/etc/issue

SEE ALSO

getty(1), motd(5)

Linux, 24 July 1993

lilo.conf

lilo.conf—Configuration file for LILO.

DESCRIPTION

This file, by default /etc/lilo.conf, is read by the boot loader installer LILO (see lilo(8)).

It might look as follows:

boot = /dev/hda delay = 40 compact

vga = normal root = /dev/hda1 read-only

image = /zImage-1.5.99 label = try

image = /zImage-1.0.9 label = 1.0.9 image = /tamu/vmlinuz label = tamu

root = /dev/hdb2 vga = ask

other = /dev/hda3 label = dos

table = /dev/hda

This configuration file specifies that LILO uses the Master Boot Record on /dev/hda. (For a discussion of the various ways to use LILO and the interaction with other operating systems, see user.tex from the LILO documentation.)

When booting, the boot loader will wait 4 seconds (40 deciseconds) for you to press Shift. If you don’t, then the first kernel image mentioned (/zImage-1.5.99, which you probably installed just 5 minutes ago) will be booted. If you do, the boot loader will ask you which image to boot. In case you forgot the possible choices, press Tab (or ? if you have a U.S. keyboard), and you will be presented with a menu. You now have the choice of booting this brand new kernel, an old trusted kernel, or a kernel on another root file system (just in case you did something stupid on your usual root) or booting a different operating system. There can be up to 16 images mentioned in lilo.conf.

As can be seen previously, a configuration file starts with a number of global options (the top six lines in the example), followed by descriptions of the options for the various images. An option in an image description will override a global option.

GLOBAL OPTIONS

There are many possible keywords. The description that follows is almost literally from user.tex (just slightly abbreviated):

moderators 1151

If this variable is omitted, the VGA mode setting contained in the kernel image is used. (That is set at compile time using the SVGA MODE variable in the kernel makefile and can later be changed with the rdev(8) program.)

SEE ALSO

lilo(8), rdev(8). The LILO distribution comes with very extensive documentation of which the preceding information is an extract.

28 July 1995

MAKEDEV.cfg

MAKEDEV.cfg—Configuration for MAKEDEV(8).

DESCRIPTION

MAKEDEV.cfg is a text file that tells MAKEDEV(8) what to do (and equally importantly, what not to do). Unlike DEVINFO(5), which is meant to be centrally maintained, it contains all local configuration for a particular site and all customization. There are basically two kinds of declaration in this file: a “class” declaration and an “omit” declaration.

A class declaration has the form

class name : owner group-owner permissions

This says that any devices placed in the specified class by DEVINFO should be created with this ownership and these permissions. A sample entry might be

class public: root system 0666

This says that devices marked public should be owned by root.system and have mode 666.

An omit declaration has the form

omit { device... }

This causes the specified devices to never be created, even if explicitly specified. Use caution when setting this up. The intent is to be able to run MAKEDEV update and not have it create all sorts of useless devices you’d never use.

SEE ALSO

MAKEDEV(8), DEVINFO(5)

Version 1.4, January 1995

moderators

moderators—Mail addresses for moderated Usenet newsgroups.

DESCRIPTION

The GetModeratorAddress(3) routine reads the file /news/lib/moderators to determine how to reach the moderator of a newsgroup. This is used by inews(1) when an unapproved local posting is made to a moderated newsgroup.

The file is read until a match is found. Blank lines and lines starting with a number sign (#) are ignored. All other lines should consist of two fields separated by a colon.

The first field is a wildmat(3)-style pattern. If it matches the name of the newsgroup, then the second field is taken to be a format string for sprintf(3). This string should have at most one %s parameter, which will be given the name of the newsgroup with periods transliterated to dashes.

mtools 1153

DESCRIPTION

/etc/mtools.conf and ~/.mtoolsrc are the configuration files for mtools. These configuration files describe the following items:

Global configuration flags and variables

Per-drive flags and variables

Character translation tables

/etc/mtools.conf is the system-wide configuration file, and ~/.mtoolsrc is the user’s private configuration file.

GENERAL SYNTAX

The configuration files is made up of sections. Each section starts with a keyword identifying the section followed by a colon. Then follow variable assignments and flags. Variable assignments take the following form:

name=value

Flags are lone keywords without an equal sign and value following them. A section either ends at the end of the file or where the next section begins.

Lines starting with a hash (#) are comments. Newline characters are equivalent to whitespace (except where ending a comment). The configuration file is case insensitive, except for items enclosed in quotes (such as filenames).

DEFAULT VALUES

For most platforms, mtools contains reasonable compiled-in defaults. You usually don’t need to bother with the configuration file, if all you want to do with mtools is access your floppy drives. On the other hand, the configuration file is needed if you also want to use mtools to access your hard disk partitions and dosemu image files.

GLOBAL VARIABLES

Global variables may be set to 1 or to 0.

The following global flags are recognized:

For example, inserting the following line into your configuration file instructs mtools to skip the sanity checks:

MTOOLS_SKIP_CHECK=1.

Global variables may also be set via the environment: export MTOOLS_SKIP_CHECK=1.

PER-DRIVE FLAGS AND VARIABLES

Per-drive flags and values may be described in a drive section. A drive section starts with drive driveletter:.

Then follow variable-value pairs and flags.

GENERAL PURPOSE DRIVE VARIABLES

The following variables are available:

Only the file option is mandatory. The other parameters may be left out. In that case, a default value or an autodetected value is used.

DRIVE GEOMETRY CONFIGURATION

Geometry information describes the physical characteristics about the disk. Its has three purposes:

Wrong geometry information may lead to very bizarre errors. That’s why I strongly recommend that you don’t use geometry configuration unless you really need it.

The following geometry related variables are available:

INTRODUCTION

DOS uses a different character code mapping from UNIX. Seven-bit characters still have the same meaning; only characters with the eight-bit set are affected. To make matters worse, there are several translation tables available depending on the country where you are. The appearance of the characters is defined using code pages. These code pages aren’t the same for all countries. For instance, some code pages don’t contain upper -case accented characters. On the other hand, some code pages contain characters that don’t exist in UNIX, such as certain line-drawing characters or accented consonants used by some Eastern European countries. This affects two things relating to filenames:

mtools considers the filenames entered on the command line as having the UNIX mapping and translates the characters to get short names. By default, code page 850 is used with the Swiss uppercase/lowercase mapping. I chose this code page because its set of existing characters most closely matches UNIX’s. Moreover, this code page covers most characters in use in the USA, Australia, and Western Europe. However, it is still possible to chose a different mapping. There are two methods: the country variable and explicit tables.

CONFIGURATION USING COUNTRY

The COUNTRY variable is recommended for people that also have access to MS-DOS system files and documentation. If you don’t have access to these, I’d suggest you use explicit tables instead.

Syntax: COUNTRY=” country [,[ codepage ], country.sys ]”

This tells mtools to use a UNIX-to-DOS translation table that matches codepage and an lowercase-to-uppercase table for country and to use the country.sys file to get the lowercase-to-uppercase table. The country code is most often the telephone prefix of the country. Refer to the DOS help page on country for more details. The codepage and the country.sys parameters are optional. Don’t type in the square brackets; they are only there to indicate which parameters are optional. The country.sys file is supplied with MS-DOS. In most cases, you don’t need it because the most common translation tables are compiled into mtools. Don’t worry if you run a UNIX-only box that lacks this file.

If codepage is not given, a per-country default code page is used. If the country.sys parameter isn’t given, compiled-in defaults are used for the lowercase-to-uppercase table. This is useful for other Unices than Linux, which may have no country.sys file available online.

The UNIX-to-DOS are not contained in the country.sys file, and thus mtools always uses compiled-in defaults for those. Thus, only a limited amount of code pages are supported. If your preferred code page is missing, or if you know the name of the Windows 95 file that contains this mapping, drop me a line at Alain.Knaff@inrialpes.fr.

The COUNTRY variable can also be set using the environment.

CONFIGURATION USING EXPLICIT TRANSLATION TABLES

Translation tables may be described in lines in the configuration file. Two tables are needed: first the DOS-to-UNIX table and then the lowercase-to-uppercase table. A DOS-to-UNIX table starts with the tounix keyword, followed by a colon and 128 hexadecimal numbers. A lower-to-upper table starts with the fucase keyword, followed by a colon and 128 hexadecimal numbers.

The tables only show the translations for characters whose codes is greater than 128 because translation for lower codes is trivial. Example:

mtools 1157

tounix:

0xc7 0xfc 0xe9 0xe2 0xe4 0xe0 0xe5 0xe7 0xea 0xeb 0xe8 0xef 0xee 0xec 0xc4 0xc5 0xc9 0xe6 0xc6 0xf4 0xf6 0xf2 0xfb 0xf9 0xff 0xd6 0xdc 0xf8 0xa3 0xd8 0xd7 0x5f 0xe1 0xed 0xf3 0xfa 0xf1 0xd1 0xaa 0xba 0xbf 0xae 0xac 0xbd 0xbc 0xa1 0xab 0xbb 0x5f 0x5f 0x5f 0x5f 0x5f 0xc1 0xc2 0xc0 0xa9 0x5f 0x5f 0x5f 0x5f 0xa2 0xa5 0xac 0x5f 0x5f 0x5f 0x5f 0x5f 0x5f 0xe3 0xc3 0x5f 0x5f 0x5f 0x5f 0x5f 0x5f 0x5f 0xa4 0xf0 0xd0 0xc9 0xcb 0xc8 0x69 0xcd 0xce 0xcf 0x5f 0x5f 0x5f 0x5f 0x7c 0x49 0x5f 0xd3 0xdf 0xd4 0xd2 0xf5 0xd5 0xb5 0xfe 0xde 0xda 0xd9 0xfd 0xdd 0xde 0xaf 0xb4 0xad 0xb1 0x5f 0xbe 0xb6 0xa7 0xf7 0xb8 0xb0 0xa8 0xb7 0xb9 0xb3 0xb2 0x5f 0x5f

fucase:

0x80 0x9a 0x90 0xb6 0x8e 0xb7 0x8f 0x80 0xd2 0xd3 0xd4 0xd8 0xd7 0xde 0x8e 0x8f 0x90 0x92 0x92 0xe2 0x99 0xe3 0xea 0xeb 0x59 0x99 0x9a 0x9d 0x9c 0x9d 0x9e 0x9f 0xb5 0xd6 0xe0 0xe9 0xa5 0xa5 0xa6 0xa7 0xa8 0xa9 0xaa 0xab 0xac 0xad 0xae 0xaf 0xb0 0xb1 0xb2 0xb3 0xb4 0xb5 0xb6 0xb7 0xb8 0xb9 0xba 0xbb 0xbc 0xbd 0xbe 0xbf 0xc0 0xc1 0xc2 0xc3 0xc4 0xc5 0xc7 0xc7 0xc8 0xc9 0xca 0xcb 0xcc 0xcd 0xce 0xcf 0xd1 0xd1 0xd2 0xd3 0xd4 0x49 0xd6 0xd7 0xd8 0xd9 0xda 0xdb 0xdc 0xdd 0xde 0xdf 0xe0 0xe1 0xe2 0xe3 0xe5 0xe5 0xe6 0xe8 0xe8 0xe9 0xea 0xeb 0xed 0xed 0xee 0xef 0xf0 0xf1 0xf2 0xf3 0xf4 0xf5 0xf6 0xf7 0xf8 0xf9 0xfa 0xfb 0xfc 0xfd 0xfe 0xff

The first table maps DOS character codes to UNIX character codes. For example, the DOS character number 129 is a u with two dots on top of it. To translate it into UNIX, we look at the character number 1 in the first table (1 = 129 - 128). This is 0xfc. (Beware; numbering starts at 0.) The second table maps lowercase DOS characters to uppercase DOS characters. The same lowercase u with dots maps to character 0x9a, which is an uppercase U with dots in DOS.

UNICODE CHARACTERS GREATER THAN 256

If an existing MS-DOS name contains Unicode character greater than 256, these are translated to underscores or to characters that are close in visual appearance. For example, accented consonants are translated into their unaccented counterparts. This translation is used for mdir and for the UNIX filenames generated by mcopy. Linux does support Unicode too, but unfortunately, too few applications support it yet to bother with it in mtools. Most importantly, xterm can’t display Unicode yet. If there is sufficient demand, I might include support for Unicode in the UNIX filenames as well.

Caution: When deleting files with mtools, the underscore matches all characters that can’t be represented in UNIX. Be careful before mdel!

LOCATION OF CONFIGURATION FILES AND PARSING ORDER

The configuration files are parsed in the following order:

Compiled-in defaults

/etc/mtools.conf

/etc/mtools. This is for backwards compatibility only and is only parsed if mtools.conf doesn’t exist.

~/.mtoolsrc

Options described in the later files override those described in the earlier files. Drives defined in earlier files persist if they are not overridden in the later files. For instance, drives A and B may be defined in /etc/mtools.conf and drives C and D may be defined in ~/.mtoolsrc. However, if ~/.mtoolsrc also defines drive A, this new description would override the description of drive A in /etc/mtools.conf instead of adding to it. If you want to add a new description to a drive already described in an earlier file, you need to use either the +drive or drive+ keywords.

BACKWARDS COMPATIBILITY

The syntax described herein is new for version mtools 2.5.4. The old line-oriented syntax is still supported. Each line beginning with a single letter is considered to be a drive description using the old syntax. Old style and new style drive sections may be mixed within the same configuration file to make upgrading easier. Support for the old syntax will be phased out eventually, and to discourage its use, I purposefully omit its description here.

FILES

/etc/mtools.conf

˜/.mtoolsrc

SEE ALSO

mtools(1)

5 December 1995

newsfeeds

newsfeeds—Determine where Usenet articles get sent.

DESCRIPTION

The file /news/lib/newsfeeds specifies how incoming articles should be distributed to other sites. It is parsed by the InterNetNews server innd(8) when it starts up or when directed to by ctlinnd(8).

The file is interpreted as a set of lines according to the following rules. If a line ends with a backslash, then the backslash, the newline, and any whitespace at the start of the next line is deleted. This is repeated until the entire “logical” line is collected. If the logical line is blank or starts with a number sign (#), it is ignored.

All other lines are interpreted as feed entries. An entry should consist of four colon-separated fields; two of the fields may have optional subfields, marked off by a slash. Fields or subfields that take multiple parameters should be separated by a comma. Extra whitespace can cause problems. Except for the site names, case is significant. The format of an entry is

sitename[/exclude,exclude,...]\ :pattern,pattern...[/distrib,distrib...]\ :flag,flag...\

:param

Each field is described below.

The sitename is the name of the site to which a news article can be sent. It is used for writing log entries and for determining if an article should be forwarded to a site. If sitename already appears in the article’s Path header, then the article will not be sent to the site. The name is usually whatever the remote site uses to identify itself in the Path line but can be almost any word that makes sense; special local entries (such as archivers or gateways) should probably end with an exclamation point to make sure that they do not have the same name as any real site. For example, gateway is an obvious name for the local entry that forwards articles out to a mailing list. If a site with the name gateway posts an article, when the local site receives the

newsfeeds 1159

article, it will see the name in the Path and not send the article to its own gateway entry. If an entry has an exclusion subfield, then the article will not be sent to that site if any of the names specified as excludes appear in the Path header. The same sitename can be used more than once; the appropriate action will be taken for each site that should receive the article, regardless of the name, although this is recommended only for program feeds to avoid confusion. Case is not significant in site names.

The patterns specify which groups to send to the site and are interpreted to build a “subscription list” for the site. The default subscription is to get all groups. The patterns in the field are wildmat(3)-style patterns and are matched in order against the list of newsgroups that the local site receives. If the first character of a pattern is an exclamation mark, then any groups matching the pattern are removed from the subscription; otherwise, any matching groups are added. For example, to receive all comp groups but only comp.sources.unix within the sources newsgroups, the following set of patterns can be used:

comp.*,!comp.sources.*,comp.sources.unix

There are three things to note about this example. The first is that the trailing .* is required. The second is that, again, the result of the last match is the most important. The third is that comp.sources.* could be written as comp.sources*, but this would not have the same effect if there were a group.

See innd(8) for details on the propagation of control messages.

A subscription can be further modified by specifying “distributions” that the site should or should not receive. The default is to send all articles to all sites that subscribe to any of the groups where it has been posted, but if an article has a Distribution header and any distribs are specified, then they are checked according to the following rules:

1.If the Distribution header matches any of the values in the subfield, then the article is sent.

2.If a distrib starts with an exclamation point and it matches the Distribution header, then the article is not sent.

3.If Distribution header does not match any distrib in the site’s entry and no negations were used, then the article is not sent.

4.If Distribution header does not match any distrib in the site’s entry and any distrib started with an exclamation point, then the article is sent.

If an article has more than one distribution specified, then each one is evaluated according to the preceding rules. If any of the specified distributions indicate that the article should be sent, it is. If none do, it is not sent: The rules are used as a “logical or.” It is almost definitely a mistake to have a single feed that specifies distributions that start with an exclamation point along with some that don’t.

Distributions are text words, not patterns; it is usually a mistake to have entries like * or all there.

The flags parameter specifies miscellaneous parameters. They may be specified in any order; flags that take values should have the value immediately after the flag letter with no whitespace. The valid flags are