shutdown

title: shutdown(8)

summary: bring the system down

text:
# shutdown(8)

## NAME
shutdown - bring the system down

## SYNOPSIS
/sbin/shutdown [-akrhPHfFnc] [-t sec] time [warning message]

## DESCRIPTION
shutdown brings the system down in a secure way. All logged-in users are notified that the system is going down, and login(1) is blocked. It is possible to shut the system down immediately or after a specified delay. All processes are first notified that the system is going down by the signal SIGTERM. This gives programs like vi(1) the time to save the file being edited, mail and news processing programs a chance to exit cleanly, etc. shutdown does its job by signalling the init process, asking it to change the runlevel. Runlevel 0 is used to halt the system, runlevel 6 is used to reboot the system, and runlevel 1 is used to put to system into a state where administrative tasks can be performed; this is the default if neither the -h or -r flag is given to shutdown. To see which actions are taken on halt or reboot see the appropriate entries for these runlevels in the file /etc/inittab.

## OPTIONS
-a

Use /etc/shutdown.allow.

-k

Don't really shutdown; only send the warning messages to everybody.

-r

Reboot after shutdown.

-h

Halt or power off after shutdown. Usually used with the -P or -H flags, depending on whether we want to poweroff or simply stop the operating system.

-P

Modifier to the -h flag. Halt action is to turn off the power. Must be used with the -h flag.

-H

Modifier to the -h flag. Halt action is to halt or drop into boot monitor on systems that support it. Must be used with the -h flag. Halting is often used to run through the shutdown process and leave output on the screen for debugging purposes. Or when the user wants the OS to stop, but leave the power on. To power off at the end of the shutdown sequence use the -P modifier instead.

-f

Skip fsck on reboot.

-F

Force fsck on reboot.

-n

[DEPRECATED] Don't call init(8) to do the shutdown but do it ourself. The use of this option is discouraged, and its results are not always what you'd expect.

-c

Cancel a waiting shutdown. ("shutdown now" is no longer waiting.) With this option it is of course not possible to give the time argument, but you can enter explanatory message arguments on the command line that will be sent to all users.

-q

Reduce the number of warnings shutdown displays. Usually shutdown displays warnings every 15 minutes and then every minute in the last 10 minutes of the countdown until time is reached. When -q is specified shutdown only warns at 60 minute intervals, at the 10 minute mark, at the 5 minue mark, and when the shutdown process actually happens.

-Q

Silence warnings prior to shutting down. Usually shutdown displays warnings every 15 minutes and then every minute in the last 10 minutes of the countdown until time is reached. When -Q is specified shutdown only warns when the shutdown process actually happens. All other warning intervals are suppressed.

-t sec

Tell init(8) to wait sec seconds between sending all processes the warning (SIGTERM) and the kill signal (SIGKILL), before changing to another runlevel. The default time, if no value is specified, between these two signals is three seconds. Warning: when shutdown calls init to perform the shutdown (the default behaviour), init checks to see if all processes have terminated and will stop waiting early once its children have all terminated. When shutdown is called with the -n flag, it waits the full time specified (or three seconds) even if all other processes have terminated.

time

When to shutdown.

warning message

Message to send to all users.

The time argument can have different formats. First, it can be an absolute time in the format hh:mm, in which hh is the hour (1 or 2 digits) and mm is the minute of the hour (in two digits). Second, it can be in the format +m, in which m is the number of minutes to wait. Third, it can be in the format +hh:mm, in which hh:mm is the number of hours and minutes to wait. The word now is an alias for +0.

If shutdown is called with a delay, it will create the advisory file /etc/nologin which causes programs such as login(1) to not allow new user logins. This file is created five minutes before the shutdown sequence starts. Shutdown removes this file if it is stopped before it can signal init (i.e. it is cancelled or something goes wrong). It also removes it before calling init to change the runlevel.

The -f flag means `reboot fast'. This only creates an advisory file /fastboot which can be tested by the system when it comes up again. The boot rc file can test if this file is present, and decide not to run fsck(1) since the system has been shut down in the proper way. After that, the boot process should remove /fastboot.

The -F flag means `force fsck'. This only creates an advisory file /forcefsck which can be tested by the system when it comes up again. The boot rc file can test if this file is present, and decide to run fsck(1) with a special `force' flag so that even properly unmounted file systems get checked. After that, the boot process should remove /forcefsck.

The -n flag causes shutdown not to call init, but to kill all running processes itself. shutdown will then turn off quota, accounting, and swapping and unmount all file systems.

## ACCESS CONTROL
shutdown can be called from init(8) when the magic keys CTRL-ALT-DEL are pressed, by creating an appropriate entry in /etc/inittab. This means that everyone who has physical access to the console keyboard can shut the system down. To prevent this, shutdown can check to see if an authorized user is logged in on one of the virtual consoles. If shutdown is called with the -a argument (add this to the invocation of shutdown in /etc/inittab), it checks to see if the file /etc/shutdown.allow is present. It then compares the login names in that file with the list of people that are logged in on a virtual console (from /var/run/utmp). Only if one of those authorized users or root is logged in, it will proceed. Otherwise it will write the message

```
shutdown: no authorized users logged in
```

