mdevctl

package: mdevctl

title: mdevctl(8)

summary: Mediated device management utility

text:
# mdevctl(8)

## NAME
mdevctl - Mediated device management utility

## SYNOPSIS
mdevctl {COMMAND} [OPTIONS...]

lsmdev [OPTIONS...]

## DESCRIPTION
mdevctl is a utility for managing and persisting devices in the mediated device device framework of the Linux kernel. Mediated devices are sub-devices of a parent device (ex. a vGPU) which can be dynamically created and potentially used by drivers like vfio-mdev for assignment to virtual machines.

lsmdev is an alias for mdevctl list.

## OPTIONS
The following options are understood:

--addattr=ATTRIBUTE

Add an attribute ATTRIBUTE. Valid for the modify command.

-a|--auto

Automatically start the device on parent availability. Valid for define and modify commands.

-d|--defined

List all defined devices, even if not active. Valid for the list command. Modify the defined configuration of a device, even if the device is active. Valid for the modify command.

--delattr

Delete an attribute entry. Valid for the modify command.

--dumpjson

Dump the configuration for a device in JSON format when filtered to as single device and used with the list command. When used with the types command, output machine readable type information.

-i|--index=INDEX

Act on the attribute INDEX. Valid for the modify command.

--jsonfile=FILE

Read the configuration for a device from a JSON file FILE. Valid for the define and start commands.

-l|--live

Modify active device without modifying the defined configuration of the device. Valid for the modify command.

-m|--manual

Do not start a device automatically on parent availability. Valid for the modify command.

-p|--parent=PARENT

Specify or identify the device by its parent device. Note that the parent device is specified by its kernel sysfs name and is case-sensitive.

-t|--type=TYPE

Specify or identify the device by its type.

-u|--uuid=UUID

Specify or identify the device by its UUID.

--value=VALUE

Set an attribute to VALUE, in the format accepted by the attribute. Valid for the modify command.

-v|--verbose

Increase output verbosity, currently only adds attribute output to the list command.

-V|--version

Print mdevctl version.

## COMMANDS
The following commands are understood:

define DEVICESPEC

Define a config for an mdev device, identified either by an UUID (if the device already exists), or by the parent device and either the type or a JSON configuration file, and, optionally, the UUID. If no UUID is specified, one is autogenerated and printed. If no file is used, -a|--auto may be used to specify that the device should be started automatically.

list

List mdev devices. With no options, currently running devices are listed. With -d|--defined, previously defined devices are listed. Can be restricted to list only devices for a given parent or UUID. With --dumpjson output is provided in machine readable JSON format. When a UUID is provided and the output results in a single device, the JSON output format is compatible with the configuration file format.

modify DEVICESPEC

Modify the configuration for an mdev device, identified via its UUID and optionally its parent. Type and startup mode (auto or manual) can be modified by this command. Attributes can be added or deleted. Attributes to be deleted must be specified by their index; if an attribute is specified without an index, it is appended at the end of the attribute list. Active devices are unaffected by this command; changes in the configuration are applied the next time the device is started. Depending on installed callout scripts active devices can be modified. With -l|--live modifications can be applied to active devices if a callout scripts supports the event live. The option -d|--defined also direct the modification to the started device configuration.

start DEVICESPEC

Start a mediated device. This command can be used to start either a previously-defined device or a newly-created transient device. If the UUID and optional parent argument matches an existing device definition, then the existing device will be started. It is an error to specify a device type that conflicts with the existing device definition.

If the UUID argument is omitted or if the specified UUID and parent does not match an existing device definition, a new transient device will be started. If the UUID is omitted, a new UUID will be automatically generated. When starting a new transient device, the parent and device type must be specified. A --jsonfile may replace the --type specification and also include additional attributes in JSON format to be applied to the started device.

stop DEVICESPEC

Stop an mdev device, specified via its UUID.

types

List the mdev device types known to the system by parent device. Output may be limited to a single parent device with the -p|--parent option. JSON output format is used with the --dumpjson option.

undefine DEVICESPEC

Undefine, or remove the configuration for an mdev device, specified by its UUID and optionally its parent. If a UUID exists for multiple parents, all of them will be removed unless restricted to a single parent. Running devices are unaffected by this command.

## NOTE ON DEVICE SPECIFICATION
For a given UUID, only one device with that UUID may be running at the same time. However, it is possible to define multiple devices with the same UUID under different parent devices. Therefore, it is sometimes necessary to specify the parent device alongside the UUID to uniquely identify a device.

## EXIT STATUS
On success, 0 is returned, a non-zero failure code otherwise.

## EXAMPLES
List running mdev devices:

```
# mdevctl list
85006552-1b4b-45ef-ad62-de05be9171df 0000:00:02.0 i915-GVTg_V4_4
83c32df7-d52e-4ec1-9668-1f3c7e4df107 0000:00:02.0 i915-GVTg_V4_8 (defined)
```

List defined mdev devices:

```
# mdevctl list -d
83c32df7-d52e-4ec1-9668-1f3c7e4df107 0000:00:02.0 i915-GVTg_V4_8 auto
b0a3989f-8138-4d49-b63a-59db28ec8b48 0000:00:02.0 i915-GVTg_V4_8 auto
5cf14a12-a437-4c82-a13f-70e945782d7b 0000:00:02.0 i915-GVTg_V4_4 manual
```

List mdev types supported on the host system:

```
# mdevctl types
0000:00:02.0

  i915-GVTg_V4_2

    Available instances: 1

    Device API: vfio-pci

    Description: low_gm_size: 256MB high_gm_size: 1024MB fence: 4 resolution: 1920x1200 weight: 8

  i915-GVTg_V4_1

    Available instances: 0

    Device API: vfio-pci

    Description: low_gm_size: 512MB high_gm_size: 2048MB fence: 4 resolution: 1920x1200 weight: 16

  i915-GVTg_V4_8

    Available instances: 4

    Device API: vfio-pci

    Description: low_gm_size: 64MB high_gm_size: 384MB fence: 4 resolution: 1024x768 weight: 2

  i915-GVTg_V4_4

    Available instances: 3

    Device API: vfio-pci

    Description: low_gm_size: 128MB high_gm_size: 512MB fence: 4 resolution: 1920x1200 weight: 4
```

Modify a defined device from automatic start to manual:

```
# mdevctl modify --uuid 83c32df7-d52e-4ec1-9668-1f3c7e4df107 --manual
# mdevctl list -d
83c32df7-d52e-4ec1-9668-1f3c7e4df107 0000:00:02.0 i915-GVTg_V4_8 manual
b0a3989f-8138-4d49-b63a-59db28ec8b48 0000:00:02.0 i915-GVTg_V4_8 auto
5cf14a12-a437-4c82-a13f-70e945782d7b 0000:00:02.0 i915-GVTg_V4_4 manual
```

Stop a running mdev device:

```
# mdevctl stop -u 83c32df7-d52e-4ec1-9668-1f3c7e4df107
```

Start an mdev device that is not defined:

```
# uuidgen
6eba5b41-176e-40db-b93e-7f18e04e0b93
# mdevctl start -u 6eba5b41-176e-40db-b93e-7f18e04e0b93 -p 0000:00:02.0 --type i915-GVTg_V4_1
# mdevctl list
85006552-1b4b-45ef-ad62-de05be9171df 0000:00:02.0 i915-GVTg_V4_4
6eba5b41-176e-40db-b93e-7f18e04e0b93 0000:00:02.0 i915-GVTg_V4_1
```

Promote the new created mdev to a defined device:

