iwpriv

title: iwpriv(8)

text:
# iwpriv(8)

## NAME
iwpriv - configure optionals (private) parameters of a wireless network interface

## SYNOPSIS
iwpriv [interface]

iwpriv interface private-command [private-parameters]

iwpriv interface private-command [I] [private-parameters]

iwpriv interface --all

## DESCRIPTION
Iwpriv is the companion tool to iwconfig(8). Iwpriv deals with parameters and setting specific to each driver (as opposed to iwconfig which deals with generic ones).

Without any argument, iwpriv list the available private commands available on each interface, and the parameters that they require. Using this information, the user may apply those interface specific commands on the specified interface.

In theory, the documentation of each device driver should indicate how to use those interface specific commands and their effect.

## PARAMETERS
private-command [private-parameters]

Execute the specified private-command on the interface.

The command may optionally take or require arguments, and may display information. Therefore, the command line parameters may or may not be needed and should match the command expectations. The list of commands that iwpriv displays (when called without argument) should give you some hints about those parameters.

However you should refer to the device driver documentation for information on how to properly use the command and the effect.

private-command [I] [private-parameters]

Idem, except that I (an integer) is passed to the command as a Token Index. Only some command will use the Token Index (most will ignore it), and the driver documentation should tell you when it's needed.

-a/--all

Execute and display all the private commands that don't take any arguments (i.e. read only).

## DISPLAY
For each device which support private commands, iwpriv will display the list of private commands available.

This include the name of the private command, the number or arguments that may be set and their type, and the number or arguments that may be display and their type.

For example, you may have the following display :

eth0 Available private ioctl :

setqualthr (89F0) : set 1 byte & get 0

gethisto (89F7) : set 0 & get 16 int

This indicate that you may set the quality threshold and display an histogram of up to 16 values with the following commands :

iwpriv eth0 setqualthr 20

iwpriv eth0 gethisto

## AUTHOR
Jean Tourrilhes - jt@hpl.hp.com

## FILES
/proc/net/wireless

## SEE ALSO
iwconfig(8), iwlist(8), iwevent(8), iwspy(8), wireless(7).


iwspy

package: wireless-tools

title: iwspy(8)

text:
# iwspy(8)

## NAME
iwspy - Get wireless statistics from specific nodes

## SYNOPSIS
iwspy [interface]

iwspy interface [+] DNSNAME | IPADDR | HWADDR [...]

iwspy interface off

iwspy interface setthr low high

iwspy interface getthr

## DESCRIPTION
Iwspy is used to set a list of addresses to monitor in a wireless network interface and to read back quality of link information for each of those. This information is the same as the one available in /proc/net/wireless : quality of the link, signal strength and noise level.

This information is updated each time a new packet is received, so each address of the list adds some overhead in the driver.

Note that this functionality works only for nodes part of the current wireless cell, you can not monitor Access Points you are not associated with (you can use Scanning for that) and nodes in other cells. In Managed mode, in most case packets are relayed by the Access Point, in this case you will get the signal strength of the Access Point. For those reasons this functionality is mostly useful in Ad-Hoc and Master mode.

## PARAMETERS
You may set any number of addresses up to 8.

DNSNAME | IPADDR

Set an IP address, or in some cases a DNS name (using the name resolver). As the hardware works with hardware addresses, iwspy will translate this IP address through ARP. In some case, this address might not be in the ARP cache and iwspy will fail. In those case, ping(8) this name/address and retry.

HWADDR

Set a hardware (MAC) address (this address is not translated & checked like the IP one). The address must contain a colon (:) to be recognised as a hardware address.

+

Add the new set of addresses at the end of the current list instead of replacing it. The address list is unique for each device, so each user should use this option to avoid conflicts.

off

Remove the current list of addresses and disable the spy functionality

setthr

Set the low and high signal strength threshold for the iwspy event (for drivers that support it).

Every time the signal strength for any of the address monitored with iwspy goes lower than the low threshold or goes higher than the high threshold, a Wireless Event will be generated.

This can be used to monitor link outages without having to run iwspy periodically.

getthr

Retrieve the current low and high signal strength threshold for the iwspy event.

## FILES
/proc/net/wireless

## SEE ALSO
iwconfig(8), iwlist(8), iwevent(8), iwpriv(8), wireless(7).


title: wpa_background(8)

text:
# wpa_background(8)

## NAME
wpa_background - Background information on Wi-Fi Protected Access and IEEE 802.11i