to the (physical) system console. The format of /etc/shutdown.allow is one user name per line. Empty lines and comment lines (prefixed by a #) are allowed. Currently there is a limit of 32 users in this file.

Note that if /etc/shutdown.allow is not present, the -a argument is ignored.

## HALT OR POWEROFF
The -H option just sets the init environment variable INIT_HALT to HALT, and the -P option just sets that variable to POWEROFF. The script (usually /etc/init.d/halt) that calls the halt(8) program as the last thing in the shutting down sequence should check this environment variable and call the halt(8) program with the right options for these options to actually have any effect.

## FILES

```
/fastboot
/etc/inittab
/etc/init.d/halt
/etc/init.d/reboot
/etc/shutdown.allow
```

## NOTES
A lot of users forget to give the time argument and are then puzzled by the error message shutdown produces. The time argument is mandatory; in 90 percent of all cases this argument will be the word now.

Init can only capture CTRL-ALT-DEL and start shutdown in console mode. If the system is running the X window System, the X server processes all key strokes. Some X11 environments make it possible to capture CTRL-ALT-DEL, but what exactly is done with that event depends on that environment.

Shutdown wasn't designed to be run setuid. /etc/shutdown.allow is not used to find out who is executing shutdown, it ONLY checks who is currently logged in on (one of the) console(s).

## AUTHOR
Miquel van Smoorenburg, miquels@cistron.nl

## SEE ALSO
fsck(8), init(8), halt(8), poweroff(8), reboot(8)


bootlogd

package: sysvinit-utils

title: bootlogd(8)

summary: record boot messages

text:
# bootlogd(8)

## NAME
bootlogd - record boot messages

## SYNOPSIS
/sbin/bootlogd [-c] [-d] [-e] [-r] [-s] [-v] [ -l logfile ] [ -p pidfile ]

## DESCRIPTION
Bootlogd runs in the background and copies all strings sent to the /dev/console device to a logfile. If the logfile is not accessible, the messages will be kept in memory until it is.

## OPTIONS
-d

Do not fork and run in the background.

-e

Print escape characters to the boot log file. This turns off filtering of escape characters and allows tools like GNU Less to see and use colour control characters (show the log in colour).

-c

Attempt to write to the logfile even if it does not yet exist. Without this option, bootlogd will wait for the logfile to appear before attempting to write to it. This behavior prevents bootlogd from creating logfiles under mount points.

-r

If there is an existing logfile called logfile rename it to logfile~ unless logfile~ already exists.

-s

Ensure that the data is written to the file after each line by calling fdatasync(3). This will slow down a fsck(8) process running in parallel.

-v

Show version.

-l logfile

Log to this logfile. The default is /var/log/boot.

-p pidfile

Put process-id in this file. The default is no pidfile.

## NOTES
bootlogd saves log data which includes control characters. The log is technically a text file, but not very easy for humans to read. To address this the readbootlog(1) command can be used to display the boot log without the control characters.

## BUGS
Bootlogd works by redirecting the console output from the console device. (Consequently bootlogd requires PTY support in the kernel configuration.) It copies that output to the real console device and to a log file. There is no standard way of ascertaining the real console device if you have a new-style /dev/console device (major 5, minor 1) so bootlogd parses the kernel command line looking for console=... lines and deduces the real console device from that. If that syntax is ever changed by the kernel, or a console type is used that bootlogd does not know about then bootlogd will not work.

## AUTHOR
Miquel van Smoorenburg, miquels@cistron.nl

## SEE ALSO
dmesg(8),fdatasync(3),readbootlog(1).


title: killall5(8)

text:
# killall5(8)

## NAME
killall5 -- send a signal to all processes.

## SYNOPSIS
killall5 -signalnumber [-o omitpid[,omitpid...]] [-o omitpid[,omitpid...]...]

## DESCRIPTION
killall5 is the SystemV killall command. It sends a signal to all processes except kernel threads and the processes in its own session, so it won't kill the shell that is running the script it was called from. Its primary (only) use is in the rc scripts found in the /etc/init.d directory.

## OPTIONS
-o omitpid

Tells killall5 to omit processes with that process id.

## NOTES
killall5 can also be invoked as pidof, which is simply a (symbolic) link to the killall5 program.

## EXIT STATUS
The program return zero if it killed processes. It return 2 if no process were killed, and 1 if it was unable to find any processes (/proc/ is missing).

## SEE ALSO
halt(8), reboot(8), pidof(8)

## AUTHOR
Miquel van Smoorenburg, miquels@cistron.nl


pidof

title: pidof(8)

text:
# pidof(8)

## NAME
pidof -- find the process ID of a running program.

## SYNOPSIS
pidof [-s] [-c] [-n] [-x] [-z] [-o omitpid[,omitpid...]] [-o omitpid[,omitpid...]...] [-d sep] program [program...]

## DESCRIPTION
Pidof finds the process id's (PIDs) of the named programs. It prints those id's on the standard output. This program is on some systems used in run-level change scripts, especially when the system has a System-V like rc structure. In that case these scripts are located in /etc/rc?.d, where ? is the runlevel. If the system has a start-stop-daemon (8) program that should be used instead.

## OPTIONS
-s

Single shot - this instructs the program to only return one pid.

-c

Only return process PIDs that are running with the same root directory. This option is ignored for non-root users, as they will be unable to check the current root directory of processes they do not own.

-n

Avoid stat(2) system function call on all binaries which are located on network based file systems like NFS. Instead of using this option the variable PIDOF_NETFS may be set and exported.

-q

Do not display matched PIDs to standard out. Simply exit with a status of true or false to indicate whether a matching PID was found.

-x

Scripts too - this causes the program to also return process id's of shells running the named scripts.

-z

Try to detect processes which are stuck in uninterruptible (D) or zombie (Z) status. Usually these processes are skipped as trying to deal with them can cause pidof to hang.

-d sep

Tells pidof to use sep as an output separator if more than one PID is shown. The default separator is a space.

-o omitpid

Tells pidof to omit processes with that process id. The special pid %PPID can be used to name the parent process of the pidof program, in other words the calling shell or shell script.

## EXIT STATUS
0

At least one program was found with the requested name.

1

No program was found with the requested name.

## NOTES
pidof is actually the same program as killall5; the program behaves according to the name under which it is called.

When pidof is invoked with a full pathname to the program it should find the pid of, it is reasonably safe. Otherwise it is possible that it returns PIDs of running programs that happen to have the same name as the program you're after but are actually other programs. Note that the executable name of running processes is calculated with readlink(2), so symbolic links to executables will also match.

Zombie processes or processes in disk sleep (states Z and D, respectively) are ignored, as attempts to access the stats of these will sometimes fail. The -z flag (see above) tells pidof to try to detect these sleeping and zombie processes, at the risk of failing or hanging.

## SEE ALSO
shutdown(8), init(8), halt(8), reboot(8), killall5(8)

## AUTHOR
Miquel van Smoorenburg, miquels@cistron.nl


title: t50(8)

text:
# t50(8)

## NAME
T50 - network packet injector

## SYNOPSIS
t50 [OPTION]... host[/CIDR]

## DESCRIPTION
Experimental mixed packet injector tool.

T50 must to be executed as root.

## OPTIONS
host[/CIDR]

The host address can be informed in one of two formats: IP address or URI name. In both cases the CIDR can be informed following the host name or IP using '/' as separator. Partial IP addresses can be informed. To do so, the user must exclude one or more octects (ex: 192.168 for 192.168.0.0/16 - "192.168." is an invalid host because of the last '.'). When using a partial IP address T50 will calculate CIDR automatically (8, 16 or 24 bits, if the first, second or thrid octect is informed, respectively).

--threshold NUM

Number of packets to send (default 1000).

--flood

Superseds the threshold.

-B, --bogus-csum

Bogus checksum.

--turbo

Extend performance (create child process).

-s, --saddr ADDR

IP source address (default RANDOM).

--help

Display full help.

## EXAMPLES
Send 500 packets to a single target:

\# t50 --threshold 500 192.168.0.100

Flood test:

$ t50 --flood 192.168.0.100

## AUTHORS
Nelson Brito

## CONTRIBUTORS
Fernando Mercês

Frederico Lamberti Pissarra

## REPORTING BUGS
Report t50 bugs at http://github.com/fredericopissarra/t50

## COPYRIGHT
Copyright © 2014 T50 developers. Licensed GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.


title: tac_plus(8)

summary: tacacs plus daemon

text:
# tac_plus(8)

## NAME
tac_plus - tacacs plus daemon

## SYNOPSIS
tac_plus -C <configfile> [-GghiLPSstv] [-B <bind_address>] [-d <level>] [-l <logfile>] [-m <max_listen_queue>] [-p <tcp_port>] [-Q <setgid>] [-U <setuid>] [-u <wtmpfile>] [-w <wholog>]

## DESCRIPTION
By default, tac_plus listens on tcp port 49 and provides network devices (normally routers and access servers) with authentication, authorization and accounting services.

A configuration file controls the details of authentication, authorization and accounting.

## COMMAND-LINE OPTIONS
-C <configfile>

Specify the configuration file name. The -C option is required.

-B <bind address>

Specify the address on which the daemon should bind(2). Successive instances of -B override previous instances. By default, the daemon listens on all addresses. Note: this changes the name of the pid file created by the daemon.

-G

Remain in the foreground, but not single-threaded nor logging to the tty.

-d <level>

Switch on debugging. By default the output will appear in the log file and syslog(3). NOTE: The -g flag will cause these messages to also appear on stdout. The -t flag will cause these messages to also be written to /dev/console.

The value of level is as described below. These values represent bits that can be logically OR'd together. The daemon logically ORs successive occurrences of the -d option.

```
Value   Meaning
2       configuration parsing debugging
4       fork(1) debugging
8       authorization debugging
16      authentication debugging
32      password file processing debugging
64      accounting debugging
128     config file parsing & lookup
256     packet transmission/reception
512     encryption/decryption
1024    MD5 hash algorithm debugging
2048    very low level encryption/decryption
32768   max session debugging
65536   lock debugging
```

-g

Single threaded mode. The daemon will only accept and service a single connection at a time without forking and without closing file descriptors. All log messages appear on standard output. This is intended only for debugging and not for normal service.

This option does not work with single-connection sessions.

-h

Display help message.

-i

tac_plus will be run from inetd(8). In inetd mode, the configuration file is parsed every time tac_plus starts. If the configuration is large or the frequency of connections is high, this negatively will affect the responsiveness of the daemon.

If the config file is small, connections are infrequent, and authentication is being done via passwd(5) files or SKEY (which are not cached), running in inetd mode should be tolerable, but still is not recommended.

This option does not work with single-connection sessions.

-l <logfile>

Specify an alternate log file location. This file is only used when the -d option is used. The logs are still posted to syslog.

-m <max_listen_queue>

Specify an alternative client listen queue limit. The default is SOMAXCONN or 64, if your O/S does not specify one.

-L

Lookup DNS PTR (Domain Name System PoinTeR) record of client addresses. The resulting FQDN (Fully Qualified Domain Name), if it resolves, will be used in log messages, libwrap (tcp_wrappers) checks, and for matching host clauses of the configuration file. Also see tac_plus.conf(5).

-P

Parse the configuration file, echo it to standard output while parsing, and then exit. tac_plus will exit non-zero when a parser error occurs. Useful for debugging configuration file syntax.

-p <port>

Listen on the specified port number instead of the default port 49 for incoming tcp connections. Note: this changes the name of the pid file created by the daemon.

-Q <setgid groupname>

Specify the groupname or GID to setgid(2). If the daemon was compiled with a specific GID, this option overrides that value. By default, the daemon inherits the GID from its parent process.

-S

Enables or allows client single-connection mode, where-by the client will create one connection and interleave queries. Note: this is broken in IOS and IOS-XE.

Note: this is currently only partially supported in the daemon.

-s

Causes the daemon to always reject authentication requests which contain a minor version number of zero (SENDPASS). This enhances security in the event that someone discovers your encryption key. SENDPASS requests permit requesters to obtain CHAP, PAP and ARAP passwords from the daemon, iff the encryption key is known. Note: IOS versions preceding 11.2 will fail.

-t

Log all informational, debugging or error messages to /dev/console in addition to logging to syslogd. Useful for debugging.

-U <setuid username>

Specify the username or UID to setuid(2). If the daemon was compiled with a specific UID, this option overrides that value. The daemon must be started by root to open the privileged port. By default, it does not change it's UID and therefore remains root.

-u <wtmpfile>

Write wtmp entries to the specified wtmp file.

-v

Display version information and exit.

-w <wholog>

Specify the location of the max session file.

## STARTING
tac_plus is normally invoked by root, as follows:

\# tac_plus -C <configfile>

where <configfile> is a full path to the configuration file. Tac_plus will background itself and start listening on port 49 for incoming tcp connections.

Tac_plus must be invoked as root to obtain privileged network socket 49 and to read the protected configuration file, which may contain confidential information such as encryption keys and cleartext passwords.

After the port is acquired and the config file is read, root privileges are no longer required. You can arrange that tac_plus will change its user and group IDs to a more innocuous user and group via the configuration file.

NOTE: The new user and group still needs permission to read any passwd(5) (and shadow(5)) files and S/KEY database if these are being used.

## TCP WRAPPERS
If tac_plus was compiled with libwrap (aka. tcp_wrappers) support, upon connection the daemon will consult with tcp_wrappers on whether the client has permission to connect. The daemon name used in a daemon list of the access control file is the name of the executable, normally "tac_plus". See hosts_access(5).

## PERMISSIONS
The configuration file should be unreadable and unwriteable by anyone except root, as it contains passwords and keys.

## SIGNALS
If the daemon is receives a SIGHUP or SIGUSR1, it will reinitialize itself and re-read its configuration file.

Note: if an error is encountered in the configuration file or the file can not be opened for reading, such as due to insufficient permissions resulting from process ownership and file permissions, the daemon will exit.

Likewise, if the daemon is configured to send accounting records to a file and that file can not be opened for writing, such as due to insufficient permissions resulting from process ownership and file permissions, the daemon will exit.

## LOG MESSAGES
tac_plus logs error and informational messages to syslog facility LOG_DAEMON.

## FILES
/var/log/tac_plus.acct

Default accounting file.

/var/log/tac_plus.log

Default log file used when the -d option is used.

/var/run/tac_plus.pid

Pid file. If the -B option is used, ".bind_address" is appended. If the -p option is used, ".port_number" is appended.

## SEE ALSO
tac_plus.conf(5), tac_pwd(8)

Also see the tac_plus User Guide (user_guide) that came with the distribution. The user guide does not cover all the modifications to the original Cisco version.

## HISTORY
There are at least 3 versions of the authentication protocol that people commonly refer to as "TACACS".

The first is ordinary tacacs, which was the first one offered on Cisco boxes and has been in use for many years. The second is an extension to the first, commonly called Extended Tacacs or XTACACS, introduced in 1990.

The third one is TACACS+ (or T+ or tac_plus) which is what is documented here. TACACS+ is NOT COMPATIBLE with any previous versions of tacacs.

## AUTHOR
The tac_plus (tacacs+) developer's kit is a product of Cisco Systems, written by Lol Grant. Made available at no cost and with no warranty of any kind. See the file COPYING and source files that came with the distribution for specifics.

Though heavily modified from the original Cisco manual pages, much of the modifications are derived from the tacacs IETF draft and the Cisco user guide.


title: tac_pwd(8)

text:
# tac_pwd(8)

## NAME
tac_pwd - generate DES or MD5 encryption of a password

## SYNOPSIS
tac_pwd [-ehm] [salt]

## DESCRIPTION
tac_pwd prompts for a clear-text password and produces a DES encryption of that password on stdout which may be used in lieu of the clear-text representation in the tac_plus.conf(5).

The DES salt may be provided as a command-line argument.

## COMMAND-LINE OPTIONS
-e

Do not echo the plain-text password to the terminal.

-h

Display help message.

-m

Generate an MD5 encryption, instead of DES. This only works if crypt() on your host supports MD5.

## SEE ALSO
crypt(3), tac_plus(8), tac_plus.conf(5)


tacitus

package: tacitus

title: tacitus(8)

text:
# tacitus(8)

## NAME
tacitus - set sort-of-actual time on early boot of systems without RTC hardware (mostly embedded)

## SYNOPSIS
service tacitus [start|stop|restart|reload|status]

## OPTIONS
start - attempt to set previously saved time; the NTP daemon would (hopefully) do the rest

stop|restart|reload - save current time for future use

status - show current and (if file exists) saved time

## NAMED AFTER
Cornelius Tacitus - rerum gestarum scriptor Romanus.

## SEE ALSO
date(1)


targetctl

package: target-restore

title: targetctl(8)

text:
# targetctl(8)

## NAME
targetctl - Save and restore configuration of kernel target

## DESCRIPTION
targetctl is a low-level script to save and restore the configuration of the LIO kernel target, to and from a file in json format. It is not normally meant to be used by end-users directly, but by system init frameworks, or advanced end-users who are generating the configuration file themselves and need a way to load the configuration without relying on the targetcli configuration shell.

## USAGE
targetctl must be invoked as root. Exit status will be 0 if successful, or nonzero if an error was encountered.

targetctl save [config-file]

Saves the current configuration of the kernel target to a file in json format. Since the file may contain cleartext passwords, the file's permissions will be set to only allow root access. If config-file is not supplied, targetctl will use the default file location, /etc/target/saveconfig.json.

targetctl restore [config-file]

Removes any existing configuration and replaces it with the configuration described in the file. See saveconfig.json(5) for more details. If parts of the configuration could not be restored, those parts will be noted in the error output, and the rest of the configuration will still be applied.

targetctl clear

Removes any existing configuration from the running kernel target.

targetctl --help

Displays usage information.

## SEE ALSO
targetcli(8), targetd(8), saveconfig.json(5)

## FILES
/etc/target/saveconfig.json

/sys/kernel/config/target

## AUTHOR
Written by Andy Grover <agrover@redhat.com>.

Man page written by Andy Grover <agrover@redhat.com>.

## REPORTING BUGS
Report bugs via <targetcli-fb-devel@lists.fedorahosted.org>

or <https://github.com/open-iscsi/rtslib-fb/issues>


targetcli

package: targetcli

title: targetcli(8)

text:
# targetcli(8)

## NAME
targetcli - administration shell for storage targets

## DESCRIPTION
targetcli is a shell for viewing, editing, and saving the configuration of the kernel's target subsystem, also known as LIO. It enables the administrator to assign local storage resources backed by either files, volumes, local SCSI devices, or ramdisk, and export them to remote systems via network fabrics, such as iSCSI or FCoE.

There is a daemon component for targetcli, which will greatly improve the overall execution time taken by targetcli commands at scale. For more details about switching to daemonized mode refer to targetclid(8) man page.

The configuration layout is tree-based, similar to a filesystem, and is navigated in a similar manner.

## USAGE
targetcli

targetcli [cmd]

Invoke targetcli as root to enter the configuration shell, or follow with a command to execute but do not enter the shell. Use ls to list nodes below the current path. Moving around the tree is accomplished by the cd command, or by entering the new location directly. Objects are created using create, removed using delete. Use help <cmd> for additional usage information. Tab-completion is available for commands and command arguments.

Configuration changes in targetcli are made immediately to the underlying kernel target configuration. Settings will not be retained across reboot unless saveconfig is either explicitly called, or implicitly by exiting the shell with the global preference auto_save_on_exit set to true, the default.

## QUICKSTART
To create an iSCSI target and share a file-backed LUN without any auth checks:

$ sudo targetcli

/> backstores/fileio create test /tmp/test.img 100m

/> iscsi/ create iqn.2006-04.com.example:test-target

/> cd iscsi/iqn.2006-04.com.example:test-target/tpg1/

tpg1/> luns/ create /backstores/fileio/test

tpg1/> set attribute generate_node_acls=1

tpg1/> exit

Although by default targetcli saves the running configuration upon exit, a distribution-specific service must be enabled to restore the saved configuration on reboot. See distribution documentation for specifics, but for example:

$ sudo systemctl enable target.service

See EXAMPLES below for more detailed information on commands and using the shell.

## BACKSTORES
Backstores are different kinds of local storage resources that the kernel target uses to "back" the SCSI devices it exports. The mappings to local storage resources that each backstore creates are called storage objects.

### FILEIO
Allows files to be treated as disk images. When storage objects of this type are created, they can support either write-back or write-thru operation. Using write-back enables the local filesystem cache, which will improve performance but increase the risk of data loss. It is also possible to use fileio with local block device files, if buffered operation is needed.

Fileio also supports using an existing file, or creating a new file. New files are sparsely allocated by default.

### BLOCK
Allows a local disk block device to be shared.

### PSCSI
Allows a local SCSI device of any type to be shared. It is generally advised to prefer the block backstore if sharing a block SCSI device is desired.

### RAMDISK
Allows kernel memory to be shared as a block SCSI device. Since memory is volatile, the contents of the ramdisk will be lost if the system restarts, and this backstore is best used for testing only.

It also supports "nullio" mode, which is not backed by any storage. It discards all writes, and returns all-zeroes for reads.

### USERSPACE-BACKED
Backstores starting with "user:" are not supported in the kernel, but rely on a userspace process to handle requests. See tcmu-runner(8) for more information on creating backstores of this type.

## TARGETS
Targets are instances of a fabric, which adapts the kernel target to a specific transport protocol such as iSCSI, Fibre Channel, or SBP-2. Creating a target in targetcli enables that target to be configured. The name of the target, its WWN (world wide name), may link the configuration to a specific hardware endpoint, like SRP for example, or it may not, like iSCSI.

Aside from "backstores", all other top-level configuration nodes in targetcli are fabrics that may have targets created for them. Fabrics that require hardware are only listed if the hardware is present and configured properly.

### CREATING A TARGET
Use the create command within a fabric's node to create a target. If the fabric's targets are tied to hardware then targetcli will constrain the WWN to available hardware WWNs. These can be shown via tab-completion. If the fabric is not tied to hardware, such as iSCSI, then targetcli will either auto-generate a WWN if none is given, or check that the given WWN has the correct format. All WWNs are prefaced by their type, such as "iqn", "naa", or "ib", and may be given with or without colons.

iSCSI supports multiple WWN formats: iqn, naa, and eui. Other fabrics support single formats only.

## CONFIGURING A TARGET
Not all fabrics have the same capabilities. Targets on different fabrics will have different configuration node layouts. iSCSI has the most to configure; other fabrics present subsets of iSCSI's feature set.

## CONFIGURING ISCSI
iSCSI has the most options for configuration.

### TPGS
TPGs (Target Portal Groups) allow the iSCSI to support multiple complete configurations within one target. This is useful for complex quality-of-service configurations. targetcli will automatically create one TPG when the target is created, and almost all setups only need one.

### PORTALS
An iSCSI target may be reached via multiple IP addresses and ports. These addr:port pairs are called portals. Both IPv4 and IPv6 addresses are supported.

When a target is created, targetcli automatically creates a default portal listening on all IPv4 and IPv6 addresses (shown as ::0) on port 3260. If IPV6_V6ONLY is set, the default will only listen on all IPv6 addresses. If a different configuration is needed, the default portal can be removed and portals configured as desired.

If the hardware supports it, iSER (iSCSI Extensions for RDMA) may be enabled via the enable_iser command within each portal's node. Or, if the hardware supports it, hardware offload may be enabled via the enable_offload command within each portal's node.

### LUNS
The kernel target exports SCSI Logical Units, also called LUNs. This section links the previously-defined storage objects with the target, and defines which number (the Logical Unit Number) the device will use. Note that if ACLs are being used, a lun mapping must be created under the ACL that refers back to the TPG LUN.

### ACLS
ACLs (Access Control Lists) allow different configuration, depending on the initiator that is connecting to the target. This includes both per-initiator authentication settings as well as per-initiator LUN mappings.

create <wwn> in the acls node creates an ACL for an initiator, and create within the ACL creates a LUN mapping. (This can either refer to the TPG LUN, or to the storage object, in which case the TPG LUN will be configured as well.) Global setting auto_add_mapped_luns affects this, see below.

### AUTHENTICATION
iSCSI supports authentication via the CHAP protocol, which uses a username and password. The initiator may be required to supply valid credentials to the target, and the target may also be required to supply credentials back to the initiator. The latter is referred to as mutual authentication.

Furthermore, authentication credentials may be different for each session phase (Discovery or Normal), and authentication in a Normal session may be set at the TPG level, or per-ACL.

Discovery Authentication

iSCSI Discovery sessions allow the initiator to connect to a portal and discover targets with the SendTargets command, but not access them. The four parameters userid, password, mutual_userid, and mutual_password are configured via set discovery_auth command within the top-level iscsi configuration node. 1-way authentication is enabled if userid and password are both set, and mutual authentication is enabled if all four are set. Authentication is disabled by unsetting the parameters.

Normal Authentication

Similarly, the four parameters userid, password, mutual_userid, and mutual_password are configured via set auth command within the TPG node and ACL nodes. However, LIO only uses one or the other, depending on the TPG's generate_node_acls attribute setting. If generate_node_acls is 1, the TPG-wide settings will be used. If generate_node_acls is 0, then the user-created ACLs' settings will be used.

Enable generate_node_acls with set attribute generate_node_acls=1 within the TPG node. This can be thought of as "ignore ACLs mode" -- both authentication and LUN mapping will then use the TPG settings.

No Authentication

Authentication is disabled by clearing the TPG "authentication" attribute: set attribute authentication=0. Although initiator names are trivially forgeable, generate_node_acls still works here to either ignore user-defined ACLs and allow all, or check that an ACL exists for the connecting initiator.

## CONFIGURING FIBRE CHANNEL (QLA2XXX)
Operation as a target requires that /sys/module/qla2xxx/parameters/qlini_mode report "disabled". This may require passing the qlini_mode=disabled parameter to the qla2xxx module when it loads.

## CONFIGURING FIBRE CHANNEL OVER ETHERNET (TCM_FC)
Ensure fcoeadm -i shows a working endpoint.

## CONFIGURING SRP
SRP (SCSI RDMA Protocol) requires that RDMA-capable hardware is present. It uses "ib" WWNs.

## CONFIGURING LOOPBACK
Storage objects may be re-exported as local SCSI devices with this fabric.

## CONFIGURING OTHER FABRICS
Other fabrics may be present. They are for specialized uses. Use at your own risk.

## EXAMPLES

### DEFINING A STORAGE OBJECT WITHIN A BACKSTORE
backstores/fileio create disk1 /disks/disk1.img 140M

Creates a storage object named disk1 with the given path and size. targetcli supports common size abbreviations like 'M', 'G', and 'T'.

### EXPORTING A STORAGE OBJECT VIA ISCSI
iscsi/ create

Creates an iSCSI target with a default WWN. It will also create an initial target portal group called tpg1.

iqn.2003-01.org.linux-iscsi.test2.x8664:sn123456789012/tpg1/

An example of changing to the configuration node for the given target's first target portal group (TPG). This is equivalent to giving the command prefixed by "cd". (Although more can be useful for certain setups, most configurations have a single TPG per target. In this case, configuring the TPG is equivalent to configuring the overall target.)

portals/ create

Add a portal, i.e. an IP address and TCP port via which the target can be contacted by initiators. Only required if the default [::0]:3260 portal is not present.

luns/ create /backstores/fileio/disk1

Create a new LUN in the TPG, attached to the storage object that has previously been defined. The storage object now shows up under the /backstores configuration node as activated.

acls/ create iqn.1994-05.com.redhat:4321576890

Creates an ACL (access control list) entry for the given iSCSI initiator.

acls/iqn.1994-05.com.redhat:4321576890 create 2 0

Gives the initiator access to the first exported LUN (lun0), which the initiator will see as lun2. The default is to give the initiator read/write access; if read-only access was desired, an additional "1" argument would be added to enable write-protect. (Note: if global setting auto_add_mapped_luns is true, this step is not necessary.)

### EXPORTING A STORAGE OBJECT VIA FCOE
tcm_fc/ create 20:00:00:19:99:a8:34:bc

Create an FCoE target with the given WWN. targetcli can tab-complete the WWN based on registered FCoE interfaces. If none are found, verify that they are properly configured and are shown in the output of fcoeadm -i.

tcm_fc/20:00:00:19:99:a8:34:bc/

If auto_cd_after_create is set to false, change to the configuration node for the given target, equivalent to giving the command prefixed by cd.

luns/ create /backstores/fileio/disk1

Create a new LUN for the interface, attached to a previously defined storage object. The storage object now shows up under the /backstores configuration node as activated.

acls/ create 00:99:88:77:66:55:44:33

Create an ACL (access control list), for defining the resources each initiator may access. The default behavior is to auto-map existing LUNs to the ACL; see help for more information.

The LUN should now be accessible via FCoE.

## OTHER COMMANDS
saveconfig

Save the current configuration settings to a file, from which settings will be restored if the system is rebooted. By default, this will save the configuration to /etc/target/saveconfig.json.

This command is executed from the configuration root node.

restoreconfig

Restore target configuration from a file, the default is the file listed under saveconfig. This will fail if there is already an established config, unless the clear_existing option is set to true.

This command is executed from the configuration root node.

clearconfig

Clears the entire current local configuration. The parameter confirm=true must also be given, as a precaution.

This command is executed from the configuration root node.

sessions [ list | detail ] [sid]

Lists the current open sessions or a specific session, with or without details.

This command is executed from the configuration root node.

exit

Leave the configuration shell.

## SETTINGS GROUPS
Settings are broken into groups. Individual settings are accessed by get <group> <setting> and set <group> <setting>=<value>, and the settings of an entire group may be displayed by get <group>. All except for global are associated with a particular configuration node.

### GLOBAL
Shell-related user-specific settings are in global, and are visible from all configuration nodes. They are mostly shell display options, but some starting with auto_ affect shell behavior and may merit customization. These include auto_save_on_exit, which controls if exiting targetcli saves the configuration; auto_add_mapped_luns, to automatically add existing LUNs to new ACLs, and new LUNS to existing ACLs; and auto_cd_after_create, to change working path to newly-created nodes. Global settings are user-specific and are saved to ~/.targetcli/ upon exit, unlike other groups, which are system-wide and kept in /etc/target/saveconfig.json.

### BACKSTORE-SPECIFIC
attribute

/backstore/<type>/<name> configuration node. Contains values relating to the backstore and storage object.

### ISCSI-SPECIFIC
discovery_auth

/iscsi configuration node. Set the normal and mutual authentication userid and password for discovery sessions, as well as enabling or disabling it. By default it is disabled -- no authentication is required for discovery.

parameter

/iscsi/<target_iqn>/tpgX configuration node. ISCSI-specific parameters such as AuthMethod, MaxBurstLength, IFMarker, DataDigest, and similar.

attribute

/iscsi/<target_iqn>/tpgX configuration node. Contains implementation-specific settings for the TPG, such as authentication, to enforce or disable authentication for the full-feature phase (i.e. non-discovery).

auth

/iscsi/<target_iqn>/tpgX/acls/<initiator_iqn> configuration node. Set the userid and password for full-feature phase for this ACL.

## FILES
/etc/target/saveconfig.json

/etc/target/backup/*

## ENVIRONMENT

### TARGETCLI_HOME
If set, this variable points to a directory that should be used instead of ~/.targetcli

## SEE ALSO
targetclid(8), targetctl(8), tcmu-runner(8)

## AUTHOR
Written by Jerome Martin <jxm@risingtidesystems.com>.

Man page written by Andy Grover <agrover@redhat.com>.

## REPORTING BUGS
Report bugs via <targetcli-fb-devel@lists.fedorahosted.org>

or <https://github.com/open-iscsi/targetcli-fb/issues>


tayga

package: tayga

title: tayga(8)

summary: stateless NAT64 daemon

text:
# tayga(8)

## NAME
tayga - stateless NAT64 daemon

## SYNOPSIS
tayga [OPTION]...

tayga --mktun [OPTION]...

tayga --rmtun [OPTION]...

## DESCRIPTION
TAYGA is a stateless NAT64 daemon for Linux. Using the in-kernel TUN network driver, TAYGA receives IPv4 and IPv6 packets from the host's network stack, translates them to the other protocol, and then sends the translated packets back to the host using the same TUN interface.

Translation is compliant with IETF Internet-Draft draft-ietf-behave-v6v4-xlate-23, and address mapping is performed in accordance with RFC 6052. Optionally, TAYGA may be configured to dynamically map IPv6 hosts to addresses drawn from a configured IPv4 address pool.

As a stateless NAT, TAYGA requires a one-to-one mapping between IPv4 addresses and IPv6 addresses. Mapping multiple IPv6 addresses onto a single IPv4 address can be achieved by mapping IPv6 addresses to private IPv4 addresses with TAYGA and then using a stateful NAT44 (such as the iptables(8) MASQUERADE target) to map the private IPv4 addresses onto the desired single IPv4 address.

TAYGA's configuration is stored in the tayga.conf(5) file, which is usually found in /etc/tayga.conf or /usr/local/etc/tayga.conf.

## INVOCATION
Without the --mktun or --rmtun options, the `tayga` executable runs as a daemon, translating packets as described above.

The --mktun and --rmtun options instruct TAYGA to create or destroy, respectively, its configured TUN device as a "persistent" interface and then immediately exit.

Persistent TUN devices remain present on the host system even when TAYGA is not running. This allows host-side network parameters and firewall rules to be configured prior to commencement of packet translation. This may simplify network configuration on the host; for example, systems which use a Debian-style /etc/network/interfaces file may configure TAYGA's TUN device at boot by running `tayga --mktun` as a "pre-up" command and then configuring the TUN device as any other network interface.

## OPTIONS
-c configfile | --config configfile

Read configuration options from configfile

-d

Enable debug messages (enables --nodetach as well)

-n | --nodetach

Do not detach from terminal

-u userid | --user userid

Set uid to userid after initialization

-g groupid | --group groupid

Set gid to groupid after initialization

-r | --chroot

chroot() to data-dir (specified in config file)

-p pidfile | --pidfile pidfile

Write process ID of daemon to pidfile

## AUTHOR
Written by Nathan Lutchansky <lutchann@litech.org>

## COPYRIGHT
Copyright © 2010 Nathan Lutchansky

License GPLv2+: GNU GPL version 2 or later

This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.

## SEE ALSO
tayga.conf(5)

<http://www.litech.org/tayga/>


package: tcb-utils

title: tcb_convert(8)

summary: utilities to convert to and from

text:
# tcb_convert(8)

## NAME
tcb_convert, tcb_unconvert - utilities to convert to and from the tcb password shadowing scheme

## SYNOPSIS
tcb_convert

tcb_unconvert

## DESCRIPTION
tcb_convert converts /etc/shadow into a set of files under /etc/tcb/ (see tcb(5)). During this operation /etc/shadow is locked.

tcb_unconvert converts the files under /etc/tcb/ back into /etc/shadow. Because it is impractical to lock all of the tcb shadow files, tcb_unconvert temporarily changes the group ownership on /etc/tcb/ to group "sys" such that the passwd(1) utility will refuse to work during the conversion.

## MIGRATING TO TCB
In order to migrate a system to the tcb password shadowing scheme from the traditional /etc/passwd+/etc/shadow setup, the following steps are necessary:

1.

Install the tcb package as well as tcb-aware shadow-utils.

2.

Create the group "auth" if it isn't present.

3.

If you want processes possessing both "shadow" and "auth" groups to have read-only access to all tcb files, add or uncomment the following line in /etc/login.defs: TCB_AUTH_GROUP yes

4.

As root, execute tcb_convert.

5.

In /etc/nsswitch.conf, find the "shadow" entry and replace the "files" method with "tcb"; the edited line should look like this: shadow: tcb

6.

In /etc/pam.d/ files, change occurrences of pam_unix.so or pam_pwdb.so (if any) to pam_tcb.so. You may wish to browse the pam_tcb(8) manual for information on additional tuning.

7.

In each file under /etc/pam.d/ which has a "password" line (most notably in /etc/pam.d/passwd) add the write_to=tcb option to the instance of pam_tcb used as the password changing module. The line should look similar to this: password required /lib/security/pam_tcb.so shadow use_authtok write_to=tcb

8.

Edit /etc/login.defs such that it contains the (uncommented) line: USE_TCB yes

9.

Now you should remove the /etc/shadow file and its backups (if any), such as /etc/shadow-. It is important that you do so such that processes possessing the "shadow" group don't get read access to all of your old password hashes (many of which may remain valid for quite some time).

10.

As root, chown root:shadow /usr/bin/passwd /etc/pam.d/passwd

chmod 2711 /usr/bin/passwd

chmod 640 /etc/pam.d/passwd

11.

Test if everything works properly, most notably logging in to the system.

## THE RETURN TO SHADOW
If for some reason you decide to return from tcb to the traditional password shadowing scheme, you can do so with the use of tcb_unconvert and by reverting some of the actions listed in "MIGRATING TO TCB", above.

## SEE ALSO
login.defs(5), tcb(5), pam_tcb(8)