```
# mdevctl define --uuid 6eba5b41-176e-40db-b93e-7f18e04e0b93
# mdevctl list -d
83c32df7-d52e-4ec1-9668-1f3c7e4df107 0000:00:02.0 i915-GVTg_V4_8 manual
6eba5b41-176e-40db-b93e-7f18e04e0b93 0000:00:02.0 i915-GVTg_V4_1 manual
b0a3989f-8138-4d49-b63a-59db28ec8b48 0000:00:02.0 i915-GVTg_V4_8 auto
5cf14a12-a437-4c82-a13f-70e945782d7b 0000:00:02.0 i915-GVTg_V4_4 manual
```

### ADVANCED EXAMPLES (ATTRIBUTES AND JSON)

```
# mdevctl list -d
783e6dbb-ea0e-411f-94e2-717eaad438bf matrix vfio_ap-passthrough manual
```

Add some attributes:

```
# mdevctl modify -u 783e6dbb-ea0e-411f-94e2-717eaad438bf --addattr=assign_adapter --value=5
# mdevctl modify -u 783e6dbb-ea0e-411f-94e2-717eaad438bf --addattr=assign_adapter --value=6
# mdevctl modify -u 783e6dbb-ea0e-411f-94e2-717eaad438bf --addattr=assign_domain --value=0xab
# mdevctl modify -u 783e6dbb-ea0e-411f-94e2-717eaad438bf --addattr=assign_control_domain --value=0xab
# mdevctl modify -u 783e6dbb-ea0e-411f-94e2-717eaad438bf --addattr=assign_domain --value=4
# mdevctl modify -u 783e6dbb-ea0e-411f-94e2-717eaad438bf --addattr=assign_control_domain --value=4
# mdevctl list -dv
783e6dbb-ea0e-411f-94e2-717eaad438bf matrix vfio_ap-passthrough manual

  Attrs:

    @{0}: {"assign_adapter":"5"}

    @{1}: {"assign_adapter":"6"}

    @{2}: {"assign_domain":"0xab"}

    @{3}: {"assign_control_domain":"0xab"}

    @{4}: {"assign_domain":"4"}

    @{5}: {"assign_control_domain":"4"}
```

Dump the JSON configuration:

```
# mdevctl list -d -u 783e6dbb-ea0e-411f-94e2-717eaad438bf --dumpjson
{

  "mdev_type": "vfio_ap-passthrough",

  "start": "manual",

  "attrs": [

    {

      "assign_adapter": "5"

    },

    {

      "assign_adapter": "6"

    },

    {

      "assign_domain": "0xab"

    },

    {

      "assign_control_domain": "0xab"

    },

    {

      "assign_domain": "4"

    },

    {

      "assign_control_domain": "4"

    }

  ]
}
```

Remove some attributes:

```
# mdevctl modify -u 783e6dbb-ea0e-411f-94e2-717eaad438bf --delattr --index=5
# mdevctl modify -u 783e6dbb-ea0e-411f-94e2-717eaad438bf --delattr --index=4
# mdevctl list -dv
783e6dbb-ea0e-411f-94e2-717eaad438bf matrix vfio_ap-passthrough manual

  Attrs:

    @{0}: {"assign_adapter":"5"}

    @{1}: {"assign_adapter":"6"}

    @{2}: {"assign_domain":"0xab"}

    @{3}: {"assign_control_domain":"0xab"}
```

Define an mdev device from a file:

```
# cat vfio_ap_device.json
{

  "mdev_type": "vfio_ap-passthrough",

  "start": "manual",

  "attrs": [

    {

      "assign_adapter": "5"

    },

    {

      "assign_domain": "0x47"

    },

    {

      "assign_domain": "0xff"

    }

  ]
}
# mdevctl define -p matrix --jsonfile vfio_ap_device.json
e2e73122-cc39-40ee-89eb-b0a47d334cae
# mdevctl list -dv
783e6dbb-ea0e-411f-94e2-717eaad438bf matrix vfio_ap-passthrough manual

  Attrs:

    @{0}: {"assign_adapter":"5"}

    @{1}: {"assign_adapter":"6"}

    @{2}: {"assign_domain":"0xab"}

    @{3}: {"assign_control_domain":"0xab"}
e2e73122-cc39-40ee-89eb-b0a47d334cae matrix vfio_ap-passthrough manual

  Attrs:

    @{0}: {"assign_adapter":"5"}

    @{1}: {"assign_domain":"0x47"}

    @{2}: {"assign_domain":"0xff"}
```

## CONFIGURATION FILE FORMAT
Configuration files are in JSON. Attributes in "attrs" are optional.

```
{

  "mdev_type": "TYPE",

  "start": "auto|manual",

  "attrs": [

    {

      "attribute0": "VALUE"

    },

    {

      "attribute1": "VALUE"

    }

  ]
}
```

## INVOKING EXTERNAL SCRIPTS FOR DEVICE EVENTS
mdevctl supports invoking external scripts to handle additional device type-specific configurations and to broadcast notifications regarding changes or updates to a device. These scripts are invoked before, after, and/or during mdevctl's "primary command execution" (e.g. writing the device configuration file for define, or activating a device for start).

Essentially, the procedure in mdevctl looks like this:

- command-line parsing & setup

- invoke live-command call-out [1]

- invoke pre-command call-out

- primary command execution [2]

- invoke post-command call-out [2]

- invoke notifier

[1]

executed only if live update is requested.

[2]

skipped if step invoke pre-command call-out fails.

### EVENT SCRIPTS
A call-out or notification event invokes a script along with a set of parameters detailing the type of call-out, mdevctl's command execution progress, and the mediated device. The parameters are as follows:

<CONFIG> | SCRIPT <-t=type -e=event -a=action -s=state -u=UUID -p=parent>

CONFIG

The device's JSON configuration, provided via standard input.

-t=type

The device type.

-e=event

Event type of call-out that is invoked. For call-out scripts, this may be pre, live, post, or get. For notification scripts, this will always be notify.

-a=action

An action synonymous with an mdevctl command (e.g. define, start).

-s=state

A trinary state of the mdevctl command execution. The possibilities are none if the mdevctl command has yet to execute, success if the mdevctl command completed successfully, or failure if there was a problem executing the mdevctl command.

-u=UUID

UUID of the mediated device.

-p=parent

Parent of the mediated the device.

### CALL-OUT EVENT SCRIPTS
A call-out event script is invoked during a live, pre, post or get event. mdevctl will attempt each script stored in the mdevctl callouts directory until either a script that satisfies the device type is found or all scripts have been attempted. A device script must check the "TYPE" parameter to ensure the specified device type is supported, otherwise error code 2 should be returned. If no script is found for the specified device type, then mdevctl will carry on as normal.

These scripts are stored in /usr/lib/mdevctl/scripts.d/callouts. The same script is invoked for live, pre, post, and get call-out events for the device type.

Live-Command

A live-command call-out event is invoked once before the pre-command call-out event execution. This only occurs if the live option is specified on the modify command and the device modified is active. Event type is live. State will always be none. If the live command line option is specified any non-zero return code results in a live modification failure except for all call-outs return with return code 2 resulting in a live update not supported information. The return code is disruptive if also the option defined is provided and will prevent the update of the defined device configuration.

A notification event will follow if the live command line option is specified.

This event is only supported for the modify command.

Pre-Command

A pre-command call-out event is invoked once prior to primary command execution. Event type is pre. State will always be none. Any non-zero return code (exempting 2) will prevent mdevctl from performing the primary command execution and mdevctl will abort early.

