gpm

package: gpm

title: gpm(8)

text:
# gpm(8)

## NAME
gpm - a cut and paste utility and mouse server for virtual consoles

## SYNOPSIS
gpm [ options ]

## DESCRIPTION
This package tries to be a useful mouse server for applications running on the Linux console. It is based on the "selection" package, and some of its code comes from selection itself. This package is intended as a replacement for "selection" as a cut-and-paste mechanism; it also provides additional facilities. The "selection" package offered the first cut-and-paste implementation for Linux using two mouse buttons, and the cut buffer is still called "selection buffer" or just "selection" throughout this document. The information below is extracted from the texinfo file, which is the preferred source of information.

The gpm executable is meant to act like a daemon (thus, gpmd would be a better name for it). This section is meant to describe the command-line options for gpm, while its internals are outlined in the next section.

Due to restrictions in the ioctl(TIOCLINUX) system call, gpm must be run by the superuser. The restrictions have been added in the last 1.1 kernels to fix a security hole related to selection and screen dumping.

The server can be configured to match the user's taste, and any application using the mouse will inherit the server's attitude. From release 1.02 up to 1.19.2 is was possible for any user logged on the system console to change the mouse feeling using the -q option. This is no longer possible for security reasons.

As of 0.97 the server program puts itself in the background. To kill gpm you can just reinvoke it with the -k cmdline switch, although killall gpm can be a better choice.

## SPECIAL COMMANDS
Version 1.10 adds the capability to execute special commands on certain circumstances. Special commands default to rebooting and halting the system, but the user can specify his/her personal choice. The capability to invoke commands using the mouse is a handy one for programmers, because it allows to issue a clean shutdown when the keyboard is locked and no network is available to restore the system to a sane state.

Special commands are toggled by triple-clicking the left and right button -- an unlikely event during normal mouse usage. The easiest way to triple-click is pressing one of the buttons and triple-click the other one. When special processing is toggled, a message appears on the console (and the speaker beeps twice, if you have a speaker); if the user releases all the buttons and presses one of them again within three seconds, then the special command corresponding to the button is executed.

The default special commands are:

left button

Reboot the system by signalling the init process

middle button (if any)

Execute /sbin/shutdown -h now

right button

Execute /sbin/shutdown -r now

The -S command line switch enables special command processing and allows to change the three special commands. To accept the default commands use -S "" (i.e., specify an empty argument). To specify your own commands, use a colon-separated list to specify commands associated to the left, middle and right button. If any of the commands is empty, it is interpreted as `send a signal to the init process'. This particular operation is supported, in addition to executing external commands, because sometimes bad bugs put the system to the impossibility to fork; in these rare case the programmer should be able to shutdown the system anyways, and killing init from a running process is the only way to do it.

As an example, -S ":telinit 1:/sbin/halt", associates killing init to the left button, going single user to the middle one, and halting the system to the right button.

System administrators should obviously be careful about special commands, as gpm runs with superuser permissions. Special commands are best suited for computers whose mouse can be physically accessed only by trusted people.

## COMMAND LINE OPTIONS
Available command line options are the following:

-a accel

Set the acceleration value used when a single motion event is longer than delta (see -d).

-A[limit]

Start up with selection pasting disabled. This is intended as a security measure; a plausible attack on a system seems to be to stuff a nasty shell command into the selection buffer (rm -rf /) including the terminating line break, then all the victim has to do is click the middle mouse button .. As of version 1.17.2, this has developed into a more general aging mechanism; the gpm daemon can disable (age) selection pasting automatically after a period of inactivity. To enable this mode just give the optional limit parameter (no space in between !) which is interpreted as the time in seconds for which a selection is considered valid and pastable. As of version 1.15.7, a trivial program called disable-paste is provided. The following makes a good addition to /etc/profile if you allow multiple users to work on your console.

case $( /usr/bin/tty ) in

/dev/tty[0-9]*) /usr/bin/disable-paste ;;

esac

-b baud

Set the baud rate.

-B sequence

Set the button sequence. 123 is the normal sequence, 321 can be used by left-handed people, and 132 can be useful with two-button mice (especially within Emacs). All the button permutations are allowable.

-d delta

Set the delta value. When a single motion event is longer than delta, accel is used as a multiplying factor. (Must be 2 or above)

-D

Do not automatically enter background operation when started, and log messages to the standard error stream, not the syslog mechanism. This is useful for debugging; in previous releases it was done with a compile-time option.

-g number

With glidepoint devices, emulate the specified button with tapping. number must be 1, 2, or 3, and refers to the button number before the -B button remapping is performed. This option applies to the mman and ps2 decoding. No button is emulated by default because the ps2 tapping is incompatible with some normal ps2 mice

-h

Print a summary of command line options.

-i interval

Set interval to be used as an upper time limit for multiple clicks. If the interval between button-up and button-down events is less than limit, the press is considered a double or triple click. Time is in milliseconds.

-k

Kill a running gpm. This can be used by busmouse users to kill gpm before running X (unless they use -R or the single-open limitation is removed from the kernel).

-l charset

Choose the inword() look up table. The charset argument is a list of characters. - is used to specify a range and \ is used to escape the next character or to provide octal codes. Only visible character can appear in charset because control characters can't appear in text-mode video memory, whence selection is cut.

-m filename

Choose the mouse file to open. Must be before -t and -o.

-M

Enable multiple mode. The daemon will read two different mouse devices. Any subsequent option will refer to the second device, while any preceding option will be used for the first device. This option automatically forces the repeater (-R) option on.

-o list-of-extra-options

The option works similary to the ``-o'' option of mount; it is used to specify a list of ``extra options'' that are specific to each mouse type. The list is comma-separated. The options dtr, rts or both are used by the serial initialization to toggle the modem lines like, compatibly with earlier gpm versions; note however that using -o dtr associated with non-plain-serial mouse types may now generate an error. And by the way, use -o after -m and after -t.

-p

Forces the pointer to be visible while selecting. This is the behaviour of selection-1.7, but it is sometimes confusing. The default is not to show the pointer, which can be confusing as well.

-r number

Set the responsiveness. A higher responsiveness is used for a faster cursor motion.

-R[name]

Causes gpm to act as a repeater: any mouse data received while in graphic mode will be produced on the fifo /dev/gpmdata in protocol name, given as an optional argument (no space in between !). In principle, you can use the same names as for the -t option, although repeating into some protocols may not be implemented for a while. In addition, you can specify raw as the name, to repeat the mouse data byte by byte, without any protocol translation. If name is omitted, it defaults to msc. Using gpm in repeater mode, you can configure the X server to use its fifo as a mouse device. This option is useful for bus-mouse owners to override the single-open limitation. It is also an easy way to manage those stupid dual-mode mice which force you to keep the middle button down while changing video mode. The option is forced on by the -M option.

-s number

Set the sample rate for the mouse device.

-S commands

Enable special-command processing, and optionally specify custom commands as a colon-separated list. See above for a detailed description of special commands.

-t name

Set the mouse type. Use -t help to get a list of allowable types. Since version 1.18.1, the list also shows which protocols are available as repeaters (see -R above), by marking them with an asterisk (``*''). Use -t after you selected the mouse device with -m.

-v

Print version information and exit.

-V[verbosity increment]

Raise or decrease the maximum level of messages that will be logged. Thus a positive argument has the effect of making the program more verbose. One can also give a negative argument to hush the program; due to getopt(3) rules, any optional argument needs to be passed without a space in between! When omitting the argument, the increment defaults to 1. Default verbosity level is 5 (LOG_NOTICE).

-2

Force two buttons. This means that the middle button, if any, will be taken as it was the right one.

-3

Force three buttons. By default the mouse is considered to be a 2-buttons one, until the middle button is pressed. If three buttons are there, the right one is used to extend the selection, and the middle one is used to paste it. Beware: if you use the -3 option with a 2-buttons mouse, you won't be able to paste the selection.

## OPERATION
To select text press the left mouse button and drag the mouse. To paste text in the same or another console, press the middle button. The right button is used to extend the selection, like in `xterm'.

Two-button mice use the right button to paste text.