## WPA
The original security mechanism of IEEE 802.11 standard was not designed to be strong and has proven to be insufficient for most networks that require some kind of security. Task group I (Security) of IEEE 802.11 working group (http://www.ieee802.org/11/) has worked to address the flaws of the base standard and has in practice completed its work in May 2004. The IEEE 802.11i amendment to the IEEE 802.11 standard was approved in June 2004 and published in July 2004.

Wi-Fi Alliance (http://www.wi-fi.org/) used a draft version of the IEEE 802.11i work (draft 3.0) to define a subset of the security enhancements that can be implemented with existing wlan hardware. This is called Wi-Fi Protected Access<TM> (WPA). This has now become a mandatory component of interoperability testing and certification done by Wi-Fi Alliance. Wi-Fi provides information about WPA at its web site (http://www.wi-fi.org/OpenSection/protected_access.asp).

IEEE 802.11 standard defined wired equivalent privacy (WEP) algorithm for protecting wireless networks. WEP uses RC4 with 40-bit keys, 24-bit initialization vector (IV), and CRC32 to protect against packet forgery. All these choices have proven to be insufficient: key space is too small against current attacks, RC4 key scheduling is insufficient (beginning of the pseudorandom stream should be skipped), IV space is too small and IV reuse makes attacks easier, there is no replay protection, and non-keyed authentication does not protect against bit flipping packet data.

WPA is an intermediate solution for the security issues. It uses Temporal Key Integrity Protocol (TKIP) to replace WEP. TKIP is a compromise on strong security and possibility to use existing hardware. It still uses RC4 for the encryption like WEP, but with per-packet RC4 keys. In addition, it implements replay protection, keyed packet authentication mechanism (Michael MIC).

Keys can be managed using two different mechanisms. WPA can either use an external authentication server (e.g., RADIUS) and EAP just like IEEE 802.1X is using or pre-shared keys without need for additional servers. Wi-Fi calls these "WPA-Enterprise" and "WPA-Personal", respectively. Both mechanisms will generate a master session key for the Authenticator (AP) and Supplicant (client station).

WPA implements a new key handshake (4-Way Handshake and Group Key Handshake) for generating and exchanging data encryption keys between the Authenticator and Supplicant. This handshake is also used to verify that both Authenticator and Supplicant know the master session key. These handshakes are identical regardless of the selected key management mechanism (only the method for generating master session key changes).

## IEEE 802.11I / WPA2
The design for parts of IEEE 802.11i that were not included in WPA has finished (May 2004) and this amendment to IEEE 802.11 was approved in June 2004. Wi-Fi Alliance is using the final IEEE 802.11i as a new version of WPA called WPA2. This includes, e.g., support for more robust encryption algorithm (CCMP: AES in Counter mode with CBC-MAC) to replace TKIP and optimizations for handoff (reduced number of messages in initial key handshake, pre-authentication, and PMKSA caching).

## SEE ALSO
wpa_supplicant(8)

## LEGAL
wpa_supplicant is copyright (c) 2003-2022, Jouni Malinen <j@w1.fi> and contributors. All Rights Reserved.

This program is licensed under the BSD license (the one with advertisement clause removed).


title: wpa_cli(8)

summary: WPA command line client

text:
# wpa_cli(8)

## NAME
wpa_cli - WPA command line client

## SYNOPSIS
wpa_cli [ -p path to ctrl sockets ] [ -g path to global ctrl_interface socket ] [ -i ifname ] [ -hvB ] [ -a action file ] [ -P pid file ] [ -G ping interval ] [ command ... ]

## OVERVIEW
wpa_cli is a text-based frontend program for interacting with wpa_supplicant. It is used to query current status, change configuration, trigger events, and request interactive user input.

wpa_cli can show the current authentication status, selected security mode, dot11 and dot1x MIBs, etc. In addition, it can configure some variables like EAPOL state machine parameters and trigger events like reassociation and IEEE 802.1X logoff/logon. wpa_cli provides a user interface to request authentication information, like username and password, if these are not included in the configuration. This can be used to implement, e.g., one-time-passwords or generic token card authentication where the authentication is based on a challenge-response that uses an external device for generating the response.

The control interface of wpa_supplicant can be configured to allow non-root user access (ctrl_interface GROUP= parameter in the configuration file). This makes it possible to run wpa_cli with a normal user account.

wpa_cli supports two modes: interactive and command line. Both modes share the same command set and the main difference is in interactive mode providing access to unsolicited messages (event messages, username/password requests).

Interactive mode is started when wpa_cli is executed without including the command as a command line parameter. Commands are then entered on the wpa_cli prompt. In command line mode, the same commands are entered as command line arguments for wpa_cli.

## INTERACTIVE AUTHENTICATION PARAMETERS REQUEST
When wpa_supplicant need authentication parameters, like username and password, which are not present in the configuration file, it sends a request message to all attached frontend programs, e.g., wpa_cli in interactive mode. wpa_cli shows these requests with "CTRL-REQ-<type>-<id>:<text>" prefix. <type> is IDENTITY, PASSWORD, or OTP (one-time-password). <id> is a unique identifier for the current network. <text> is description of the request. In case of OTP request, it includes the challenge from the authentication server.

The reply to these requests can be given with identity, password, and otp commands. <id> needs to be copied from the matching request. password and otp commands can be used regardless of whether the request was for PASSWORD or OTP. The main difference between these two commands is that values given with password are remembered as long as wpa_supplicant is running whereas values given with otp are used only once and then forgotten, i.e., wpa_supplicant will ask frontend for a new value for every use. This can be used to implement one-time-password lists and generic token card -based authentication.

Example request for password and a matching reply:

```
CTRL-REQ-PASSWORD-1:Password needed for SSID foobar
> password 1 mysecretpassword
```

Example request for generic token card challenge-response:

```
CTRL-REQ-OTP-2:Challenge 1235663 needed for SSID foobar
> otp 2 9876
```

## COMMAND ARGUMENTS
-p path

Change the path where control sockets should be found.

-g control socket path

Connect to the global control socket at the indicated path rather than an interface-specific control socket.

-i ifname

Specify the interface that is being configured. By default, choose the first interface found with a control socket in the socket path.

-h

Help. Show a usage message.

-v

Show version information.

-B

Run as a daemon in the background.

-a file

Run in daemon mode executing the action file based on events from wpa_supplicant. The specified file will be executed with the first argument set to interface name and second to "CONNECTED" or "DISCONNECTED" depending on the event. This can be used to execute networking tools required to configure the interface. Additionally, three environmental variables are available to the file: WPA_CTRL_DIR, WPA_ID, and WPA_ID_STR. WPA_CTRL_DIR contains the absolute path to the ctrl_interface socket. WPA_ID contains the unique network_id identifier assigned to the active network, and WPA_ID_STR contains the content of the id_str option.

-P file

Set the location of the PID file.

-G ping interval

Set the interval (in seconds) at which wpa_cli pings the supplicant.

command

Run a command. The available commands are listed in the next section.

## COMMANDS
The following commands are available:

status

get current WPA/EAPOL/EAP status

mib

get MIB variables (dot1x, dot11)

help

show this usage help

interface [ifname]

show interfaces/select interface

level <debug level>

change debug level

license

show full wpa_cli license

logoff

IEEE 802.1X EAPOL state machine logoff

logon

IEEE 802.1X EAPOL state machine logon

set

set variables (shows list of variables when run without arguments)

pmksa

show PMKSA cache

reassociate

force reassociation

reconfigure

force wpa_supplicant to re-read its configuration file

preauthenticate <BSSID>

force preauthentication

identity <network id> <identity>

configure identity for an SSID

password <network id> <password>

configure password for an SSID

pin <network id> <pin>

configure pin for an SSID

otp <network id> <password>

configure one-time-password for an SSID

bssid <network id> <BSSID>

set preferred BSSID for an SSID

list_networks

list configured networks

terminate

terminate wpa_supplicant

quit

exit wpa_cli

## SEE ALSO
wpa_supplicant(8)

## LEGAL
wpa_supplicant is copyright (c) 2003-2022, Jouni Malinen <j@w1.fi> and contributors. All Rights Reserved.

This program is licensed under the BSD license (the one with advertisement clause removed).


title: wpa_passphrase(8)

text:
# wpa_passphrase(8)

## NAME
wpa_passphrase - Generate a WPA PSK from an ASCII passphrase for a SSID

## SYNOPSIS
wpa_passphrase [ ssid ] [ passphrase ]

## OVERVIEW
wpa_passphrase pre-computes PSK entries for network configuration blocks of a wpa_supplicant.conf file. An ASCII passphrase and SSID are used to generate a 256-bit PSK.

## OPTIONS
ssid

The SSID whose passphrase should be derived.

passphrase

The passphrase to use. If not included on the command line, passphrase will be read from standard input.

## SEE ALSO
wpa_supplicant.conf(5) wpa_supplicant(8)

## LEGAL
wpa_supplicant is copyright (c) 2003-2022, Jouni Malinen <j@w1.fi> and contributors. All Rights Reserved.

This program is licensed under the BSD license (the one with advertisement clause removed).


title: wpa_supplicant(8)

text:
# wpa_supplicant(8)

## NAME
wpa_supplicant - Wi-Fi Protected Access client and IEEE 802.1X supplicant

## SYNOPSIS
wpa_supplicant [ -BddfhKLqqsTtuvW ] [ -iifname ] [ -cconfig file ] [ -Ddriver ] [ -PPID_file ] [ -foutput file ] [ -Iadditional config file ]

## OVERVIEW
Wireless networks do not require physical access to the network equipment in the same way that wired networks do. This makes it easier for unauthorized users to passively monitor a network and capture all transmitted frames. In addition, unauthorized use of the network is much easier. In many cases, this can happen even without user's explicit knowledge since the wireless LAN adapter may have been configured to automatically join any available network.

Link-layer encryption can be used to provide a layer of security for wireless networks. The original wireless LAN standard, IEEE 802.11, included a simple encryption mechanism, WEP. However, that proved to be flawed in many areas and networks protected with WEP cannot be considered secure. IEEE 802.1X authentication and frequently changed dynamic WEP keys can be used to improve the network security, but even that has inherited security issues due to the use of WEP for encryption. Wi-Fi Protected Access and the IEEE 802.11i amendment to the wireless LAN standard introduce a much improved mechanism for securing wireless networks. IEEE 802.11i enabled networks that are using CCMP (an encryption mechanism based on the strong cryptographic algorithm AES) can finally be called secure and used for applications which require efficient protection against unauthorized access.

wpa_supplicant is an implementation of the WPA Supplicant component, i.e., the part that runs in the client stations. It implements WPA key negotiation with a WPA Authenticator and EAP authentication with Authentication Server. In addition, it controls the roaming and IEEE 802.11 authentication/association of the wireless LAN driver.

wpa_supplicant is designed to be a "daemon" program that runs in the background and acts as the backend component controlling the wireless connection. wpa_supplicant supports separate frontend programs and an example text-based frontend, wpa_cli, is included with wpa_supplicant.

Before wpa_supplicant can do its work, the network interface must be available. That means that the physical device must be present and enabled, and the driver for the device must be loaded. The daemon will exit immediately if the device is not already available.

After wpa_supplicant has configured the network device, higher level configuration of the device, such as DHCP, may proceed. There are a variety of ways to integrate wpa_supplicant into a machine's networking scripts, a few of which are described in sections below.

The following steps are used when associating with an AP using WPA:

•

wpa_supplicant requests the kernel driver to scan neighboring BSSes (Basic Service Set)

•

wpa_supplicant selects a BSS based on its configuration

•

wpa_supplicant requests the kernel driver to associate with the chosen BSS

•

If WPA-EAP: integrated IEEE 802.1X Supplicant completes EAP authentication with the authentication server (proxied by the Authenticator in the AP)

•

If WPA-EAP: master key is received from the IEEE 802.1X Supplicant

•

If WPA-PSK: wpa_supplicant uses PSK as the master session key

•

wpa_supplicant completes WPA 4-Way Handshake and Group Key Handshake with the Authenticator (AP)

•

wpa_supplicant configures encryption keys for unicast and broadcast

•

normal data packets can be transmitted and received

## SUPPORTED FEATURES
Supported WPA/IEEE 802.11i features:

•

WPA-PSK ("WPA-Personal")

•

WPA with EAP (e.g., with RADIUS authentication server) ("WPA-Enterprise") Following authentication methods are supported with an integrate IEEE 802.1X Supplicant:

•

EAP-TLS

•

EAP-PEAP/MSCHAPv2 (both PEAPv0 and PEAPv1)

•

EAP-PEAP/TLS (both PEAPv0 and PEAPv1)

•

EAP-PEAP/GTC (both PEAPv0 and PEAPv1)

•

EAP-PEAP/OTP (both PEAPv0 and PEAPv1)

•

EAP-PEAP/MD5-Challenge (both PEAPv0 and PEAPv1)

•

EAP-TTLS/EAP-MD5-Challenge

•

EAP-TTLS/EAP-GTC

•

EAP-TTLS/EAP-OTP

•

EAP-TTLS/EAP-MSCHAPv2

•

EAP-TTLS/EAP-TLS

•

EAP-TTLS/MSCHAPv2

•

EAP-TTLS/MSCHAP

•

EAP-TTLS/PAP

•

EAP-TTLS/CHAP

•

EAP-SIM

•

EAP-AKA

•

EAP-PSK

•

EAP-PAX

•

LEAP (note: requires special support from the driver for IEEE 802.11 authentication)

•

(following methods are supported, but since they do not generate keying material, they cannot be used with WPA or IEEE 802.1X WEP keying)

•

EAP-MD5-Challenge

•

EAP-MSCHAPv2

•

EAP-GTC

•

EAP-OTP

•

key management for CCMP, TKIP, WEP104, WEP40

•

RSN/WPA2 (IEEE 802.11i)

•

pre-authentication

•

PMKSA caching

## AVAILABLE DRIVERS
A summary of available driver backends is below. Support for each of the driver backends is chosen at wpa_supplicant compile time. For a list of supported driver backends that may be used with the -D option on your system, refer to the help output of wpa_supplicant (wpa_supplicant -h).

nl80211

Uses the modern Linux nl80211/cfg80211 netlink-based interface (most new drivers).

wext

Uses the legacy Linux wireless extensions ioctl-based interface (older hardware/drivers).

wired

wpa_supplicant wired Ethernet driver

macsec_linux

MACsec Ethernet driver for Linux

roboswitch

wpa_supplicant Broadcom switch driver

none

no driver (RADIUS server/WPS ER only)

bsd

BSD 802.11 support (Atheros, etc.).

ndis

Windows NDIS driver.

## COMMAND LINE OPTIONS
Most command line options have global scope. Some are given per interface, and are only valid if at least one -i option is specified, otherwise they're ignored. Option groups for different interfaces must be separated by -N option.

-b br_ifname

Optional bridge interface name. (Per interface)

-B

Run daemon in the background.

-c filename

Path to configuration file. (Per interface)

-C ctrl_interface

Path to ctrl_interface socket (Per interface. Only used if -c is not).

-i ifname

Interface to listen on. Multiple instances of this option can be present, one per interface, separated by -N option (see below).

-I filename

Path to additional configuration file.

-d

Increase debugging verbosity (-dd even more).

-D driver

Driver to use (can be multiple drivers: nl80211,wext). (Per interface, see the available options below.)

-e entropy file

File for wpa_supplicant to use to maintain its internal entropy store in over restarts.

-f output file

Log output to specified file instead of stdout. (This is only available if wpa_supplicant was built with the CONFIG_DEBUG_FILE option.)

-g global ctrl_interface

Path to global ctrl_interface socket. If specified, interface definitions may be omitted.

-K

Include keys (passwords, etc.) in debug output.

-h

Help. Show a usage message.

-L

Show license (BSD).

-o override driver

Override the driver parameter for new interfaces.

-O override ctrl_interface

Override the ctrl_interface parameter for new interfaces.

-p

Driver parameters. (Per interface)

-P PID_file

Path to PID file.

-q

Decrease debugging verbosity (-qq even less).

-s

Log output to syslog instead of stdout. (This is only available if wpa_supplicant was built with the CONFIG_DEBUG_SYSLOG option.)

-T

Log output to Linux tracing in addition to any other destinations. (This is only available if wpa_supplicant was built with the CONFIG_DEBUG_LINUX_TRACING option.)

-t

Include timestamp in debug messages.

-u

Enable DBus control interface. If enabled, interface definitions may be omitted. (This is only available if wpa_supplicant was built with the CONFIG_CTRL_IFACE_DBUS_NEW option.)

-v

Show version.

-W

Wait for a control interface monitor before starting.

-N

Start describing new interface.

## EXAMPLES
In most common cases, wpa_supplicant is started with:

```
wpa_supplicant -B -c/etc/wpa_supplicant.conf -iwlan0
```

This makes the process fork into the background.

The easiest way to debug problems, and to get a debug log for bug reports, is to start wpa_supplicant in the foreground with debugging enabled:

```
wpa_supplicant -c/etc/wpa_supplicant.conf -iwlan0 -d
```

If the specific driver wrapper is not known beforehand, it is possible to specify multiple comma separated driver wrappers on the command line. wpa_supplicant will use the first driver wrapper that is able to initialize the interface.

```
wpa_supplicant -Dnl80211,wext -c/etc/wpa_supplicant.conf -iwlan0
```

wpa_supplicant can control multiple interfaces (radios) either by running one process for each interface separately or by running just one process and list of options at command line. Each interface is separated with -N argument. As an example, following command would start wpa_supplicant for two interfaces:

```
wpa_supplicant \
	-c wpa1.conf -i wlan0 -D nl80211 -N \
	-c wpa2.conf -i ath0 -D wext
```

## OS REQUIREMENTS
Current hardware/software requirements:

•

Linux kernel 2.6.30 or higher with nl80211/cfg80211 support

•

Linux kernel 2.4.x or higher with Linux Wireless Extensions v15 or newer

•

FreeBSD 6-CURRENT

•

Microsoft Windows with WinPcap (at least WinXP, may work with other versions)

## SUPPORTED DRIVERS
Linux nl80211/cfg80211

This is the preferred driver for Linux.

Linux wireless extensions

In theory, any driver that supports Linux wireless extensions can be used with IEEE 802.1X (i.e., not WPA) when using ap_scan=0 option in configuration file.

Wired Ethernet drivers

Use ap_scan=0.

BSD net80211 layer (e.g., Atheros driver)

At the moment, this is for FreeBSD 6-CURRENT branch.

Windows NDIS

The current Windows port requires WinPcap (http://winpcap.polito.it/). See README-Windows.txt for more information.

wpa_supplicant was designed to be portable for different drivers and operating systems. Hopefully, support for more wlan cards and OSes will be added in the future. See developer.txt for more information about the design of wpa_supplicant and porting to other drivers. One main goal is to add full WPA/WPA2 support to Linux wireless extensions to allow new drivers to be supported without having to implement new driver-specific interface code in wpa_supplicant.

## ARCHITECTURE
The wpa_supplicant system consists of the following components:

wpa_supplicant.conf

the configuration file describing all networks that the user wants the computer to connect to.

wpa_supplicant

the program that directly interacts with the network interface.

wpa_cli

the client program that provides a high-level interface to the functionality of the daemon.

wpa_passphrase

a utility needed to construct wpa_supplicant.conf files that include encrypted passwords.

## QUICK START
First, make a configuration file, e.g. /etc/wpa_supplicant.conf, that describes the networks you are interested in. See wpa_supplicant.conf(5) for details.

Once the configuration is ready, you can test whether the configuration works by running wpa_supplicant with following command to start it on foreground with debugging enabled:

```
wpa_supplicant -iwlan0 -c/etc/wpa_supplicant.conf -d

```

Assuming everything goes fine, you can start using following command to start wpa_supplicant on background without debugging:

```
wpa_supplicant -iwlan0 -c/etc/wpa_supplicant.conf -B

```

Please note that if you included more than one driver interface in the build time configuration (.config), you may need to specify which interface to use by including -D<driver name> option on the command line.

## INTERFACE TO PCMCIA-CS/CARDMRG
For example, the following small changes to pcmcia-cs scripts can be used to enable WPA support:

Add MODE="Managed" and WPA="y" to the network scheme in /etc/pcmcia/wireless.opts.

Add the following block to the end of start action handler in /etc/pcmcia/wireless:

```
if [ "$WPA" = "y" -a -x /usr/local/bin/wpa_supplicant ]; then

    /usr/local/bin/wpa_supplicant -B -c/etc/wpa_supplicant.conf -i$DEVICE
fi

```

Add the following block to the end of stop action handler (may need to be separated from other actions) in /etc/pcmcia/wireless:

```
if [ "$WPA" = "y" -a -x /usr/local/bin/wpa_supplicant ]; then

    killall wpa_supplicant
fi

```

This will make cardmgr start wpa_supplicant when the card is plugged in.

## SEE ALSO
wpa_background(8) wpa_supplicant.conf(5) wpa_cli(8) wpa_passphrase(8)

## LEGAL
wpa_supplicant is copyright (c) 2003-2022, Jouni Malinen <j@w1.fi> and contributors. All Rights Reserved.

This program is licensed under the BSD license (the one with advertisement clause removed).


wsdd

package: wsdd

title: wsdd(8)

text:
# wsdd(8)

## NAME
wsdd - A Web Service Discovery host and client daemon.

## SYNOPSIS
wsdd [options]

## DESCRIPTION
wsdd implements both a Web Service Discovery (WSD) host and a WSD client daemon. The host implementation enables (Samba) hosts, like your local NAS device, to be found by Web Service Discovery clients like Windows. The client mode allows searching for other WSD hosts on the local network.

The default mode of operation is the host mode. The client or discovery mode must be enabled explictely. Unless configured otherwise, the host mode is always active. Both modes can be used at the same time.

## OPTIONS

### General options
-4, --ipv4only

See below.

-6, --ipv6only

Restrict to the given address family. If both options are specified no addreses will be available and wsdd will exit.

-A, --no-autostart

Do not start networking activities automatically when the program is started. The API interface (see below) can be used to start and stop the networking activities while the application is running.

-c DIRECTORY, --chroot DIRECTORY

chroot into the given DIRECTORY after initialization has been performed and right before the handling of incoming messages starts. The new root directory can be empty. Consider using the -u option as well.

-h, --help

Show help and exit.

-H HOPLIMIT, --hoplimit HOPLIMIT

Set the hop limit for multicast packets. The default is 1 which should prevent packets from leaving the local network segment.

-i INTERFACE/ADDRESS, --interface INTERFACE/ADDRESS

Specify on which interfaces wsdd will be listening on. If no interfaces are specified, all interfaces are used. Loop-back interfaces are never used, even when explicitly specified. For interfaces with IPv6 addresses, only link-local addresses will be used for announcing the host on the network. This option can be provided multiple times in order to restrict traffic to more than one interface. This option also accepts IP addresses that the service should bind to. For IPv6, only link local addresses are actually considered as noted above.

--metadata-timeout TIMEOUT

Set the timeout for HTTP-based metadata exchange. Default is 2.0 seconds.

-s, --shortlog

Use a shorter logging format that only includes the level and message. This is useful in cases where the logging mechanism, like systemd on Linux, automatically prepends a date and process name plus ID to the log message.

-u USER[:GROUP], --user USER[:GROUP]

Change user (and group) when running before handling network packets. Together with -c this option can be used to increase security if the execution environment, like the init system, cannot ensure this in another way.

-U UUID, --uuid UUID

The WSD specification requires a device to have a unique address that is stable across reboots or changes in networks. In the context of the standard, it is assumed that this is something like a serial number. Wsdd attempts to read the machine ID from /etc/machine-id and /etc/hostid (in that order) before potentially chrooting in another environment. If reading the machine ID fails, wsdd falls back to a version 5 UUID with the DNS namespace and the host name of the local machine as inputs. Thus, the host name should be stable and not be modified, e.g. by DHCP. However, if you want wsdd to use a specific UUID you can use this option.

-v, --verbose

Additively increase verbosity of the log output. A single occurrence of -v/--verbose sets the log level to INFO. More -v options set the log level to DEBUG.

-V, --version

Show the version number and exit.

### Host Mode Options
-d DOMAIN, --domain DOMAIN

Assume that the host running wsdd joined an ADS domain. This will make wsdd report the host being a domain member. It disables workgroup membership reporting. The (provided) hostname is automatically converted to lower case. Use the `-p` option to change this behavior.

-n HOSTNAME, --hostname HOSTNAME

Override the host name wsdd uses during discovery. By default the machine's host name is used (look at hostname(1)). Only the host name part of a possible FQDN will be used in the default case.

-o, --no-host

Disable host operation mode. If this option is provided, the host cannot be discovered by other (Windows) hosts. It can be useful when client/discovery mode is used and no announcement of the host that runs wsdd should be made.

-p, --preserve-case

Preserve the hostname as it is. Without this option, the hostname is converted as follows. For workgroup environments (see -w) the hostname is made upper case by default. Vice versa it is made lower case for usage in domains (see -d).

-t, --no-http

Do not service HTTP requests of the WSD protocol. This option is intended for debugging purposes where another process may handle the Get messages.

-w WORKGROUP, --workgroup WORKGROUP

By default wsdd reports the host is a member of a workgroup rather than a domain (use the -d/--domain option to override this). With -w/--workgroup the default workgroup name can be changed. The default work group name is WORKGROUP. The (provided) hostname is automatically converted to upper case. Use the `-p` option to change this behavior.

### Client/Discovery Mode Options
-D, --discovery

Enable discovery mode to search for other WSD hosts/servers. Found hosts are logged with INFO priority. The server interface (see below) can be used for a programatic interface. Refer to the man page for details of the server interface.

-l PATH/PORT, --listen PATH/PORT

Specify the location of the socket for the server programming interface. If the option value is numeric, it is interpreted as numeric port for a TCP server port. Then, the server socket is bound to the localhost only. If the option value is non-numeric, it is assumed to be a path to UNIX domain socket to which a client can connect to.

## EXAMPLE USAGE

### Handle traffic on eth0 and eth2 only, but only with IPv6 addresses

wsdd -i eth0 -i eth2 -6

or

wsdd --interface eth0 --interface eth2 --ipv6only

### Set the Workgroup according to smb.conf, be verbose, run with dropped privileges, and change the root directory to an (empty) directory

SMB_GROUP=$(grep -i '^workgroup=' smb.conf | cut -f2 -d= | tr -d '[:blank:]')

wsdd -v -w $SMB_GROUP -u daemon:daemon -c /var/run/wsdd/chroot

## FIREWALL SETUP
Traffic for the following ports, directions and addresses must be allowed:

- Incoming and outgoing traffic to udp/3702 with multicast destination: 239.255.255.250 for IPv4 and ff02::c for IPv6

- Outgoing unicast traffic from udp/3702

- Incoming traffic to tcp/5357

You should further restrict the traffic to the (link-)local subnet, e.g. by using the `fe80::/10` address space for IPv6. Please note that IGMP traffic must be enabled in order to get IPv4 multicast traffic working.

## API INTERFACE
Wsdd provides a text-based, line-oriented API interface to query information and trigger actions. The interface can be used with TCP and UNIX domain sockets (see -l/--listen option). The TCP socket is bound to the local host only. The following commands can be issued:

### clear - Clear list of discovered devices
Clears the list of all discovered devices. Use the probe command to search for devices again. This command does not return any data and is only available in discover mode.

### list [TYPE] - List discovered devices
Returns a tab-separated list of discovered devices of the provided TYPE (e.g. "pub:Computer") with the following information. If no type is provided, all discovered devices are listed. The possibly empty list of detected hosts is always terminated with a single dot ('.') in an otherwise empty line. This command is only available in discover mode.

UUID

UUID of the discovered device. Note that a multi-homed device should appear only once but with multiple addresses (see below)

name

The name reported by the device. For discovered Windows hosts, it is the configured computer name that is reported here.

association

Specifies the domain or workgroup to which the discovered host belongs to. The type of the association (workgroup or domain) is separated from its value by a colon.

last_seen

The date and time the device was last seen as a consequence of Probe/Hello messages provided in ISO8601 with seconds.

addresses

List of all transport addresses that were collected during the discovery process delimited by commas. Addresses are provided along with the interface (separated by '%') on which they were discovered. IPv6 addresses are reported on square brackets. Note that the reported addresses may not match the actual device on which the device may be reached.

types

Types of the detected device, delimited by commas.

### probe [INTERFACE] - Search for devices
Triggers a Probe message on the provided INTERFACE (eth0, e.g.) to search for WSD hosts. If no interface is provided, all interfaces wsdd listens on are probed. A Probe messages initiates the discovery message flow. It may take some time for hosts to be actually discovered. This command does not return any data and is only available in discovery mode.

### start - Start networking activities
This command starts the networking acitivies of wsdd if they haven't been started yet. "Hello" messages are emitted and the host is announced on the network(s) when the host mode is active. If the discovery mode is enabled a probe process is also started.

### stop - Stop networking activities
This is the reverse operation to start. When this command is received, "Bye" messages are sent in order to notify hosts in the network about the host's disappearance. All networking sockets used for the WSD protocol are closed as well. Activities can be restarted with the start operation.

## SECURITY
wsdd does not implement any security feature, e.g. by using TLS for the http service. This is because wsdd's intended usage is within private, i.e. home, LANs. The Hello message contains the hosts transport address, i.e. the IP address which speeds up discovery (avoids Resolve message).

## KNOWN ISSUES

### Using only IPv6 on FreeBSD
If wsdd is running on FreeBSD using IPv6 only, the host running wsdd may not be reliably discovered. The reason appears to be that Windows is not always able to connect to the HTTP service for unknown reasons. As a workaround, run wsdd with IPv4 only.

### Tunnel/Bridge Interface
If tunnel/bridge interfaces like those created by OpenVPN or Docker exist, they may interfere with wsdd if executed without providing an interface that it should bind to (so it binds to all). In such cases, the wsdd hosts appears after wsdd has been started but it disappears when an update of the Network view in Windows Explorer is forced, either by refreshing the view or by a reboot of the Windows machine. To solve this issue, the interface that is connected to the network on which the host should be announced needs to be specified with the -i/--interface option. This prevents the usage of the tunnel/bridge interfaces.

Background: Tunnel/bridge interfaces may cause Resolve requests from Windows hosts to be delivered to wsdd multiple times, i.e. duplicates of such request are created. If wsdd receives such a request first from a tunnel/bridge it uses the transport address (IP address) of that interface and sends the response via unicast. Further duplicates are not processed due to the duplicate message detection which is based on message UUIDs. The Windows host which receives the response appears to detect a mismatch between the transport address in the ResolveMatch message (which is the tunnel/bridge address) and the IP of the sending host/interface (LAN IP, e.g.). Subsequently, the wsdd host is ignored by Windows.


title: x2gobroker-keygen(8)

text:
# x2gobroker-keygen(8)

## NAME
x2gobroker-keygen - Generate SSH keys for X2Go Session Broker

## SYNOPSIS

x2gobroker-keygen

[ options ]

## DESCRIPTION
x2gobroker-keygen generates a SSH pub/priv key pair and makes it usable through X2Go Session Broker.

This command has to be execute once per broker installation and requires root privileges.

## COMMON OPTIONS
x2gobroker-keygen accepts the following common options:

-h, --help

Display a help with all available command line options and exit.

-t {RSA,DSA}, --key_type {RSA,DSA}

SSH pub/priv key type (allowed values: RSA, DSA).

-f, --force

Re-generate SSH pub/priv key pair and enforce overwriting of existing key pair files. WARNING: you will loose previously create key files when this option is used.

## FILES
~x2gobroker/.ssh/*

## AUTHOR
This manual has been written for the X2Go project by Mike Gabriel <mike.gabriel@das-netzwerkteam.de>.


title: x2gobroker-testagent(8)

text:
# x2gobroker-testagent(8)

## NAME
x2gobroker-testagent - Session Broker for X2Go (Agent Test Utility)

## SYNOPSIS

x2gobroker-testagent

[ options ]

## DESCRIPTION
x2gobroker-testagent is a test utility for local/remote X2Go Session Broker Agents. The x2gobroker-testagent has to run as super-user root.

The x2gobroker-testagent tool is normally run on the machine that acts as the X2Go Session Broker.

The x2gobroker-testagent tries to connect to a local or remote X2Go Session Broker Agent. X2Go Broker Agents are co-installed on X2Go Server hosts and support the broker in controlling that X2Go Server.

The x2gobroker-testagent executes a test task on the broker agent. The broker agent tries to switch to the given user's context and runs the given task on behalf of that user.

## COMMON OPTIONS
x2gobroker-testagent provides help on command line options:

-h, --help

Display a help with all available command line options and exit.

## REQUIRED OPTIONS
You can either list the broker agent's tasks that are available for testing:

--list-tasks

Render a list of available broker agent tasks. This list shows what can be tested. The capabilities of the remote agent and the broker server's test code are compared and displayed.

Or run a given task on behalf of an X2Go user on a local or remote broker agent:

-u, --user, --username

Instruct the broker agent to switch to this user's context when running the given task on the local/remote host.

-t TASK, --task TASK

The task that shall be test-executed on the remote broker agent.

## REMOTE BROKER OPTIONS
The default mode for calling the X2Go Session Broker Agent is "LOCAL". Alternatively, remote broker agents can be called via mode "SSH". For this, you additionally need to specify the below options:

-H HOSTNAME, --host HOSTNAME

Hostname to connect to via SSH for running remote broker agent test commands.

-p PORT, --port PORT

The TCP/IP port that the remote system's SSH daemon listens on (default: 22).

## SUPPLIMENTARY OPTIONS
For some tasks, you have to provide additional parameters.

-A, --add-to-known-hosts

When connecting to a remote broker agent via SSH, add the broker agent machine's SSH host key to the list of known hosts (normally /var/lib/x2gobroker/.ssh/known_hosts). This has to be done once per broker agent machine, that the X2Go Session Broker is supposed to connect to.

--session-id SESSION_ID

When testing the 'suspendsession' or the 'terminatesession' task, you have to additionally give a session ID to test those tasks on.

--pubkey PUBKEY_AS_STRING

Use your own provided SSH public key when testing the 'addauthkey' and the 'delauthkey' tasks.

## MISC OPTIONS
x2gobroker-testagent also accepts the following miscellaneous options:

-d, --debug

Enable debugging code.

-C, --config FILENAME

Specify an alternative configuration file name, default is: /etc/x2go/x2gobroker.conf.

## FILES
/etc/x2go/x2gobroker.conf, /etc/x2go/broker/* (configuration files)

/etc/x2go/broker/defaults.conf (environment for X2Go Session Broker)

/var/log/x2gobroker/* (log files of X2Go Session Broker)

## SEE ALSO
/usr/share/doc/x2gobroker

## AUTHOR
This manual has been written for the X2Go project by Mike Gabriel <mike.gabriel@das-netzwerkteam.de>.


title: x2gobroker-pubkeyauthorizer(8)

text:
# x2gobroker-pubkeyauthorizer(8)

## NAME
x2gobroker-pubkeyauthorizer - Retrieve public SSH keys from an X2Go Session Broker

## SYNOPSIS

x2gobroker-pubkeyauthorizer

[ options ]

## DESCRIPTION
x2gobroker-pubkeyauthorizer retrieves the X2Go Session Broker's public SSH key(s) and adds it to ~x2gobroker/.ssh/authorized_keys.

This command has to be executed once on each X2Go Server that is to become a member of a muli-node X2Go server farm. The execution of this command requires root-privileges.

## COMMON OPTIONS
x2gobroker-pubkeyauthorizer accepts the following common options:

-h, --help

Display a help with all available command line options and exit.

-b <BROKER_URL>, --broker-url <BROKER_URL>

The URL of the X2Go Session Broker that we want to retrieve public keys from. The common pattern for this URL is http(s)://<broker_hostname>:<port>/pubkeys/, but may differ depending on your X2Go Session Broker setup.

## FILES
~x2gobroker/.ssh/authorized_keys

## AUTHOR
This manual has been written for the X2Go project by Mike Gabriel <mike.gabriel@das-netzwerkteam.de>.


title: x2gobroker-authservice(8)

text:
# x2gobroker-authservice(8)

## NAME
x2gobroker-authservice - PAM authentication service for X2Go Session Broker

## SYNOPSIS

x2gobroker-authservice

[ options ]

## DESCRIPTION
x2gobroker-authservice is a PAM authentication service for X2Go Session Broker. Whereas the X2Go Session Broker runs as a non-privileged user (standalone daemon mode) or as the also non-privileged httpd server's system user (WSGI mode), an authentication against PAM requires root privileges in most cases (esp. for pam_unix.so).

Thus, the PAM authentication has been moved into a separate service. The communication between X2Go Session Broker and PAM Authentication Service is handled through a unix domain socket file (<RUNDIR>/x2gobroker/x2gobroker-authservice.socket).

This command is normally started through the host's init system.

## COMMON OPTIONS
x2gobroker-authservice accepts the following common options:

-h, --help

Display a help with all available command line options and exit.

-D, --daemonize

Fork this application to background and detach from the running terminal.

-P, --pidfile

Custom PID file location when daemonizing (default: <RUNDIR>/x2gobroker/x2gobroker-authservice.pid).

-L, --logdir

Directory where stdout/stderr will be redirected after having daemonized (default: /var/log/x2gobroker/).

-s <AUTHSOCKET>, --socket <AUTHSOCKET>

File name of the unix domain socket file used for communication between broker and authentication service.

-o <OWNER>, --owner <OWNER>

User ownership of the <AUTHSOCKET> file.

-g <GROUP>, --group <GROUP>

Group ownership of the <AUTHSOCKET> file.

-p <PERMISSIONS>, --permissions <PERMISSIONS>

Set these file permissions for the <AUTHSOCKET> file. Use numerical permissions (e.g. 0640).

## FILES
<RUNDIR>/x2gobroker/x2gobroker-authservice.socket

## AUTHOR
This manual has been written for the X2Go project by Mike Gabriel <mike.gabriel@das-netzwerkteam.de>.


title: x2gobroker-daemon-debug(8)

text:
# x2gobroker-daemon-debug(8)

## NAME
x2gobroker-daemon-debug - Debug X2Go Session Broker's Standalone Daemon

## SYNOPSIS

x2gobroker-daemon-debug

[ options ]

## DESCRIPTION
x2gobroker-daemon-debug is a helper tool for the site admin that launches the standalone http(s) daemon of X2Go Session Broker in debug and interactive mode. Debug mode is activated automatically, all logging is re-directed to STDERR (instead of logging into the broker's log files).

The x2gobroker-daemon-debug scripts accepts all options of x2gobroker except the --mode option (which is enforced by x2gobroker-daemon-debug by default).

x2gobroker-daemon-debug requires root privileges.

## SEE ALSO
x2gobroker(1)

## AUTHOR
This manual has been written for the X2Go project by Mike Gabriel <mike.gabriel@das-netzwerkteam.de>.


title: x2gobroker-loadchecker(8)

text:
# x2gobroker-loadchecker(8)

## NAME
x2gobroker-loadchecker - Load checker service for X2Go Session Broker

## SYNOPSIS

x2gobroker-loadchecker

[ options ]

## DESCRIPTION
x2gobroker-loadchecker is a service that collects system load metrics from broker-associated X2Go Servers.

When load-balancing shall be used, the simplest way to detect "server load" is counting the numbers of running and suspended sessions. No extra daemon nor service is required for this. The server with the least amount of sessions will be selected for starting the next X2Go session.

However, simply counting running and suspended sessions per X2Go Server as a representative for the server load can be highly inaccurate. A better approach is checking each X2Go Server's load in regular intervals by the x2gobroker-loadchecker daemon (running on the broker host) and querying the x2gobroker-loadchecker daemon before selecting the best server on session startup requests.

The x2gobroker-loadchecker collects server metrics of all associated X2Go Servers and keeps the latest load factors in RAM. Once the broker needs load factors of a certain session profile (i.e., of all servers configured in that session profile), the x2gobroker-loadchecker delivers that info immediately. The remembered load factors may not be 100% up-to-date (default: collected within the last five minutes), but the response time of the load checker is much faster than a query to all possible X2Go Servers would be.

The load factor calculation uses this algorithm:

( memAvail[MByte]/1000 ) * numCPUs * typeCPUs[MHz]

load-factor = --------------------------------------------------

loadavg*100 * numSessions

The higher the load-factor, the more likely that a server will be chosen for the next to be allocated X2Go session.

The communication between X2Go Session Broker and the Load Checker Service is handled through a unix domain socket file (<RUNDIR>/x2gobroker/x2gobroker-loadchecker.socket).

This command is normally started through the host's init system.

## COMMON OPTIONS
x2gobroker-loadchecker accepts the following common options:

-h, --help

Display a help with all available command line options and exit.

-D, --daemonize

Fork this application to background and detach from the running terminal.

-P, --pidfile

Custom PID file location when daemonizing (default: <RUNDIR>/x2gobroker/x2gobroker-loadchecker.pid).

-L, --logdir

Directory where stdout/stderr will be redirected after having daemonized (default: /var/log/x2gobroker/).

-s <LOADCHECKERSOCKET>, --socket <LOADCHECKERSOCKET>

File name of the unix domain socket file used for communication between broker and load checker service.

-o <OWNER>, --owner <OWNER>

User ownership of the <LOADCHECKERSOCKET> file.

-g <GROUP>, --group <GROUP>

Group ownership of the <LOADCHECKERSOCKET> file.

-p <PERMISSIONS>, --permissions <PERMISSIONS>

Set these file permissions for the <LOADCHECKERSOCKET> file. Use numerical permissions (e.g. 0640).

## FILES
<RUNDIR>/x2gobroker/x2gobroker-loadchecker.socket

## AUTHOR
This manual has been written for the X2Go project by Mike Gabriel <mike.gabriel@das-netzwerkteam.de>.


title: x2gobasepath(8)

text:
# x2gobasepath(8)

## NAME
x2gobasepath - Detect Base Path of X2Go Server Installation

## SYNOPSIS

x2gobasepath

## DESCRIPTION
x2gobasepath writes the X2Go server installation base path (/usr, /usr/local, ...) to stdout.

x2gobasepath can be run with user privileges.

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


title: x2gocmdexitmessage(8)

summary: Exit Message of X2Go Command

text:
# x2gocmdexitmessage(8)

## NAME
x2gocmdexitmessage - Exit Message of X2Go Command

## SYNOPSIS

x2gocmdexitmessage <session_id>

## DESCRIPTION
x2gocmdexitmessage prints out the exit message of the last command run with x2goruncommand for session <session_id>.

x2gocmdexitmessage is run with X2Go user privileges.

## RETURN VALUES
x2gocmdexitmessage prints out the last command's exit message.

As exitcode x2gocmdexitmessage always returns 0.

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


title: x2godbadmin(8)

summary: X2Go Server Database Administrator

text:
# x2godbadmin(8)

## NAME
x2godbadmin - X2Go Server Database Administrator

## SYNOPSIS

x2godbadmin <options>

## DESCRIPTION
x2godbadmin is used to set up the initial X2Go session database and perform other maintenance tasks on the X2Go server's database.

x2godbadmin must be run with root privileges.

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


title: x2gofeature(8)

text:
# x2gofeature(8)

## NAME
x2gofeature - Query X2Go Feature Availability on X2Go Server

## SYNOPSIS

x2gofeature <feature_name>

## DESCRIPTION
x2gofeature allows client applications to query the server for certain features before trying to use them.

x2gofeature can be run with user privileges.

## RETURN VALUES
If feature <feature_name> is available on the X2Go server, then ,,ok'' is written to stdout. Otherwise the expression ,,not available'' is written to stdout.

## SEE ALSO
/usr/share/x2go/x2gofeature.d/*.features x2gofeaturelist(8)

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


title: x2gofeaturelist(8)

summary: Query X2Go Feature List for X2Go Server

text:
# x2gofeaturelist(8)

## NAME
x2gofeaturelist - Query X2Go Feature List for X2Go Server

## SYNOPSIS

x2gofeaturelist

## DESCRIPTION
x2gofeaturelist allows client applications to query a server-side list of X2Go features. Such a list is very handy when new X2Go clients connect to older X2Go server. The list of features provides an overview to the client on what functionalities the server support and what not.

x2gofeaturelist can be run with user privileges.

## RETURN VALUES
List of X2Go feature names.

## SEE ALSO
/usr/share/x2go/x2gofeature.d/*.features x2gofeature(8)

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


title: x2gogetapps(8)

summary: Generate list of Published Applications

text:
# x2gogetapps(8)

## NAME
x2gogetapps - Generate list of Published Applications

## SYNOPSIS

x2gogetapps

## DESCRIPTION
x2gogetapps returns a machine-readable list of X2Go Published Applications. This command is evoked from connected X2Go client applications.

x2gogetapps is run with normal user privileges.

## RETURN VALUES
x2gogetapps returns one or multiple items in the below format:

<icon>

[ ... base64 encoded image information ...]

</icon>

<desktop>

[ ... selected fields form .desktop file ... ]

</desktop>

...

As exitcode x2gogetapps always returns 0.

## SECURITY INFORMATION / DISCLAIMER
Users are advised to not misinterpret X2GoServer's Published Application Mode as a security feature.

Even when using Published Application Mode, it is still possible for users to locally configure an X2Go Client with any setting they want, and use that to connect.

So if you're trying to keep users from running a certain application on the host, using Published Application Mode to "lock" the configuration is the *wrong* way. The users will still be able to run that application by creating their own, local configuration file and using that.

To keep users from running an application on the server, you have to use *filesystem permissions*. In the simplest case, this means setting chmod 750 or 550 on the particular application on the host, and making sure the users in question are not the owner and also not a member of the group specified for the application.

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


title: x2gogetservers(8)

summary: Retrieve list of available X2Go servers

text:
# x2gogetservers(8)

## NAME
x2gogetservers - Retrieve list of available X2Go servers

## SYNOPSIS

x2gogetservers

## DESCRIPTION
x2gogetservers retrieves a list of available X2Go servers.

This command is used in X2Go load balancing scenarios.

The x2gogetservers is run with X2Go user privileges.

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


title: x2golistdesktops(8)

summary: List Available X Desktops

text:
# x2golistdesktops(8)

## NAME
x2golistdesktops - List Available X Desktops

## SYNOPSIS

x2golistdesktops [<server_hostname>]

## DESCRIPTION
x2golistdesktops returns a list of active desktop sessions running on server <server_hostname>. If no server hostname is given at the command line, the fully qualified domain name of the local system is used here.

x2golistdesktops is run with X2Go user privileges and it is used by X2Go clients to render a list of available desktops that may be candidates for X2Go desktop sharing (shadow sessions).

The list of desktops will include local desktop sessions (launched via KDM, GDM, etc.) run by the same user, X2Go desktop sessions run by the same user and desktop sessions of other users (local or remote) that are announced via the x2godesktopsharing utility.

## RETURN VALUES
A list of available X desktops, line-by-line.

As exitcode x2golistdesktop always returns 0.

## SEE ALSO
x2godesktopsharing(1)

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


title: x2golistmounts(8)

summary: List Mounted Shares for an X2Go Session

text:
# x2golistmounts(8)

## NAME
x2golistmounts - List Mounted Shares for an X2Go Session

## SYNOPSIS

x2golistmounts [<session_id>]

## DESCRIPTION
x2golistmounts returns a list of mounted client-side folders or devices for X2Go session <session_id>.

If this commands get evoked inside an X2Go session, the <session_id> parameter can be omitted (and the env var $X2GO_SESSION will be used instead).

x2golistmounts is run with normal user privileges and it is used by X2Go clients to render a list of SSHFS mounts for a given X2Go sessions.

## RETURN VALUES
A line-by-line list of mounted shares is returned by x2golistmounts. Each line consists of two mount point attribute fields separated by the pipe symbol (,,|'').

The meanings of these mount point attributes are:

field 01: <sshfs_target_host_ip>

field 02: <mount_point_path_on_server>

As exitcode x2golistmounts always returns 0.

## SEE ALSO
x2gomountdirs(8), x2goumount-session(8)

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


title: x2golistsessions(8)

summary: List Available X2Go Sessions for User

text:
# x2golistsessions(8)

## NAME
x2golistsessions - List Available X2Go Sessions for User

## SYNOPSIS

x2golistsessions [<server_hostname>|--all-servers]

## DESCRIPTION
x2golistsessions returns a list of running or suspended X2Go sessions for X2Go server <server_hostname>. If no server hostname is given at the command line, the session list query runs for the local system.

x2golistsessions is run with normal user privileges and it is used by X2Go clients to render a list of available X2Go sessions.

## X2GO CLUSTER MODE
If x2golistsessions is executed with the --all-servers option then the central database of your X2Go cluster is queried for running/suspended sessions belonging to the user executing this command. These sessions may be active on any of the X2Go servers within your cluster.

## RETURN VALUES
A line-by-line list of available X2Go sessions. Each line consists of several session attribute fields separated by the pipe symbol (,,|'').

The meaning of the session attributes of each output line are shown below:

field 01: <agent_pid>

field 02: <session_id>

field 03: <port>

field 04: <host>

field 05: <state>

field 06: <init_time>

field 07: <session_cookie>

field 08: <client_ip>

field 09: <gr_port>

field 10: <snd_port>

field 11: <last_time>

field 12: <user>

field 13: <age_in_secs>

field 14: <sshfs_port>

field 15: <tekictrl_port> (if Telekinesis is available/enabled)

field 15: <tekidata_port> (if Telekinesis is available/enabled)

As exitcode x2golistsessions always returns 0.

## SEE ALSO
x2golistsessions_root(8), x2golistdesktops(8), x2goresume-session(8), x2gosuspend-session(8), x2goterminate-session(8)

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


title: x2golistsessions_root(8)

summary: List X2Go Sessions for System

text:
# x2golistsessions_root(8)

## NAME
x2golistsessions_root - List X2Go Sessions for System

## SYNOPSIS

x2golistsessions_root [<server_hostname>]

## DESCRIPTION
x2golistsessions_root shows a list of all available X2Go sessions on the server <server_hostname>. If no server hostname is given at the command line, the session list query runs for the local system.

x2golistsessions_root must be run with root privileges.

## RETURN VALUES
Same as explained in x2golistsessions(8).

## SEE ALSO
x2golistsessions(8)

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


title: x2golistshadowsessions(8)

text:
# x2golistshadowsessions(8)

## NAME
x2golistshadowsessions - List Available X2Go Shadow Sessions for User

## SYNOPSIS

x2golistshadowsessions [<server_hostname>|--all-servers]

## DESCRIPTION
x2golistshadowsessions returns a list of running or suspended X2Go shadow sessions (sessions that provide the X2Go Desktop Sharing feature) for X2Go server <server_hostname>. If no server hostname is given at the command line, the shadow session list query runs for the local system.

x2golistshadowsessions is run with normal user privileges and it is used by X2Go clients to render a list of available X2Go shadow sessions.

## X2GO CLUSTER MODE
If x2golistshadowsessions is executed with the --all-servers option then the central database of your X2Go cluster is queried for running/suspended shadow sessions belonging to the user executing this command. These sessions may be active on any of the X2Go servers within your cluster.

## RETURN VALUES
A line-by-line list of available X2Go sessions. Each line consists of several session attribute fields separated by the pipe symbol (,,|'').

The meaning of the session attributes of each output line are shown below:

field 01: <agent_pid>

field 02: <session_id>

field 03: <port>

field 04: <host>

field 05: <state>

field 06: <init_time>

field 07: <session_cookie>

field 08: <client_ip>

field 09: <gr_port>

field 10: <snd_port>

field 11: <last_time>

field 12: <user>

field 13: <age_in_secs>

field 14: <sshfs_port>

As exitcode x2golistshadowsessions always returns 0.

## SEE ALSO
x2golistsessions(8), x2golistdesktops(8), x2goresume-session(8), x2gosuspend-session(8), x2goterminate-session(8)

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


title: x2gomountdirs(8)

text:
# x2gomountdirs(8)

## NAME
x2gomountdirs - Share Client-Side Folder with X2Go Session

## SYNOPSIS

x2gomountdirs <mount_type> <session_id> <username> <key_file> <dir1> [<dir2> [<dir3> [...]]]

## DESCRIPTION
x2gomountdirs mounts client-side folders or devices onto mountpoints that are accessible from within your remote X2Go session.

x2gomountdirs is run with X2Go user privileges and normally issued by an X2Go client application.

## ARGUMENTS
<mount_type>

If the mount type is set to ,,dir'' then the client-side mount target is interpreted as a folder. If other, it is interpreted as a device.

<session_id>

The <session_id> is the unique identifier of the X2Go session that this command is run for.

<username>

The owner of session <session_id> is given as the <username> argument.

<key_file>

Location of a temporary private SSH key file (only valid for this command execution).

<dir1> [<dir2> [<dir3> [...]]]

A list of client-side folders or device mount points that shall be mounted for X2Go session <session_id>.

## PERMISSIONS
X2Go uses the fuse-based SSH filesystem (SSHFS) for sharing client-side file resources with X2Go sessions. Users that shall use X2Go folder sharing must be members of the X2Go server's ,,fuse'' POSIX group.

## RETURN VALUES
x2gomountdirs returns some mount point information to stdout if the mounting process has been successful. The mount results are printed line-by-line. The individual lines must be interpreted as shown below:

line 01: dirs:<local_path>__REVERSESSH_PORT__<sshfs_port>

line 02: ssh port:<sshfs_port>

line 03: Host:<client_ip>

line 04: User:<user>

line 05: inserted, sshfs -o <options> \

"<user">@<client_ip>:"<local_path>" \

"<server_path>" -p <sshfs_port>

line 06: mount <local_path> ok

line 07: fname: <desktop_icon_name>

If mounting of a client folder fails, either of the errors is returned (on stdout):

error 01: mounting of <local_path> failed

error 02: insertion of <local_path> failed (already mounted?), not mounting

As exitcode x2gomoundirs always returns 0.

## SEE ALSO
x2goumount-session(8)

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


title: x2gopath(8)

text:
# x2gopath(8)

## Name
x2gopath - Show X2Go Server installation paths

## Synopsis
x2gopath {base|lib|libexec|share}

## Description
x2gopath displays the paths of the selected X2Go installation directory.

base

The prefix under which X2Go was installed. This is generally /usr or /usr/local.

lib

The location of X2Go architecture-dependent parts (e.g. libraries, but also Perl modules).

libexec

The location of private X2Go binaries.

share

The location of X2Go's data files.


title: x2goresume-session(8)

summary: Resume X2Go Session

text:
# x2goresume-session(8)

## NAME
x2goresume-session - Resume X2Go Session

## SYNOPSIS

x2goresume-session <session_id> \

<geometry> \

<link_quality> \

<nx_pack_meth> \

<kblayout> \

<kbtype> \

<setkbd> \

<clipboardmode>

## DESCRIPTION
x2goresume-session resumes the suspended session with session ID <session_id>.

This command is normally issued by an X2Go client application with X2Go user privileges.

## ARGUMENTS
<session_id>

The session ID (or session name) of the suspend session that is to be resumed.

<geometry>

Session window size on screen (allowed values: <width>x<height> or fullscreen).

<link_quality>

Any value out of: modem, isdn, adsl, wan or lan.

<nx_pack_method>

NX compression method (see below for possible values).

<cache_type+dpi>

Cache type and color depth for X2Go session window. The most common value is: unix-kde-depth_24 where ,,24'' is the color depth in bit.

<kblayout>

Keyboard layout (e.g. us, de, etc.).

<kbtype>

Keyboard type/model (e.g. pc105/us).

<setkbd>

Force setting keyboard layout and type within the X2Go session on startup. Values: 0 or 1.

<clipboardmode>

The session's clipboard mode. Possible values: both, server, client, none. Allows one to configure clipboard security per session via the connecting X2Go client. If the clipboard parameter is set server-side in /etc/x2go/x2goagent.options, then that value will override client-side settings.

## RETURN VALUES
x2goresume-session reports to stderr if resuming of session <session_id> failed. This very probably means that the session's X agent has died, so the session <session_id> will be marked as finished in the X2Go session database.

If everything works out well, a list of session attributes is returned after successful session resumption. Session attributes will be presented on a line-by-line basis:

field 01: <graphics_port>

field 02: <sound_port>

field 03: <sshfs_port>

field 04: <tekictrl_port> (if Telekinesis is available/enabled)

field 04: <tekidata_port> (if Telekinesis is available/enabled)

As exitcode x2goresume-session always returns 0.

## SEE ALSO
x2gostartagent(8), x2goruncommand(8), x2gosuspend-session(8), x2goterminate-session(8)

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


title: x2goruncommand(8)

summary: Launch Command inside an X2Go Session

text:
# x2goruncommand(8)

## NAME
x2goruncommand - Launch Command inside an X2Go Session

## SYNOPSIS

x2goruncommand <display> <agent_pid> <session_id> <command> <sound_system> <session_type>

## DESCRIPTION
x2goruncommand launches a(n X-based) command inside of a given X2Go session.

x2goruncommand is run with X2Go user privileges and normally executed by an X2Go client application.

## ARGUMENTS
<display>

The X display number/port of the session this command is for.

<agent_pid>

The process ID (pid) of the x2goagent instance that the given session runs in.

<session_id>

The <session_id> is the unique identifier of the X2Go session that this command is intended for.

<command>

Execute command <command>. Full paths will be ignored, the command has to be in the server's $PATH. Possible generic values for <command> are: WWWBROWSER, OFFICE, MAILCLIENT and TERMINAL.

<sound_system>

Either of the possible sound systems supported by X2Go: pulse, esd, arts (obsolete) or none.

<session_type>

Allowed values for <session_type> are: D (desktop) and R (rootless).

## RETURN VALUES
By x2goruncommand nothing is reported on stdout or stderr.

As exitcode x2goruncommand always returns 0.

## SEE ALSO
x2gostartagent(8), x2goresume-session(8), x2gosuspend-session(8), x2goterminate-sessions(8)

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


title: x2goserver-run-extensions(8)

summary: Run X2Go Server Extensions

text:
# x2goserver-run-extensions(8)

## NAME
x2goserver-run-extensions - Run X2Go Server Extensions

## SYNOPSIS

x2goserver-run-extensions <session_id> <modality>

## DESCRIPTION
x2goserver-run-extensions is called from within a number of X2Go Server core scripts.

WARNING: Do not call it directly unless you really know what you are doing.

x2goserver-run-extensions executes scripts that have been provided by third-party X2Go extension packages.

What this man page is about is not the script usage itself but the way of how to provide X2Go server extensions and features without the need to change the core X2Go server scripts.

## MODALITIES
x2goserver-run-extensions is called with user privileges. As first command line argument the session ID and as the second command line argument a so-called modality is provided.

This modality tells x2goserver-run-extensions at what stage of an X2Go session startup, resumption, suspension or termination the calling script currently is at.

These X2Go Server core scripts currently call x2goserver-run-extensions: x2gostartagent(8), x2goruncommand(8), x2goresume-session(8), x2gosuspend-session(8) and x2goterminate-session(8).

The modality names all refer to a sub-directory of the path:

<libexecdir>/x2go/extensions

where <libexecdir> is /usr/libexec/x2go or /usr/lib/x2go on commonly-used GNU/Linux systems.

In any of these sub-directories third-party X2Go extension packages can place scripts or binaries that will then get executed by the core X2Go server commands, either before or after the essential functionality (e.g. x2goagent startup, x2goagent suspension, x2goagent resumption, etc.) or on failure of that essential functionality.

The following table shows the available modalities, the calling scripts and the location where to place third-party extension scripts:

CALLING SCRIPT MODALITY NAMES EXTENSION SCRIPTS LOCATION

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

x2gostartagent pre-start extensions/pre-start.d/

post-start extensions/post-start.d/

fail-start extensions/fail-start.d/

x2goruncommand pre-runcommand extensions/pre-runcommand.d/

post-runcommand extensions/post-runcommand.d/

fail-runcommand extensions/fail-runcommand.d/

x2goresume-session pre-resume extensions/pre-resume.d/

post-resume extensions/post-resume.d/

fail-resume extensions/fail-resume.d/

x2gosuspend-session pre-suspend extensions/pre-suspend.d/

post-suspend extensions/post-suspend.d/

fail-suspend extensions/fail-suspend.d/

x2goterminate-session pre-terminate extensions/pre-terminate.d/

post-terminate extensions/post-terminate.d/

fail-terminate extensions/fail-terminate.d/

IMPORTANT:

When providing X2Go Server extensions by this mechanism, please pretty well make sure that extension scripts you place in either of the above folders do under no circumstance fail during execution. Return codes are ignored and failures are therefore not (yet) propagated.

## EXECUTION OF EXTENSIONS
Scripts (or binaries) that have been placed into one of the pre/post/fail modality folders (see above) are executed in alpha-numerical sorting order.

Extensions will only get executed if their file names start with three digits followed by an underscore character. This restriction is in place to make sure that X2Go Server extensions get executed in the correct/wanted order:

For example:

010_x2goserver-statistics

020_x2goserver-mail-notify

021_x2goserver-monitoring

etc. pp.

## RETURN VALUES
x2goserver-run-extensions always returns 0 as exit code and pretends to be permanently happy :-).

## SEE ALSO
x2gostartagent(8), x2goruncommand(8), x2goresume-session(8), x2gosuspend-session(8) and x2goterminate-session(8).

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


title: x2gosessionlimit(8)

summary: Detect Session Limit for User or Group

text:
# x2gosessionlimit(8)

## NAME
x2gosessionlimit - Detect Session Limit for User or Group

## SYNOPSIS

x2gosessionlimit

## DESCRIPTION
x2gosessionlimit is not yet documented as a man page... TODO!

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


title: x2gosetkeyboard(8)

text:
# x2gosetkeyboard(8)

## NAME
x2gosetkeyboard - Allow server-side Keyboard Setting Updates issued by X2Go Client

## SYNOPSIS

x2gosetkeyboard

## DESCRIPTION
x2gosetkeyboard looks for a 'keyboard' file in the X2Go session directory and introspects the X2Go session keyboard settings requested from the client side.

If no 'keyboard' file is present in the X2Go session directory, nothing happens (i.e. no error will be raised).

## RETURN VALUES
If x2gosetkeyboard successfully sets the session's keyboard parameters an exit code of 0 is returned. Also, if the file ${HOME}/.x2go/C-${X2GO_SESSION}/keyboard is not presented at the expected location, a zero-exitcode is returned.

If the command fails on its way, then the exitcode of the failing command is returned.

## FILES
${HOME}/.x2go/C-${X2GO_SESSION}/keyboard

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


title: x2goshowblocks(8)

summary: Show X2Go-Mounted Block Devices

text:
# x2goshowblocks(8)

## NAME
x2goshowblocks - Show X2Go-Mounted Block Devices

## SYNOPSIS

x2goshowblocks <username> <session_id>

## DESCRIPTION
x2goshowblocks lists mounted shares for user <username> and X2Go session with ID <session_id>.

The x2goshowblocks must be run with root privileges.

## SEE ALSO
x2gomountdirs(8), x2goumount-session(8)

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


title: x2gostartagent(8)

summary: Start a New X2Go Session

text:
# x2gostartagent(8)

## NAME
x2gostartagent - Start a New X2Go Session

## SYNOPSIS

x2gostartagent <geometry> \

<link_quality> \

<nx_pack_meth> \

<cache_type+dpi> \

<kblayout> \

<kbtype> \

<setkbd> \

<session_type> \

<command> \

<clipboardmode> \

## DESCRIPTION
x2gostartagent coordinates the startup process of a new X2Go session. It expects quite a list of parameters, all of which are obligatory.

x2gostartagent is run with X2Go user privileges and normally executed by an X2Go client application.

## ARGUMENTS
<geometry>

Session window size on screen (allowed values: <width>x<height> or fullscreen).

<link_quality>

Any value out of: modem, isdn, adsl, wan or lan.

<nx_pack_method>

NX compression method (see below for possible values).

<cache_type+dpi>

Cache type and color depth for X2Go session window. The most common value is: unix-kde-depth_24 where ,,24'' is the color depth in bit.

<kblayout>

Keyboard layout (e.g. us, de, etc.).

<kbtype>

Keyboard type/model (e.g. pc105/us).

<setkbd>

Force setting keyboard layout and type within the X2Go session on startup. Values: 0 or 1.

<session_type>

Allowed values for <session_type> are: D (desktop), R (rootless) or S (shadow session, X2Go desktop sharing).

<command>

The command given by the <command> argument is only used to create the session ID for this new X2Go session. The actual execution of a command is handled by x2goruncommand.

<clipboardmode>

The session's clipboard mode. Possible values: both, server, client, none. Allows one to configure clipboard security per session via the connecting X2Go client. If the clipboard parameter is set server-side in /etc/x2go/x2goagent.options, then that value will override client-side settings.

## RETURN VALUES
A list of session attributes is returned after successful session startup. Session attributes will be presented on a line-by-line basis:

field 01: <X_display_number>

field 02: <session_cookie_hash>

field 03: <agent_pid>

field 04: <session_id>

field 05: <graphics_port>

field 06: <sound_port>

field 07: <sshfs_port>

field 08: <tekictrl_port> (if Telekinesis is available/enabled)

field 09: <tekidata_port> (if Telekinesis is available/enabled)

## NX COMPRESSION METHODS
As NX compression methods (<link-quality> argument) the following values are possible. The % character must be replaced by a digit 0-9.

nopack, 8, 64, 256, 512, 4k, 32k, 64k, 256k, 2m, 16m 256-rdp, 256-rdp-compressed, 32k-rdp, 32k-rdp-compressed, 64k-rdp 64k-rdp-compressed, 16m-rdp, 16m-rdp-compressed rfb-hextile, rfb-tight, rfb-tight-compressed 8-tight, 64-tight, 256-tight, 512-tight, 4k-tight, 32k-tight 64k-tight, 256k-tight, 2m-tight, 16m-tight 8-jpeg-%, 64-jpeg, 256-jpeg, 512-jpeg, 4k-jpeg, 32k-jpeg 64k-jpeg, 256k-jpeg, 2m-jpeg, 16m-jpeg-% 8-png-jpeg-%, 64-png-jpeg, 256-png-jpeg, 512-png-jpeg, 4k-png-jpeg 32k-png-jpeg, 64k-png-jpeg, 256k-png-jpeg, 2m-png-jpeg, 16m-png-jpeg-% 8-png-%, 64-png, 256-png, 512-png, 4k-png 32k-png, 64k-png, 256k-png, 2m-png, 16m-png-% 16m-rgb-%, 16m-rle-%

## SEE ALSO
x2goruncommand(8), x2goresume-session(8), x2gosuspend-session(8), x2goterminate-session(8)

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


title: x2gosuspend-session(8)

summary: Suspend an X2Go Session

text:
# x2gosuspend-session(8)

## NAME
x2gosuspend-session - Suspend an X2Go Session

## SYNOPSIS

x2gosuspend-session <session_id>

## DESCRIPTION
x2gosuspend-session suspends the running session with session ID <session_id>.

This command is normally issued by an X2Go client application with X2Go user privileges.

## RETURN VALUES
x2gosuspend-session reports to stderr if resuming of session <session_id> failed. This very probably means that the session's X agent has died, so the session <session_id> will be marked as finished in the X2Go session database.

As exitcode x2gosuspend-session always returns 0.

## SEE ALSO
x2gostartagent(8), x2goruncommand(8), x2goresume-session(8), x2goterminate-session(8)

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


title: x2goterminate-session(8)

summary: Terminate an X2Go Session

text:
# x2goterminate-session(8)

## NAME
x2goterminate-session - Terminate an X2Go Session

## SYNOPSIS

x2goterminate-session <session_id>

## DESCRIPTION
x2goterminate-session cleanly terminates the running or suspended session with session ID <session_id>.

This command is normally issued by an X2Go client application with X2Go user privileges.

## RETURN VALUES
By x2goterminate-session nothing is reported on stdout or stderr.

As exitcode x2goterminate-session always returns 0.

## SEE ALSO
x2gostartagent(8), x2goruncommand(8), x2goresume-session(8), x2gosuspend-session(8)

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


title: x2goumount-session(8)

text:
# x2goumount-session(8)

## NAME
x2goumount-session - Unshare mounted Folders from X2Go Session

## SYNOPSIS

x2goumount-session <session_id> [<local_path_on_client>]

## DESCRIPTION
x2goumount-session is used to unshare client folders from X2Go session with session ID <session_id>. Shared folders have been previously mounted into the X2Go session by the x2gomountdirs command.

x2goumount-session is run with X2Go user privileges and normally issued by an X2Go client application.

## ARGUMENTS
<session_id>

Unmount shared folder(s) as registered for X2Go session ID <session_id> in the X2Go session database.

<local_path_on_client>

Optionally, you can name a local path name (path name as found on the client-side) here. If given, only the named folder is unshared from the X2Go session <session_id>.

If this optional argument is omitted, then ALL session folders will be unshared (including spool folders for printing and MIME box).

## RETURN VALUES
By x2goumount-session nothing is reported on stdout or stderr.

As exitcode x2goumount-session return 0 on successful an umount action. If there is a failure during unmounting a shared folder a non-zero exit code is returned.

## SEE ALSO
x2gomountdirs(8)

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


title: x2goumount_session(8)

text:
# x2goumount_session(8)

## NAME
x2goumount-session - Unshare mounted Folders from X2Go Session

## SYNOPSIS

x2goumount-session <session_id> [<local_path_on_client>]

## DESCRIPTION
x2goumount-session is used to unshare client folders from X2Go session with session ID <session_id>. Shared folders have been previously mounted into the X2Go session by the x2gomountdirs command.

x2goumount-session is run with X2Go user privileges and normally issued by an X2Go client application.

## ARGUMENTS
<session_id>

Unmount shared folder(s) as registered for X2Go session ID <session_id> in the X2Go session database.

<local_path_on_client>

Optionally, you can name a local path name (path name as found on the client-side) here. If given, only the named folder is unshared from the X2Go session <session_id>.

If this optional argument is omitted, then ALL session folders will be unshared (including spool folders for printing and MIME box).

## RETURN VALUES
By x2goumount-session nothing is reported on stdout or stderr.

As exitcode x2goumount-session return 0 on successful an umount action. If there is a failure during unmounting a shared folder a non-zero exit code is returned.

## SEE ALSO
x2gomountdirs(8)

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


title: x2goversion(8)

text:
# x2goversion(8)

## NAME
x2goversion - Retrieve Code Versions of X2Go Server Components

## SYNOPSIS

x2goversion [<x2go-component>]

## DESCRIPTION
x2goversion allows one to retrieve code versions of X2Go server components.

If the [<x2go-component>] parameter is omitted then a list of all available X2Go server component names and versions is listed.

If an X2Go component is specified with the [<x2go-component>] parameter, then only the component's version is printed to stdout.

The x2goversion tool can be used by X2Go client implementations to query server-side versions of X2Go components.

## RETURN VALUES
x2goversion reports X2Go component version information to stdout.

As exitcode x2goversion always returns 0.

## FILES
/usr/share/x2go/versions/VERSION.*

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


title: x2goresume-desktopsharing(8)

text:
# x2goresume-desktopsharing(8)

## NAME
x2goresume-desktopsharing - Resume Desktop Sharing Applet for a given X2Go Session

## SYNOPSIS

x2goresume-desktopsharing <session_id>

## DESCRIPTION
x2goresume-desktopsharing launches the x2godesktopsharing applet for X2Go session <session_id>.

x2goresume-desktopsharing is run with normal user privileges and it is used from within X2Go Server. There normally is no need to execute this command manually.

## RETURN VALUES
As exitcode x2goresume-desktopsharing always returns 0.

## SEE ALSO
x2godesktopsharing(1), x2goresume-session(8), x2gosuspend-desktopsharing(8), x2goterminate-desktopsharing(8)

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


title: x2gosuspend-desktopsharing(8)

text:
# x2gosuspend-desktopsharing(8)

## NAME
x2gosuspend-desktopsharing - Suspend Desktop Sharing for a given X2Go Session

## SYNOPSIS

x2gosuspend-desktopsharing <session_id>

## DESCRIPTION
x2gosuspend-desktopsharing executes x2goterminate-desktopsharing and places a reminder file

,,resume-desktopsharing''

into

$HOME/.x2go/C-<session_id>/

so that x2godesktopsharing can be resumed on session resume.

x2gosuspend-desktopsharing is run with normal user privileges and it is used from within X2Go Server. There normally is no need to execute this command manually.

## RETURN VALUES
As exitcode x2gosuspend-desktopsharing always returns 0.

## SEE ALSO
x2godesktopsharing(1), x2gosuspend-session(8), x2goterminate-desktopsharing(8), x2goresume-desktopsharing(8)

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


title: x2goterminate-desktopsharing(8)

text:
# x2goterminate-desktopsharing(8)

## NAME
x2goterminate-desktopsharing - Cleanly Terminate Desktop Sharing for a given X2Go Session

## SYNOPSIS

x2goterminate-desktopsharing <session_id>

## DESCRIPTION
x2goterminate-desktopsharing allows one to detect a running and associated x2godesktopsharing applet and to cleanly terminate this applet.

x2goterminate-desktopsharing is run with normal user privileges and it is used from within X2Go Server. There normally is no need to execute this command manually.

## RETURN VALUES
As exitcode x2goterminate-desktopsharing returns 0 if a x2godesktopsharing process could be identified and terminated. If not, the exit code is -1.

## SEE ALSO
x2godesktopsharing(1), x2goteminate-session(8), x2gosuspend-desktopsharing(8), x2goresume-desktopsharing(8)

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


title: x2gofm(8)

text:
# x2gofm(8)

## NAME
x2gofm - X2Go wrapper for Browsing X2Go Shared Folders

## SYNOPSIS

x2gofm <shared-folder>

## DESCRIPTION
x2gofm is a component of the generic file manager bindings for X2Go's shared folders. x2gofm uses XDG (namely x2go-open <dir>) to launch the default file browser on all client-side folders shared via X2Go.

The default file browser is defined by the freedesktop.org specification of the running desktop environment.

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


title: x2goprint(8)

summary: Process X2Go Print Job

text:
# x2goprint(8)

## NAME
x2goprint - Process X2Go Print Job

## SYNOPSIS

x2goprint <username> <session_id> <pdf_file> <title_file>

## DESCRIPTION
X2Go print jobs are rendered by the cups-x2go backend on your network's (central) CUPS server and then get copied to the X2Go server that the X2Go print job was issued from.

On that X2Go server cups-x2go places two print job files (a PDF file and a title file) into the home directory of the POSIX system user ,,x2goprint'' where they await further processing by x2goprint.

The x2goprint command on the session's X2Go server (executed by cups-x2go backend) then prepares the job files for delivery to the X2Go client-side.

x2goprint must run with root privileges and is executed by cups-x2go.

## ARGUMENTS
<username>

The owner of the incoming print jobs is given as the <username> argument.

<session_id>

The <session_id> is the unique identifier of the X2Go session that the processed print job is coming from.

<pdf_file>

The filename of the PDF file as dropped into ~x2goprint by cups-x2go.

<title_file>

The filename of the title file as dropped into ~x2goprint by cups-x2go.

## PERMISSIONS
X2Go uses the fuse-based SSH filesystem (SSHFS) for transferring print jobs from X2Go server to X2Go client. Users that shall use X2Go printing must be members of the X2Go server's ,,fuse'' POSIX group.

## X2GO CLUSTER MODE
If X2Go server and CUPS server are the same machine, no further setup for X2Go printing is necessary.

However, if X2Go server and CUPS server are hosted on separate machines then a special setup of sudo and SSH is required on X2Go server(s) and the central CUPS server.

Refer to https://wiki.x2go.org/installing_x2go_printing_debian_ubuntu for further information.

## RETURN VALUES
By x2goprint nothing is reported on stdout or stderr.

If x2goprint has run successfully, an exitcode of 0 is returned. If the script has either been called by a non-root user or with the wrong number of command line arguments, a non-zero exitcode is returned.

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


xauthority-hostname-updater

package: xauthority-hostname-updater

title: xauthority-hostname-updater(8)

text:
# xauthority-hostname-updater(8)

xauthority-hostname-updater

## NAME
xauthority-hostname-updater - Daemon that keeps hostname in the Xauthority files up-to-date

## SYNOPSIS

```
  /usr/bin/xauthority-hostname-updater [OPTION...]
```

## DESCRIPTION
xauthority-hostname-updater watches org.freedesktop.hostname1 for hostname changes, and update hostnames in Xauthority files for all active displays. When hostname is changed, xauthority-hostname-updater performs the following steps:

- Determines display names: uses $DISPLAY as the local display name and filter the /proc/net/tcp records by PORT > 6000 and real UID to identify remote displays

- Changes hostname in Xauthority files ($HOME/.Xauthority and $TMPDIR/xauth-$UID-_$DISPLAY) in records where:

- family of the record matches with the FamilyLocal (means non-network connection, usually UDS)

- hostname of the record matches with the previous hostname (the hostname before it was changed)

- display name of the record is contained in the list of display names generated at the 1st step

•

Remembers the hostname and sleeps for the next signal from the org.freedesktop.hostname1

## OPTIONS
-d

Run as daemon

-h

Show help and exit