A notification event will follow only if an error code (exempting 2) is observed.

This event is not supported for the list, types, or version commands.

Post-Command

A post-command call-out event is invoked once after primary command execution. Event type is post. State will be success if mdevctl was able to finish primary command execution successfully, or failure otherwise. The same script used for the pre event is used for the post event.

Any return code is non-disruptive.

A notification event will always follow a post-command call-out.

This event is not supported for the list, types, or version commands.

Get-attributes

A get event is invoked during a define and list command to acquire device attributes from an active device. Event type is get. Action is attributes. State is none. Note that, unlike other call-outs events, get-attributes does not expect a device config on stdin, and an array of JSON formatted device attributes is returned via stdout. The same script used for the pre event is used for the get event. If the script is not designed to support a get event, then the return code is 0.

For define, a non-zero return code (exempting 2) will disrupt the define command entirely.

For list, any return code is non-disruptive.

A script must return a JSON formatted array of device attributes on standard output. Example:

```
[

    {

        "attribute0": "VALUE"

    },

    {

        "attribute1": "VALUE"

    }
]
```

Get-capabilities

A get event is invoked on every new mdevctl execution to find a matching script supporting versioning for the device type. Event type is get. Action is capabilities. State is none. Note that, unlike other call-outs events, get-capabilities provides a versioning JSON on stdin, and expects a versioning JSON is returned via stdout. The provided JSON on stdin explains in provides which actions and events mdevctl supports. The information is offered to the script to derive its supported actions and events from but it there is no obligation for scripts to follow this pattern. A valid versioning JSON response provides in supports the supported actions in actions and the supported events in events. If a valid versioning JSON is returned on stdout by the script and the return code is NOT 2 the script is considered a positive match for the provided device type. A script providing versioning is the primary choice for a device type when mdevctl is executing callouts or in other words if a script which supports versioning is found the script is used for every event and action for the device type. Should no versioning supporting script be found the none versioning search pattern is used.

A script is provided on standard in with a versioning JSON describing the mdevctl supported version, actions and events. Example:

```
{

  "provides": {

    "version": 1,

    "actions": [

      "start",

      "stop",

      "define",

      "undefine",

      "modify",

      "attributes",

      "capabilities"

    ],

    "events": [

      "pre",

      "post",

      "notify",

      "get"

    ]

  }
}
```

A script that wants to support versioning must return a versioning JSON on standard output. The script should list all supported actions in the actions array and all supported events in the events array. It is possible to add additional actions or events in the array but if mdevctl did not have these in the arrays in provides they are ignored. Example:

```
{

  "supports": {

    "version": 1,

    "actions": [

      "start",

      "stop",

      "define",

      "undefine",

      "modify",

      "attributes",

      "capabilities"

    ],

    "events": [

      "pre",

      "post",

      "notify",

      "get"

    ]

  }
}
```

### AUTO-START CALL-OUTS
For each device set to start automatically during system boot, mdevctl will invoke the pre and post events. Action is the string start.

Return code and notification event behavior is the same as documented for the pre and post events. Errors reported by a script will disrupt the auto-start for that particular device and the message will be reported to the system log before attempting to the next auto-start device.

Note that if a notification script is used to convey information to another program or daemon during the auto-start procedure, it is not guaranteed that the program will already be active prior to mdevctl's invocation (e.g. the auto-start event may occur before the libvirt daemon is activated).

### NOTIFICATION EVENT SCRIPTS
Notification event scripts may be used to signal the state of the mediated device or the state of an mdevctl command to other programs or loggers. Unlike call-out scripts, notifier scripts are device-type agnostic.

Notify

A notification event is invoked once either following a pre-command call-out failure or after a post-command call-out. Event is notify. If following a pre event, then state will be none. If following a post event, then state will mirror the value passed to the post-command call-out. These scripts are stored in /usr/lib/mdevctl/scripts.d/notifiers. All notification scripts will be invoked during a notification event.

A non-zero return code is ignored.

This event is not supported for the list, types, or version commands.

### SCRIPT RETURN VALUES
A call-out script should return one of the following values:

- 0 if OK,

- 1 if an error occurred,

- 2 if the script does not support the device type