Double and triple clicks select whole word and whole lines. Use of the `-p' option is recommended for best visual feedback.

If a trailing space after the contents of a line is highlighted, and if there is no other text on the remainder of the line, the rest of the line will be selected automatically. If a number of lines are selected, highlighted trailing spaces on each line will be removed from the selection buffer.

Any output on the virtual console holding the selection will clear the highlighted selection from the screen, to maintain integrity of the display, although the contents of the paste buffer will be unaffected.

The selection mechanism is disabled if the controlling virtual console is placed in graphics mode, for example when running X11, and is re-enabled when text mode is resumed. (But see BUGS section below.)

## BUGS
The gpm server may have problems interacting with X: if your mouse is a single-open device (i.e. a bus mouse), you should kill gpm before starting X, or use the -R option (see above). To kill gpm just invoke gpm -k. This problem doesn't apply to serial mice.

Two instances of gpm can't run on the same system. If you have two mice use the -M option (see above).

While the current console is in graphic mode, gpm sleeps until text mode is back (unless -R is used). Thus, it won't reply to clients. Anyways, it is unlikely that mouse-eager clients will spur out in hidden consoles.

The clients shipped out with gpm are not updated, thus there are potential security risks when using them.

## AUTHORS

```
Andrew Haylett <ajh@gec-mrc.co.uk> (the original selection code)
Ian Zimmerman <itz@speakeasy.org> (old maintainer)
Alessandro Rubini <rubini@linux.it> (old maintainer (still helps a lot))
Nico Schottelius <nico@schottelius.org> (maintainer)
Many many contributors, to both selection and gpm.
```

## MAINTAINERS
The current maintainer is Nico Schottelius. But without the help of Alessandro Rubini and the mailing list it would be impossible for him to maintain gpm. The development mailing list can be reached under gpm@lists.linux.it. More information on the list is in the README file part of the source distribution of gpm.

## FILES

```
/var/run/gpm.pid The PID of the running gpm
/dev/gpmctl     A control socket for clients
/dev/gpmdata    The fifo written to by a repeater (`-R') daemon.
```

## SEE ALSO

```
 mev(1)        A sample client for the gpm daemon.
 gpm-root(1)   An handler for Control-Mouse events.
```

The info file about `gpm', which gives more complete information and explains how to write a gpm client.


gpsd

package: gpsd

title: gpsd(8)

summary: interface daemon for GPS receivers

text:
# gpsd(8)

## NAME
gpsd - interface daemon for GPS receivers

## SYNOPSIS
gpsd [OPTIONS]

gpsd -h

gpsd -V

## QUICK START
If you have a GPS attached on the lowest-numbered USB port of a Linux system, and want to read reports from it on TCP/IP port 2947, it will normally suffice to do this, as root:

```
# gpsd /dev/ttyUSB0
```

For the lowest-numbered serial port:

```
# gpsd /dev/ttyS0
```

gpsd may be started as a normal user, or by using sudo, but some functionality will be lost. Best to start as root. See SECURITY AND PERMISSIONS ISSUES below.

Change the device number as appropriate if you need to use a different port. Command-line flags enable verbose logging, a control port, and other optional extras but should not be needed for basic operation; the one exception, on very badly designed hardware, might be -b (which see).

On Linux systems supporting udev, gpsd is normally started automatically when a USB plugin event fires (if it is not already running) and is handed the name of the newly active device. In that case no invocation is required at all.

For your initial tests set your GPS hardware to speak NMEA, as gpsd is guaranteed to be able to process that. If your GPS has a native or binary mode with better performance that gpsd knows how to speak, gpsd may autoconfigure that mode.

You can verify correct operation by first starting gpsd. Then xgps, the X windows test client or cgps the curses based terminal client.

If you have problems, the GPSD project maintains helpful information online. Some links are at the end of this man page.

## DESCRIPTION
gpsd is a monitor daemon that collects information from GPSes, differential-GPS radios, or AIS receivers attached to the host machine. Each GPS, DGPS radio, or AIS receiver is expected to be directly connected to the host via a USB or RS232C serial device. The serial device may be specified to gpsd at startup, or it may be set via a command shipped down a local control socket (e.g. by a USB hotplug script). Given a GPS device by either means, gpsd discovers the correct port speed and protocol for it.

gpsd should be able to query any GPS that speaks either the standard textual NMEA 0183 protocol, or the (differing) extended NMEA dialects used by MTK-3301, iTrax, Motorola OnCore, Sony CXD2951, Ashtech/Thales and some other devices. It can also interpret the binary protocols used by EverMore, Garmin, Javad, Navcom, Rockwell/Zodiac, SiRF, Trimble, and u-blox devices. Under Linux it can read NMEA2000 packets through the kernel CAN socket. It can read heading and attitude information from the TNT Revolution digital compasses.

The GPS reporting formats supported by your binary of gpsd may differ depending on how it was compiled; general-purpose versions support many, but it can be built with protocol subsets down to a singleton for use in constrained environments. For a list of the GPS protocols supported by your binary, see the output of gpsd -l

gpsd effectively hides the differences among the GPS types it supports. It also knows about and uses commands that tune these GPSes for lower latency. By using gpsd as an intermediary, applications avoid contention for serial devices.

gpsd can use differential-GPS corrections from a DGPS radio or over the net, from a ground station running a DGPSIP server or a Ntrip broadcaster that reports RTCM-104 data; this may shrink position errors. When gpsd opens a serial device emitting RTCM-104, it automatically recognizes this and uses the device as a correction source for all connected GPSes that accept RTCM corrections (this is dependent on the type of the GPS; not all GPSes have the firmware capability to accept RTCM correction packets).

Client applications typically communicate with gpsd via a TCP/IP port, port 2947 by default. Both IPv4 and IPv6 connections are supported and a client may connect via either.

## OPTIONS
The program accepts the following options:

-?, -h, ---help

Display help message and terminate.

-b, --readonly

Broken-device-safety mode, otherwise known as read-only mode. A few bluetooth and USB receivers lock up or become totally inaccessible when probed or reconfigured; see the hardware compatibility list on the GPSD project website for details. This switch prevents gpsd from writing to a receiver. This means that gpsd cannot configure the receiver for optimal performance, but it also means that gpsd cannot break the receiver. A better solution would be for Bluetooth to not be so fragile. A platform independent method to identify serial-over-Bluetooth devices would also be nice.

-D LVL, --debug LVL

Set debug level. Default is 0. At debug levels 2 and above, gpsd reports incoming sentence and actions to standard error if gpsd is in the foreground (-N) or to syslog if in the background. See LOGGING below.

-F FILE, --sockfile FILE

Create a control socket for device addition and removal commands. Default is None. You must specify a valid pathname on your local filesystem; this will be created as a Unix-domain socket to which you can write commands that edit the daemon’s internal device list.

-f FRAME, --framing FRAME

Fix the framing to the GNSS device. The framing parameter is of the form: [78][ENO][012]. Most GNSS are 8N1. Some Trimble default to 8O1. The default is to search for the correct framing.

-G, --listenany

This flag causes gpsd to listen on all addresses (INADDR_ANY) rather than just the loop back (INADDR_LOOPBACK) address. For the sake of privacy and security, gpsd information is private by default to the local machine until the user makes an effort to expose this to the world.

-l, --drivers

List all drivers compiled into this gpsd instance. The letters to the left of each driver name are the gpsd control commands supported by that driver. Then exit.

-n, --nowait

Don’t wait for a client to connect before polling whatever GPS is associated with it. Some RS232 GPSes wait in a standby mode (drawing less power) when the host machine is not asserting DTR, and some cellphone and handheld embedded GPSes have similar behaviors. Accordingly, waiting for a watch request to open the device may save battery power. (This capability is rare in consumer-grade devices). You should use this option if you plan to use gpsd to provide reference clock information to ntpd or chronyd. This option will also enable clients to see data from the receiver sooner on connection.

-N, --foreground

Don’t daemonize; run in foreground. This switch is mainly useful for debugging.

-p, --passive

Passive mode. Do not autoconfigure the receiver, but allow manual configuration changes.

-P FILE, --pidfile FILE

Specify the name and path to record the daemon’s process ID.

-r, --badtime

Use GPS time even with no current fix. Some GPSs have battery powered Real Time Clocks (RTC’s) built in, making them a valid time source even before a fix is acquired. This can be useful on a Raspberry Pi, or other device that has no battery powered RTC, and thus has no valid time at startup. Use with caution.

--port PORT, -S PORT

Set TCP/IP port on which to listen for GPSD clients (default is 2947).

-s SPEED, --speed SPEED

Fix the serial port speed to the GNSS device. Allowed speeds are: 4800, 9600, 19200, 38400, 57600, 115200, 230400, 460800 and 921600. The default is to autobaud. Note that some devices with integrated USB ignore port speed.

-V, --version

Dump version and exit.

Arguments are interpreted as the names of data sources. Normally, a data source is the device pathname of a local device from which the daemon may expect GPS data. But there are three other special source types recognized, for a total of four:

Local serial or USB device

A normal Unix device name of a serial or USB device to which a sensor is attached. Examples: /dev/ttyS0, or /dev/ttyUSB0.

Local PPS device

A normal Unix device name of a PPS device to which a PPS source is attached. The device name must start with "/dev/pps" and a local serial or USB GPS device must also be available. Example: /dev/pps0.

TCP feed

A URI with the prefix "tcp://", followed by a hostname, a colon, and a port number. The daemon will open a socket to the indicated address and port and read data packets from it, which will be interpreted as though they had been issued by a serial device. Example: tcp://data.aishub.net:4006.

UDP feed

A URI with the prefix "udp://", followed by a hostname, a colon, and a port number. The daemon will open a socket listening for UDP datagrams arriving in the indicated address and port, which will be interpreted as though they had been issued by a serial device. Example: udp://127.0.0.1:5000.

Ntrip caster

A URI with the prefix "ntrip://" followed by the name of an Ntrip caster (Ntrip is a protocol for broadcasting differential-GPS fixes over the net). For Ntrip services that require authentication, a prefix of the form "username:password@" can be added before the name of the Ntrip broadcaster. For Ntrip service, you must specify which stream to use; the stream is given in the form "/streamname". An example DGPSIP URI could be "dgpsip://dgpsip.example.com" and a Ntrip URI could be "ntrip://foo:bar@ntrip.example.com:80/example-stream". Corrections from the caster will be sent to each attached GPS with the capability to accept them.

DGPSIP server

A URI with the prefix "dgpsip://" followed by a hostname, a colon, and an optional colon-separated port number (defaulting to 2101). The daemon will handshake with the DGPSIP server and read RTCM2 correction data from it. Corrections from the server will be set to each attached GPS with the capability to accept them. Example: dgpsip://dgps.wsrcc.com:2101.

Remote gpsd feed

A URI with the prefix "gpsd://", followed by a hostname and optionally a colon and a port number (if the port is absent the default gpsd port will be used). Then followed optionally by a second colon and the remote device name The daemon will open a socket to the indicated address and port and emulate a gpsd client, collecting JSON reports from the remote gpsd instance that will be passed to local clients. Example: gpsd://gpsd.io:2947:/dev/ttyAMA0.

NMEA2000 CAN data

A URI with the prefix "nmea2000://", followed by a CAN devicename. Only Linux socket CAN interfaces are supported. The interface must be configured to receive CAN messages before gpsd can be started. If there is more than one unit on the CAN bus that provides GPS data, gpsd chooses the unit from which a GPS message is first seen. Example: nmea2000://can0.

(The "ais:://" source type supported in some older versions of the daemon has been retired in favor of the more general "tcp://".)

Additionally, two serial device name have a side effect, if your binary was compiled with the MAGIC_HAT option:

/dev/ttyAMA0

The UART device on a Raspberry Pi. Has the side effect of opening /dev/pps0 for RFC2783 1PPS data.

/dev/gpsd0

Generic GPS device 0. Has the side effect of opening /dev/pps0 for RFC2783 1PPS data.

Note, however, that if /dev/pps0 is the fake "ktimer" PPS, then /dev/pps1 will be used instead.

Internally, the daemon maintains a device pool holding the pathnames of devices and remote servers known to the daemon. Initially, this list is the list of device-name arguments specified on the command line. That list may be empty, in which case the daemon will have no devices on its search list until they are added by a control-socket command. Daemon startup will abort with an error if no devices and no control socket is specified.

When a device is activated (i.e. a client requests data from it), gpsd attempts to execute a hook from /etc/gpsd/device-hook with first command line argument set to the pathname of the device and the second to ACTIVATE. On deactivation, it does the same passing DEACTIVATE for the second argument.

gpsd can export data to client applications in three ways: via a sockets interface, via a shared-memory segment, and via D-Bus. The next three major sections describe these interfaces.

## LOGGING
When gpsd is running as a daemon (not in the foreground) is sends all of its logging to syslog(3). Logging is sent with ident "gpsd" using facility "LOG_USER".

If you are using syslog-ng, then you can send all gpsd logs to a file /var/log/gpsd. Put this at the end of your /etc/syslog-ng/syslog-ng.conf file:

```
destination gpsdf { file("/var/log/gpsd"); };
filter f_gpsd { program("gpsd"); };
log { source(src); filter(f_gpsd); destination(gpsdf); };
```

## THE SOCKET INTERFACE
Clients may communicate with the daemon via textual request and responses over a socket. It is a bad idea for applications to speak the protocol directly: rather, they should use the libgps client library and take appropriate care to conditionalize their code on the major and minor protocol version symbols.

The request-response protocol for the socket interface is fully documented in gpsd_json(5).

## SHARED-MEMORY AND DBUS INTERFACES
gpsd has two other (read-only) interfaces.

Whenever the daemon recognizes a packet from any attached device, it writes the accumulated state from that device to a shared memory segment. The C and C++ client libraries shipped with GPSD can read this segment. Client methods, and various restrictions associated with the read-only nature of this interface, are documented at libgps(3). The shared-memory interface is intended primarily for embedded deployments in which gpsd monitors a single device, and its principal advantage is that a daemon instance configured with shared memory but without the sockets interface loses a significant amount of runtime weight.

The daemon may be configured to emit a D-Bus signal each time an attached device delivers a fix. The signal path is "path /org/gpsd", the signal interface is "org.gpsd", and the signal name is "fix". The signal payload layout is as follows:

Table 1. Satellite object

Type

Description

DBUS_TYPE_DOUBLE

Time (seconds since Unix epoch)

DBUS_TYPE_INT32

mode

DBUS_TYPE_DOUBLE

Time uncertainty (seconds).

DBUS_TYPE_DOUBLE

Latitude in degrees.

DBUS_TYPE_DOUBLE

Longitude in degrees.

DBUS_TYPE_DOUBLE

Horizontal uncertainty in meter.

DBUS_TYPE_DOUBLE

Altitude MSL in meters.

DBUS_TYPE_DOUBLE

Altitude uncertainty in meters.

DBUS_TYPE_DOUBLE

Course in degrees from true north.

DBUS_TYPE_DOUBLE

Course uncertainty in meters

DBUS_TYPE_DOUBLE

Speed, meters per second.

DBUS_TYPE_DOUBLE

Speed uncertainty in meters per second.

DBUS_TYPE_DOUBLE

Climb, meters per second.

DBUS_TYPE_DOUBLE

Climb uncertainty in meters per second.

DBUS_TYPE_STRING

Device name

Uncertainty values are provided by the GNSS receiver. Check your

receiver documentation to see if is specifies what its "uncertainty" means.

## GPS DEVICE MANAGEMENT
gpsd maintains an internal list of GPS devices (the "device pool"). If you specify devices on the command line, the list is initialized with those pathnames, otherwise the list starts empty. Commands to add and remove GPS device paths from the daemon’s device list must be written to a local Unix-domain socket which will be accessible only to programs running as root. This control socket will be located wherever the -F option specifies it.

A device may will also be dropped from the pool if GPSD gets a zero length read from it. This end-of-file condition indicates that the device has been disconnected.

When gpsd is installed along with working hotplug notifier scripts feeding it device-add commands over the control socket, gpsd should require no configuration or user action to find hotplug devices.

Sending SIGHUP to a running gpsd forces it to close all GPSes and all client connections. It will then attempt to reconnect to any GPSes on its device list and resume listening for client connections. This may be useful if your GPS enters a wedged or confused state but can be soft-reset by pulling down DTR.

When gpsd is called with no initial devices (thus, expecting devices to be passed to it by notifications to the control socket), and reaches a state where there are no devices connected and no subscribers after some devices have been seen, it shuts down gracefully. It is expected that future device hotplug events will reactivate it.

To point gpsd at a device that may be a GPS, write to the control socket a plus sign ('+') followed by the device name followed by LF or CR-LF. Thus, to point the daemon at /dev/foo. send "+/dev/foo\n". To tell the daemon that a device has been disconnected and is no longer available, send a minus sign ('-') followed by the device name followed by LF or CR-LF. Thus, to remove /dev/foo from the search list, send "-/dev/foo\n".

To send a control string to a specified device, write to the control socket a '!', followed by the device name, followed by '=', followed by the control string.

To send a binary control string to a specified device, write to the control socket a '&', followed by the device name, followed by '=', followed by the control string in paired hex digits.

Your client may await a response, which will be a line beginning with either "OK" or "ERROR". An ERROR response to an 'add' command means the device did not emit data recognizable as GPS packets, an ERROR response to a remove command means the specified device was not in gpsd's device pool. An ERROR response to a '!' command means the daemon did not recognize the devicename specified.

The control socket is intended for use by hotplug scripts and other device-discovery services. This control channel is separate from the public gpsd service port, and only locally accessible, in order to prevent remote denial-of-service and spoofing attacks.

## ACCURACY
The base User Estimated Range Error (UERE) of GPSes is 8 meters or less at 66% confidence, 15 meters or less at 95% confidence. Actual horizontal error will be UERE times a dilution factor dependent on current satellite position. Altitude determination is more sensitive to variability in ionospheric signal lag than latitude/longitude is, and is also subject to errors in the estimation of local mean sea level, base error is 12 meters at 66% confidence, 23 meters at 95% confidence. Again, this will be multiplied by a vertical dilution of precision (VDOP) dependent on satellite geometry, and VDOP is typically larger than HDOP. Users should not rely on GPS altitude for life-critical tasks such as landing an airplane.

These errors are intrinsic to the design and physics of the GPS system. gpsd does its internal computations at sufficient accuracy that it will add no measurable position error of its own.

DGPS correction may reduce UERE, provided you are within about 100 miles (160 km) of a DGPS ground station from which you are receiving corrections.

On a 4800bps connection, the time latency of fixes provided by gpsd will be one second or less 95% of the time. Most of this lag is due to the fact that GPSes normally emit fixes once per second, thus expected latency is 0.5sec. On the personal-computer hardware available in 2005 and later, computation lag induced by gpsd will be negligible, on the order of a millisecond. Nevertheless, latency can introduce significant errors for vehicles in motion, at 50 km/h (31 mi/h) of speed over ground, 1 second of lag corresponds to 13.8 meters change in position between updates.

The time reporting of the GPS system itself has an intrinsic accuracy limit of 14 nanoseconds, but this can only be approximated by specialized receivers using that send the high-accuracy PPS (Pulse-Per-Second) over RS232 to cue a clock crystal. Most GPS receivers only report time to a precision of 0.01s or 0.001s, and with no accuracy guarantees below 1sec.

If your GPS uses a SiRF chipset at firmware level 231, reported UTC time may be off by the difference between whatever default leap-second offset has been compiled in and whatever leap-second correction is currently applicable, from startup until complete subframe information is received. Firmware levels 232 and up don’t have this problem. You may run gpsd at debug level 4 to see the chipset type and firmware revision level.

There are exactly two circumstances under which gpsd relies on the host-system clock:

In the GPS broadcast signal, GPS time is represented using a week number that rolls over after 2^10 or 2^13 weeks (about 19.6 years, or 157 years), depending on the spacecraft. Receivers are required to disambiguate this to the correct date, but may have difficulty due to not knowing time to within half this interval, or may have bugs. Users have reported incorrect dates which appear to be due to this issue. gpsd uses the startup time of the daemon detect and compensate for rollovers while it is running, but otherwise reports the date as it is reported by the receiver without attempting to correct it.

If you are using an NMEA-only GPS (that is, not using SiRF or Garmin or Zodiac binary mode), gpsd relies on the system clock to tell it the current century. If the system clock returns an invalid value near zero, and the GPS does not emit GPZDA at the start of its update cycle (which most consumer-grade NMEA GPSes do not) then the century part of the dates gpsd delivers may be wrong. Additionally, near the century turnover, a range of dates as wide in seconds as the accuracy of your system clock may be referred to the wrong century.

## USE WITH NTP
gpsd can provide reference clock information to ntpd or chronyd, to keep the system clock synchronized to the time provided by the GPS receiver.

On Linux, gpsd includes support for interpreting the PPS pulses emitted at the start of every clock second on the carrier-detect lines of some serial GPSes, this pulse can be used to update NTP at much higher accuracy than message time provides. You can determine whether your GPS emits this pulse by running at -D 5 and watching for carrier-detect state change messages in the logfile. In addition, if your kernel provides the RFC 2783 kernel PPS API then gpsd will use that for extra accuracy.

gpsd communicates with ntpd using shared memory segments (SHMs). The SHMs are numbered SHM(0) to SHM(7). and have a name (key) of NTP0 to NTP7. The first local time source on the command line may use NTP0 and NTP1. The second may use NTP2 and NTP3, etc.

You can see the output of gpsd to ntpd in real time with the ntpshmmon command.

Other daemons, such as ptp4l may also be using the same SHMs to talk to ntpd.

Detailed instructions for using GPSD to set up a high-quality time service can be found among the documentation on the GPSD website.

## USE WITH D-BUS
On operating systems that support D-BUS, gpsd can be built to broadcast GPS fixes to D-BUS-aware applications. As D-BUS is still at a pre-1.0 stage, we will not attempt to document this interface here. Read the gpsd source code to learn more.

## SECURITY AND PERMISSIONS ISSUES
gpsd, if given the -G flag, will listen for connections from any reachable host, and then disclose the current position. Before using the -G flag, consider whether you consider your computer’s location to be sensitive data to be kept private or something that you wish to publish.

gpsd must start up as root in order to open the NTPD shared-memory segment, open its logfile, and create its local control socket. Note that starting gpsd with sudo is not the same as starting as root. Before doing any processing of GPS data, it tries to drop root privileges by setting its UID to "nobody" (or another configured userid) and its group ID to the group of the initial GPS passed on the command line — or, if that device doesn’t exist, to the group of /dev/ttyS0.

Privilege-dropping is a hedge against the possibility that carefully crafted data, either presented from a client socket or from a subverted serial device posing as a GPS, could be used to induce misbehavior in the internals of gpsd. It ensures that any such compromises cannot be used for privilege elevation to root.

The assumption behind gpsd's particular behavior is that all the tty devices to which a GPS might be connected are owned by the same non-root group and allow group read/write, though the group may vary because of distribution-specific or local administrative practice. If this assumption is false, gpsd may not be able to open GPS devices in order to read them (such failures will be logged).

In order to fend off inadvertent denial-of-service attacks by port scanners (not to mention deliberate ones), gpsd will time out inactive client connections. Before the client has issued a command that requests a channel assignment, a short timeout (60 seconds) applies. There is no timeout for clients in watcher or raw modes; rather, gpsd drops these clients if they fail to read data long enough for the outbound socket write buffer to fill. Clients with an assigned device in polling mode are subject to a longer timeout (15 minutes).

### CAPABILITIES
If your gpsd was compiled to support capabilities(7), then it may be able to start as a normal user and retain some educed functionality, The following capabilities will be helpful:

Table 2. caps object

Name

Description

CAP_FOWNER

for chmod()

CAP_SETGID

for setgid(), setgroups()

CAP_SETUID

for setuid()

You can set the capabilities by running these commands a root:

```
export CAPS='cap_fowner=ep cap_setgid=ep cap_setuid=ep'
setcap "${CAPS}" [path-to-gpsd]
```

And check the capabilities where set by running this command as a normal user:

```
getcap [path-to-gpsd]
```

## LIMITATIONS
If multiple NMEA talkers are feeding RMC, GLL, and GGA sentences to the same serial device (possible with an RS422 adapter hooked up to some marine-navigation systems), a 'TPV' response may mix an altitude from one device’s GGA with latitude/longitude from another’s RMC/GLL after the second sentence has arrived.

gpsd may change control settings on your GPS (such as the emission frequency of various sentences or packets) and not restore the original settings on exit. This is a result of inadequacies in NMEA and the vendor binary GPS protocols, which often do not give clients any way to query the values of control settings in order to be able to restore them later.

Some receivers do not report VDOP/TDOP/GDOP figures and associated error estimates. In that case they may be computed by gpsd instead. This computation does not exactly match what chips do internally, which includes some satellite weighting using parameters gpsd cannot see.

Autobauding on the Trimble GPSes can take as long as 20 seconds, or more, if the device speed is not matched to the GPS speed. Use the -s option to avoid autobaud delays.

Generation of position error estimates (eph, epv, epd, eps, epc) from the incomplete data handed back by GPS reporting protocols involves both a lot of mathematical black art and fragile device-dependent assumptions. This code has been bug-prone in the past and problems may still lurk there.

AIDVM decoding of types 16-17, 22-23, and 25-26 is unverified.

GPSD presently fully recognizes only the 2.1 level of RTCM2 (message types 1, 3, 4, 5, 6, 7, 9, 16). The 2.3 message types 13, 14, and 31 are recognized and reported. Message types 8, 10-12, 15-27, 28-30 (undefined), 31-37, 38-58 (undefined), and 60-63 are not yet supported.

The ISGPS used for RTCM2 and subframes decoder logic is sufficiently convoluted to confuse some compiler optimizers, notably in GCC 3.x at -O2, into generating bad code.

Devices meant to use PPS for high-precision timekeeping may fail if they are specified after startup by a control-socket command, as opposed to on the daemon’s original command line. Root privileges are dropped early, and some Unix variants require them in order to set the PPS line discipline. Under Linux the POSIX capability to set the line discipline is retained, but other platforms cannot use this code.

USB GPS devices often do not identify themselves through the USB subsystem; they typically present as the class 00h (undefined) or class FFh (vendor-specific) of USB-to-serial adapters. Because of this, the Linux hotplug scripts must tell gpsd to sniff data from every USB-to-serial adapter that goes active and is known to be of a type used in GPSes. No such device is sent configuration strings until after it has been identified as a GPS, and gpsd never opens a device that is opened by another process. But there is a tiny window for non-GPS devices not opened; if the application that wants them loses a race with GPSD its device open will fail and have to be retried after GPSD sniffs the device (normally less than a second later).

## FILES
/dev/ttyS0

Prototype TTY device. After startup, gpsd sets its group ID to the owning group of this device if no GPS device was specified on the command line does not exist.

/etc/gpsd/device-hook

Optional file containing the device activation/deactivation script. Note that while /etc/gpsd is the default system configuration directory, it is possible to build the GPSD source code with different assumptions. See above for further details on the device-hook mechanism.

/@RUNDIR@/chrony.XXX.sock

Optional Unix domain socket provided by chronyd configured with a SOCK reference clock, where XXX is the name of the serial device (e.g. ttyS0). When gpsd is started, it will try to connect to this socket. If connected, it will be sending PPS timing information to chronyd in order to synchronize the system clock.

/@RUNDIR@/chrony.clk.XXX.sock

Similar to chrony.XXX.sock, but will be used to pass timing information to chronyd that is derived from the serial (likely NMEA) timing instead of PPS.

## ENVIRONMENT VARIABLES
By setting the environment variable GPSD_SHM_KEY, you can control the key value used to create the shared-memory segment used for communication with the client library. This will be useful mainly when isolating test instances of gpsd from production ones.

## RETURN VALUES
0

on success.

1

on failure

## APPLICABLE STANDARDS
The official NMEA protocol standards for NMEA0183 and NMEA2000 are available from the National Marine Electronics Association, but are proprietary and expensive; the maintainers of gpsd have made a point of not looking at them. The GPSD project website links to several documents that collect publicly disclosed information about the protocol.

gpsd parses the following NMEA sentences: RMC, GGA, GLL, GSA, GSV, VTG, ZDA, GBS, HDT, DBT, GST. It recognizes these with either the normal GP talker-ID prefix, or with the GN prefix used by GLONASS, or with the II prefix emitted by Seahawk Autohelm marine navigation systems, or with the IN prefix emitted by some Garmin units, or with the EC prefix emitted by ECDIS units, or with the SD prefix emitted by depth sounders, or with the HC and TI prefix emitted by some Airmar equipment. It recognizes some vendor extensions: the PGRME emitted by some Garmin GPS models, the PTNTHTM emitted by True North digital compasses, the PMTK omitted by some San Jose Navigation GPSes, and the PASHR sentences emitted by some Ashtech GPSes.

Note that gpsd JSON returns pure decimal degrees, not the hybrid degree/minute format described in the NMEA standard.

Differential-GPS corrections are conveyed by the RTCM protocols. The applicable standard for RTCM-104 V2 is RTCM Recommended Standards for Differential GNSS (Global Navigation Satellite) Service RTCM Paper 136-2001/SC 104-STD. The applicable standard for RTCM-104 V3 is RTCM Standard 10403.1 for Differential GNSS Services - Version 3 RTCM Paper 177-2006-SC104-STD. Ordering instructions for the RTCM standards are accessible from the website of the Radio Technical Commission for Maritime Services under "Publications".

AIS is defined by ITU Recommendation M.1371, Technical Characteristics for a Universal Shipborne Automatic Identification System Using Time Division Multiple Access. The AIVDM/AIVDO format understood by this program is defined by IEC-PAS 61162-100, Maritime navigation and radiocommunication equipment and systems. A more accessible description of both can be found at AIVDM/AIVDO Protocol Decoding, on the references page of the GPSD project website.

Subframe data is defined by IS-GPS-200, GLOBAL POSITIONING SYSTEM WING (GPSW) SYSTEMS ENGINEERING & INTEGRATION, INTERFACE SPECIFICATION IS-GPS-200. The format understood by this program is defined in Section 20 (Appendix II),

JSON is specified by RFC 7159, The JavaScript Object Notation (JSON) Data Interchange Format.

The API for PPS time service is specified by RFC 2783, Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0

The gpsd capabilities follow the proposed, but rescinded POSIX 1e Section 25.2 Capabilities. See capabilities(7).

## AUTHORS
Authors: Eric S. Raymond, Chris Kuethe, Gary Miller. Former authors whose bits have been plowed under by code turnover: Remco Treffcorn, Derrick Brashear, Russ Nelson.

This manual page by Eric S. Raymond <esr@thyrsus.com>.

## SEE ALSO
gpsctl(1), gps(1), gpsprof(1), gpsfake(1). gpscat(1), *ntpshmmon(1),

libgps(3), libgpsmm(3)

gpsd_json(5)

capabilities(7)

chronyd(8), gpsd(8), gpsdctl(8), ntpd(8)

## RESOURCES
Project web site: <https://gpsd.io/> GPSD FAQ: <https://gpsd.io/faq.html> GPSD Time Service HOWTO: <https://gpsd.io/gpsd-time-service-howto.html> Introduction to Time Service: <https://gpsd.io/time-service-intro.html>

## COPYING
This file is Copyright by the GPSD project

SPDX-License-Identifier: BSD-2-clause


gpsdctl

title: gpsdctl(8)

text:
# gpsdctl(8)

## NAME
gpsdctl - tool for sending commands to gpsd over its control socket

## SYNOPSIS
gpsdctl action device

## OPTIONS
action

may be add or remove. If no daemon instance is running when an add is requested, this program will launch one.

device

argument should be the pathname of a device. The device will be opened by gpsd to read sensor data.

## DESCRIPTION
This is a tool for sending an instance of gpsd commands over its control socket to add or remove devices from the daemon’s device list. It is not intended to be called by users, but rather by the Linux hotplug system and similar facilities.

## ENVIRONMENT
Two environment variables are interpreted.

GPSD_SOCKET

sets the location of the control socket. If the effective user ID of this program is root then it usually defaults to /run/gpsd.sock, although some systems may use the deprecated /var/run/gpsd.sock instead. Non-root users will use /tmp/gpsd.sock.

GPSD_OPTIONS

may be a list of options to be passed to gpsd when this tool launches it. It defaults to an empty string.

## RETURN VALUES
0

on success.

1

if the action was unknown or the write to the control socket failed,

## SEE ALSO
gpsd(8), gpsctl(1), gps(1), libgps(3), libgpsmm(3), gpsprof(1), gpsfake(1).

## RESOURCES
Project web site: <https://gpsd.io/>

## COPYING
This file is Copyright 2013 by the GPSD project

SPDX-License-Identifier: BSD-2-clause

## AUTHOR
Eric S. Raymond


gpsinit

title: gpsinit(8)

summary: initialize CAN kernel modules for GPSD

text:
# gpsinit(8)

## NAME
gpsinit - initialize CAN kernel modules for GPSD

## SYNOPSIS
gpsinit [-n control] [-s speed] module_name [interface_name]

gpsinit -h

gpsinit -V

## DESCRIPTION
gpsinit initializes whatever kernel-level modules are needed to enable special non-serial hardware to communicate with a gpsd instance. Note: it will need root permissions to load modules and perform other special operations, such as changing kernel-interface baudrates.

At present, all modes of this tool are concerned with setting up kernel-level interfaces to hardware on a CAN (Control Area Network) speaking NMEA2000.

The program accepts the following options:

-h

Display a brief help text.

-n

Set the CAN network number. The default is 0.

-s

Set the baudrate to be used to communicate over the serial line to the CAN hardware. The default is 38400 baud.

-V

Display the version of gpsinit.

The parameter module_name is mandatory. The socket CAN driver module module_name.ko will be loaded. gpsinit recognize the following module names:

plx_pci, esd_usb2, vcan, slcan

The parameter interface_name and -s speed can used here.

beaglebone

The dcan module needed for the beaglebone is part of the Linux kernel, so no module is loaded in this case.

The parameter interface_name is needed for slcan hardware only. It gives the name of the serial device to which the SL CAN hardware is connected. The default is /dev/ttyUSB0.

## EXAMPLES
All the following examples probably need to be run as root.

gpsinit plx_pci

Attempt to load the module plx_pci and initialize net 0 for the connection to a NMEA2000 network. It will set the baudrate to 250kBits.

gpsinit -n 1 plx_pci

As above, but use net 1.

gpsinit -s 38400 slcan /dev/ttyUSB0

Attempt to load the module slcan and talk to the hardware at 38400 baud connected to port /dev/ttyUSB0.

gpsinit -h

Display a brief help message.

gpsinit -v

Display the version of gpsinit.

## RETURN VALUES
0

on success.

1

on failure

## SEE ALSO
gpsd(8), gps(1)

## RESOURCES
Project web site: <https://gpsd.io/>

## COPYING
This file is Copyright 2013 by the GPSD project

SPDX-License-Identifier: BSD-2-clause

## AUTHOR
Reinhard Arlt


ppscheck

title: ppscheck(8)

summary: tool to check a serial port for PPS

text:
# ppscheck(8)

## NAME
ppscheck - tool to check a serial port for PPS

## SYNOPSIS
ppscheck [-?] [--help] [-p] [--pps] [--version] [-h] [-V]

ppscheck [-m] device

## DESCRIPTION
ppscheck watches a specified serial port for transitions that might be PPS. It looks for changes in handshake lines CD, CTS, DSR, and RI by running ioctl(...., TIOCMIWAIT, ...) in a loop. When it sees a state change it emits a timestamped line of output dumping the state of the handshake signals. It’s useful for checking whether a device is emitting PPS.

ppscheck can run as a normal user, but that user must have permissions to read the target device. Running under sudo may, or may not, work. Running as root will always work.

To check the first serial port do this:

```
# ppscheck /dev/ttyS0
```

As a side effect, ppscheck will try to create the matching /dev/ppsX by setting the tty line discipline (ldisc) to N_PPS (18). You should then have a device /dev/pps0. Note that not all serial devices support ldisc N_PPS.

You can now use ppscheck to see if the KPPS (RFC 2783) interface is working:

```
# ppscheck /dev/pps0
```

ppscheck is not intended for routine use, but rather for diagnostic purposes. Once you have verified a particular device can output PPS signals you will never need to use it again on that device.

## OPTIONS
The program accepts the following options:

-?, `-h, `--help

Print help message, then exit.

-m, `--match

Find PPS device that matches device.

-p, `--pps

Print active PPS devices, then exit.

-V, `--version

Dump version, then exit.

-x SEC, --seconds SEC

Exit after delay of SEC seconds.

## ARGUMENTS
The device argument should be the pathname of a device. Such as /dev/ttyS0 or /dev/pps0. It will be the device monitored.

For a tty device, each output line is the second and nanosecond parts of a timestamp followed by the names of the handshake signals then asserted. Off transitions may generate lines with no signals asserted.

For a pps device, each output line will contain the assert and clear times last detected by KPPS.

If you don’t see output within a second, use cgps, xgps, or some other equivalent tool to check that your device has a satellite lock and is getting 3D fixes before giving up on the possibility of PPS.

Check your cable. Cheap DB9 to DB9 cables such as those issued with UPSes often carry TXD/RXD/GND only, omitting handshake lines such as CD. Suspect this especially if the cable jacket looks too skinny to hold more than three leads!

Most GPS that have built in USB do not support PPS. When in doubt, contact the vendor for confirmation that your device does supply PPS.

## RETURN VALUES
0

OK

1

if the device could not be opened, or some other failure

## SEE ALSO
cgps(1), xgps(1), gpsd(8)

## RESOURCES
Project web site: <https://gpsd.io/>

## COPYING
This file is Copyright 2013 by the GPSD project

SPDX-License-Identifier: BSD-2-clause

## AUTHOR
Eric S. Raymond


grub-btrfs

package: grub-btrfs

title: grub-btrfs(8)

text:
# grub-btrfs(8)

## NAME
grub-btrfs - Automatically add btrfs-Snapshots as a Grub submenu

## SYNOPSIS
/etc/grub.d/41_snapshots-btrfs [-V, --version]

## DESCRIPTION
Improves grub by adding “btrfs snapshots” to the grub menu.

You can boot your system on a “snapshot” from the grub menu. Supports manual snapshots, snapper and timeshift. Features of grub-btrfs:

—

Automatically list snapshots existing on root partition (btrfs).

—

Automatically detect if /boot is in separate partition.

—

Automatically detect kernel, initramfs and intel/amd microcode in /boot directory on snapshots.

—

Automatically create corresponding “menuentry” in grub.cfg

—

Automatically detect the type/tags and descriptions/comments of snapper/timeshift snapshots.

—

Automatically generate grub.cfg if you use the provided systemd service.

## CONFIGURATION
grub-btrfs is configured via the file /etc/default/grub-btrfs/config. Possible options are:

### GRUB_BTRFS_DISABLE
Disable grub-btrfs if true.

—

Default: “false”

—

Example: GRUB_BTRFS_DISABLE="true"

### GRUB_BTRFS_TITLE_FORMAT
The snapshot entries submenu in Grub are added according to this line. It is possible to change to order of the fields.

—

Default: (“date” “snapshot” “type” “description”)

—

Example: GRUB_BTRFS_TITLE_FORMAT=("date" "snapshot" "type" "description")

### GRUB_BTRFS_LIMIT
Maximum number of snapshots in the GRUB snapshots sub menu.

—

Default: “50”

—

Example: GRUB_BTRFS_LIMIT="50"

### GRUB_BTRFS_SUBVOLUME_SORT
Sort the found subvolumes by “ogeneration” or “generation” or “path” or “rootid”.

—

See Sorting section in btrfs-subvolume(8)

“-rootid” means list snapshot by new ones first.

—

Default: “-rootid”

—

Example: GRUB_BTRFS_SUBVOLUME_SORT="+ogen,-gen,path,rootid"

### GRUB_BTRFS_SHOW_SNAPSHOTS_FOUND
Show snapshots found during run “grub-mkconfig”

—

Default: “true”

—

Example: GRUB_BTRFS_SHOW_SNAPSHOTS_FOUND="false"

### GRUB_BTRFS_ROOTFLAGS
Comma seperated mount options to be used when booting a snapshot. They can be defined here as well as in the “/” line inside the respective snapshots’ “/etc/fstab” files. Mount options found in both places are combined, and this variable takes priority over `fstab` entries. NB: Do NOT include “subvol=...” or “subvolid=...” here.

—

Default: “”

—

Example: GRUB_BTRFS_ROOTFLAGS="space_cache,commit=10,norecovery"

### GRUB_BTRFS_OVERRIDE_BOOT_PARTITION_DETECTION
By default “grub-btrfs” automatically detects your boot partition, either located at the system root or on a separate partition or in a subvolume, Change to “true” if your boot partition is not detected as separate.

—

Default: “false”

—

Example: GRUB_BTRFS_OVERRIDE_BOOT_PARTITION_DETECTION="true"

### GRUB_BTRFS_NKERNEL / GRUB_BTRFS_NINIT / GRUB_BTRFS_CUSTOM_MICROCODE
By default, “grub-btrfs” automatically detects most existing kernels, initramfs and microcode. Customs kernel, initramfs and microcodes that are not detected can be added in these variables.

—

Default: (“”)

—

Example: GRUB_BTRFS_NKERNEL=("kernel-5.19.4-custom" "vmlinux-5.19.4-custom") GRUB_BTRFS_NINIT=("initramfs-5.19.4-custom.img" "initrd-5.19.4-custom.img" "otherinit-5.19.4-custom.gz") GRUB_BTRFS_CUSTOM_MICROCODE=("custom-ucode.img" "custom-uc.img "custom_ucode.cpio")

### GRUB_BTRFS_SNAPSHOT_KERNEL_PARAMETERS
Additonal kernel command line parameters that should be passed to the kernelwhen booting a snapshot. For dracut based distros this could be useful to pass “rd.live.overlay.overlayfs=1” or “rd.live.overlay.readonly=1” to the Kernel for booting read only snapshots.

—

Default: “”

—

Example: GRUB_BTRFS_SNAPSHOT_KERNEL_PARAMETERS="rd.live.overlay.overlayfs=1"

### GRUB_BTRFS_IGNORE_SPECIFIC_PATH
Ignore specific path during run “grub-mkconfig”. Only exact paths are ignored. e.g : if `specific path` = @, only `@` snapshot will be ignored.

—

Default: (“@”)

—

Example: GRUB_BTRFS_IGNORE_SPECIFIC_PATH=("@home")

### GRUB_BTRFS_IGNORE_PREFIX_PATH
Ignore prefix path during run “grub-mkconfig”. Any path starting with the specified string will be ignored. e.g : if `prefix path` = @, all snapshots beginning with “@/...” will be ignored.

—

Default: (“var/lib/docker” “@var/lib/docker” “@/var/lib/docker”)

—

Example: GRUB_BTRFS_IGNORE_PREFIX_PATH=("var/lib/docker" "@var/lib/docker" "@/var/lib/docker")

### GRUB_BTRFS_IGNORE_SNAPSHOT_TYPE
Ignore specific type/tag of snapshot during run “grub-mkconfig”. For snapper: Type = single, pre, post. For Timeshift: Tag = boot, ondemand, hourly, daily, weekly, monthly.

—

Default: (“”)

—

Example: GRUB_BTRFS_IGNORE_SNAPSHOT_TYPE=("ondemand")

### GRUB_BTRFS_IGNORE_SNAPSHOT_DESCRIPTION
Ignore specific description of snapshot during run “grub-mkconfig”.

—

Default: (“”)

—

Example: GRUB_BTRFS_IGNORE_SNAPSHOT_DESCRIPTION=("timeline")

### GRUB_BTRFS_BOOT_DIRNAME
Location of kernels/initramfs/microcode. Used by “grub-btrfs” to detect the boot partition and the location of kernels, initramfs and microcodes.

—

Default: “/boot”

—

Example: GRUB_BTRFS_BOOT_DIRNAME="/"

### GRUB_BTRFS_GRUB_DIRNAME
Location of the folder containing the “grub.cfg” file. Might be grub2 on some systems. For example, on Fedora with EFI : “/boot/efi/EFI/fedora”

—

Default: “/boot/grub”

—

Example: GRUB_BTRFS_GRUB_DIRNAME="/boot/grub2"

### GRUB_BTRFS_GBTRFS_DIRNAME
Location where grub-btrfs.cfg should be saved. Some distributions (like OpenSuSE) store those file at the snapshot directory instead of boot. Be aware that this direcory must be available for grub during startup of the system.

—

Default: $GRUB_BTRFS_GRUB_DIRNAME

—

Example: GRUB_BTRFS_GBTRFS_DIRNAME="/.snapshots"

### GRUB_BTRFS_GBTRFS_SEARCH_DIRNAME
Location of the directory where Grub searches for the grub-btrfs.cfg file. Some distributions (like OpenSuSE) store those file at the snapshot directory instead of boot. Be aware that this direcory must be available for grub during startup of the system.

—

Default: “prefix}” (This is a grub variable that resolves to where grub is

installed. (like /boot/grub, /boot/efi/grub))

—

NOTE: If variables of grub are used here like ${prefix}, they need to be escaped

with `$` before the `$`

—

Example: GRUB_BTRFS_GBTRFS_SEARCH_DIRNAME="prefix}"

### GRUB_BTRFS_MKCONFIG
Name/path of the command to generate the grub menu, used by “grub-btrfs.service” Might be ’grub2-mkconfig’ on some systems (e.g. Fedora) Default paths are /sbin:/bin:/usr/sbin:/usr/bin, if your path is missing, report it on the upstream project. You can use the name of the command only or full the path.

—

Default: grub-mkconfig

—

Example: GRUB_BTRFS_MKCONFIG=/sbin/grub2-mkconfig

### GRUB_BTRFS_SCRIPT_CHECK
Name of grub-script-check command, used by “grub-btrfs” Might be ’grub2-script-check’ on some systems (e.g. Fedora)

—

Default: grub-script-check

—

Example: GRUB_BTRFS_SCRIPT_CHECK=grub2-script-check

### GRUB_BTRFS_MKCONFIG_LIB
Path of grub-mkconfiglib file, used by “grub-btrfs” Might be ’/usr/share/grub2/grub-mkconfiglib’ on some systems (e.g. Opensuse)

—

Default: /usr/share/grub/grub-mkconfiglib

—

Example: GRUB_BTRFS_MKCONFIG_LIB=/usr/share/grub2/grub-mkconfig_lib

### GRUB_BTRFS_PROTECTION_AUTHORIZED_USERS
Password protection management for submenu, snapshots Refer to the Grub documentation https://www.gnu.org/software/grub/manual/grub/grub.html#Authentication-and-authorisation and this comment https://github.com/Antynea/grub-btrfs/issues/95#issuecomment-682295660 Add authorized usernames separate by comma (userfoo,userbar). When Grub’s password protection is enabled, the superuser is authorized by default, it is not necessary to add it

—

Default: “”

—

Example: GRUB_BTRFS_PROTECTION_AUTHORIZED_USERS="userfoo,userbar"

### GRUB_BTRFS_DISABLE_PROTECTION_SUBMENU
Disable authentication support for submenu of Grub-btrfs only (--unrestricted) does not work if GRUBBTRFSPROTECTIONAUTHORIZEDUSERS is not empty

—

Default: “false”

—

Example: GRUB_BTRFS_DISABLE_PROTECTION_SUBMENU="true"

## FILES
/etc/default/grub-btrfs/config

## SEE ALSO
btrfs(8) btrfs-subvolume(8) grub-btrfsd(8) grub-mkconfig(8)

## COPYRIGHT
Copyright (c) 2022 Pascal Jäger


grub-btrfsd

title: grub-btrfsd(8)

text:
# grub-btrfsd(8)

## NAME
grub-btrfsd - An OpenRC daemon to automatically update the grub menu with grub-btrfs(8)

when a new btrfs snapshot is created.

## SYNOPSIS
grub-btrfsd [-h, --help] [-c, --no-color] [-l, --log-file LOG_FILE] [-r, --recursive] [-s, --syslog] [-t, --timeshift-auto] [-o, --timeshift-old] [-v, --verbose] SNAPSHOTS_DIRS

## DESCRIPTION
Grub-btrfsd is a shell script which is meant to be run as a daemon. Grub-btrfsd watches a directory where btrfs-snapshots are created or deleted via inotifywait and runs grub-mkconfig (if grub-mkconfig never ran before since grub-btrfs was installed) or /etc/grub.d/41_snapshots-btrfs (when grub-mkconfig ran before with grub-btrfs installed) when something in that directory changes.

## OPTIONS

### SNAPSHOTS_DIRS
This argument specifies the (space separated) paths where grub-btrfsd looks for newly created snapshots and snapshot deletions. It is usually defined by the program used to make snapshots. E.g. for Snapper this would be /.snapshots. It is possible to define more than one directory here, all directories will inherit the same settings (recursive etc.). This argument is not necessary to provide if --timeshift-auto is set.

### -c / --no-color
Disable colors in output.

### -l / --log-file
This arguments specifies a file where grub-btrfsd should write log messages.

### -r / --recursive
Watch snapshot directory recursively

### -s / --syslog
Write to syslog

### -t / --timeshift-auto
This is a flag to activate the auto detection of the path where Timeshift stores snapshots. Newer versions (>=22.06) of Timeshift mount their snapshots to /run/timeshift/$PID/backup/timeshift-btrfs. Where $PID is the process ID of the currently running Timeshift session. The PID is changing every time Timeshift is opened. grub-btrfsd can automatically take care of the detection of the correct PID and directory if this flag is set. In this case the argument SNAPSHOTS_DIRS has no effect.

### -o / --timeshift-old
Look for snapshots in /run/timeshift/backup/timeshift-btrfs instead of /run/timeshift/$PID/backup/timeshift-btrfs. This is to be used for Timeshift versions <22.06.

### -v / --verbose
Let the log of the daemon be more verbose

### -h / --help
Displays a short help message.

## CONFIGURATION
The daemon is usually configured via the file /etc/conf.d/grub-btrfsd on openrc-init systems and sudo systemctl edit --full grub-btrfsd on systemd systems. In this file the arguments (See OPTIONS), that OpenRC passes to the daemon when it is started, can be configured.

### NOTES
A common configuration for Snapper would be to set SNAPSHOTS_DIR to /.snapshots and not to set --timeshift-auto. For Timeshift --timeshift-auto is set to true and SNAPSHOTS_DIR can be left as is.

## FILES
/etc/conf.d/grub-btrfsd /usr/lib/systemd/system/grub-btrfsd.service

## SEE ALSO
btrfs(8) btrfs-subvolume(8) grub-btrfsd(8) grub-mkconfig(8) inotifywait(1) openrc(8) rc-service(8) timeshift(1)

## COPYRIGHT
Copyright (c) 2022 Pascal Jäger


grub-bios-setup

package: grub-common

title: grub-bios-setup(8)

summary: set up a device to boot using GRUB

text:
# grub-bios-setup(8)

## NAME
grub-bios-setup - set up a device to boot using GRUB

## SYNOPSIS
grub-bios-setup [OPTION...] DEVICE

## DESCRIPTION
Set up images to boot from DEVICE.

You should not normally run this program directly. Use grub-install instead.

-a, --allow-floppy

make the drive also bootable as floppy (default for fdX devices). May break on some BIOSes.

-b, --boot-image=FILE

use FILE as the boot image [default=boot.img]

-c, --core-image=FILE

use FILE as the core image [default=core.img]

-d, --directory=DIR

use GRUB files in the directory DIR [default=/boot/grub]

-f, --force

install even if problems are detected

-m, --device-map=FILE

use FILE as the device map [default=/boot/grub/device.map]

--no-rs-codes

Do not apply any reed-solomon codes when embedding core.img. This option is only available on x86 BIOS targets.

-s, --skip-fs-probe

do not probe for filesystems in DEVICE

-v, --verbose

print verbose messages.

-?, --help

give this help list

--usage

give a short usage message

-V, --version

print program version

Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options.

DEVICE must be an OS device (e.g. /dev/sda).

## REPORTING BUGS
Report bugs to <bug-grub@gnu.org>.

## SEE ALSO
grub-install(8), grub-mkimage(1), grub-mkrescue(1)

The full documentation for grub-bios-setup is maintained as a Texinfo manual. If the info and grub-bios-setup programs are properly installed at your site, the command

info grub-bios-setup

should give you access to the complete manual.


grub-entries

title: grub-entries(8)

text:
# grub-entries(8)

## NAME
grub-entries - simple script for show grub menu and check menu items

## SYNOPSIS
grub-entries [options]

## DESCRIPTION
grub-entries parse specified or default grub config file, list all grub menu items in the one of the three forms. Also can search specified item in menu and returns 0, if this item exists, otherwise returns non-zero value. By default, /boot/grub/grub.cfg config file used.

In default output mode, menu items that match the saved default entry (set by grub-set-default(8)) are marked with *, and items that match the next boot entry (set by grub-reboot(8)) are marked with N. If an entry matches both, both markers are shown (* N). The markers appear between the item number and the title. Entries are matched by number, title, or menuentry id.

## OPTIONS
-f, --config filename

Specify path to the grub config.

-e, --env filename

Specify path to the grub environment file. By default, grubenv in the same directory as the grub config is used.

-n, --numbers

Show only menu item sequence numbers.

-t, --titles

Show only menu item names.

-c, --check menuitem

Specify menu item to validate.

-V, --version

Show script version and exit.

-h, --help

Show help message and exit.

## FILES
/boot/grub/grub.cfg

Default grub configuration file.

/boot/grub/grubenv

Default grub environment file (read via grub-editenv(1)).

## AUTHORS
Leonid Krivoshein <klark@altlinux.org>

## SEE ALSO
grub-reboot(8), grub-set-default(8)


grub-install

title: grub-install(8)

summary: install GRUB to a device

text:
# grub-install(8)

## NAME
grub-install - install GRUB to a device

## SYNOPSIS
grub-install [OPTION...] [OPTION] [INSTALL_DEVICE]

## DESCRIPTION
Install GRUB on your drive.

--appended-signature-size=SIZE

Add a note segment reserving SIZE bytes for an appended signature

--compress=no|xz|gz|lzo

compress GRUB files [optional]

--disable-cli

disabled command line interface access

--disable-shim-lock

disable shim_lock verifier

--dtb=FILE

embed a specific DTB

-d, --directory=DIR

use images and modules under DIR [default=/usr/lib64/grub/<platform>]

--fonts=FONTS

install FONTS [default=unicode]

--install-modules=MODULES

install only MODULES and their dependencies [default=all]

-k, --pubkey=FILE

embed FILE as public key for signature checking

--locale-directory=DIR use translations under DIR

[default=/usr/share/locale]

--locales=LOCALES

install only LOCALES [default=all]

--modules=MODULES

pre-load specified modules MODULES

--no-sbat

do not embed default SBAT metadata

--sbat=FILE

SBAT metadata [default=./sbat.csv]

--themes=THEMES

install THEMES [default=starfield]

-v, --verbose

print verbose messages.

-x, --x509key=FILE

embed FILE as an x509 certificate for appended signature checking

--allow-floppy

make the drive also bootable as floppy (default for fdX devices). May break on some BIOSes.

--boot-directory=DIR

install GRUB images under the directory DIR/grub instead of the boot/grub directory

--boot-directory-only

populate /boot/grub without installing to ESP or updating NVRAM. This option is only available on EFI targets.

--bootloader-id=ID

the ID of bootloader. This option is only available on EFI and Macs.

--core-compress=xz|none|auto

choose the compression to use for core image

--disk-module=MODULE

disk module to use (biosdisk or native). This option is only available on BIOS target.

--efi-directory=DIR

use DIR as the EFI System Partition root.

--force

install even if problems are detected

--force-file-id

use identifier file even if UUID is available

--label-bgcolor=COLOR

use COLOR for label background

--label-color=COLOR

use COLOR for label

--label-font=FILE

use FILE as font for label

--macppc-directory=DIR use DIR for PPC MAC install.

--no-bootsector

do not install bootsector

--no-nvram

don't update the `boot-device'/`Boot*' NVRAM variables. This option is only available on EFI and IEEE1275 targets.

--no-rs-codes

Do not apply any reed-solomon codes when embedding core.img. This option is only available on x86 BIOS targets.

--product-version=STRING

use STRING as product version

--recheck

delete device map if it already exists

--removable

the installation device is removable. This option is only available on EFI.

-s, --skip-fs-probe

do not probe for filesystems in DEVICE

--target=TARGET

install GRUB for TARGET platform [default=i386-pc]; available targets: arm-coreboot, arm-efi, arm-uboot, arm64-efi, i386-coreboot, i386-efi, i386-ieee1275, i386-multiboot, i386-pc, i386-qemu, i386-xen, i386-xen_pvh, ia64-efi, loongarch64-efi, mips-arc, mips-qemu_mips, mipsel-arc, mipsel-loongson, mipsel-qemu_mips, powerpc-ieee1275, riscv32-efi, riscv64-efi, sparc64-ieee1275, x86_64-efi, x86_64-xen

-?, --help

give this help list

--usage

give a short usage message

-V, --version

print program version

Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options.

INSTALL_DEVICE must be system device filename. grub-install copies GRUB images into boot/grub. On some platforms, it may also install GRUB into the boot sector.

## REPORTING BUGS
Report bugs to <bug-grub@gnu.org>.

## SEE ALSO
grub-mkconfig(8), grub-mkimage(1), grub-mkrescue(1)

The full documentation for grub-install is maintained as a Texinfo manual. If the info and grub-install programs are properly installed at your site, the command

info grub-install

should give you access to the complete manual.


grub-macbless

title: grub-macbless(8)

summary: bless a mac file/directory

text:
# grub-macbless(8)

## NAME
grub-macbless - bless a mac file/directory

## SYNOPSIS
grub-macbless [OPTION...] --ppc PATH|--x86 FILE

## DESCRIPTION
Mac-style bless on HFS or HFS+

-p, --ppc

bless for ppc-based macs

-v, --verbose

print verbose messages.

-x, --x86

bless for x86-based macs

-?, --help

give this help list

--usage

give a short usage message

-V, --version

print program version

## REPORTING BUGS
Report bugs to <bug-grub@gnu.org>.

## SEE ALSO
grub-install(1)

The full documentation for grub-macbless is maintained as a Texinfo manual. If the info and grub-macbless programs are properly installed at your site, the command

info grub-macbless

should give you access to the complete manual.


grub-mkconfig

title: grub-mkconfig(8)

summary: generate a GRUB configuration file

text:
# grub-mkconfig(8)

## NAME
grub-mkconfig - generate a GRUB configuration file

## SYNOPSIS
grub-mkconfig [OPTION]

## DESCRIPTION
Generate a grub config file

-o, --output=FILE

output generated config to FILE [default=stdout]

-h, --help

print this message and exit

-V, --version

print the version information and exit

## REPORTING BUGS
Report bugs to <bug-grub@gnu.org>.

## SEE ALSO
grub-install(8)

The full documentation for grub-mkconfig is maintained as a Texinfo manual. If the info and grub-mkconfig programs are properly installed at your site, the command

info grub-mkconfig

should give you access to the complete manual.


grub-ofpathname

title: grub-ofpathname(8)

summary: find OpenBOOT path for a device

text:
# grub-ofpathname(8)

## NAME
grub-ofpathname - find OpenBOOT path for a device

## SYNOPSIS
grub-ofpathname DEVICE

## SEE ALSO
grub-probe(8)

The full documentation for grub-ofpathname is maintained as a Texinfo manual. If the info and grub-ofpathname programs are properly installed at your site, the command

info grub-ofpathname

should give you access to the complete manual.


grub-probe

title: grub-probe(8)

summary: probe device information for GRUB

text:
# grub-probe(8)

## NAME
grub-probe - probe device information for GRUB

## SYNOPSIS
grub-probe [OPTION...] [OPTION]... [PATH|DEVICE]

## DESCRIPTION
Probe device information for a given path (or device, if the -d option is given).

-0

separate items in output using ASCII NUL characters

-d, --device

given argument is a system device, not a path

-m, --device-map=FILE

use FILE as the device map [default=/boot/grub/device.map]

-t, --target=TARGET

print TARGET available targets: abstraction, arc_hints, baremetal_hints, bios_hints, compatibility_hint, cryptodisk_uuid, device, disk, drive, efi_hints, fs, fs_label, fs_uuid, gpt_parttype, hints_string, ieee1275_hints, msdos_parttype, partmap, partuuid, zero_check [default=fs]

-v, --verbose

print verbose messages (pass twice to enable debug printing).

-?, --help

give this help list

--usage

give a short usage message

-V, --version

print program version

Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options.

## REPORTING BUGS
Report bugs to <bug-grub@gnu.org>.

## SEE ALSO
grub-fstest(1)

The full documentation for grub-probe is maintained as a Texinfo manual. If the info and grub-probe programs are properly installed at your site, the command

info grub-probe

should give you access to the complete manual.


grub-reboot

title: grub-reboot(8)

text:
# grub-reboot(8)

## NAME
grub-reboot - set the default boot entry for GRUB, for the next boot only

## SYNOPSIS
grub-reboot [OPTION] MENU_ENTRY

## DESCRIPTION
Set the default boot menu entry for GRUB, for the next boot only.

-h, --help

print this message and exit

-V, --version

print the version information and exit

--boot-directory=DIR

expect GRUB images under the directory DIR/grub instead of the /boot/grub directory

MENU_ENTRY is a number, a menu item title or a menu item identifier. Please note that menu items in submenus or sub-submenus require specifying the submenu components and then the menu item component. The titles should be separated using the greater-than character (>) with no extra spaces. Depending on your shell some characters including > may need escaping. More information about this is available in the GRUB Manual in the section about the 'default' command.

NOTE: In cases where GRUB cannot write to the environment block, such as when it is stored on an MDRAID or LVM device, the chosen boot menu entry will remain the default even after reboot.

## REPORTING BUGS
Report bugs to <bug-grub@gnu.org>.

## SEE ALSO
grub-set-default(8), grub-editenv(1)

The full documentation for grub-reboot is maintained as a Texinfo manual. If the info and grub-reboot programs are properly installed at your site, the command

info grub-reboot

should give you access to the complete manual.


grub-set-default

title: grub-set-default(8)

text:
# grub-set-default(8)

## NAME
grub-set-default - set the saved default boot entry for GRUB

## SYNOPSIS
grub-set-default [OPTION] MENU_ENTRY

## DESCRIPTION
Set the default boot menu entry for GRUB. This requires setting GRUB_DEFAULT=saved in /etc/default/grub.

-h, --help

print this message and exit

-V, --version

print the version information and exit

--boot-directory=DIR

expect GRUB images under the directory DIR/grub instead of the /boot/grub directory

MENU_ENTRY is a number, a menu item title or a menu item identifier.

## REPORTING BUGS
Report bugs to <bug-grub@gnu.org>.

## SEE ALSO
grub-reboot(8), grub-editenv(1)

The full documentation for grub-set-default is maintained as a Texinfo manual. If the info and grub-set-default programs are properly installed at your site, the command

info grub-set-default

should give you access to the complete manual.


title: grub-sparc64-setup(8)

summary: set up a device to boot using GRUB

text:
# grub-sparc64-setup(8)

## NAME
grub-sparc64-setup - set up a device to boot using GRUB

## SYNOPSIS
grub-sparc64-setup [OPTION...] DEVICE

## DESCRIPTION
Set up images to boot from DEVICE.

You should not normally run this program directly. Use grub-install instead.

-a, --allow-floppy

make the drive also bootable as floppy (default for fdX devices). May break on some BIOSes.

-b, --boot-image=FILE

use FILE as the boot image [default=boot.img]

-c, --core-image=FILE

use FILE as the core image [default=core.img]

-d, --directory=DIR

use GRUB files in the directory DIR [default=/boot/grub]

-f, --force

install even if problems are detected

-m, --device-map=FILE

use FILE as the device map [default=/boot/grub/device.map]

--no-rs-codes

Do not apply any reed-solomon codes when embedding core.img. This option is only available on x86 BIOS targets.

-s, --skip-fs-probe

do not probe for filesystems in DEVICE

-v, --verbose

print verbose messages.

-?, --help

give this help list

--usage

give a short usage message

-V, --version

print program version

Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options.

DEVICE must be an OS device (e.g. /dev/sda).

## REPORTING BUGS
Report bugs to <bug-grub@gnu.org>.

## SEE ALSO
grub-install(8), grub-mkimage(1), grub-mkrescue(1)

The full documentation for grub-sparc64-setup is maintained as a Texinfo manual. If the info and grub-sparc64-setup programs are properly installed at your site, the command

info grub-sparc64-setup

should give you access to the complete manual.


update-grub

title: update-grub(8)

summary: stub for grub-mkconfig

text:
# update-grub(8)

## NAME
update-grub, update-grub2 - stub for grub-mkconfig

## SYNOPSIS
update-grub

## DESCRIPTION
update-grub is a stub for running grub-mkconfig -o /boot/grub/grub.cfg to generate a grub2 config file.

## SEE ALSO
grub-mkconfig(8)


gssntlmssp

package: gssntlmssp

title: gssntlmssp(8)

text:
# gssntlmssp(8)

## NAME
gssntlmssp - GSSAPI NTLM Security Service Provider mechanism

## SYNOPSIS
gssntlmssp_v1 2.16.840.1.113730.3.8.15.X /usr/lib64/gssntlmssp/gssntlmssp.so [options]

## DESCRIPTION
A GSSAPI NTLM mechanism that allows to perform NTLM authentication in GSSAPI programs.

## ENVIRONMENT VARIABLES
NTLM_USER_FILE

A file containing users and their password hashes. The file formats supported are the one used by Heimdal for its NTLM backend, and the samba password file format.

NETBIOS_COMPUTER_NAME

Set the NETBIOS (short) Computer name used in NTLM packets

NETBIOS_DOMAIN_NAME

Set the NETBIOS (short) Domain name used in NTLM packets

NTLMUSER

Set the NTLM User name used for authentication on initiation of the security context

USER

The default source for the User name used on initiation of the security context

LM_COMPAT_LEVEL

The LM Compatibility Level enforced during security context negotiation. The default level is 3

GSSNTLMSSP_DEBUG

The name of a file to send debug logs

GSSNTLMSSP_WB_TLS_CTX

This variable is used to control whether thread local contexts are used for winbindd communication or whether a single process context is used. Setting the value of this variable to 0 disables per-thread contexts. Because creating Winbindd contexts is an expensive operation this is used as an optimization in applications that can insure a single thread is used, or already handle their own locking. The default behavior is to create a context for each thread, this behavior can be restored by setting the environment variable back to the value 1

## SEE ALSO
gssapi(8).

## AUTHORS
GSS-NTLMSSP - http://ssimo.org/gss-ntlmssp


gssproxy

package: gssproxy

title: gssproxy(8)

summary: GssProxy Daemon

text:
# gssproxy(8)

## NAME
gssproxy - GssProxy Daemon

## SYNOPSIS
gssproxy [options]

## DESCRIPTION
gssproxy provides a daemon to manage access to GSSAPI credentials.

gssproxy consists of the gssproxy daemon (configured by the gssproxy.conf(5) file) and a GSSAPI interposer plugin (gssproxy-mech(8)).

## OPTIONS
-D,--daemon

Become a daemon after starting up.

-c,--config

Specify a config file to use as the main config file (read before the rest of the config directory). The default is to use the file /etc/gssproxy/gssproxy.conf. For reference on the config file syntax and options, consult the gssproxy.conf(5) manual page.

-C,--configdir

Specify a non-default config dir. Files named of the form "##-foo.conf" (that is, beginning with two digits and a dash, and ending in ".conf") will be read in numeric order from this directory, in addition to the config file itself. The default is /etc/gssproxy. For reference on the config file syntax and options, consult the gssproxy.conf(5) manual page.

-d,--debug

Turn on debugging. This option is identical to --debug-level=1.

--debug-level=

Turn on debugging at the specified level. 0 corresponds to no logging, while 1 turns on basic debug logging. Level 2 increases verbosity, including more detailed credential verification. At level 3 and above, KRB5_TRACE output is logged. If KRB5_TRACE was already set in the execution environment, trace output is sent to its value instead.

-i,--interactive

Run in the foreground, don't become a daemon.

-u,--userproxy

Run gssproxy in userproxy mode. This mode ignores configuration files, and listens on a socket in $XDG_RUNTIME_DIR/gssproxy/default.sock instead. See the project documentation for more information on the behavior of this mode.

-s,--socket

Specify a custom default socket name. This socket will be used by all sections that do not define an explicit socket.

--syslog-status

Enable additional logging to syslog.

--version

Print version number and exit.

## SIGNALS
SIGTERM/SIGINT

Informs the GssProxy to gracefully terminate all of its child processes and then shut down.

SIGHUP

Request a reload of all configuration for gssproxy. If there is an error in the configuration files, the existing configuration will not be replaced; if there is a problem applying the new configuration, gssproxy will exit.

## SEE ALSO
gssproxy.conf(5) and gssproxy-mech(8).

## AUTHORS
GSS-Proxy - http://fedorahosted.org/gss-proxy


gssproxy-mech

title: gssproxy-mech(8)

summary: GssProxy GSSAPI mechanism plugin

text:
# gssproxy-mech(8)

## NAME
gssproxy-mech - GssProxy GSSAPI mechanism plugin

## SYNOPSIS
proxymech_v1 2.16.840.1.113730.3.8.15.1 /usr/lib64/gssproxy/proxymech.so [options]

## DESCRIPTION
The gssproxy proxymech module is a interposer plugin that is loaded by GSSAPI. It is enabled by /etc/gss/mech configuration file.

The interposer plugin allows to intercept the entire GSSAPI communication and detour to the gssproxy daemon. When the interposer plugin is installed two other conditions need to be met in order to activate it:

a) interposer configuration file

The plugin needs to be manually enabled in the /etc/gss/mech file.

b) gssproxy environment variable

With default build options the interposer plugin will not forward to the gssproxy daemon unless the environment variable named GSS_USE_PROXY=yes is set. This behavior default may be controlled at build time and can be set to always forward unless the environment variable is set to GSS_USE_PROXY=no

The current setting for always forwarding is: false

Furthermore, the interposer plugin can be configured to behave in different ways when called from the GSSAPI. This behavior is controlled via the GSSPROXY_BEHAVIOR environment variable. It accepts four different values:

LOCAL_ONLY

All commands received with this setting will cause to immediately reenter the GSSAPI w/o any interaction with the gssproxy daemon. When the request cannot be processed it will just fail.

LOCAL_FIRST

All commands received with this setting will cause to immediately reenter the GSSAPI. When the local GSSAPI cannot process the request, it will resend the request to the gssproxy daemon.

REMOTE_FIRST

All commands received with this setting will be forwarded to the gssproxy daemon first. If the request cannot be handled there, the request will reenter the local GSSAPI.

REMOTE_ONLY

This setting is currently not fully implemented and therefor not supported.

The default setting for GSSPROXY_BEHAVIOR is REMOTE_FIRST.

Finally the interposer may need to use a special per-service socket in order to communicate with gssproxy. The path to this socket is set via the GSSPROXY_SOCKET environment variable.

## SEE ALSO
gssproxy.conf(5) and gssproxy(8).

## AUTHORS
GSS-Proxy - http://fedorahosted.org/gss-proxy


guacd

package: guacd

title: guacd(8)

summary: Guacamole proxy daemon

text:
# guacd(8)

## NAME
guacd - Guacamole proxy daemon

## SYNOPSIS
guacd [-b HOST] [-l PORT] [-p PID FILE] [-L LOG LEVEL] [-C CERTIFICATE FILE] [-K KEY FILE] [-f] [-v]

## DESCRIPTION
guacd is the Guacamole proxy daemon used by the Guacamole web application and framework. As JavaScript cannot handle binary protocols (like VNC and remote desktop) efficiently, a new text-based protocol was developed which would contain a common superset of the operations needed for efficient remote desktop access, but would be easy for JavaScript programs to process. guacd is the proxy which translates between arbitrary protocols and the Guacamole protocol.

## OPTIONS
-b HOST

Changes the host or address that guacd listens on.

-l PORT

Changes the port that guacd listens on (the default is port 4822).

-p FILE

Causes guacd to write the PID of the daemon process to the specified file. This is useful for init scripts and is used by the provided init script.

-L LEVEL

Sets the maximum level at which guacd will log messages to syslog and, if running in the foreground, the console. Legal values are trace, debug, info, warning, and error. The default value is info.

-f

Causes guacd to run in the foreground, rather than automatically forking into the background.

-v

Causes guacd to simply print its version information and exit.

## SSL/TLS OPTIONS
If libssl was present at the time guacd was compiled, it will contain SSL/TLS support, and connections between the web application and guacd can be encrypted if a certificate file is given.

When using a chain of certificates, you must append the additional certificates to your server certificate. This can be done easily with the standard cat command. Beware that the certificate for guacd must be the first certificate in the file.

-C CERTIFICATE FILE

Enables SSL/TLS using the given certificate file. Future connections to this instance of guacd will require SSL/TLS enabled in the client (the web application). If this option is not given, communication with guacd must be unencrypted.

-K KEY FILE

Enables SSL/TLS using the given private key file. Future connections to this instance of guacd will require SSL/TLS enabled in the client (the web application). If this option is not given, communication with guacd must be unencrypted.

## SEE ALSO
guacd.conf(5)


guestfsd

package: guestfsd

title: guestfsd(8)

summary: guestfs daemon

text:
# guestfsd(8)

## NAME
guestfsd - guestfs daemon

## SYNOPSIS

```
 guestfsd [-r] [-v|--verbose]
```

## DESCRIPTION
"guestfsd" is the libguestfs daemon. Normal users never need to run this program explicitly. This man page discusses what "guestfsd" does in both the libguestfs appliance and when using libguestfs live.

### LIBGUESTFS APPLIANCE
For the architecture of the libguestfs appliance, see "ARCHITECTURE" in guestfs(3).

After the appliance boots, the /init script in the appliance starts "guestfsd" with no arguments. "guestfsd" opens the virtio-serial port on a known path (see "FILES"). It initiates the protocol (see "COMMUNICATION PROTOCOL" in guestfs(3)) and processes requests one at a time from the library until the appliance is destroyed.

Filesystems are mounted under /sysroot and all filesystem operations happen relative to this directory.

### LIBGUESTFS LIVE
In the libguestfs live case, "guestfsd -r" is started from the rc-scripts, systemd, etc.

The "-r" option causes the daemon to operate on the root filesystem instead of /sysroot.

Currently (because of limitations in virtio-serial) only one client can connect at a time, and "guestfsd" must be restarted after each client disconnects. If libguestfs live were changed to use a different transport such as TCP/IP then this limitation could be removed.

## OPTIONS
-?

--help

Display brief help.

-c CHANNEL

--channel CHANNEL

--channel fd:N

Pass the name of the virtio-serial channel, serial port, etc. over which guestfsd will communicate with the library. If this parameter is not given, then an internal default port is used. The "fd:N" form causes guestfsd to use the file descriptor "N" directly.

-l

--listen

Instead of opening the "guestfs_channel" and thus expecting that it already exists, create the channel as a Unix domain socket, listen on it, and accept a single connection. This is mainly used for testing the daemon.

-n

--network

Enable network features in the daemon.

-r

Set the root filesystem to be / (instead of the default which is /sysroot). Also do not unmount filesystems when the daemon exits. This option is used to enable libguestfs live.

-v

--verbose

Enable verbose messages for debugging. The verbose flag is also set if the Linux command line contains the substring "guestfs_verbose=1".

## EXIT STATUS
This program returns 0 if successful, or non-zero if there was an error.

## FILES
/dev/virtio-ports/org.libguestfs.channel.0

The virtio serial port which "guestfsd" connects to.

/proc/cmdline

The Linux command line is parsed to discover "guestfs_*" flags. The following flags are understood:

guestfs_verbose=1

Enable verbose messages. This flag is passed by the libguestfs library to the appliance to make the daemon more verbose (it acts like the -v flag on the command line). Unrelated to the daemon, it also causes the appliance init script to print out a lot more debugging information.

guestfs_channel=PATH

Set the path to the virtio-serial channel to something other than the default (which is /dev/virtio-ports/org.libguestfs.channel.0). This is used by the User-Mode Linux backend to use a regular emulated serial port instead of virtio-serial.

guestfs_network=1

This is set if the appliance network is enabled (see "guestfs_set_network").

## SEE ALSO
guestfs(3), http://libguestfs.org/.

## AUTHOR
Richard W.M. Jones http://people.redhat.com/~rjones/

## COPYRIGHT
Copyright (C) 2009-2025 Red Hat Inc.

## LICENSE
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

## BUGS
To get a list of bugs against libguestfs, use this link: https://bugzilla.redhat.com/buglist.cgi?component=libguestfs&product=Virtualization+Tools

To report a new bug against libguestfs, use this link: https://bugzilla.redhat.com/enter_bug.cgi?component=libguestfs&product=Virtualization+Tools

When reporting a bug, please supply:

- The version of libguestfs.

- Where you got libguestfs (eg. which Linux distro, compiled from source, etc)

- Describe the bug accurately and give a way to reproduce it.

- Run libguestfs-test-tool(1) and paste the complete, unedited output into the bug report.


cups-calibrate

package: gutenprint-cups

title: cups-calibrate(8)

summary: ESP CUPS Printer Calibration Tool

text:
# cups-calibrate(8)

## NAME
cups-calibrate - ESP CUPS Printer Calibration Tool

## SYNOPSIS
cups-calibrate

## DESCRIPTION
This program allows you to calibrate the color output of printers using the Gutenprint CUPS driver. Please note that this program only works with the Gutenprint CUPS driver.

These drivers are identified by the text CUPS+Gutenprint in the model description displayed by the CUPS web interface.

To make a calibration profile for all users, run this program as the root user. The program displays a series of prompts which should simply be followed.

## SEE ALSO
CUPS Software Administrators Manual, http://localhost:631/documentation.html

## COPYRIGHT
Copyright © 2001 Michael Sweet (mike@easysw.com)

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License, version 2, as published by the Free Software Foundation.

This manual page was written by Roger Leigh (rleigh@debian.org).


cups-genppd

title: cups-genppd(8)

text:
# cups-genppd(8)

## NAME
cups-genppd - generate Gutenprint PPD files for use with CUPS

## SYNOPSIS
cups-genppd [-c localedir] [-l locale] [-p prefix] [-q] [-v] model1 [model2, ...modeln]

cups-genppd -L [-c localedir]

cups-genppd -M [-v]

cups-genppd -h

cups-genppd -V

## DESCRIPTION
cups-genppd generates Gutenprint PPD files for use with CUPS. The default behavior is to output PPD files for all models of printer that the Gutenprint printer driver library supports. You may restrict the models by listing either the driver names or the full names of the printers you wish to generate PPD files for after any options. Additionally, the PPD files may be localised, that is, translated, to use your native language rather than US English. There are commands to find out what printer models and languages are supported.

## EXAMPLES
cups-genppd -v bjc-6200 'Epson Stylus Photo 1280' 'HP DeskJet 850C'

verbosely generate three PPD files, listing the driver name in the first case, and the full name in the second.

LANG=de_DE genppd -p ppd -c /usr/share/locale

generate PPDs for all available models, in directory ppd using the locale data found under /usr/share/locale. The language to use is taken from the environment (de_DE).

cups-genppd -L -c /usr/local/share/locale

list available languages using the locale data found under /usr/local/share/locale.

cups-genppd -M -v

list available drivers, with long model descriptions

## COMMANDS
-h

show a help message

-L

list available translations (message catalogs). If a locale is used for which there is not a corresponding translation, then then US English will be used.

-M

list available printer models. By default, only driver names are listed; if verbose mode is used, the full model name will also be printed

-V

show version information and defaults

The default behavior is to output PPDs if no command is given.

## OPTIONS
-c localedir

use localedir as the base directory for locale data

-l locale

output PPDs translated with messages for locale. Note that locale must be a locale as shown by locale -a. For example, the de translation is used by the de_DE locale; de alone will not work.

-p prefix

output PPDs in directory prefix. Directories are not recursively created.

-q

Quiet mode.

-v

Verbose mode.

models

a list of printer models, either the driver or quoted full name.

## SEE ALSO
CUPS Software Administrators Manual, http://localhost:631/documentation.html

## COPYRIGHT
Copyright © 1992-2002 Michael Sweet (mike@easysw.com)

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License, version 2, as published by the Free Software Foundation.

This manual page was written by Roger Leigh (rleigh@debian.org).


cups-genppdupdate

title: cups-genppdupdate(8)

summary: update CUPS+Gutenprint PPD files

text:
# cups-genppdupdate(8)

## NAME
cups-genppdupdate - update CUPS+Gutenprint PPD files

## SYNOPSIS
cups-genppdupdate [-h] [-n] [-N] [-q | -v] [-s ppd-directory] [-s output-directory] [PPD-FILES or QUEUES...]

## DESCRIPTION
cups-genppdupdate regenerates the Gutenprint PPD files in use by CUPS, using the PPD files under /usr/share/cups/model/gutenprint as templates. The new PPD file replaces the old PPD file under /etc/cups/ppd, but all the options set in the old PPD will be merged into the new PPD, provided that they are still valid in the new file.

If no files or queue names are specified, cups-genppdupdate updates all Gutenprint PPD files in /etc/cups/ppd. Otherwise, cups-genppdupdate updates all files or queues listed on the command line.

cups-genppdupdate does not update PPD files from Gimp-Print 4.2 or earlier.

cups-genppdupdate does not restart cupsd. cupsd will need manually reloading (or send SIGHUP) once cups-genppdupdate has completed.

## OPTIONS
-h

Show a help message.

-n

No action. The program will run, but the old PPD files will not be replaced.

-q

Quiet mode. No messages will be issued, apart from errors.

-v

Verbose mode. More informative messages will be issued. Note that extremely verbose output may be turned on by setting $debug=1 in the source, but this output will not be of use to the average user.

-s ppd-directory

Use ppd-directory as the base directory to read PPD files from. By default, the base directory is /usr/share/cups/model/gutenprint. Under this directory, the PPD files are located in subdirectories according to language code and territory.

-o output-directory

Place updated PPD files in output-directory. By default, this is the same as the input directory.

-N

Reset all options to their defaults (do not merge options from the current PPD file)

## SEE ALSO
cups-genppd(8), cups-genppdconfig(8), CUPS Software Administrators Manual, http://localhost:631/documentation.html

## COPYRIGHT
Copyright © 2002-2006 Roger Leigh (rleigh@debian.org) and Robert Krawitz (rlk@alum.mit.edu)

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License, version 2, as published by the Free Software Foundation.

This manual page was written by Roger Leigh (rleigh@debian.org).