## FILES
/etc/mdevctl.d/*

Configuration files are in one subdirectory per parent device and named by UUID.

/usr/lib/mdevctl/scripts.d/callouts/*

Scripts for pre/post/get call-out events. NOTE: these scripts were previously located at /etc/mdevctl.d/scripts.d/callouts/*, but that location is now deprecated.

/usr/lib/mdevctl/scripts.d/notifiers/*

Scripts for notification call-out events. NOTE: these scripts were previously located at /etc/mdevctl.d/scripts.d/notifiers/*, but that location is now deprecated.

## SEE ALSO
udev(7), udevadm(8), driverctl(8)

branch: sisyphus


mdmpd

package: mdmpd

title: mdmpd(8)

summary: daemon to monitor MD multipath devices

text:
# mdmpd(8)

## NAME
mdmpd - daemon to monitor MD multipath devices

## SYNOPSIS
mdmpd

## DESCRIPTION
Enterprise storage requirements often include the desire to have more than one way to talk to a single disk drive so that in the event of some failure to talk to a disk drive via one controller, the system can automatically switch to another controller and keep going. This is called multipath disk access. The linux kernel implements multipath disk access via the software RAID stack known as the md (Multiple Devices) driver. The kernel portion of the md multipath driver only handles routing I/O requests to the proper device and handling failures on the active path. It does not try and find out if a path that has previously failed might be working again. That's what this daemon does. Upon startup, the daemon will fork and place itself in the background. Then it reads the current state of the md raid arrays, saves that state, and then waits for the kernel to tell it something interesting has happened. It then wakes up, checks to see if any paths on a multipath device have failed, and if they have then it starts to poll the failed path once every 15 seconds until it starts working again. Once it starts working again, the daemon will then add the path back into the multipath md device it was originally part of as a new spare path.

## OPTIONS
None. This is a very simple program that only does one thing.

## FILES

### /proc/mdstat
If you're using the /proc filesystem, /proc/mdstat lists all active md devices with information about them. mdmpd requires this to find arrays to monitor paths on and to get notification of interesting events.


memtester

package: memtester

title: memtester(8)

text:
# memtester(8)

## NAME
memtester - stress test to find memory subsystem faults.

## SYNOPSIS
memtester [-p PHYSADDR [-d DEVICE] [-u]] <MEMORY> [ITERATIONS]

## DESCRIPTION
memtester is an effective userspace tester for stress-testing the memory subsystem. It is very effective at finding intermittent and non-deterministic faults. Note that problems in other hardware areas (overheating CPU, out-of-specification power supply, etc.) can cause intermittent memory faults, so it is still up to you to determine where the fault lies through normal hardware diagnostic procedures; memtester just helps you determine whether a problem exists.

memtester will malloc(3) the amount of memory specified, if possible. If this fails, it will decrease the amount of memory requested until it succeeds. It will then attempt to mlock(3) this memory; if it cannot do so, testing will be slower and much less effective. Run memtester as root so that it can mlock the memory it tests.

Note that the maximum amount of memory that memtester can test will be less than the total amount of memory installed in the system; the operating system, libraries, and other system limits take some of the available memory. memtester is also limited to the amount of memory available to a single process; for example, on 32-bit machines with more than 4GB of memory, memtester is still limited to less than 4GB.

Note that it is up to you to know how much memory you can safely allocate for testing. If you attempt to allocate more memory than is available, memtester should figure that out, reduce the amount slightly, and try again. However, this can lead to memtester successfully allocating and mlocking essentially all free memory on the system -- if other programs are running, this can lead to excessive swapping and slowing the system down to the point that it is difficult to use. If the system allows allocation of more memory than is actually available (overcommit), it may lead to a deadlock, where the system halts. If the system has an out-of-memory process killer (like Linux), memtester or another process may be killed by the OOM killer.

So choose wisely.

## OPTIONS
-p PHYSADDR

tells memtester to test a specific region of memory starting at physical address PHYSADDR (given in hex), by mmap(2)ing a device specified by the -d option (below, or /dev/mem by default). This is mostly of use to hardware developers, for testing memory-mapped I/O devices and similar. Note that the memory region will be overwritten during testing, so it is not safe to specify memory which is allocated for the system or for other applications; doing so will cause them to crash. If you absolutely must test a particular region of actual physical memory, arrange to have that memory allocated by your test software, and hold it in this allocated state, then run memtester on it with this option.

-d DEVICE

specifies the device to open with the -p option above. If not supplied, /dev/mem is the default.

-u

causes memtester to open the device specified by the -d option above without the O_SYNC flag, which causes the system to use uncached memory semantics on some systems.

MEMORY

the amount of memory to allocate and test, in megabytes by default. You can include a suffix of B, K, M, or G to indicate bytes, kilobytes, megabytes, or gigabytes respectively.

ITERATIONS

(optional) number of loops to iterate through. Default is infinite.

## ENVIRONMENT
If the environment variable MEMTESTER_TEST_MASK is set, memtester treats the value as a bitmask of which tests (other than the stuck address test) to run. The value can be specified in decimal, in octal (with a leading 0), or in hexadecimal (with a leading 0x). The specific bit values corresponding to particular tests may change from release to release; consult the list of tests in the source for the appropriate index values for the version of memtester you are running. Note that skipping some tests will reduce the time it takes for memtester to run, but also reduce memtester's effectiveness.

## NOTE
memtester must be run with root privileges to mlock(3) its pages. Testing memory without locking the pages in place is mostly pointless and slow.

## EXIT CODE
memtester's exit code is 0 when everything works properly. Otherwise, it is the logical OR of the following values:

x01

error allocating or locking memory, or invocation error

x02

error during stuck address test

x04

error during one of the other tests

## AUTHOR
Written by Charles Cazabon.

## REPORTING BUGS
Report bugs to <charlesc-memtester-bugs@pyropus.ca>.

## COPYRIGHT
Copyright © 2001-2024 Charles Cazabon

This is free software; see the file COPYING for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


title: mf2b(8)

summary: micro fail2ban

text:
# mf2b(8)

## NAME
mf2b - micro fail2ban

## SYNOPSIS
mf2b [-fqv] [-c config-file ] [-l log-file ] [-p pid-file ] [-r chroot-dir ]

## DESCRIPTION
mf2b acts as a replacement to the well-known fail2ban daemon, but with embedded systems in mind. Therefore it has been written in pure C and doesn't depend on external libraries to be present on the target. Despite the similar concept, it's not a drop-in replacement as configuration syntax aligns more with that of logrotate.

## OPTIONS
-c config-file

Read configuration from config-file instead of the default /etc/mf2b.conf.

-f

Do not fork into background. Log output is then sent to stderr instead of syslog when daemonising.

-l log-file

Change log output to log-file instead of the default of stderr or syslog when -f has not been specified. The argument log-file may either be a path to a file log messages are to be appended to, stderr if log messages should go to standard error or syslog if log messages should be sent to the syslog daemon.

-q

Decrease log verbosity from the default of (as in syslog-terminology LOG_ERR down to LOG_CRIT or no logging at all, so (without any -v given before) this option may effectively be passed up to two times.

-p pid-file

Write daemon's process ID to pid-file. If multiple instances are started with the same pid-file specified, the file will contain the latest executed process' ID.

-r chroot-dir

Change root directory to chroot-dir prior to going into normal service. For this to work, mf2b has to be running with effective user ID 0.

-v

Increase log verbosity from the default of (as in syslog-terminology LOG_ERR up to LOG_WARNING, LOG_NOTICE, LOG_INFO, or LOG_DEBUG respectively, so (without any -q given before) this option may effectively be passed up to four times.

## FILES
/etc/mf2b.conf

The default configuration file. See mf2b.conf(5) for further details.

## BUGS
There certainly are, but of course this is subject to change. :)

## AUTHOR
Phil Sutter <phil AT nwl DOT cc>

## SEE ALSO
mf2b.conf(5)


milter-greylist

package: milter-greylist

title: milter-greylist(8)

text:
# milter-greylist(8)

## NAME
milter-greylist - grey listing filter for sendmail

## SYNOPSIS
milter-greylist [-A] [-a autowhite_delay] [-c] [-D] [-d dumpfile] [-f configfile] [-h] [-l] [-q] [-r] [-S] [-T] [-u username[:groupname]] [-v] [-w greylist_delay] [-L cidrmask] [-M prefixlen] [-P pidfile] -p socket

## DESCRIPTION
milter-greylist is a mail filter for sendmail that implements grey listing, a spam filtering technique proposed by Evan Harris.

Grey listing works by assuming that contrarily to legitimate MTA, spam engines will not retry sending their junk mail on a temporary error. The filter will always temporarily reject mail on a first attempt, and accept it after some time has elapsed.

If spammers ever try to resend rejected messages, we can assume they will not stay idle between the two sends. Odds are good that the spammer will send a mail to an honey pot address and get blacklisted in a distributed black list before the second attempt.

Of course, the filter can be configured to not apply grey listing to some hosts or networks. You can whitelist friendly SMTP servers, and you should whitelist your own network, otherwise your SMTP clients will have real trouble to send e-mail. Whitelisting localhost is also a must.

milter-greylist works with two files. greylist.conf is the configuration file. It holds the whitelist of addresses that will not suffer grey list filtering. It is read once upon milter-greylist startup, then it will be automatically reloaded whenever a new message gets in and if it had been modified. You should not send milter-greylist a kill -1 as it will just terminate it (libmilter works that way).

See greylist.conf(5) for documentation on the file's format.

The second file is greylist.db. milter-greylist will regularly dump its grey list database into this file, which is used on startup to restore the previous grey list state. If the file does not exist or is unreadable, milter-greylist will start with an empty grey list.

The default location for the grey list database and the socket for communicating with sendmail is /var/milter-greylist/. That directory must be owned and writeable by the user id under which milter-greylist runs.

The following options are available; if present, they override their equivalents specified in the configuration file:

-A

Normally, milter-greylist does not greylist senders that succeeded SMTP AUTH. This option disables that feature and causes authentication to be ignored. Equivalent to the noauth option in the configuration file.

-a autowhite_delay

Configure auto-whitelisting. After a tuple (sender IP, sender e-mail, recipient e-mail) has been accepted, other identical tuples will get accepted for autowhite_delay. The default is one day. Use zero to disable auto-whitelisting. A suffix can be added to specify seconds (s), minutes (m), hours (h), days (d) or weeks (w). Without any suffix, values are treated as seconds. Equivalent to the autowhite option in the configuration file.

-c

Only check the configuration file and exit. Return value is 0 if the configuration is valid, or an error code from <sysexit.h> otherwise.

-D

Do not fork; run in the foreground instead. Without this flag, milter-greylist will become a daemon. Equivalent to the nodetach option in the configuration file.

-d dumpfile

Location of the dump file. Default is /var/milter-greylist/greylist.db. Equivalent to the dumpfile option in the configuration file.

-f configfile

Location of the config file. Default is /etc/mail/greylist.conf.

-h

Show usage information.

-L cidrmask

Use cidrmask as a matching mask when checking IPv4 addresses entries in the greylist. This is aimed as a workaround to mail farms that re-emit messages from different IP addresses. With -L 24, the matching mask is 255.255.255.0, and all addresses within the same class C network are considered the same. Default is -L 32, which corresponds to all addresses considered different.

-M prefixlen

Use prefixlen as a matching mask when checking IPv6 addresses entries in the greylist. This is aimed as a workaround to mail farms that re-emit messages from different IP addresses. With -M 64, the matching mask is ffff:ffff:ffff:ffff::, and all addresses within the same subnet are considered the same. Default is -M 128, which corresponds to all IPv6 addresses considered different.

-l

Enable debug output in the access-list management code.

-P pidfile

write the daemon's PID to pidfile. Equivalent to the pidfile option in the configuration file.

-p socket

Use socket as the socket used by sendmail(8) to communicate with milter-greylist.

-q

Quiet mode. milter-greylist will not tell SMTP clients how much time they have to wait before the message will be accepted. Equivalent to the quiet option in the configuration file.

-r

Display milter-greylist version and build environment, then exit.

-S

If milter-greylist was built with SPF support, then SPF-compliant senders bypass greylisting. This flag causes messages to be greylisted regardless of whether they are SPF-compliant or not. Equivalent to the nospf option in the configuration file.

-T

Enable test mode. This alters the meaning of rcpt lines in greylist.conf, so that only messages sent to recipient addresses listed there are selected for greylisting. This option and the rcpt lines have been deprecated in favor of ACL, so do not use it.

-u username[:groupname]

Drop root privileges and switch to username (and optionally groupname) credentials. Make sure this user (and group) has write access to greylist.db. Equivalent to the user option in the configuration file.

-v

Enable debug output. milter-greylist will send messages (and debug output if it is given the -v flag) to syslogd(8) with facility LOG_MAIL. Equivalent to the verbose option in the configuration file.

-w greylist_delay

sets the minimum delay between the first attempt and the time the message can be accepted. Default is 30 minutes. A suffix can be added to specify seconds (s), minutes (m), hours (h), days (d) or weeks (w). Without any suffix, values are treated as seconds. Equivalent to the greylist option in the configuration file.

## GREYLIST MX SYNC
milter-greylist is now able to sync the greylist between multiple MX. In order to enable this feature, you need to list the peer MXs in greylist.conf(5) like this:

peer 192.0.2.17

peer 192.0.2.18

When peers are configured, milter-greylist will listen on the port defined for the mxglsync service in /etc/services (defaults to 5252), and it will connect to peers at this port. Each time an entry is added or deleted on one MX, it will be propagated to the others.

The protocol is quite simple, just telnet to your MX at port 5252, and type help to see how it works. Note that connections will only be accepted from peer MXs, even localhost will be rejected (and don't ever add localhost as a peer for MX sync, as you will cause each entry in the greylist to be added twice).

If an MX is down, changes to the greylist will be queued until it gets back up again. The queue length is limited (default is 1024 entries), and if it overflows, newer entries will be discarded.

## AUTHORS
Emmanuel Dreyfus <manu@netbsd.org>

milter-greylist received many contributions from (in alphabetical order): Adrian Dabrowski, Aida Shinra, Adam Katz, Alexander Lobodzinski, Alexandre Cherif, Alexey Popov, Andrew McGill, Attila Bruncsak, Benoit Branciard, Bernhard Schneider, Bob Smith, Constantine A. Murenin, Chris Bennett, Christian Pelissier, Cyril Guibourg, Dan Hollis, David Binderman, Denis Solovyov, Elrond, Enrico Scholz, Eugene Crosser, Fabien Tassin, Fredrik Pettai, Gary Aitken, Georg Horn, Gert Doering, Greg Troxel, Guido Kerkewitz, Hajimu Umemoto, Hideki ONO, Ivan F. Martinez, Jacques Beigbeder, Jean Benoit, Jean-Jacques Puig, Jeff Rife, Jim Klimov, Jobst Schmalenbach, Joe Pruett, Joel Bertrand, Johann E. Klasek, Johann Klasek, John Thiltges, John Wood, Jorgen Lundman, Kazuyuki Yoshida, Klas Heggemann, Kouhei Sutou, Laurence Moindrot, Lev Walkin, Manuel Badzong, Markus Wennrich, Mart Pirita, Martin Paul, Matt Kettler, Mattheu Herrb, Matthias Scheler, Matthieu Herrb, Michael Fromme, Moritz Both, Nerijus Baliunas, Ole Hansen, Pavel Cahyna, Pascal Lalonde, Per Holm, Petar Bogdanovic, Petr Kristof, Piotr Wadas, R P Herrold, Ralf S. Engelschall, Ranko Zivojnovic, Remy Card, Rick Adams, Rogier Maas, Romain Kang, Rudy Eschauzier, Stephane Lentz, Steven Hiscocks, Thomas Scheunemann, Tim Mooney, Vincent Dufresne, Wolfgang Solfrank, and Yaroslav Boychuk.

Thanks to Helmut Messerer and Thomas Pfau for their feedback on the first releases of this software.

## SEE ALSO
greylist.conf(5), sendmail(8), syslogd(8).

Evan Harris's paper:

http://projects.puremagic.com/greylisting/

milter-greylist's web site:

http://hcpnet.free.fr/milter-greylist/


mingetty

package: mingetty

title: mingetty(8)

summary: minimal getty for consoles

text:
# mingetty(8)

## NAME
mingetty - minimal getty for consoles

## SYNOPSIS
mingetty [--noclear] [--long-hostname] tty

## DESCRIPTION
mingetty is a minimal getty for use on virtual consoles. Unlike agetty(8), mingetty is not suitable for serial lines. I recommend using mgetty(8) for this purpose.

## OPTIONS
--noclear

Do not clear the screen before prompting for the login name (the screen is normally cleared).

--long-hostname

By default the hostname is only printed until the first dot. With this option enabled, the full text from gethostname() is shown.

## ISSUE ESCAPES
mingetty recognizes the following escapes sequences which might be embedded in the /etc/issue file:

\d

insert current day (localtime),

\l

insert line on which mingetty is running,

\m

inserts machine architecture (uname -m),

\n

inserts machine's network node hostname (uname -n),

\o

inserts domain name,

\r

inserts operating system release (uname -r),

\t

insert current time (localtime),

\s

inserts operating system name,

\u

resp. \U the current number of users which are currently logged in. \U inserts "n users", where as \u only inserts "n".

\v

inserts operating system version (uname -v).

## EXAMPLE
"Linux eos i386 #1 Tue Mar 19 21:54:09 MET 1996" was produced by putting "\s \n \m \v" into /etc/issue.

## FILES
/etc/issue, /var/run/utmp.

## SEE ALSO
mgetty(8), agetty(8).

## AUTHOR
Copyright © 1996 Florian La Roche <florian@suse.de> or <florian@jurix.jura.uni-sb.de>. Man-page written by David Frey <David.Frey@eos.lugs.ch> and Florian La Roche.


title: mini_httpd(8)

text:
# mini_httpd(8)

## NAME
mini_httpd - small HTTP server

## SYNOPSIS
mini_httpd [-C configfile] [-p port] [-d dir] [-dd data_dir] [-c cgipat] [-u user] [-h hostname] [-r] [-v] [-l logfile] [-i pidfile] [-T charset] [-P P3P] [-M maxage] [-S] [-E certfile] [-Y cipher] [-D] [-V]

## DESCRIPTION
mini_httpd is a small HTTP server. Its performance is not great, but for low or medium traffic sites it's quite adequate. It implements all the basic features of an HTTP server, including:

*

GET, HEAD, and POST methods.

*

CGI.

*

Basic authentication.

*

Security against ".." filename snooping.

*

The common MIME types.

*

Trailing-slash redirection.

*

index.html, index.htm, index.cgi

*

Directory listings.

*

Multihoming / virtual hosting.

*

Standard logging.

*

Custom error pages.

It can also be configured to do SSL/HTTPS.

mini_httpd was written for a couple reasons. One, as an experiment to see just how slow an old-fashioned forking web server would be with today's operating systems. The answer is, surprisingly, not that slow - on FreeBSD 3.2, mini_httpd benchmarks at about 90% the speed of Apache. The other main reason for writing mini_httpd was to get a simple platform for experimenting with new web server technology, for instance SSL.

## OPTIONS
-C

Specifies a config-file to read. All options can be set either by command-line flags or in the config file. See below for details.

-p

Specifies an alternate port number to listen on. The default is 80. The config-file option name for this flag is "port".

-d

Specifies a directory to chdir() to at startup. This is merely a convenience - you could just as easily do a cd in the shell script that invokes the program. The config-file option name for this flag is "dir".

-dd

Specifies a directory to chdir() to after chrooting. If you're not chrooting, you might as well do a single chdir() with the -d flag. If you are chrooting, this lets you put the web files in a subdirectory of the chroot tree, instead of in the top level mixed in with the chroot files. The config-file option name for this flag is "data_dir".

-c

Specifies a wildcard pattern for CGI programs, for instance "**.cgi" or "cgi-bin/*". The default is no CGI. The config-file option name for this flag is "cgipat".

-u

Specifies what user to switch to after initialization when started as root. The default is "nobody". The config-file option name for this flag is "user".

-h

Specifies a hostname to bind to, for multihoming. The default is to bind to all hostnames supported on the local machine. The config-file option name for this flag is "host".

-r

Do a chroot() at initialization time, restricting file access to the program's current directory. See below for details. The config-file option names for this flag are "chroot" and "nochroot".

-v

Do virtual hosting. See below for details. The config-file option name for this flag is "vhost".

-l

Specifies a log file name. The default is no logging. The config-file option name for this flag is "logfile".

-i

Specifies a file to write the process-id to. If no file is specified, no process-id is written. You can use this file to send signals to mini_httpd. The config-file option name for this flag is "pidfile".

-T

Specifies the character set to use with text MIME types. The default is "UTF-8". The config-file option name for this flag is "charset".

-P

Specifies a P3P server privacy header to be returned with all responses. See http://www.w3.org/P3P/ for details. Mini_httpd doesn't do anything at all with the string except put it in the P3P: response header. The config-file option name for this flag is "p3p".

-M

Specifies the number of seconds to be used in a "Cache-Control: max-age" header to be returned with all responses. An equivalent "Expires" header is also generated. The default is no Cache-Control or Expires headers, which is just fine for most sites. The config-file option name for this flag is "maxage".

-S

If mini_httpd is configured to do SSL/HTTPS, then the -S flag is available to enable this feature. The config-file option name for this flag is "ssl".

-E

If mini_httpd is configured to do SSL/HTTPS, then you can specify a server certificate with this flag. You can make a certificate with the command "make cert". The default is "mini_httpd.pem" (in the directory where you start mini_httpd). The config-file option name for this flag is "certfile".

-Y

If mini_httpd is configured to do SSL/HTTPS, then you can specify a cipher set with this flag. Examples of cipher sets: "RC4-MD5", "DES-CBC3-SHA", "AES256-SHA". The default is to let each browser negotiate ciphers separately, and unless you know what you're doing it's best to let them do so. The config-file option name for this flag is "cipher".

-D

This was originally just a debugging flag, however it's worth mentioning because one of the things it does is prevent mini_httpd from making itself a background daemon. Instead it runs in the foreground like a regular program. This is necessary when you want to run mini_httpd wrapped in a little shell script that restarts it if it exits. The config-file option name for this flag is "debug".

-V

Shows mini_httpd's version and then exits.

## CGI
mini_httpd supports the CGI 1.1 spec.

In order for a CGI program to be run, its name must match the pattern you specify with the -c flag This is a simple shell-style filename pattern. You can use * to match any string not including a slash, or ** to match any string including slashes, or ? to match any single character. You can also use multiple such patterns separated by |. The patterns get checked against the filename part of the incoming URL. Don't forget to quote any wildcard characters so that the shell doesn't mess with them.

## BASIC AUTHENTICATION
Basic Authentication uses a password file called ".htpasswd", in the directory to be protected. This file is formatted as the familiar colon-separated username/encrypted-password pair, records delimited by newlines. The protection does not carry over to subdirectories. The utility program htpasswd(1) is included to help create and modify .htpasswd files.

## CHROOT
chroot() is a system call that restricts the program's view of the filesystem to the current directory and directories below it. It becomes impossible for remote users to access any file outside of the initial directory. The restriction is inherited by child processes, so CGI programs get it too. This is a very strong security measure, and is recommended. The only downside is that only root can call chroot(), so this means the program must be started as root. However, the last thing it does during initialization is to give up root access by becoming another user, so this is safe.

Note that with some other web servers, such as NCSA httpd, setting up a directory tree for use with chroot() is complicated, involving creating a bunch of special directories and copying in various files. With mini_httpd it's a lot easier, all you have to do is make sure any shells, utilities, and config files used by your CGI programs and scripts are available. If you have CGI disabled, or if you make a policy that all CGI programs must be written in a compiled language such as C and statically linked, then you probably don't have to do any setup at all.

However, one thing you should do is tell syslogd about the chroot tree, so that mini_httpd can still generate syslog messages. Check your system's syslodg man page for how to do this. In FreeBSD you would put something like this in /etc/rc.conf:

```
    syslogd_flags="-l /usr/local/www/data/dev/log"
```

Substitute in your own chroot tree's pathname, of course. Don't worry about creating the log socket, syslogd wants to do that itself. (You may need to create the dev directory.) In Linux the flag is -a instead of -l, and there may be other differences.

## MULTIHOMING
Multihoming means using one machine to serve multiple hostnames. For instance, if you're an internet provider and you want to let all of your customers have customized web addresses, you might have www.joe.acme.com, www.jane.acme.com, and your own www.acme.com, all running on the same physical hardware. This feature is also known as "virtual hosts". There are three steps to setting this up.

One, make DNS entries for all of the hostnames. The current way to do this, allowed by HTTP/1.1, is to use CNAME aliases, like so:

```
  www.acme.com IN A 192.100.66.1

  www.joe.acme.com IN CNAME www.acme.com

  www.jane.acme.com IN CNAME www.acme.com
```

However, this is incompatible with older HTTP/1.0 browsers. If you want to stay compatible, there's a different way - use A records instead, each with a different IP address, like so:

```
  www.acme.com IN A 192.100.66.1

  www.joe.acme.com IN A 192.100.66.200

  www.jane.acme.com IN A 192.100.66.201
```

This is bad because it uses extra IP addresses, a somewhat scarce resource. But if you want people with older browsers to be able to visit your sites, you still have to do it this way. Step two. If you're using the modern CNAME method of multihoming, then you can skip this step. Otherwise, using the older multiple-IP-address method you must set up IP aliases or multiple interfaces for the extra addresses. You can use ifconfig(8)'s alias command to tell the machine to answer to all of the different IP addresses. Example:

```
  ifconfig le0 www.acme.com

  ifconfig le0 www.joe.acme.com alias

  ifconfig le0 www.jane.acme.com alias
```

If your OS's version of ifconfig doesn't have an alias command, you're probably out of luck. Third and last, you must set up mini_httpd to handle the multiple hosts. The easiest way is with the -v flag. This works with either CNAME multihosting or multiple-IP multihosting. What it does is send each incoming request to a subdirectory based on the hostname it's intended for. All you have to do in order to set things up is to create those subdirectories in the directory where mini_httpd will run. With the example above, you'd do like so:

```
  mkdir www.acme.com www.joe.acme.com www.jane.acme.com
```

If you're using old-style multiple-IP multihosting, you should also create symbolic links from the numeric addresses to the names, like so:

```
  ln -s www.acme.com 192.100.66.1

  ln -s www.joe.acme.com 192.100.66.200

  ln -s www.jane.acme.com 192.100.66.201
```

This lets the older HTTP/1.0 browsers find the right subdirectory. There's an optional alternate step three if you're using multiple-IP multihosting: run a separate mini_httpd process for each hostname, using the -h flag to specify which one is which. This gives you more flexibility, since you can run each of these processes in separate directories or with different options. Example:

```
  ( cd /usr/www ; mini_httpd -h www.acme.com )

  ( cd /usr/www/joe ; mini_httpd -u joe -h www.joe.acme.com )

  ( cd /usr/www/jane ; mini_httpd -u jane -h www.jane.acme.com )
```

But remember, this multiple-process method does not work with CNAME multihosting - for that, you must use a single mini_httpd process with the -v flag.

## CUSTOM ERRORS
mini_httpd lets you define your own custom error pages for the various HTTP errors. There's a separate file for each error number, all stored in one special directory. The directory name is "errors", at the top of the web directory tree. The error files should be named "errNNN.html", where NNN is the error number. So for example, to make a custom error page for the authentication failure error, which is number 401, you would put your HTML into the file "errors/err401.html". If no custom error file is found for a given error number, then the usual built-in error page is generated.

If you're using the virtual hosts option, you can also have different custom error pages for each different virtual host. In this case you put another "errors" directory in the top of that virtual host's web tree. mini_httpd will look first in the virtual host errors directory, and then in the server-wide errors directory, and if neither of those has an appropriate error file then it will generate the built-in error.

## NON-LOCAL REFERRERS
Sometimes another site on the net will embed your image files in their HTML files, which basically means they're stealing your bandwidth. You can prevent them from doing this by using non-local referrer filtering. With this option, certain files can only be fetched via a local referrer. The files have to be referenced by a local web page. If a web page on some other site references the files, that fetch will be blocked. There are three config-file variables for this feature:

urlpat

A wildcard pattern for the URLs that should require a local referrer. This is typically just image files, sound files, and so on. For example:

```
  urlpat=**.jpg|**.gif|**.au|**.wav
```

For most sites, that one setting is all you need to enable referrer filtering.

noemptyreferrers

By default, requests with no referrer at all, or a null referrer, or a referrer with no apparent hostname, are allowed. With this variable set, such requests are disallowed.

localpat

A wildcard pattern that specifies the local host or hosts. This is used to determine if the host in the referrer is local or not. If not specified it defaults to the actual local hostname.

## SIGNALS
mini_httpd will terminate cleanly upon receipt of a number of different signals, which you can send via the standard Unix kill(1) command. Any of SIGTERM, SIGINT, or SIGUSR1 will do the trick. All requests in progress will be completed. The network socket used to accept new connections gets closed immediately, which means a fresh mini_httpd can be started up right away. This is convenient when you're rotating your log files.

In addition, a SIGHUP will attempt to close and re-open the log file. This is a little tricky to set up correctly, for instance if you are using chroot() then the log file must be within the chroot tree, but it's definitely doable.

## CERTIFICATES
If you're going to serve SSL/HTTPS you will need a server certificate. There are a bunch of companies that will issue one for you; see the lists at http://www.apache-ssl.org/#Digital_Certificates and http://www.modssl.org/docs/2.4/ssl_faq.html#ToC23

You can also create one for yourself, using the openssl tool. Step one - create the key and certificate request:

```
    openssl req -new > cert.csr
```

Step two - remove the passphrase from the key:

```
    openssl rsa -in privkey.pem -out key.pem
```

Step three - convert the certificate request into a signed certificate:

```
    openssl x509 -in cert.csr -out cert.pem -req -signkey key.pem -days 365
```

This creates four files. The ones you want are cert.pem and key.pem. You don't need cert.csr and privkey.pem, and may remove them.

## SEE ALSO
htpasswd(1), weblog_parse(1), http_get(1)

## AUTHOR
Copyright © 1999,2000 by Jef Poskanzer <jef@mail.acme.com>. All rights reserved.


title: mini_sendmail(8)

text:
# mini_sendmail(8)

## NAME
mini_sendmail - accept email on behalf of real sendmail

## SYNOPSIS
mini_sendmail [-f<name>] [-t] [-s<server>] [-p<port>] [-T<timeout>] [-v] address ...

## DESCRIPTION
With no flags, mini_sendmail reads its standard input up to an end-of-file and sends a copy of the message found there to all of the addresses listed.

The message is sent by connecting to a local SMTP server. This means mini_sendmail can be used to send email from inside a chroot(2) area.

-f

Sets the name of the "from" person (i.e. the sender of the mail).

-t

Read message for recipients. To:, Cc:, and Bcc: lines will be scanned for recipient addresses. The Bcc: line will be deleted before transmission.

-s

Specifies the SMTP server to use. Without this it uses localhost.

-p

Specifies the port to use. Without this it uses 25, the standard SMTP port.

-T

Specifies timeout - defaults to one minute.

-v

Verbose mode - shows the conversation with the SMTP server.

## SEE ALSO
sendmail(8)

## AUTHOR
Copyright © 1999 by Jef Poskanzer <jef@mail.acme.com>. All rights reserved.


minidlnad

package: minidlna

title: minidlnad(8)

summary: MiniDLNA DLNA/UPnP-AV Server

text:
# minidlnad(8)

## NAME
minidlnad - MiniDLNA DLNA/UPnP-AV Server

## SYNOPSIS
minidlnad options

## DESCRIPTION
minidlna is a lightweight but very functional DLNA/UPnP-AV server allowing easy sharing of your media files including pictures to any capable device or client on your local wired and wireless network. Common PC software like totem is a good lightweight and fast choice for Linux/BSD; more fully featured software for Linux, Windows and MAC is XBMC, also Mediahouse on Android, and any media sharing capable DVR/TV etc.

## OPTIONS
minidlna's options are normally set from the global /etc/minidlna.conf file.

```
But there may be times when you need to temporarily alter some of these options,
you can do this by running minidlna with the following command line switches.
```

-R Rescan

This forces minidlna to rescan all of the media_dir directories.

-f config_file

Run minidlna with a different configuration file than the global default.

-p port

Allows to run minidlna on a different port.

-w presentation_url

Change the default presentation url address.

-d debug

minidlna will run in the foreground with debug output.

-P pid_filename

Specify a location for the PID file.

-m model

Force minidlna to report a specific model number.

-s serial

Force minidlna to report a specific serial number.

-t notify_interval

Change the notify interval, in seconds. Defaults to 895 seconds.

-h help

Show basic switch options for running minidlna.

-V Version

Shows the program version number and exits.

## VERSION
This man page corresponds to minidlna version 1.1.0

## AUTHOR

```
minidlna developed by Justin Maggard  https://sourceforge.net/projects/minidlna/
man page written by Noel Butler <noelb@ausics.net>
```

## FILES
/usr/sbin/minidlnad

## SEE ALSO

minidlna.conf(5)


miredo

package: miredo

title: miredo(8)

summary: Teredo IPv6 tunneling for Unix

text:
# miredo(8)

## NAME
miredo - Teredo IPv6 tunneling for Unix

## SYNOPSIS
miredo [-c config_file] [-f] [-u user] [ server_name]

## DESCRIPTON
Miredo is a daemon program providing a Teredo tunnel service compatible with the "Teredo: Tunneling IPv6 over UDP through NATs" Internet proposed standard (RFC 4380). It can provide either Teredo client or Teredo relay functionality.

This is mostly useful to provide IPv6 connectivity to users behind NAT, most of which do not support IPv6 at all. Many NATs do not even support proto-41 forwarding, so it is not possible to set up a 6to4 or point-to-point IPv6-over-IPv4 tunnel through them.

A Teredo relay is an IPv6 router which forwards IPv6 packets between the IPv6 Internet and Teredo clients by encapsulating these IPv6 packets over UDP/IPv4.

A Teredo client is an IPv6-enabled host which is located behind an IPv4-only Network Address Translator (a.k.a. NAT), and encapsulates its IPv6 traffic inside UDP over IPv4 packets.

A Teredo server is a special Teredo relay which is required for Teredo clients to setup their IPv6 connectivity through Teredo. A Teredo server must have to global static subsequent IPv4 addresses. It receives packets from Teredo clients and Teredo relays on UDP port 3544.

## OPTIONS
-c config_file or --config config_file

Specify an alternate configuration file for Miredo instead of the default, /etc/miredo/miredo.conf.

-f or --foreground

Do not detach from the console. Run the program in the foreground.

-h or --help

Display some help and exit.

-u username or --user username

Override the user that the program will run as. By default, it runs as nobody.

-V or --version

Display program version and license and exit.

server_name

This optional command argument specifies a Teredo server to use. It will override any ServerAddress directive found in the configuration file. It is ignored if RelayType is not set to "client" (see miredo.conf).

## SECURITY
Miredo requires root privileges to create its IPv6 tunneling network interface, and to set it up properly. Once its initialization is complete, it will setgid and setuid (see option -u), so as to decrease the system's exposure to potential security issues. However, if Miredo runs as a Teredo client, it needs root privileges when running, to change the tunneling network interface settings automatically. To prevent possible root compromise, Miredo implements priveleges separation. The process that handles data from the network is not privileged.

While that is not specific to nor dependent on Miredo, it should be noted that Teredo connectivity allows anyone behind a NAT to obtain global public IPv6 connectivity. It might break some corporate policy. If that is an issue, outgoing UDP packets with destination port 3544 should be blocked at the perimeter firewall.

## SIGNALS
SIGHUP Force a reload of the daemon.

SIGINT, SIGTERM Shutdown the daemon.

SIGUSR1, SIGUSR2 Do nothing, might be used in future versions.

## FILES
/etc/miredo/miredo.conf

The default configuration file.

//run/miredo.pid

The process-id file.

## SEE ALSO
miredo.conf(5), miredo-server(8), ipv6(7), route(8), ip(8)

## AUTHOR
Rémi Denis-Courmont <remi at remlab dot net>

http://www.remlab.net/miredo/


miredo-checkconf

title: miredo-checkconf(8)

text:
# miredo-checkconf(8)

## NAME
miredo-checkconf - Miredo configuration file syntax checking tool

## SYNOPSIS
miredo-checkconf [config_file]

## DESCRIPTON
miredo-checkconf checks the syntax of a configuration file for Miredo. miredo-checkconf exits with an error code if the syntax was found to be incorrect, contained unused directives or if the file could not be opened.

## OPTIONS
-h or --help

Display some help and exit.

-V or --version

Display program version and exit.

config_file

This optional argument specifies the path to the configuration file to be checked. If not given, the default /etc/miredo/miredo.conf will be assumed.

## BUGS
miredo-checkconf cannot check the syntax of a configuration file for miredo-server.

## FILES
/etc/miredo/miredo.conf

The default configuration file.

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

## AUTHOR
Rémi Denis-Courmont <remi at remlab dot net>

http://www.remlab.net/miredo/


miredo-server

package: miredo-server

title: miredo-server(8)

summary: Teredo server for Unix

text:
# miredo-server(8)

## NAME
miredo-server - Teredo server for Unix

## SYNOPSIS
miredo-server [-c config_file] [-f] [-u user] [server_name]

## DESCRIPTON
Miredo-server is an Unix daemon program which implements a Teredo server as specified by the "Teredo: Tunneling IPv6 over UDP through NATs" Internet proposed standard (RFC 4380).

A Teredo server is required for Teredo clients to setup their IPv6 connectivity through Teredo. A Teredo server must have two global static subsequent IPv4 addresses. It receives packets from Teredo clients and Teredo relays on UDP port 3544.

## OPTIONS
-c config_file or --config config_file

Specify an alternate configuration file for Miredo instead of the default, /etc/miredo/miredo-server.conf.

-f or --foreground

Do not detach from the console. Run the program in the foreground.

-h or --help

Display some help and exit.

-u username or --user username

Override the user that the program will run as. By default, it runs as nobody.

-V or --version

Display program version and license and exit.

## SECURITY
miredo-server requires root privileges to create open a raw IPv6 socket that is used to emit ICMPv6 Echo Request packets. Once its initialization is complete, it will setgid and setuid (see option -u), so as to

decrease the system's exposure to potential security issues.

## SIGNALS
SIGHUP Force a reload of the daemon.

SIGINT, SIGTERM Shutdown the daemon.

SIGUSR1, SIGUSR2 Do nothing, might be used in future versions.

## FILES
/etc/miredo/miredo-server.conf

The default configuration file.

//run/miredo-server.pid

The process-id file.

## SEE ALSO
miredo-server.conf(5), miredo(8), ipv6(7)

## AUTHOR
Rémi Denis-Courmont <remi at remlab dot net>

http://www.remlab.net/miredo/


mkelfImage

package: mkelfimage

title: mkelfImage(8)

text:
# mkelfImage(8)

## NAME
mkelfImage - make an elf network bootable image for linux

## SYNOPSIS
mkelfImage [--command-line=command line] [--kernel=path to vmlinux] [--ramdisk=path to ramdisk] [--output=file] [--ramdisk-base=<start addr>]

## DESCRIPTION
mkelfImage is a program that makes a elf boot image for linux kernel images. The image should work with any i386 multiboot compliant boot loader, an ELF bootloader that passes no options, a loader compliant with the linuxBIOS elf booting spec or with the linux kexec kernel patch. A key feature here is that nothing relies upon BIOS calls, but they are made when necessary. This is useful for systems running linuxbios.

## BUGS
Not all kernel parameters can be passed with the multiboot image format. ip configuration is not automatically passed to a node. The ramdisk base is hard coded to 8MB by default. This man page need to be updated.

## SEE ALSO
The kexec kernel patch. LinuxBIOS. Etherboot. The multiboot standard.

## COPYRIGHT
mkelfImage is under the GNU Public License version 2

## AUTHOR
Eric Biederman <ebiederman@lnxi.com>