This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

man5

1: Linux cli command proc_pid_maps
2: Linux cli command Xsession.options.d
3: Linux cli command ldap.conf
4: Linux cli command proc_diskstats
5: Linux cli command sepermit.conf
6: Linux cli command moduli
7: Linux cli command extension-release
8: Linux cli command systemd.mount
9: Linux cli command snmp_config
10: Linux cli command networkd.conf
11: Linux cli command depmod.d
12: Linux cli command apt.conf
13: Linux cli command proc_cmdline
14: Linux cli command mib2c.conf
15: Linux cli command proc_kallsyms
16: Linux cli command proc_pid_status
17: Linux cli command Xsession
18: Linux cli command sudo_plugin
19: Linux cli command deb-extra-override
20: Linux cli command org.bluez.obex.PhonebookAccess
21: Linux cli command org.freedesktop.LogControl1
22: Linux cli command proc_tid
23: Linux cli command exim4-config_files
24: Linux cli command os-release
25: Linux cli command proc_pid_clear_refs
26: Linux cli command gitweb.conf
27: Linux cli command smartd.conf
28: Linux cli command smbpasswd
29: Linux cli command avahi-daemon.conf
30: Linux cli command libaudit.conf
31: Linux cli command systemd.device
32: Linux cli command proc_stat
33: Linux cli command acct
34: Linux cli command securetty
35: Linux cli command org.bluez.obex.Transfer
36: Linux cli command pfm
37: Linux cli command ntp.conf
38: Linux cli command gitformat-signature
39: Linux cli command proc_partitions
40: Linux cli command exim4_exim_crt
41: Linux cli command termcap
42: Linux cli command githooks
43: Linux cli command proc_pid
44: Linux cli command deb-old
45: Linux cli command proc_profile
46: Linux cli command proc_pid_cpuset
47: Linux cli command proc_pid_mem
48: Linux cli command nss
49: Linux cli command openvpn-examples
50: Linux cli command variables
51: Linux cli command exim4_sender_local_deny_exceptions
52: Linux cli command org.freedesktop.portable1
53: Linux cli command proc_timer_stats
54: Linux cli command proc_iomem
55: Linux cli command shells
56: Linux cli command org.freedesktop.login1
57: Linux cli command proc_timer_list
58: Linux cli command systemd.socket
59: Linux cli command ppm
60: Linux cli command org.freedesktop.systemd1
61: Linux cli command libnftables-json
62: Linux cli command proc_pid_task
63: Linux cli command proc_kmsg
64: Linux cli command pnm
65: Linux cli command gitignore
66: Linux cli command exim4_exim_key
67: Linux cli command proc_interrupts
68: Linux cli command org.bluez.AgentManager
69: Linux cli command gitprotocol-http
70: Linux cli command proc_tid_children
71: Linux cli command org.freedesktop.hostname1
72: Linux cli command org.bluez.obex.Client
73: Linux cli command exim4_hubbed_hosts
74: Linux cli command proc_sys_user
75: Linux cli command proc_fs
76: Linux cli command proc_cgroups
77: Linux cli command papersize
78: Linux cli command org.bluez.obex.Session
79: Linux cli command proc_pid_fdinfo
80: Linux cli command libsasl
81: Linux cli command gitformat-index
82: Linux cli command mke2fs.conf
83: Linux cli command tzfile
84: Linux cli command extendedopacity
85: Linux cli command org.bluez.obex.Message
86: Linux cli command fips_configssl
87: Linux cli command proc_dma
88: Linux cli command sshd_config
89: Linux cli command adjtime_config
90: Linux cli command sysfs
91: Linux cli command proc_cpuinfo
92: Linux cli command whois.conf
93: Linux cli command apt_preferences
94: Linux cli command org.bluez.DeviceSet
95: Linux cli command proc_tty
96: Linux cli command ext3
97: Linux cli command deb-substvars
98: Linux cli command pam_env.conf
99: Linux cli command lmhosts
100: Linux cli command proc_sys_debug
101: Linux cli command ts.conf
102: Linux cli command gitformat-commit-graph
103: Linux cli command systemd.positive
104: Linux cli command proc_sys_dev
105: Linux cli command proc_pid_mountinfo
106: Linux cli command proc_kcore
107: Linux cli command systemd.exec
108: Linux cli command snmpd.examples
109: Linux cli command iocost.conf
110: Linux cli command sudo_logsrvd.conf
111: Linux cli command deb-conffiles
112: Linux cli command proc_pid_mountstats
113: Linux cli command localtime
114: Linux cli command init-d-script
115: Linux cli command org.freedesktop.network1
116: Linux cli command opensc.conf
117: Linux cli command proc_pci
118: Linux cli command proc_pid_statm
119: Linux cli command utmp
120: Linux cli command charmap
121: Linux cli command configssl
122: Linux cli command systemd.target
123: Linux cli command deb-symbols
124: Linux cli command user-dirs.dirs
125: Linux cli command crypttab
126: Linux cli command groff_font
127: Linux cli command updmap.cfg
128: Linux cli command deb-triggers
129: Linux cli command proc_buddyinfo
130: Linux cli command proc_pid_limits
131: Linux cli command mosquitto.conf
132: Linux cli command proc_pid_personality
133: Linux cli command udev.conf
134: Linux cli command wtmp
135: Linux cli command proc_ksyms
136: Linux cli command proc_sys_fs
137: Linux cli command proc_sys_net
138: Linux cli command org.bluez.obex.Synchronization
139: Linux cli command proc_pid_auxv
140: Linux cli command proc_pid_timerslack_ns
141: Linux cli command repertoiremap
142: Linux cli command update-initramfs.conf
143: Linux cli command wpa_supplicant.conf
144: Linux cli command proc_pid_comm
145: Linux cli command gitrepository-layout
146: Linux cli command intro
147: Linux cli command etc-aliases
148: Linux cli command org.bluez.MediaFolder
149: Linux cli command crontab
150: Linux cli command modules.dep
151: Linux cli command limits.conf
152: Linux cli command proc_pid_stat
153: Linux cli command deb-src-files
154: Linux cli command shadow
155: Linux cli command exim4_local_host_blacklist
156: Linux cli command proc_version
157: Linux cli command proc_pid_autogroup
158: Linux cli command proc_self
159: Linux cli command dnssec-trust-anchors.d
160: Linux cli command gitprotocol-capabilities
161: Linux cli command terminal-colors.d
162: Linux cli command deluser.conf
163: Linux cli command proc_pid_numa_maps
164: Linux cli command proc_locks
165: Linux cli command systemd.swap
166: Linux cli command filesystems
167: Linux cli command mac-vendor
168: Linux cli command org.bluez.AdminPolicySet
169: Linux cli command deb-prerm
170: Linux cli command modprobe.d
171: Linux cli command proc_pid_cgroup
172: Linux cli command rsyncd.conf
173: Linux cli command modules.dep.bin
174: Linux cli command initrd-release
175: Linux cli command proc_driver
176: Linux cli command exim4_local_sender_callout
177: Linux cli command pkcs15-profile
178: Linux cli command proc_modules
179: Linux cli command pc
180: Linux cli command systemd-user.conf
181: Linux cli command proc_kpageflags
182: Linux cli command proc_pid_environ
183: Linux cli command updatedb.conf
184: Linux cli command deb-control
185: Linux cli command ext4
186: Linux cli command proc_malloc
187: Linux cli command mailcap.order
188: Linux cli command XCompose
189: Linux cli command [email protected]
190: Linux cli command proc_filesystems
191: Linux cli command systemd.pcrlock
192: Linux cli command proc_sys
193: Linux cli command GeoIP.conf
194: Linux cli command Xsession.options
195: Linux cli command terminfo
196: Linux cli command proc_sysrq-trigger
197: Linux cli command proc_scsi
198: Linux cli command systemd.negative
199: Linux cli command geoclue
200: Linux cli command [email protected]
201: Linux cli command org.bluez.GattCharacteristic
202: Linux cli command org.freedesktop.timedate1
203: Linux cli command proc_pid_fd
204: Linux cli command proc_pid_cwd
205: Linux cli command org.bluez.Media
206: Linux cli command procfs
207: Linux cli command slabinfo
208: Linux cli command org.bluez.GattDescriptor
209: Linux cli command snmpd.internal
210: Linux cli command pwhistory.conf
211: Linux cli command gitprotocol-v2
212: Linux cli command key.dns_resolver.conf
213: Linux cli command avahi.service
214: Linux cli command proc_sys_abi
215: Linux cli command user_caps
216: Linux cli command org.bluez.obex.FileTransfer
217: Linux cli command pbm
218: Linux cli command gshadow
219: Linux cli command nfsrahead
220: Linux cli command org.bluez.LEAdvertisingManager
221: Linux cli command proc_mounts
222: Linux cli command reader.conf
223: Linux cli command semanage.conf
224: Linux cli command sudoers_timestamp
225: Linux cli command proc_fb
226: Linux cli command proc_pid_seccomp
227: Linux cli command proc_sys_kernel
228: Linux cli command adduser.conf
229: Linux cli command proc_sys_proc
230: Linux cli command sysstat
231: Linux cli command fonts-conf
232: Linux cli command journald.conf.d
233: Linux cli command snmp.conf
234: Linux cli command proc_key-users
235: Linux cli command core
236: Linux cli command deb-postinst
237: Linux cli command org.bluez.MediaControl
238: Linux cli command hosts_access
239: Linux cli command issue
240: Linux cli command veritytab
241: Linux cli command hostname
242: Linux cli command proc_ioports
243: Linux cli command exim4_host_local_deny_exceptions
244: Linux cli command proc_pid_smaps
245: Linux cli command proc_pid_exe
246: Linux cli command snmpd.conf
247: Linux cli command kernel-img.conf
248: Linux cli command pgm
249: Linux cli command proc_pid_setgroups
250: Linux cli command hdparm.conf
251: Linux cli command gitmailmap
252: Linux cli command dhclient.conf
253: Linux cli command sysctl.d
254: Linux cli command org.bluez.AdvertisementMonitor
255: Linux cli command org.bluez.GattService
256: Linux cli command gitprotocol-pack
257: Linux cli command fstab
258: Linux cli command proc_pid_mounts
259: Linux cli command proc_sys_vm
260: Linux cli command org.bluez.MediaItem
261: Linux cli command proc_pid_uid_map
262: Linux cli command odbcinst.ini
263: Linux cli command exim4_passwd_client
264: Linux cli command proc_pid_cmdline
265: Linux cli command proc_pid_attr
266: Linux cli command mailcap
267: Linux cli command tmpfiles.d
268: Linux cli command ssh_config
269: Linux cli command console-setup
270: Linux cli command networks
271: Linux cli command org.bluez.BatteryProvider
272: Linux cli command proc_execdomains
273: Linux cli command deb-origin
274: Linux cli command user_clusters
275: Linux cli command hosts
276: Linux cli command deb-src-rules
277: Linux cli command hosts.equiv
278: Linux cli command deb-override
279: Linux cli command resolv.conf
280: Linux cli command logind.conf.d
281: Linux cli command dhcp-eval
282: Linux cli command dir_colors
283: Linux cli command org.bluez.Device
284: Linux cli command udev.conf.d
285: Linux cli command utmpx
286: Linux cli command org.bluez.obex.ObjectPush
287: Linux cli command e2fsck.conf
288: Linux cli command locale
289: Linux cli command namespace.conf
290: Linux cli command apt_auth.conf
291: Linux cli command deb-buildinfo
292: Linux cli command org.freedesktop.locale1
293: Linux cli command gemfile
294: Linux cli command proc_net
295: Linux cli command systemd-user-runtime-dir
296: Linux cli command protocols
297: Linux cli command subgid
298: Linux cli command nanorc
299: Linux cli command crypt
300: Linux cli command proc_loadavg
301: Linux cli command exim4_local_sender_blacklist
302: Linux cli command proc_pid_io
303: Linux cli command systemd.path
304: Linux cli command pkgconf-personality
305: Linux cli command editrcedit
306: Linux cli command deb-changes
307: Linux cli command proc_pid_syscall
308: Linux cli command sleep.conf.d
309: Linux cli command systemd.scope
310: Linux cli command netconfig
311: Linux cli command systemd.automount
312: Linux cli command interfaces
313: Linux cli command gitmodules
314: Linux cli command gitformat-pack
315: Linux cli command idmapd.conf
316: Linux cli command proc_swaps
317: Linux cli command org.bluez.Adapter
318: Linux cli command odbc.ini
319: Linux cli command login.defs
320: Linux cli command fmtutil.cnf
321: Linux cli command systemd.dnssd
322: Linux cli command dsc
323: Linux cli command proc_zoneinfo
324: Linux cli command ucf.conf
325: Linux cli command binfmt.d
326: Linux cli command logind.conf
327: Linux cli command proc_pid_net
328: Linux cli command org.freedesktop.machine1
329: Linux cli command motd
330: Linux cli command proc_mtrr
331: Linux cli command org.bluez.AdvertisementMonitorManager
332: Linux cli command postgresqlrc
333: Linux cli command vlan-interfaces
334: Linux cli command proc_pid_ns
335: Linux cli command smb.conf
336: Linux cli command deb-shlibs
337: Linux cli command sudoers
338: Linux cli command systemd.preset
339: Linux cli command [email protected]
340: Linux cli command org.bluez.GattManager
341: Linux cli command [email protected]
342: Linux cli command pam.conf
343: Linux cli command proc_vmstat
344: Linux cli command miredo.conf
345: Linux cli command proc_kpagecount
346: Linux cli command groff_out
347: Linux cli command systemd.timer
348: Linux cli command gitattributes
349: Linux cli command proc_pid_coredump_filter
350: Linux cli command pstore.conf.d
351: Linux cli command journald.conf
352: Linux cli command gitformat-bundle
353: Linux cli command manpath
354: Linux cli command org.bluez.ProfileManager
355: Linux cli command proc_pid_pagemap
356: Linux cli command deb-src-symbols
357: Linux cli command proc_devices
358: Linux cli command hosts_options
359: Linux cli command gai.conf
360: Linux cli command proc_thread-self
361: Linux cli command request-key.conf
362: Linux cli command gitprotocol-common
363: Linux cli command deb822
364: Linux cli command nfs
365: Linux cli command access.conf
366: Linux cli command proc_config.gz
367: Linux cli command term
368: Linux cli command ethers
369: Linux cli command proc_crypto
370: Linux cli command org.bluez.MediaTransport
371: Linux cli command org.bluez.obex.MessageAccess
372: Linux cli command proc_kpagecgroup
373: Linux cli command freetds.conf
374: Linux cli command scr_dump
375: Linux cli command proc_pid_projid_map
376: Linux cli command systemd.slice
377: Linux cli command resolver
378: Linux cli command org.bluez.Network
379: Linux cli command rpc
380: Linux cli command locale.conf
381: Linux cli command hgignore
382: Linux cli command systemd.kill
383: Linux cli command org.bluez.BatteryProviderManager
384: Linux cli command systemd.network
385: Linux cli command environment.d
386: Linux cli command deb-preinst
387: Linux cli command org.bluez.Input
388: Linux cli command proc_pid_gid_map
389: Linux cli command org.bluez.NetworkServer
390: Linux cli command org.bluez.Agent
391: Linux cli command faillock.conf
392: Linux cli command ext2
393: Linux cli command proc_ide
394: Linux cli command etc-email-addresses
395: Linux cli command user-dirs.defaults
396: Linux cli command org.bluez.GattProfile
397: Linux cli command org.bluez.Battery
398: Linux cli command org.bluez.MediaEndpoint
399: Linux cli command deb-src-control
400: Linux cli command deb-split
401: Linux cli command regulatory.db
402: Linux cli command etter.conf
403: Linux cli command synctex
404: Linux cli command menufile
405: Linux cli command deb-postrm
406: Linux cli command systemd.resource-control
407: Linux cli command machine-info
408: Linux cli command sources.list
409: Linux cli command environment
410: Linux cli command deb-changelog
411: Linux cli command org.bluez.MediaPlayer
412: Linux cli command update-exim4.conf.conf
413: Linux cli command proc_apm
414: Linux cli command dpkg.cfg
415: Linux cli command integritytab
416: Linux cli command keymaps
417: Linux cli command proc_pid_oom_score
418: Linux cli command systemd.link
419: Linux cli command proc_pid_stack
420: Linux cli command ntp.keys
421: Linux cli command user.conf.d
422: Linux cli command pam
423: Linux cli command sysusers.d
424: Linux cli command proc_pid_oom_adj
425: Linux cli command sudo_logsrv.proto
426: Linux cli command x509v3_configssl
427: Linux cli command user-dirs.conf
428: Linux cli command gitformat-chunk
429: Linux cli command systemd-sleep.conf
430: Linux cli command group
431: Linux cli command proc_pid_oom_score_adj
432: Linux cli command networkd.conf.d
433: Linux cli command proc_pid_wchan
434: Linux cli command proc_sysvipc
435: Linux cli command proc_keys
436: Linux cli command modules-load.d
437: Linux cli command org.bluez.Profile
438: Linux cli command pcap-savefile
439: Linux cli command sudo.conf
440: Linux cli command nsswitch.conf
441: Linux cli command pam.d
442: Linux cli command systemd.netdev
443: Linux cli command logrotate.conf
444: Linux cli command proc_uptime
445: Linux cli command fs
446: Linux cli command sysctl.conf
447: Linux cli command system.conf.d
448: Linux cli command hosts.deny
449: Linux cli command proc_meminfo
450: Linux cli command pstore.conf
451: Linux cli command elf
452: Linux cli command services
453: Linux cli command keyboard
454: Linux cli command systemd.unit
455: Linux cli command erofs
456: Linux cli command proc_pid_timers
457: Linux cli command Compose
458: Linux cli command exim4_passwd
459: Linux cli command sslsplit.conf
460: Linux cli command exim4_local_rcpt_callout
461: Linux cli command initramfs.conf
462: Linux cli command systemd.pcrlock.d
463: Linux cli command hosts.allow
464: Linux cli command svnserve.conf
465: Linux cli command avahi.hosts
466: Linux cli command exim4_local_domain_dnsbl_whitelist
467: Linux cli command deb
468: Linux cli command time.conf
469: Linux cli command nfs.conf
470: Linux cli command subuid
471: Linux cli command hgrc
472: Linux cli command ldif
473: Linux cli command authorized_keys
474: Linux cli command inetsim.conf
475: Linux cli command org.bluez.obex.Agent
476: Linux cli command proc_pid_root
477: Linux cli command nologin
478: Linux cli command org.bluez.obex.AgentManager
479: Linux cli command deb-md5sums
480: Linux cli command host.conf
481: Linux cli command systemd-system.conf
482: Linux cli command dhclient.leases
483: Linux cli command nfsmount.conf
484: Linux cli command machine-id
485: Linux cli command proc_bus
486: Linux cli command tmpfs
487: Linux cli command proc_pid_map_files
488: Linux cli command org.bluez.AdminPolicyStatus
489: Linux cli command proc
490: Linux cli command proc_slabinfo
491: Linux cli command ttytype
492: Linux cli command org.bluez.LEAdvertisement
493: Linux cli command groff_tmac
494: Linux cli command dhcp-options
495: Linux cli command proc_sys_sunrpc
496: Linux cli command magic
497: Linux cli command group.conf
498: Linux cli command passwd

1 - Linux cli command proc_pid_maps

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_maps and provides detailed information about the command proc_pid_maps, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_maps.

NAME 🖥️ proc_pid_maps 🖥️

mapped memory regions

DESCRIPTION

/proc/pid/maps
A file containing the currently mapped memory regions and their access permissions. See mmap(2) for some further information about memory mappings.

Permission to access this file is governed by a ptrace access mode PTRACE_MODE_READ_FSCREDS check; see ptrace(2).

The format of the file is:

address perms offset dev inode pathname
00400000-00452000 r-xp 00000000 08:02 173521      /usr/bin/dbus-daemon
00651000-00652000 r--p 00051000 08:02 173521      /usr/bin/dbus-daemon
00652000-00655000 rw-p 00052000 08:02 173521      /usr/bin/dbus-daemon
00e03000-00e24000 rw-p 00000000 00:00 0           [heap]
00e24000-011f7000 rw-p 00000000 00:00 0           [heap]
...
35b1800000-35b1820000 r-xp 00000000 08:02 135522  /usr/lib64/ld-2.15.so
35b1a1f000-35b1a20000 r--p 0001f000 08:02 135522  /usr/lib64/ld-2.15.so
35b1a20000-35b1a21000 rw-p 00020000 08:02 135522  /usr/lib64/ld-2.15.so
35b1a21000-35b1a22000 rw-p 00000000 00:00 0
35b1c00000-35b1dac000 r-xp 00000000 08:02 135870  /usr/lib64/libc-2.15.so
35b1dac000-35b1fac000 ---p 001ac000 08:02 135870  /usr/lib64/libc-2.15.so
35b1fac000-35b1fb0000 r--p 001ac000 08:02 135870  /usr/lib64/libc-2.15.so
35b1fb0000-35b1fb2000 rw-p 001b0000 08:02 135870  /usr/lib64/libc-2.15.so
...
f2c6ff8c000-7f2c7078c000 rw-p 00000000 00:00 0    [stack:986]
...
7fffb2c0d000-7fffb2c2e000 rw-p 00000000 00:00 0   [stack]
7fffb2d48000-7fffb2d49000 r-xp 00000000 00:00 0   [vdso]

The address field is the address space in the process that the mapping occupies. The perms field is a set of permissions:

r = read
w = write
x = execute
s = shared
p = private (copy on write)

The offset field is the offset into the file/whatever; dev is the device (major:minor); inode is the inode on that device. 0 indicates that no inode is associated with the memory region, as would be the case with BSS (uninitialized data).

The pathname field will usually be the file that is backing the mapping. For ELF files, you can easily coordinate with the offset field by looking at the Offset field in the ELF program headers (readelf -l).

There are additional helpful pseudo-paths:

[stack]
The initial process’s (also known as the main thread’s) stack.

[stack:tid] (from Linux 3.4 to Linux 4.4)
A thread’s stack (where the tid is a thread ID). It corresponds to the /proc/pid/task/tid/ path. This field was removed in Linux 4.5, since providing this information for a process with large numbers of threads is expensive.

[vdso]
The virtual dynamically linked shared object. See vdso(7).

[heap]
The process’s heap.

[anon:name] (since Linux 5.17)
A named private anonymous mapping. Set with prctl(2) PR_SET_VMA_ANON_NAME.

[anon_shmem:name] (since Linux 6.2)
A named shared anonymous mapping. Set with prctl(2) PR_SET_VMA_ANON_NAME.

If the pathname field is blank, this is an anonymous mapping as obtained via mmap(2). There is no easy way to coordinate this back to a process’s source, short of running it through gdb(1), strace(1), or similar.

pathname is shown unescaped except for newline characters, which are replaced with an octal escape sequence. As a result, it is not possible to determine whether the original pathname contained a newline character or the literal *

character sequence.

If the mapping is file-backed and the file has been deleted, the string " (deleted)" is appended to the pathname. Note that this is ambiguous too.

Under Linux 2.0, there is no field giving pathname.

2 - Linux cli command Xsession.options.d

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command Xsession.options.d and provides detailed information about the command Xsession.options.d, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the Xsession.options.d.

NAME 🖥️ Xsession.options.d 🖥️

configuration options for Xsession(5)

DESCRIPTION

/etc/X11/Xsession.options and /etc/X11/Xsession.options.d/*.conf contain options that determine some of the behavior of the Xsession(5) Bourne shell (sh(1)) script. See the Xsession(5) manpage for further information.

These configuration files may contain comments, which begin with a hash mark (‘#’) and end at the next newline, just like comments in shell scripts. The rest of the file consists of options which are expressed as words separated by hyphens, with only one option per line. Options are enabled by simply placing them in the file; they are disabled by prefixing the option name with ‘no-’.

Options are read from /etc/X11/Xsession.options, followed by /etc/X11/Xsession.options.d/*.conf in sorted order; later occurrences of an option (with or without the ‘no-’ prefix) take precedence over earlier occurrences.

Available options are:

allow-failsafe
If the ‘failsafe’ argument is passed to the Xsession script, an emergency X session is invoked, consisting of only an x-terminal-emulator(1) in the upper-left hand corner of the screen. No window manager is started. If an x-terminal-emulator program is not available, the session exits immediately.

allow-user-resources
If users have a file called .Xresources in their home directories, these resources will be merged with the default X resources when they log in.

allow-user-xsession
If users have an executable file called .xsession in their home directories, it can be used as the startup program for the X session (see Xsession(5)). If the file is present but not executable, it may still be used, but is assumed to be a Bourne shell script, and executed with sh(1).

use-session-dbus
If the dbus package is installed, the session bus will be activated at X session launch.

use-ssh-agent
If the ssh-agent(1) program is available and no agent process appears to be running already, the X session will be invoked by exec’ing ssh-agent with the startup command, instead of the startup command directly.

All of the above options are enabled by default. Additional options may be supported by the local administrator. Xsession(5) describes how this is accomplished.

AUTHORS

Stephen Early, Mark Eichin, and Branden Robinson developed Debian’s X session handling scripts. Branden Robinson wrote this manual page.

3 - Linux cli command ldap.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ldap.conf and provides detailed information about the command ldap.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ldap.conf.

NAME 🖥️ ldap.conf 🖥️

LDAP configuration file/environment variables

SYNOPSIS

/etc/ldap/ldap.conf, ldaprc, .ldaprc, $LDAP<option-name>

DESCRIPTION

If the environment variable LDAPNOINIT is defined, all defaulting is disabled.

The ldap.conf configuration file is used to set system-wide defaults to be applied when running ldap clients.

Users may create an optional configuration file, ldaprc or .ldaprc, in their home directory which will be used to override the system-wide defaults file. The file ldaprc in the current working directory is also used.

Additional configuration files can be specified using the LDAPCONF and LDAPRC environment variables. LDAPCONF may be set to the path of a configuration file. This path can be absolute or relative to the current working directory. The LDAPRC, if defined, should be the basename of a file in the current working directory or in the user’s home directory.

Environmental variables may also be used to augment the file based defaults. The name of the variable is the option name with an added prefix of LDAP. For example, to define BASE via the environment, set the variable LDAPBASE to the desired value.

Some options are user-only. Such options are ignored if present in the ldap.conf (or file specified by LDAPCONF).

Thus the following files and variables are read, in order:

    variable     $LDAPNOINIT, and if that is not set:
    system file  /etc/ldap/ldap.conf,
    user files   $HOME/ldaprc,  $HOME/.ldaprc,  ./ldaprc,
    system file  $LDAPCONF,
    user files   $HOME/$LDAPRC, $HOME/.$LDAPRC, ./$LDAPRC,
    variables    $LDAP<uppercase option name>.

Settings late in the list override earlier ones.

SYNTAX

The configuration options are case-insensitive; their value, on a case by case basis, may be case-sensitive.

Blank lines are ignored.
Lines beginning with a hash mark (`#’) are comments, and ignored.

Valid lines are made of an option’s name (a sequence of non-blanks, conventionally written in uppercase, although not required), followed by a value. The value starts with the first non-blank character after the option’s name, and terminates at the end of the line, or at the last sequence of blanks before the end of the line. The tokenization of the value, if any, is delegated to the handler(s) for that option, if any. Quoting values that contain blanks may be incorrect, as the quotes would become part of the value. For example,

	# Wrong - erroneous quotes:
	URI     "ldap:// ldaps://"

	# Right - space-separated list of URIs, without quotes:
	URI     ldap:// ldaps://

	# Right - DN syntax needs quoting for Example, Inc:
	BASE    ou=IT staff,o="Example, Inc",c=US
	# or:
	BASE    ou=IT staff,o=Example\2C Inc,c=US

	# Wrong - comment on same line as option:
	DEREF   never           # Never follow aliases

A line cannot be longer than LINE_MAX, which should be more than 2000 bytes on all platforms. There is no mechanism to split a long line on multiple lines, either for beautification or to overcome the above limit.

OPTIONS

The different configuration options are:

URI <ldap[si]://[name[:port]] …>
Specifies the URI(s) of an LDAP server(s) to which the LDAP library should connect. The URI scheme may be any of ldap, ldaps or ldapi, which refer to LDAP over TCP, LDAP over SSL (TLS) and LDAP over IPC (UNIX domain sockets), respectively. Each server’s name can be specified as a domain-style name or an IP address literal. Optionally, the server’s name can followed by a ‘:’ and the port number the LDAP server is listening on. If no port number is provided, the default port for the scheme is used (389 for ldap://, 636 for ldaps://). For LDAP over IPC, name is the name of the socket, and no port is required, nor allowed; note that directory separators must be URL-encoded, like any other characters that are special to URLs; so the socket

/usr/local/var/ldapi

must be specified as

ldapi://%2Fusr%2Flocal%2Fvar%2Fldapi

A space separated list of URIs may be provided.

BASE <base>
Specifies the default base DN to use when performing ldap operations. The base must be specified as a Distinguished Name in LDAP format.

BINDDN <dn>
Specifies the default bind DN to use when performing ldap operations. The bind DN must be specified as a Distinguished Name in LDAP format. This is a user-only option.

DEREF <when>
Specifies how alias dereferencing is done when performing a search. The <when> can be specified as one of the following keywords:

never
Aliases are never dereferenced. This is the default.

searching
Aliases are dereferenced in subordinates of the base object, but not in locating the base object of the search.

finding
Aliases are only dereferenced when locating the base object of the search.

always
Aliases are dereferenced both in searching and in locating the base object of the search.

HOST <name[:port] …>
Specifies the name(s) of an LDAP server(s) to which the LDAP library should connect. Each server’s name can be specified as a domain-style name or an IP address and optionally followed by a ‘:’ and the port number the ldap server is listening on. A space separated list of hosts may be provided. HOST is deprecated in favor of URI.

KEEPALIVE_IDLE
Sets/gets the number of seconds a connection needs to remain idle before TCP starts sending keepalive probes. Linux only.

KEEPALIVE_PROBES
Sets/gets the maximum number of keepalive probes TCP should send before dropping the connection. Linux only.

KEEPALIVE_INTERVAL
Sets/gets the interval in seconds between individual keepalive probes. Linux only.

NETWORK_TIMEOUT <integer>
Specifies the timeout (in seconds) after which the poll(2)/select(2) following a connect(2) returns in case of no activity.

PORT <port>
Specifies the default port used when connecting to LDAP servers(s). The port may be specified as a number. PORT is deprecated in favor of URI.

REFERRALS <on/true/yes/off/false/no>
Specifies if the client should automatically follow referrals returned by LDAP servers. The default is on. Note that the command line tools ldapsearch(1) &co always override this option.

SIZELIMIT <integer>
Specifies a size limit (number of entries) to use when performing searches. The number should be a non-negative integer. SIZELIMIT of zero (0) specifies a request for unlimited search size. Please note that the server may still apply any server-side limit on the amount of entries that can be returned by a search operation.

SOCKET_BIND_ADDRESSES <IP>
Specifies the source bind IP to be used for connecting to target LDAP server. Multiple IP addresses must be space separated. Only one valid IPv4 address and/or one valid IPv6 address are allowed in the list.

TIMELIMIT <integer>
Specifies a time limit (in seconds) to use when performing searches. The number should be a non-negative integer. TIMELIMIT of zero (0) specifies unlimited search time to be used. Please note that the server may still apply any server-side limit on the duration of a search operation.

VERSION {2|3}
Specifies what version of the LDAP protocol should be used.

TIMEOUT <integer>
Specifies a timeout (in seconds) after which calls to synchronous LDAP APIs will abort if no response is received. Also used for any ldap_result(3) calls where a NULL timeout parameter is supplied.

SASL OPTIONS

If OpenLDAP is built with Simple Authentication and Security Layer support, there are more options you can specify.

SASL_MECH <mechanism>
Specifies the SASL mechanism to use.

SASL_REALM <realm>
Specifies the SASL realm.

SASL_AUTHCID <authcid>
Specifies the authentication identity. This is a user-only option.

SASL_AUTHZID <authcid>
Specifies the proxy authorization identity. This is a user-only option.

SASL_SECPROPS <properties>
Specifies Cyrus SASL security properties. The <properties> can be specified as a comma-separated list of the following:

none
(without any other properties) causes the properties defaults (“noanonymous,noplain”) to be cleared.

noplain
disables mechanisms susceptible to simple passive attacks.

noactive
disables mechanisms susceptible to active attacks.

nodict
disables mechanisms susceptible to passive dictionary attacks.

noanonymous
disables mechanisms which support anonymous login.

forwardsec
requires forward secrecy between sessions.

passcred
requires mechanisms which pass client credentials (and allows mechanisms which can pass credentials to do so).

minssf=<factor>
specifies the minimum acceptable security strength factor as an integer approximate to effective key length used for encryption. 0 (zero) implies no protection, 1 implies integrity protection only, 128 allows RC4, Blowfish and other similar ciphers, 256 will require modern ciphers. The default is 0.

maxssf=<factor>
specifies the maximum acceptable security strength factor as an integer (see minssf description). The default is INT_MAX.

maxbufsize=<factor>
specifies the maximum security layer receive buffer size allowed. 0 disables security layers. The default is 65536.

SASL_NOCANON <on/true/yes/off/false/no>
Do not perform reverse DNS lookups to canonicalize SASL host names. The default is off.

SASL_CBINDING <none/tls-unique/tls-endpoint>
The channel-binding type to use, see also LDAP_OPT_X_SASL_CBINDING. The default is none.

GSSAPI OPTIONS

If OpenLDAP is built with Generic Security Services Application Programming Interface support, there are more options you can specify.

GSSAPI_SIGN <on/true/yes/off/false/no>
Specifies if GSSAPI signing (GSS_C_INTEG_FLAG) should be used. The default is off.

GSSAPI_ENCRYPT <on/true/yes/off/false/no>
Specifies if GSSAPI encryption (GSS_C_INTEG_FLAG and GSS_C_CONF_FLAG) should be used. The default is off.

GSSAPI_ALLOW_REMOTE_PRINCIPAL <on/true/yes/off/false/no>
Specifies if GSSAPI based authentication should try to form the target principal name out of the ldapServiceName or dnsHostName attribute of the targets RootDSE entry. The default is off.

TLS OPTIONS

If OpenLDAP is built with Transport Layer Security support, there are more options you can specify. These options are used when an ldaps:// URI is selected (by default or otherwise) or when the application negotiates TLS by issuing the LDAP StartTLS operation.

TLS_CACERT <filename>
Specifies the file that contains certificates for all of the Certificate Authorities the client will recognize.

TLS_CACERTDIR <path>
Specifies the path of a directory that contains Certificate Authority certificates in separate individual files. The TLS_CACERT is always used before TLS_CACERTDIR.

TLS_CERT <filename>
Specifies the file that contains the client certificate. This is a user-only option.

TLS_ECNAME <name>
Specify the name of the curve(s) to use for Elliptic curve Diffie-Hellman ephemeral key exchange. This option is only used for OpenSSL. This option is not used with GnuTLS; the curves may be chosen in the GnuTLS ciphersuite specification.

TLS_KEY <filename>
Specifies the file that contains the private key that matches the certificate stored in the TLS_CERT file. Currently, the private key must not be protected with a password, so it is of critical importance that the key file is protected carefully. This is a user-only option.

TLS_CIPHER_SUITE <cipher-suite-spec>
Specifies acceptable cipher suite and preference order. <cipher-suite-spec> should be a cipher specification for the TLS library in use (OpenSSL or GnuTLS). Example:

OpenSSL:
TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv2
GnuTLS:
TLS_CIPHER_SUITE SECURE256:!AES-128-CBC

To check what ciphers a given spec selects in OpenSSL, use:

	openssl ciphers -v <cipher-suite-spec>

With GnuTLS the available specs can be found in the manual page of gnutls-cli(1) (see the description of the option –priority).

In older versions of GnuTLS, where gnutls-cli does not support the option –priority, you can obtain the — more limited — list of ciphers by calling:

	gnutls-cli -l

TLS_PROTOCOL_MIN <major>[.<minor>]
Specifies minimum SSL/TLS protocol version that will be negotiated. If the server doesn’t support at least that version, the SSL handshake will fail. To require TLS 1.x or higher, set this option to 3.(x+1), e.g.,

	TLS_PROTOCOL_MIN 3.2

would require TLS 1.1. Specifying a minimum that is higher than that supported by the OpenLDAP implementation will result in it requiring the highest level that it does support. This parameter is ignored with GnuTLS. On Debian openldap is linked against GnuTLS.

TLS_RANDFILE <filename>
Specifies the file to obtain random bits from when /dev/[u]random is not available. Generally set to the name of the EGD/PRNGD socket. The environment variable RANDFILE can also be used to specify the filename. This parameter is ignored with GnuTLS. On Debian openldap is linked against GnuTLS.

TLS_REQCERT <level>
Specifies what checks to perform on server certificates in a TLS session. The <level> can be specified as one of the following keywords:

never
The client will not request or check any server certificate.

allow
The server certificate is requested. If a bad certificate is provided, it will be ignored and the session proceeds normally.

try
The server certificate is requested. If a bad certificate is provided, the session is immediately terminated.

demand | hard
These keywords are equivalent and the same as try. This is the default setting.

TLS_REQSAN <level>
Specifies what checks to perform on the subjectAlternativeName (SAN) extensions in a server certificate when validating the certificate name against the specified hostname of the server. The <level> can be specified as one of the following keywords:

never
The client will not check any SAN in the certificate.

allow
The SAN is checked against the specified hostname. If a SAN is present but none match the specified hostname, the SANs are ignored and the usual check against the certificate DN is used. This is the default setting.

try
The SAN is checked against the specified hostname. If no SAN is present in the server certificate, the usual check against the certificate DN is used. If a SAN is present but doesn’t match the specified hostname, the session is immediately terminated. This setting may be preferred when a mix of certs with and without SANs are in use.

demand | hard
These keywords are equivalent. The SAN is checked against the specified hostname. If no SAN is present in the server certificate, or no SANs match, the session is immediately terminated. This setting should be used when only certificates with SANs are in use.

TLS_CRLCHECK <level>
Specifies if the Certificate Revocation List (CRL) of the CA should be used to verify if the server certificates have not been revoked. This requires TLS_CACERTDIR parameter to be set. This parameter is ignored with GnuTLS. On Debian openldap is linked against GnuTLS. <level> can be specified as one of the following keywords:

none
No CRL checks are performed

peer
Check the CRL of the peer certificate

all
Check the CRL for a whole certificate chain

TLS_CRLFILE <filename>
Specifies the file containing a Certificate Revocation List to be used to verify if the server certificates have not been revoked. This parameter is only supported with GnuTLS.

ENVIRONMENT VARIABLES

LDAPNOINIT
disable all defaulting

LDAPCONF
path of a configuration file

LDAPRC
basename of ldaprc file in $HOME or $CWD

LDAP<option-name>
Set <option-name> as from ldap.conf

FILES

/etc/ldap/ldap.conf
system-wide ldap configuration file

$HOME/ldaprc, $HOME/.ldaprc
user ldap configuration file

$CWD/ldaprc
local ldap configuration file

AUTHOR

Kurt Zeilenga, The OpenLDAP Project

ACKNOWLEDGEMENTS

OpenLDAP Software is developed and maintained by The OpenLDAP Project <http://www.openldap.org/>. OpenLDAP Software is derived from the University of Michigan LDAP 3.3 Release.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

4 - Linux cli command proc_diskstats

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_diskstats and provides detailed information about the command proc_diskstats, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_diskstats.

NAME 🖥️ proc_diskstats 🖥️

disk I/O statistics

DESCRIPTION

/proc/diskstats (since Linux 2.5.69)
This file contains disk I/O statistics for each disk device. See the Linux kernel source file Documentation/admin-guide/iostats.rst (or Documentation/iostats.txt before Linux 5.3) for further information.

5 - Linux cli command sepermit.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command sepermit.conf and provides detailed information about the command sepermit.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the sepermit.conf.

NAME 🖥️ sepermit.conf 🖥️

configuration file for the pam_sepermit module

DESCRIPTION

The lines of the configuration file have the following syntax:

<user>[:<option>:<option>…]

The user can be specified in the following manner:

·
a username

·
a groupname, with @group syntax. This should not be confused with netgroups.

·
a SELinux user name with %seuser syntax.

The recognized options are:

exclusive

Only single login session will be allowed for the user and the users processes will be killed on logout.

ignore

The module will never return PAM_SUCCESS status for the user. It will return PAM_IGNORE if SELinux is in the enforcing mode, and PAM_AUTH_ERR otherwise. It is useful if you want to support passwordless guest users and other confined users with passwords simultaneously.

The lines which start with # character are comments and are ignored.

EXAMPLES

These are some example lines which might be specified in /etc/security/sepermit.conf.

%guest_u:exclusive %staff_u:ignore %user_u:ignore

AUTHOR

pam_sepermit and this manual page were written by Tomas Mraz <[email protected]>

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

6 - Linux cli command moduli

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command moduli and provides detailed information about the command moduli, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the moduli.

The

file contains prime numbers and generators for use by

in the Diffie-Hellman Group Exchange key exchange method.

New moduli may be generated with

using a two-step process. An initial

pass, using

calculates numbers that are likely to be useful. A second

pass, using

provides a high degree of assurance that the numbers are prime and are safe for use in Diffie-Hellman operations by

This

format is used as the output from each pass.

The file consists of newline-separated records, one per modulus, containing seven space-separated fields. These fields are as follows:

The time that the modulus was last processed as YYYYMMDDHHMMSS.

Decimal number specifying the internal structure of the prime modulus. Supported types are:

Unknown, not tested.

“Safe” prime; (p-1)/2 is also prime.

Sophie Germain; 2p+1 is also prime.

Moduli candidates initially produced by

are Sophie Germain primes (type 4). Further primality testing with

produces safe prime moduli (type 2) that are ready for use in

Other types are not used by OpenSSH.

Decimal number indicating the type of primality tests that the number has been subjected to represented as a bitmask of the following values:

Not tested.

Composite number – not prime.

Sieve of Eratosthenes.

Probabilistic Miller-Rabin primality tests.

The

moduli candidate generation uses the Sieve of Eratosthenes (flag 0x02). Subsequent

primality tests are Miller-Rabin tests (flag 0x04).

Decimal number indicating the number of primality trials that have been performed on the modulus.

Decimal number indicating the size of the prime in bits.

The recommended generator for use with this modulus (hexadecimal).

The modulus itself in hexadecimal.

When performing Diffie-Hellman Group Exchange,

first estimates the size of the modulus required to produce enough Diffie-Hellman output to sufficiently key the selected symmetric cipher.

then randomly selects a modulus from

that best meets the size requirement.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

7 - Linux cli command extension-release

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command extension-release and provides detailed information about the command extension-release, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the extension-release.

NAME 🖥️ extension-release 🖥️

release, initrd-release, extension-release - Operating system identification

SYNOPSIS

/etc/os-release

/usr/lib/os-release

/etc/initrd-release

/usr/lib/extension-release.d/extension-release.IMAGE

DESCRIPTION

The /etc/os-release and /usr/lib/os-release files contain operating system identification data.

The format of os-release is a newline-separated list of environment-like shell-compatible variable assignments. It is possible to source the configuration from Bourne shell scripts, however, beyond mere variable assignments, no shell features are supported (this means variable expansion is explicitly not supported), allowing applications to read the file without implementing a shell compatible execution engine. Variable assignment values must be enclosed in double or single quotes if they include spaces, semicolons or other special characters outside of A–Z, a–z, 0–9. (Assignments that do not include these special characters may be enclosed in quotes too, but this is optional.) Shell special characters ("$", quotes, backslash, backtick) must be escaped with backslashes, following shell style. All strings should be in UTF-8 encoding, and non-printable characters should not be used. Concatenation of multiple individually quoted strings is not supported. Lines beginning with “#” are treated as comments. Blank lines are permitted and ignored.

The file /etc/os-release takes precedence over /usr/lib/os-release. Applications should check for the former, and exclusively use its data if it exists, and only fall back to /usr/lib/os-release if it is missing. Applications should not read data from both files at the same time. /usr/lib/os-release is the recommended place to store OS release information as part of vendor trees. /etc/os-release should be a relative symlink to /usr/lib/os-release, to provide compatibility with applications only looking at /etc/. A relative symlink instead of an absolute symlink is necessary to avoid breaking the link in a chroot or initrd environment.

os-release contains data that is defined by the operating system vendor and should generally not be changed by the administrator.

As this file only encodes names and identifiers it should not be localized.

The /etc/os-release and /usr/lib/os-release files might be symlinks to other files, but it is important that the file is available from earliest boot on, and hence must be located on the root file system.

os-release must not contain repeating keys. Nevertheless, readers should pick the entries later in the file in case of repeats, similarly to how a shell sourcing the file would. A reader may warn about repeating entries.

For a longer rationale for os-release please refer to the Announcement of /etc/os-release[1].

/etc/initrd-release

In the initrd[2], /etc/initrd-release plays the same role as os-release in the main system. Additionally, the presence of that file means that the system is in the initrd phase. /etc/os-release should be symlinked to /etc/initrd-release (or vice versa), so programs that only look for /etc/os-release (as described above) work correctly.

The rest of this document that talks about os-release should be understood to apply to initrd-release too.

/usr/lib/extension-release.d/extension-release.IMAGE

/usr/lib/extension-release.d/extension-release.IMAGE plays the same role for extension images as os-release for the main system, and follows the syntax and rules as described in the Portable Services[3] page. The purpose of this file is to identify the extension and to allow the operating system to verify that the extension image matches the base OS. This is typically implemented by checking that the ID= options match, and either SYSEXT_LEVEL= exists and matches too, or if it is not present, VERSION_ID= exists and matches. This ensures ABI/API compatibility between the layers and prevents merging of an incompatible image in an overlay.

In order to identify the extension image itself, the same fields defined below can be added to the extension-release file with a SYSEXT_ prefix (to disambiguate from fields used to match on the base image). E.g.: SYSEXT_ID=myext, SYSEXT_VERSION_ID=1.2.3.

In the extension-release.IMAGE filename, the IMAGE part must exactly match the file name of the containing image with the suffix removed. In case it is not possible to guarantee that an image file name is stable and doesnt change between the build and the deployment phases, it is possible to relax this check: if exactly one file whose name matches “extension-release.*” is present in this directory, and the file is tagged with a user.extension-release.strict xattr(7) set to the string “0”, it will be used instead.

The rest of this document that talks about os-release should be understood to apply to extension-release too.

OPTIONS

The following OS identifications parameters may be set using os-release:

General information identifying the operating system

NAME=

A string identifying the operating system, without a version component, and suitable for presentation to the user. If not set, a default of “NAME=Linux” may be used.
Examples: “NAME=Fedora”, “NAME=“Debian GNU/Linux””.

ID=

A lower-case string (no spaces or other characters outside of 0–9, a–z, “.”, “_” and “-”) identifying the operating system, excluding any version information and suitable for processing by scripts or usage in generated filenames. If not set, a default of “ID=linux” may be used. Note that even though this string may not include characters that require shell quoting, quoting may nevertheless be used.
Examples: “ID=fedora”, “ID=debian”.

ID_LIKE=

A space-separated list of operating system identifiers in the same syntax as the ID= setting. It should list identifiers of operating systems that are closely related to the local operating system in regards to packaging and programming interfaces, for example listing one or more OS identifiers the local OS is a derivative from. An OS should generally only list other OS identifiers it itself is a derivative of, and not any OSes that are derived from it, though symmetric relationships are possible. Build scripts and similar should check this variable if they need to identify the local operating system and the value of ID= is not recognized. Operating systems should be listed in order of how closely the local operating system relates to the listed ones, starting with the closest. This field is optional.
Examples: for an operating system with “ID=centos”, an assignment of “ID_LIKE=“rhel fedora”” would be appropriate. For an operating system with “ID=ubuntu”, an assignment of “ID_LIKE=debian” is appropriate.

PRETTY_NAME=

A pretty operating system name in a format suitable for presentation to the user. May or may not contain a release code name or OS version of some kind, as suitable. If not set, a default of “PRETTY_NAME=“Linux”” may be used
Example: “PRETTY_NAME=“Fedora 17 (Beefy Miracle)””.

CPE_NAME=

A CPE name for the operating system, in URI binding syntax, following the Common Platform Enumeration Specification[4] as proposed by the NIST. This field is optional.
Example: “CPE_NAME=“cpe:/o:fedoraproject:fedora:17"”

VARIANT=

A string identifying a specific variant or edition of the operating system suitable for presentation to the user. This field may be used to inform the user that the configuration of this system is subject to a specific divergent set of rules or default configuration settings. This field is optional and may not be implemented on all systems.
Examples: “VARIANT=“Server Edition””, “VARIANT=“Smart Refrigerator Edition””.
Note: this field is for display purposes only. The VARIANT_ID field should be used for making programmatic decisions.
Added in version 220.

VARIANT_ID=

A lower-case string (no spaces or other characters outside of 0–9, a–z, “.”, “_” and “-”), identifying a specific variant or edition of the operating system. This may be interpreted by other packages in order to determine a divergent default configuration. This field is optional and may not be implemented on all systems.
Examples: “VARIANT_ID=server”, “VARIANT_ID=embedded”.
Added in version 220.

Information about the version of the operating system

VERSION=

A string identifying the operating system version, excluding any OS name information, possibly including a release code name, and suitable for presentation to the user. This field is optional.
Examples: “VERSION=17”, “VERSION=“17 (Beefy Miracle)””.

VERSION_ID=

A lower-case string (mostly numeric, no spaces or other characters outside of 0–9, a–z, “.”, “_” and “-”) identifying the operating system version, excluding any OS name information or release code name, and suitable for processing by scripts or usage in generated filenames. This field is optional.
Examples: “VERSION_ID=17”, “VERSION_ID=11.04”.

VERSION_CODENAME=

A lower-case string (no spaces or other characters outside of 0–9, a–z, “.”, “_” and “-”) identifying the operating system release code name, excluding any OS name information or release version, and suitable for processing by scripts or usage in generated filenames. This field is optional and may not be implemented on all systems.
Examples: “VERSION_CODENAME=buster”, “VERSION_CODENAME=xenial”.
Added in version 231.

BUILD_ID=

A string uniquely identifying the system image originally used as the installation base. In most cases, VERSION_ID or IMAGE_ID+IMAGE_VERSION are updated when the entire system image is replaced during an update. BUILD_ID may be used in distributions where the original installation image version is important: VERSION_ID would change during incremental system updates, but BUILD_ID would not. This field is optional.
Examples: “BUILD_ID=“2013-03-20.3"”, “BUILD_ID=201303203”.
Added in version 200.

IMAGE_ID=

A lower-case string (no spaces or other characters outside of 0–9, a–z, “.”, “_” and “-”), identifying a specific image of the operating system. This is supposed to be used for environments where OS images are prepared, built, shipped and updated as comprehensive, consistent OS images. This field is optional and may not be implemented on all systems, in particularly not on those that are not managed via images but put together and updated from individual packages and on the local system.
Examples: “IMAGE_ID=vendorx-cashier-system”, “IMAGE_ID=netbook-image”.
Added in version 249.

IMAGE_VERSION=

A lower-case string (mostly numeric, no spaces or other characters outside of 0–9, a–z, “.”, “_” and “-”) identifying the OS image version. This is supposed to be used together with IMAGE_ID described above, to discern different versions of the same image.
Examples: “IMAGE_VERSION=33”, “IMAGE_VERSION=47.1rc1”.
Added in version 249.

To summarize: if the image updates are built and shipped as comprehensive units, IMAGE_ID+IMAGE_VERSION is the best fit. Otherwise, if updates eventually completely replace previously installed contents, as in a typical binary distribution, VERSION_ID should be used to identify major releases of the operating system. BUILD_ID may be used instead or in addition to VERSION_ID when the original system image version is important.

Presentation information and links

HOME_URL=, DOCUMENTATION_URL=, SUPPORT_URL=, BUG_REPORT_URL=, PRIVACY_POLICY_URL=

Links to resources on the Internet related to the operating system. HOME_URL= should refer to the homepage of the operating system, or alternatively some homepage of the specific version of the operating system. DOCUMENTATION_URL= should refer to the main documentation page for this operating system. SUPPORT_URL= should refer to the main support page for the operating system, if there is any. This is primarily intended for operating systems which vendors provide support for. BUG_REPORT_URL= should refer to the main bug reporting page for the operating system, if there is any. This is primarily intended for operating systems that rely on community QA. PRIVACY_POLICY_URL= should refer to the main privacy policy page for the operating system, if there is any. These settings are optional, and providing only some of these settings is common. These URLs are intended to be exposed in “About this system” UIs behind links with captions such as “About this Operating System”, “Obtain Support”, “Report a Bug”, or “Privacy Policy”. The values should be in RFC3986 format[5], and should be “http:” or “https:” URLs, and possibly “mailto:” or “tel:”. Only one URL shall be listed in each setting. If multiple resources need to be referenced, it is recommended to provide an online landing page linking all available resources.
Examples: “HOME_URL=“https://fedoraproject.org/"", “BUG_REPORT_URL=“https://bugzilla.redhat.com/"".

SUPPORT_END=

The date at which support for this version of the OS ends. (What exactly “lack of support” means varies between vendors, but generally users should assume that updates, including security fixes, will not be provided.) The value is a date in the ISO 8601 format “YYYY-MM-DD”, and specifies the first day on which support is not provided.
For example, “SUPPORT_END=2001-01-01” means that the system was supported until the end of the last day of the previous millennium.
Added in version 252.

LOGO=

A string, specifying the name of an icon as defined by freedesktop.org Icon Theme Specification[6]. This can be used by graphical applications to display an operating systems or distributors logo. This field is optional and may not necessarily be implemented on all systems.
Examples: “LOGO=fedora-logo”, “LOGO=distributor-logo-opensuse”
Added in version 240.

ANSI_COLOR=

A suggested presentation color when showing the OS name on the console. This should be specified as string suitable for inclusion in the ESC [ m ANSI/ECMA-48 escape code for setting graphical rendition. This field is optional.
Examples: “ANSI_COLOR=“0;31"” for red, “ANSI_COLOR=“1;34"” for light blue, or “ANSI_COLOR=“0;38;2;60;110;180"” for Fedora blue.

VENDOR_NAME=

The name of the OS vendor. This is the name of the organization or company which produces the OS. This field is optional.
This name is intended to be exposed in “About this system” UIs or software update UIs when needed to distinguish the OS vendor from the OS itself. It is intended to be human readable.
Examples: “VENDOR_NAME=“Fedora Project”” for Fedora Linux, “VENDOR_NAME=“Canonical”” for Ubuntu.
Added in version 254.

VENDOR_URL=

The homepage of the OS vendor. This field is optional. The VENDOR_NAME= field should be set if this one is, although clients must be robust against either field not being set.
The value should be in RFC3986 format[5], and should be “http:” or “https:” URLs. Only one URL shall be listed in the setting.
Examples: “VENDOR_URL=“https://fedoraproject.org/"", “VENDOR_URL=“https://canonical.com/"".
Added in version 254.

Distribution-level defaults and metadata

DEFAULT_HOSTNAME=

A string specifying the hostname if hostname(5) is not present and no other configuration source specifies the hostname. Must be either a single DNS label (a string composed of 7-bit ASCII lower-case characters and no spaces or dots, limited to the format allowed for DNS domain name labels), or a sequence of such labels separated by single dots that forms a valid DNS FQDN. The hostname must be at most 64 characters, which is a Linux limitation (DNS allows longer names).
See org.freedesktop.hostname1(5) for a description of how systemd-hostnamed.service(8) determines the fallback hostname.
Added in version 248.

ARCHITECTURE=

A string that specifies which CPU architecture the userspace binaries require. The architecture identifiers are the same as for ConditionArchitecture= described in systemd.unit(5). The field is optional and should only be used when just single architecture is supported. It may provide redundant information when used in a GPT partition with a GUID type that already encodes the architecture. If this is not the case, the architecture should be specified in e.g., an extension image, to prevent an incompatible host from loading it.
Added in version 252.

SYSEXT_LEVEL=

A lower-case string (mostly numeric, no spaces or other characters outside of 0–9, a–z, “.”, “_” and “-”) identifying the operating system extensions support level, to indicate which extension images are supported. See /usr/lib/extension-release.d/extension-release.IMAGE, initrd[2] and systemd-sysext(8)) for more information.
Examples: “SYSEXT_LEVEL=2”, “SYSEXT_LEVEL=15.14”.
Added in version 248.

CONFEXT_LEVEL=

Semantically the same as SYSEXT_LEVEL= but for confext images. See /etc/extension-release.d/extension-release.IMAGE for more information.
Examples: “CONFEXT_LEVEL=2”, “CONFEXT_LEVEL=15.14”.
Added in version 254.

SYSEXT_SCOPE=

Takes a space-separated list of one or more of the strings “system”, “initrd” and “portable”. This field is only supported in extension-release.d/ files and indicates what environments the system extension is applicable to: i.e. to regular systems, to initrds, or to portable service images. If unspecified, “SYSEXT_SCOPE=system portable” is implied, i.e. any system extension without this field is applicable to regular systems and to portable service environments, but not to initrd environments.
Added in version 250.

CONFEXT_SCOPE=

Semantically the same as SYSEXT_SCOPE= but for confext images.
Added in version 254.

PORTABLE_PREFIXES=

Takes a space-separated list of one or more valid prefix match strings for the Portable Services[3] logic. This field serves two purposes: it is informational, identifying portable service images as such (and thus allowing them to be distinguished from other OS images, such as bootable system images). It is also used when a portable service image is attached: the specified or implied portable service prefix is checked against the list specified here, to enforce restrictions how images may be attached to a system.
Added in version 250.

Notes

If you are using this file to determine the OS or a specific version of it, use the ID and VERSION_ID fields, possibly with ID_LIKE as fallback for ID. When looking for an OS identification string for presentation to the user use the PRETTY_NAME field.

Note that operating system vendors may choose not to provide version information, for example to accommodate for rolling releases. In this case, VERSION and VERSION_ID may be unset. Applications should not rely on these fields to be set.

Operating system vendors may extend the file format and introduce new fields. It is highly recommended to prefix new fields with an OS specific name in order to avoid name clashes. Applications reading this file must ignore unknown fields.

Example: “DEBIAN_BTS=“debbugs://bugs.debian.org/””.

Container and sandbox runtime managers may make the hosts identification data available to applications by providing the hosts /etc/os-release (if available, otherwise /usr/lib/os-release as a fallback) as /run/host/os-release.

EXAMPLES

Example 1. os-release file for Fedora Workstation

NAME=Fedora VERSION=“32 (Workstation Edition)” ID=fedora VERSION_ID=32 PRETTY_NAME=“Fedora 32 (Workstation Edition)” ANSI_COLOR=“0;38;2;60;110;180” LOGO=fedora-logo-icon CPE_NAME=“cpe:/o:fedoraproject:fedora:32” HOME_URL=“https://fedoraproject.org/" DOCUMENTATION_URL=“https://docs.fedoraproject.org/en-US/fedora/f32/system-administrators-guide/" SUPPORT_URL=“https://fedoraproject.org/wiki/Communicating_and_getting_help" BUG_REPORT_URL=“https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT=“Fedora” REDHAT_BUGZILLA_PRODUCT_VERSION=32 REDHAT_SUPPORT_PRODUCT=“Fedora” REDHAT_SUPPORT_PRODUCT_VERSION=32 PRIVACY_POLICY_URL=“https://fedoraproject.org/wiki/Legal:PrivacyPolicy" VARIANT=“Workstation Edition” VARIANT_ID=workstation

Example 2. extension-release file for an extension for Fedora Workstation 32

ID=fedora VERSION_ID=32

Example 3. Reading os-release in sh(1)

#!/bin/sh -eu # SPDX-License-Identifier: MIT-0

test -e /etc/os-release && os_release=/etc/os-release || os_release=/usr/lib/os-release
. "${os_release}"

echo "Running on ${PRETTY_NAME:-Linux}"

if [ "${ID:-linux}" = "debian" ] || [ "${ID_LIKE#*debian*}" != "${ID_LIKE}" ]; then
    echo "Looks like Debian!"
fi

Example 4. Reading os-release in python(1) (versions >= 3.10)

#!/usr/bin/python # SPDX-License-Identifier: MIT-0

import platform
os_release = platform.freedesktop_os_release()

pretty_name = os_release.get(PRETTY_NAME, Linux)
print(fRunning on {pretty_name!r})

if fedora in [os_release.get(ID, linux),
                *os_release.get(ID_LIKE, ).split()]:
    print(Looks like Fedora!)

See docs for platform.freedesktop_os_release[7] for more details.

Example 5. Reading os-release in python(1) (any version)

#!/usr/bin/python # SPDX-License-Identifier: MIT-0

import ast
import re
import sys

def read_os_release():
    try:
        filename = /etc/os-release
        f = open(filename)
    except FileNotFoundError:
        filename = /usr/lib/os-release
        f = open(filename)

    for line_number, line in enumerate(f, start=1):
        line = line.rstrip()
        if not line or line.startswith(#):
            continue
        m = re.match(r([A-Z][A-Z_0-9]+)=(.*), line)
        if m:
            name, val = m.groups()
            if val and val[0] in "\:
                val = ast.literal_eval(val)
            yield name, val
        else:
            print(f{filename}:{line_number}: bad line {line!r},
                  file=sys.stderr)

os_release = dict(read_os_release())

pretty_name = os_release.get(PRETTY_NAME, Linux)
print(fRunning on {pretty_name!r})

if debian in [os_release.get(ID, linux),
                *os_release.get(ID_LIKE, ).split()]:
    print(Looks like Debian!)

Note that the above version that uses the built-in implementation is preferred in most cases, and the open-coded version here is provided for reference.

NOTES

Announcement of /etc/os-release

https://0pointer.de/blog/projects/os-release

initrd

https://docs.kernel.org/admin-guide/initrd.html

Portable Services

https://systemd.io/PORTABLE_SERVICES

Common Platform Enumeration Specification

http://scap.nist.gov/specifications/cpe/

RFC3986 format

https://tools.ietf.org/html/rfc3986

freedesktop.org Icon Theme Specification

https://standards.freedesktop.org/icon-theme-spec/latest

platform.freedesktop_os_release

https://docs.python.org/3/library/platform.html#platform.freedesktop_os_release

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

8 - Linux cli command systemd.mount

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.mount and provides detailed information about the command systemd.mount, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.mount.

NAME 🖥️ systemd.mount 🖥️

Mount unit configuration

SYNOPSIS

mount.mount

DESCRIPTION

A unit configuration file whose name ends in “.mount” encodes information about a file system mount point controlled and supervised by systemd.

This man page lists the configuration options specific to this unit type. See systemd.unit(5) for the common options of all unit configuration files. The common configuration items are configured in the generic [Unit] and [Install] sections. The mount specific configuration options are configured in the [Mount] section.

Additional options are listed in systemd.exec(5), which define the execution environment the mount(8) program is executed in, and in systemd.kill(5), which define the way the processes are terminated, and in systemd.resource-control(5), which configure resource control settings for the processes of the service.

Note that the options User= and Group= are not useful for mount units. systemd passes two parameters to mount(8); the values of What= and Where=. When invoked in this way, mount(8) does not read any options from /etc/fstab, and must be run as UID 0.

Mount units must be named after the mount point directories they control. Example: the mount point /home/lennart must be configured in a unit file home-lennart.mount. For details about the escaping logic used to convert a file system path to a unit name, see systemd.unit(5). Note that mount units cannot be templated, nor is possible to add multiple names to a mount unit by creating symlinks to its unit file.

Optionally, a mount unit may be accompanied by an automount unit, to allow on-demand or parallelized mounting. See systemd.automount(5).

Mount points created at runtime (independently of unit files or /etc/fstab) will be monitored by systemd and appear like any other mount unit in systemd. See /proc/self/mountinfo description in proc(5).

Some file systems have special semantics as API file systems for kernel-to-userspace and userspace-to-userspace interfaces. Some of them may not be changed via mount units, and cannot be disabled. For a longer discussion see API File Systems[1].

The systemd-mount(1) command allows creating .mount and .automount units dynamically and transiently from the command line.

AUTOMATIC DEPENDENCIES

Implicit Dependencies

The following dependencies are implicitly added:

·
If a mount unit is beneath another mount unit in the file system hierarchy, both a requirement dependency and an ordering dependency between both units are created automatically.

·
Block device backed file systems automatically gain Requires=, StopPropagatedFrom=, and After= type dependencies on the device unit encapsulating the block device (see x-systemd.device-bound= for details).

·
If traditional file system quota is enabled for a mount unit, automatic Wants= and Before= dependencies on systemd-quotacheck.service and quotaon.service are added.

·
Additional implicit dependencies may be added as result of execution and resource control parameters as documented in systemd.exec(5) and systemd.resource-control(5).

Default Dependencies

The following dependencies are added unless DefaultDependencies=no is set:

·
All mount units acquire automatic Before= and Conflicts= on umount.target in order to be stopped during shutdown.

·
Mount units referring to local file systems automatically gain an After= dependency on local-fs-pre.target, and a Before= dependency on local-fs.target unless one or more mount options among nofail, x-systemd.wanted-by=, and x-systemd.required-by= is set. See below for detailed information.
Additionally, an After= dependency on swap.target is added when the file system type is “tmpfs”.

·
Network mount units automatically acquire After= dependencies on remote-fs-pre.target, network.target, plus After= and Wants= dependencies on network-online.target, and a Before= dependency on remote-fs.target, unless one or more mount options among nofail, x-systemd.wanted-by=, and x-systemd.required-by= is set.

Mount units referring to local and network file systems are distinguished by their file system type specification. In some cases this is not sufficient (for example network block device based mounts, such as iSCSI), in which case _netdev may be added to the mount option string of the unit, which forces systemd to consider the mount unit a network mount.

FSTAB

Mount units may either be configured via unit files, or via /etc/fstab (see fstab(5) for details). Mounts listed in /etc/fstab will be converted into native units dynamically at boot and when the configuration of the system manager is reloaded. In general, configuring mount points through /etc/fstab is the preferred approach to manage mounts for humans. For tooling, writing mount units should be preferred over editing /etc/fstab. See systemd-fstab-generator(8) for details about the conversion from /etc/fstab to mount units.

The NFS mount option bg for NFS background mounts as documented in nfs(5) is detected by systemd-fstab-generator and the options are transformed so that systemd fulfills the job-control implications of that option. Specifically systemd-fstab-generator acts as though “x-systemd.mount-timeout=infinity,retry=10000” was prepended to the option list, and “fg,nofail” was appended. Depending on specific requirements, it may be appropriate to provide some of these options explicitly, or to make use of the “x-systemd.automount” option described below instead of using “bg”.

When reading /etc/fstab a few special mount options are understood by systemd which influence how dependencies are created for mount points. systemd will create a dependency of type Wants= or Requires= (see option nofail below), from either local-fs.target or remote-fs.target, depending whether the file system is local or remote.

x-systemd.requires=

Configures a Requires= and an After= dependency between the created mount unit and another systemd unit, such as a device or mount unit. The argument should be a unit name, or an absolute path to a device node or mount point. This option may be specified more than once. This option is particularly useful for mount point declarations that need an additional device to be around (such as an external journal device for journal file systems) or an additional mount to be in place (such as an overlay file system that merges multiple mount points). See After= and Requires= in systemd.unit(5) for details.
Note that this option always applies to the created mount unit only regardless whether x-systemd.automount has been specified.
Added in version 220.

x-systemd.before=, x-systemd.after=

In the created mount unit, configures a Before= or After= dependency on another systemd unit, such as a mount unit. The argument should be a unit name or an absolute path to a mount point. This option may be specified more than once. This option is particularly useful for mount point declarations with nofail option that are mounted asynchronously but need to be mounted before or after some unit start, for example, before local-fs.target unit. See Before= and After= in systemd.unit(5) for details.
Note that these options always apply to the created mount unit only regardless whether x-systemd.automount has been specified.
Added in version 233.

x-systemd.wanted-by=, x-systemd.required-by=

In the created mount unit, configures a WantedBy= or RequiredBy= dependency on another unit. This option may be specified more than once. If this is specified, the default dependencies (see above) other than umount.target on the created mount unit, e.g. local-fs.target, are not automatically created. Hence it is likely that some ordering dependencies need to be set up manually through x-systemd.before= and x-systemd.after=. See WantedBy= and RequiredBy= in systemd.unit(5) for details.
Added in version 245.

x-systemd.wants-mounts-for=, x-systemd.requires-mounts-for=

Configures a RequiresMountsFor= or WantsMountsFor= dependency between the created mount unit and other mount units. The argument must be an absolute path. This option may be specified more than once. See RequiresMountsFor= or WantsMountsFor= in systemd.unit(5) for details.
Added in version 220.

x-systemd.device-bound=

Takes a boolean argument. If true or no argument, a BindsTo= dependency on the backing device is set. If false, the mount unit is not stopped no matter whether the backing device is still present. This is useful when the file system is backed by volume managers. If not set, and the mount comes from unit fragments, i.e. generated from /etc/fstab by systemd-fstab-generator(8) or loaded from a manually configured mount unit, a combination of Requires= and StopPropagatedFrom= dependencies is set on the backing device. If doesnt, only Requires= is used.
Added in version 233.

x-systemd.automount

An automount unit will be created for the file system. See systemd.automount(5) for details.
Added in version 215.

x-systemd.idle-timeout=

Configures the idle timeout of the automount unit. See TimeoutIdleSec= in systemd.automount(5) for details.
Added in version 220.

x-systemd.device-timeout=

Configure how long systemd should wait for a device to show up before giving up on an entry from /etc/fstab. Specify a time in seconds or explicitly append a unit such as “s”, “min”, “h”, “ms”.
Note that this option can only be used in /etc/fstab, and will be ignored when part of the Options= setting in a unit file.
Added in version 215.

x-systemd.mount-timeout=

Configure how long systemd should wait for the mount command to finish before giving up on an entry from /etc/fstab. Specify a time in seconds or explicitly append a unit such as “s”, “min”, “h”, “ms”.
Note that this option can only be used in /etc/fstab, and will be ignored when part of the Options= setting in a unit file.
See TimeoutSec= below for details.
Added in version 233.

x-systemd.makefs

The file system will be initialized on the device. If the device is not “empty”, i.e. it contains any signature, the operation will be skipped. It is hence expected that this option remains set even after the device has been initialized.
Note that this option can only be used in /etc/fstab, and will be ignored when part of the Options= setting in a unit file.
See [email protected](8).
wipefs(8) may be used to remove any signatures from a block device to force x-systemd.makefs to reinitialize the device.
Added in version 236.

x-systemd.growfs

The file system will be grown to occupy the full block device. If the file system is already at maximum size, no action will be performed. It is hence expected that this option remains set even after the file system has been grown. Only certain file system types are supported, see [email protected](8) for details.
Note that this option can only be used in /etc/fstab, and will be ignored when part of the Options= setting in a unit file.
Added in version 236.

x-systemd.pcrfs

Measures file system identity information (mount point, type, label, UUID, partition label, partition UUID) into PCR 15 after the file system has been mounted. This ensures the [email protected](8) or systemd-pcrfs-root.service services are pulled in by the mount unit.
Note that this option can only be used in /etc/fstab, and will be ignored when part of the Options= setting in a unit file. It is also implied for the root and /usr/ partitions discovered by systemd-gpt-auto-generator(8).
Added in version 253.

x-systemd.rw-only

If a mount operation fails to mount the file system read-write, it normally tries mounting the file system read-only instead. This option disables that behaviour, and causes the mount to fail immediately instead. This option is translated into the ReadWriteOnly= setting in a unit file.
Added in version 246.

_netdev

Normally the file system type is used to determine if a mount is a “network mount”, i.e. if it should only be started after the network is available. Using this option overrides this detection and specifies that the mount requires network.
Network mount units are ordered between remote-fs-pre.target and remote-fs.target, instead of local-fs-pre.target and local-fs.target. They also pull in network-online.target and are ordered after it and network.target.
Added in version 235.

noauto, auto

With noauto, the mount unit will not be added as a dependency for local-fs.target or remote-fs.target. This means that it will not be mounted automatically during boot, unless it is pulled in by some other unit. The auto option has the opposite meaning and is the default.
Note that if x-systemd.automount (see above) is used, neither auto nor noauto have any effect. The matching automount unit will be added as a dependency to the appropriate target.
Added in version 215.

nofail

With nofail, this mount will be only wanted, not required, by local-fs.target or remote-fs.target. Moreover the mount unit is not ordered before these target units. This means that the boot will continue without waiting for the mount unit and regardless whether the mount point can be mounted successfully.
Added in version 215.

x-initrd.mount

An additional filesystem to be mounted in the initrd. See initrd-fs.target description in systemd.special(7). This is both an indicator to the initrd to mount this partition early and an indicator to the host to leave the partition mounted until final shutdown. Or in other words, if this flag is set it is assumed the mount shall be active during the entire regular runtime of the system, i.e. established before the initrd transitions into the host all the way until the host transitions to the final shutdown phase.
Added in version 215.

If a mount point is configured in both /etc/fstab and a unit file that is stored below /usr/, the former will take precedence. If the unit file is stored below /etc/, it will take precedence. This means: native unit files take precedence over traditional configuration files, but this is superseded by the rule that configuration in /etc/ will always take precedence over configuration in /usr/.

OPTIONS

Mount unit files may include [Unit] and [Install] sections, which are described in systemd.unit(5).

Mount unit files must include a [Mount] section, which carries information about the file system mount points it supervises. A number of options that may be used in this section are shared with other unit types. These options are documented in systemd.exec(5), systemd.kill(5) and systemd.resource-control(5). The options specific to the [Mount] section of mount units are the following:

What=

Takes an absolute path or a fstab-style identifier of a device node, file or other resource to mount. See mount(8) for details. If this refers to a device node, a dependency on the respective device unit is automatically created. (See systemd.device(5) for more information.) This option is mandatory. Note that the usual specifier expansion is applied to this setting, literal percent characters should hence be written as “%%”. If this mount is a bind mount and the specified path does not exist yet it is created as directory.

Where=

Takes an absolute path of a file or directory for the mount point; in particular, the destination cannot be a symbolic link. If the mount point does not exist at the time of mounting, it is created as either a directory or a file. The former is the usual case; the latter is done only if this mount is a bind mount and the source (What=) is not a directory. This string must be reflected in the unit filename. (See above.) This option is mandatory.

Type=

Takes a string for the file system type. See mount(8) for details. This setting is optional.
If the type is “overlay”, and “upperdir=” or “workdir=” are specified as options and they dont exist, they will be created.

Options=

Mount options to use when mounting. This takes a comma-separated list of options. This setting is optional. Note that the usual specifier expansion is applied to this setting, literal percent characters should hence be written as “%%”.

SloppyOptions=

Takes a boolean argument. If true, parsing of the options specified in Options= is relaxed, and unknown mount options are tolerated. This corresponds with mount(8)s -s switch. Defaults to off.
Added in version 215.

LazyUnmount=

Takes a boolean argument. If true, detach the filesystem from the filesystem hierarchy at time of the unmount operation, and clean up all references to the filesystem as soon as they are not busy anymore. This corresponds with umount(8)s -l switch. Defaults to off.
Added in version 232.

ReadWriteOnly=

Takes a boolean argument. If false, a mount point that shall be mounted read-write but cannot be mounted so is retried to be mounted read-only. If true the operation will fail immediately after the read-write mount attempt did not succeed. This corresponds with mount(8)s -w switch. Defaults to off.
Added in version 246.

ForceUnmount=

Takes a boolean argument. If true, force an unmount (in case of an unreachable NFS system). This corresponds with umount(8)s -f switch. Defaults to off.
Added in version 232.

DirectoryMode=

Directories of mount points (and any parent directories) are automatically created if needed. This option specifies the file system access mode used when creating these directories. Takes an access mode in octal notation. Defaults to 0755.

TimeoutSec=

Configures the time to wait for the mount command to finish. If a command does not exit within the configured time, the mount will be considered failed and be shut down again. All commands still running will be terminated forcibly via SIGTERM, and after another delay of this time with SIGKILL. (See KillMode= in systemd.kill(5).) Takes a unit-less value in seconds, or a time span value such as “5min 20s”. Pass 0 to disable the timeout logic. The default value is set from DefaultTimeoutStartSec= option in systemd-system.conf(5).

Check systemd.unit(5), systemd.exec(5), and systemd.kill(5) for more settings.

NOTES

API File Systems

https://systemd.io/API_FILE_SYSTEMS

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

9 - Linux cli command snmp_config

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command snmp_config and provides detailed information about the command snmp_config, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the snmp_config.

NAME 🖥️ snmp_config 🖥️

handling of Net-SNMP configuration files

DESCRIPTION

The Net-SNMP package uses various configuration files to configure its applications. This manual page merely describes the overall nature of them, so that the other manual pages don’t have to.

DIRECTORIES SEARCHED

First off, there are numerous places that configuration files can be found and read from. By default, the applications look for configuration files in the following 4 directories, in order: /etc/snmp, /usr/share/snmp, /usr/lib/x86_64-linux-gnu/snmp, and $HOME/.snmp. In each of these directories, it looks for files snmp.conf, snmpd.conf and/or snmptrapd.conf, as well as snmp.local.conf, snmpd.local.conf and/or snmptrapd.local.conf. *.local.conf are always read last. In this manner, there are 8 default places a configuration file can exist for any given configuration file type.

Additionally, the above default search path can be overridden by setting the environment variable SNMPCONFPATH to a colon-separated list of directories to search for. The path for the persistent data should be included when running applications that use persistent storage, such as snmpd.

Applications will read persistent configuration files in the following order of preference:

file in SNMP_PERSISTENT_FILE environment variable
directories in SNMPCONFPATH environment variable
directory defined by persistentDir snmp.conf variable
directory in SNMP_PERSISTENT_DIR environment variable
default /var/lib/snmp directory

Finally, applications will write persistent configuration files in the following order of preference:

file in SNMP_PERSISTENT_FILE environment variable
directory defined by persistentDir snmp.conf variable
directory in SNMP_PERSISTENT_DIR environment variable
default /var/lib/snmp directory

Note: When using SNMP_PERSISTENT_FILE, the filename should match the application name. For example, /var/net-snmp/snmpd.conf.

CONFIGURATION FILE TYPES

Each application may use multiple configuration files, which will configure various different aspects of the application. For instance, the SNMP agent (snmpd) knows how to understand configuration directives in both the snmpd.conf and the snmp.conf files. In fact, most applications understand how to read the contents of the snmp.conf files. Note, however, that configuration directives understood in one file may not be understood in another file. For further information, read the associated manual page with each configuration file type. Also, most of the applications support a -H switch on the command line that will list the configuration files it will look for and the directives in each one that it understands.

The snmp.conf configuration file is intended to be a application suite wide configuration file that supports directives that are useful for controlling the fundamental nature of all of the SNMP applications, such as how they all manipulate and parse the textual SNMP MIB files.

SWITCHING CONFIGURATION TYPES IN MID-FILE

It’s possible to switch in mid-file the configuration type that the parser is supposed to be reading. Since that sentence doesn’t make much sense, lets give you an example: say that you wanted to turn on packet dumping output for the agent by default, but you didn’t want to do that for the rest of the applications (ie, snmpget, snmpwalk, …). Normally to enable packet dumping in the configuration file you’d need to put a line like:

dumpPacket true

into the snmp.conf file. But, this would turn it on for all of the applications. So, instead, you can put the same line in the snmpd.conf file so that it only applies to the snmpd daemon. However, you need to tell the parser to expect this line. You do this by putting a special type specification token inside a [] set. In other words, inside your snmpd.conf file you could put the above snmp.conf directive by adding a line like so:

[snmp] dumpPacket true

This tells the parser to parse the above line as if it were inside a snmp.conf file instead of an snmpd.conf file. If you want to parse a bunch of lines rather than just one then you can make the context switch apply to the remainder of the file or until the next context switch directive by putting the special token on a line by itself:

make this file handle snmp.conf tokens:

[snmp]
dumpPacket true
logTimestamp true
# return to our original snmpd.conf tokens:
[snmpd]
rocommunity mypublic

The same approach can be used to set configuration directives for a particular client application (or group of applications). For example, any program that uses the ‘snmp_parse_args()’ call to handle command-line arguments (including the standard command-line tools shipped as part of the Net-SNMP distributions) will automatically read the config file ‘snmpapp.conf’. To set library-level settings for these applications (but not other more-specific tools), use configuration such as the following:

[snmp] defCommunity myCommunity

for a single directive, or

make this file handle snmp.conf tokens:

[snmp]
defCommunity myCommunity
defVersion   2c
# return to our original snmpapp.conf tokens:
[snmpapp]

for multiple settings. Similarly for any other application token (as passed to init_snmp()).

COMMENTS

Any lines beginning with the character ‘#’ in the configuration files are treated as a comment and are not parsed.

INCLUDING OTHER CONFIGURATION FILES

It is possible to include other configuration files for processing during normal configuration file processing.:

include site specific config

includeFile site.conf

This will load the specified configuration file. The
path to file must be either absolute, starting with '/',
or relative. The relative path is then relative to the directory
where the parent file with 'includeFile' directive resides.

The included file name does not need to have '.conf' suffix.

# include a all *.conf files in a directory
includeDir /etc/snmp/config.d

This will search specified directory for all files with '.conf'
suffix and process them as if they were included using includeFile
directive. The configuration files are not processed in any particular
order.

The specified directory must be absolute directory path.

API INTERFACE

Information about writing C code that makes use of this system in either the agent’s MIB modules or in applications can be found in the netsnmp_config_api(3) manual page.

10 - Linux cli command networkd.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command networkd.conf and provides detailed information about the command networkd.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the networkd.conf.

NAME 🖥️ networkd.conf 🖥️

Global Network configuration files

SYNOPSIS

/etc/systemd/networkd.conf

/run/systemd/networkd.conf

/usr/local/lib/systemd/networkd.conf

/usr/lib/systemd/networkd.conf

/etc/systemd/networkd.conf.d/*.conf

/run/systemd/networkd.conf.d/*.conf

/usr/local/lib/systemd/networkd.conf.d/*.conf

/usr/lib/systemd/networkd.conf.d/*.conf

DESCRIPTION

These configuration files control global network parameters.

CONFIGURATION DIRECTORIES AND PRECEDENCE

The default configuration is set during compilation, so configuration is only needed when it is necessary to deviate from those defaults. The main configuration file is loaded from one of the listed directories in order of priority, only the first file found is used: /etc/systemd/, /run/systemd/, /usr/local/lib/systemd/ [1], /usr/lib/systemd/. The vendor version of the file contains commented out entries showing the defaults as a guide to the administrator. Local overrides can also be created by creating drop-ins, as described below. The main configuration file can also be edited for this purpose (or a copy in /etc/ if its shipped under /usr/), however using drop-ins for local configuration is recommended over modifications to the main configuration file.

In addition to the main configuration file, drop-in configuration snippets are read from /usr/lib/systemd/*.conf.d/, /usr/local/lib/systemd/*.conf.d/, and /etc/systemd/*.conf.d/. Those drop-ins have higher precedence and override the main configuration file. Files in the *.conf.d/ configuration subdirectories are sorted by their filename in lexicographic order, regardless of in which of the subdirectories they reside. When multiple files specify the same option, for options which accept just a single value, the entry in the file sorted last takes precedence, and for options which accept a list of values, entries are collected as they occur in the sorted files.

When packages need to customize the configuration, they can install drop-ins under /usr/. Files in /etc/ are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages. Drop-ins have to be used to override package drop-ins, since the main configuration file has lower precedence. It is recommended to prefix all filenames in those subdirectories with a two-digit number and a dash, to simplify the ordering. This also defines a concept of drop-in priorities to allow OS vendors to ship drop-ins within a specific range lower than the range used by users. This should lower the risk of package drop-ins overriding accidentally drop-ins defined by users. It is recommended to use the range 10-40 for drop-ins in /usr/ and the range 60-90 for drop-ins in /etc/ and /run/, to make sure that local and transient drop-ins take priority over drop-ins shipped by the OS vendor.

To disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in the configuration directory in /etc/, with the same filename as the vendor configuration file.

[NETWORK] SECTION OPTIONS

The following options are available in the [Network] section:

SpeedMeter=

Takes a boolean. If set to yes, then systemd-networkd measures the traffic of each interface, and networkctl status INTERFACE shows the measured speed. Defaults to no.
Added in version 244.

SpeedMeterIntervalSec=

Specifies the time interval to calculate the traffic speed of each interface. If SpeedMeter=no, the value is ignored. Defaults to 10sec.
Added in version 244.

ManageForeignRoutingPolicyRules=

A boolean. When true, systemd-networkd will remove rules that are not configured in .network files (except for rules with protocol “kernel”). When false, it will not remove any foreign rules, keeping them even if they are not configured in a .network file. Defaults to yes.
Added in version 249.

ManageForeignRoutes=

A boolean. When true, systemd-networkd will remove routes that are not configured in .network files (except for routes with protocol “kernel”, “dhcp” when KeepConfiguration= is true or “dhcp”, and “static” when KeepConfiguration= is true or “static”). When false, it will not remove any foreign routes, keeping them even if they are not configured in a .network file. Defaults to yes.
Added in version 246.

ManageForeignNextHops=

A boolean. When true, systemd-networkd will remove nexthops that are not configured in .network files (except for routes with protocol “kernel”). When false, it will not remove any foreign nexthops, keeping them even if they are not configured in a .network file. Defaults to yes.
Added in version 256.

RouteTable=

Defines the route table name. Takes a whitespace-separated list of the pairs of route table name and number. The route table name and number in each pair are separated with a colon, i.e., “name:number”. The route table name must not be “default”, “main”, or “local”, as these route table names are predefined with route table number 253, 254, and 255, respectively. The route table number must be an integer in the range 1…4294967295, except for predefined numbers 253, 254, and 255. This setting can be specified multiple times. If an empty string is specified, then the list specified earlier are cleared. Defaults to unset.
Added in version 248.

IPv4Forwarding=

Configures IPv4 packet forwarding for the system. Takes a boolean value. This controls the net.ipv4.conf.default.forwarding and net.ipv4.conf.all.forwardingsysctl options. See IP Sysctl[2] for more details about the sysctl options. Defaults to unset and the sysctl options will not be changed.
Added in version 256.

IPv6Forwarding=

Configures IPv6 packet forwarding for the system. Takes a boolean value. This controls the net.ipv6.conf.default.forwarding and net.ipv6.conf.all.forwarding sysctl options. See IP Sysctl[2] for more details about the sysctl options. Defaults to unset and the sysctl options will not be changed.
Added in version 256.

IPv6PrivacyExtensions=

Specifies the default value for per-network IPv6PrivacyExtensions=. Takes a boolean or the special values “prefer-public” and “kernel”. See for details in systemd.network(5). Defaults to “no”.
Added in version 254.

UseDomains=

Specifies the network- and protocol-independent default value for the same settings in [IPv6AcceptRA], [DHCPv4], and [DHCPv6] sections below. Takes a boolean, or the special value route. See the same setting in systemd.network(5). Defaults to “no”.
Added in version 256.

[IPV6ACCEPTRA] SECTION OPTIONS

This section configures the default setting of the Neighbor Discovery. The following options are available in the [IPv6AcceptRA] section:

UseDomains=

Specifies the network-independent default value for the same setting in the [IPv6AcceptRA] section in systemd.network(5). Takes a boolean, or the special value route. When unspecified, the value specified in the [Network] section in networkd.conf(5), which defaults to “no”, will be used.
Added in version 256.

[DHCPV4] SECTION OPTIONS

This section configures the DHCP Unique Identifier (DUID) value used by DHCP protocol. DHCPv4 client protocol sends IAID and DUID to the DHCP server when acquiring a dynamic IPv4 address if ClientIdentifier=duid. IAID and DUID allows a DHCP server to uniquely identify the machine and the interface requesting a DHCP IP address. To configure IAID and ClientIdentifier, see systemd.network(5).

The following options are understood:

DUIDType=

Specifies how the DUID should be generated. See RFC 3315[3] for a description of all the options.
This takes an integer in the range 0…65535, or one of the following string values:
vendor
If “DUIDType=vendor”, then the DUID value will be generated using “43793” as the vendor identifier (systemd) and hashed contents of machine-id(5). This is the default if DUIDType= is not specified.
Added in version 230.
uuid
If “DUIDType=uuid”, and DUIDRawData= is not set, then the product UUID is used as a DUID value. If a system does not have valid product UUID, then an application-specific machine-id(5) is used as a DUID value. About the application-specific machine ID, see sd_id128_get_machine_app_specific(3).
Added in version 230.
link-layer-time[:TIME], link-layer
If “link-layer-time” or “link-layer” is specified, then the MAC address of the interface is used as a DUID value. The value “link-layer-time” can take additional time value after a colon, e.g. “link-layer-time:2018-01-23 12:34:56 UTC”. The default time value is “2000-01-01 00:00:00 UTC”.
Added in version 240.
In all cases, DUIDRawData= can be used to override the actual DUID value that is used.
Added in version 230.

DUIDRawData=

Specifies the DHCP DUID value as a single newline-terminated, hexadecimal string, with each byte separated by “:”. The DUID that is sent is composed of the DUID type specified by DUIDType= and the value configured here.
The DUID value specified here overrides the DUID that systemd-networkd.service(8) generates from the machine ID. To configure DUID per-network, see systemd.network(5). The configured DHCP DUID should conform to the specification in RFC 3315[4], RFC 6355[5]. To configure IAID, see systemd.network(5).
Example 1. A DUIDType=vendor with a custom value
DUIDType=vendor DUIDRawData=00:00:ab:11:f9:2a:c2:77:29:f9:5c:00
This specifies a 14 byte DUID, with the type DUID-EN (“00:02”), enterprise number 43793 (“00:00:ab:11”), and identifier value “f9:2a:c2:77:29:f9:5c:00”.
Added in version 230.

UseDomains=

Same as the one in the [IPv6AcceptRA] section, but applied for DHCPv4 protocol.
Added in version 256.

[DHCPV6] SECTION OPTIONS

This section configures the DHCP Unique Identifier (DUID) value used by DHCPv6 protocol. DHCPv6 client protocol sends the DHCP Unique Identifier and the interface Identity Association Identifier (IAID) to a DHCPv6 server when acquiring a dynamic IPv6 address. IAID and DUID allows a DHCPv6 server to uniquely identify the machine and the interface requesting a DHCP IP address. To configure IAID, see systemd.network(5).

The following options are understood:

DUIDType=, DUIDRawData=

As in the [DHCPv4] section.
Added in version 249.

UseDomains=

As in the [DHCPv4] section.
Added in version 256.

[DHCPSERVER] SECTION OPTIONS

This section configures the default setting of the DHCP server. The following options are available in the [DHCPServer] section:

UseDomains=

Same as the one in the [IPv6AcceptRA] section, but applied for DHCPv4 protocol.
Added in version 256.

NOTES

💣💥🧨💥💥💣 Please note that those configuration files must be available at all times. If /usr/local/ is a separate partition, it may not be available during early boot, and must not be used for configuration.

IP Sysctl

https://docs.kernel.org/networking/ip-sysctl.html

RFC 3315

https://tools.ietf.org/html/rfc3315#section-9

RFC 3315

http://tools.ietf.org/html/rfc3315#section-9

RFC 6355

http://tools.ietf.org/html/rfc6355

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

11 - Linux cli command depmod.d

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command depmod.d and provides detailed information about the command depmod.d, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the depmod.d.

NAME 🖥️ depmod.d 🖥️

Configuration directory for depmod

SYNOPSIS

/lib/depmod.d/*.conf

/usr/lib/depmod.d/*.conf

/usr/local/lib/depmod.d/*.conf

/run/depmod.d/*.conf

/etc/depmod.d/*.conf

DESCRIPTION

The order in which modules are processed by the depmod command can be altered on a global or per-module basis. This is typically useful in cases where built-in kernel modules are complemented by custom built versions of the same and the user wishes to affect the priority of processing in order to override the module version supplied by the kernel.

The format of files under depmod.d is simple: one command per line, with blank lines and lines starting with # ignored (useful for adding comments). A \ at the end of a line causes it to continue on the next line, which makes the files a bit neater.

COMMANDS

search subdirectory…

This allows you to specify the order in which /lib/modules (or other configured module location) subdirectories will be processed by depmod. Directories are listed in order, with the highest priority given to the first listed directory and the lowest priority given to the last directory listed. The special keyword built-in refers to the standard module directories installed by the kernel. Another special keyword external refers to the list of external directories, defined by the external command.
By default, depmod will give a higher priority to a directory with the name updates using this built-in search string: “updates built-in” but more complex arrangements are possible and are used in several popular distributions.

override modulename kernelversion modulesubdirectory

This command allows you to override which version of a specific module will be used when more than one module sharing the same name is processed by the depmod command. It is possible to specify one kernel or all kernels using the * wildcard. modulesubdirectory is the name of the subdirectory under /lib/modules (or other module location) where the target module is installed.
For example, it is possible to override the priority of an updated test module called kmod by specifying the following command: “override kmod * extra”. This will ensure that any matching module name installed under the extra subdirectory within /lib/modules (or other module location) will take priority over any likenamed module already provided by the kernel.

external kernelversion absolutemodulesdirectory…

This specifies a list of directories, which will be checked according to the priorities in the search command. The order matters also, the first directory has the higher priority.
The kernelversion is a POSIX regular expression or * wildcard, like in the override.

exclude excludedir

This specifies the trailing directories that will be excluded during the search for kernel modules.
The excludedir is the trailing directory to exclude

COPYRIGHT

AUTHORS

Jon Masters <[email protected]>

Developer

Robby Workman <[email protected]>

Developer

Lucas De Marchi <[email protected]>

Developer

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

12 - Linux cli command apt.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command apt.conf and provides detailed information about the command apt.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the apt.conf.

NAME 🖥️ apt.conf 🖥️

Configuration file for APT

DESCRIPTION

/etc/apt/apt.conf is the main configuration file shared by all the tools in the APT suite of tools, though it is by no means the only place options can be set. The suite also shares a common command line parser to provide a uniform environment.

When an APT tool starts up it will read the configuration files in the following order:

1.
the file specified by the APT_CONFIG environment variable (if any)

2.
all files in Dir::Etc::Parts in alphanumeric ascending order which have either no or “conf” as filename extension and which only contain alphanumeric, hyphen (-), underscore (_) and period (.) characters. Otherwise APT will print a notice that it has ignored a file, unless that file matches a pattern in the Dir::Ignore-Files-Silently configuration list - in which case it will be silently ignored.

3.
the main configuration file specified by Dir::Etc::main

4.
all options set in the binary specific configuration subtree are moved into the root of the tree.

5.
the command line options are applied to override the configuration directives or to load even more configuration files.

SYNTAX

The configuration file is organized in a tree with options organized into functional groups. Option specification is given with a double colon notation; for instance APT::Get::Assume-Yes is an option within the APT tool group, for the Get tool. Options do not inherit from their parent groups.

Syntactically the configuration language is modeled after what the ISC tools such as bind and dhcp use. Lines starting with // are treated as comments (ignored), as well as all text between /* and */, just like C/C++ comments. Lines starting with # are also treated as comments. Each line is of the form APT::Get::Assume-Yes “true”;. The quotation marks and trailing semicolon are required. The value must be on one line, and there is no kind of string concatenation. Values must not include backslashes or extra quotation marks. Option names are made up of alphanumeric characters and the characters “/-:._+”. A new scope can be opened with curly braces, like this:

APT {
  Get {
    Assume-Yes "true";
    Fix-Broken "true";
  };
};

with newlines placed to make it more readable. Lists can be created by opening a scope and including a single string enclosed in quotes followed by a semicolon. Multiple entries can be included, separated by a semicolon.

DPkg::Pre-Install-Pkgs {"/usr/sbin/dpkg-preconfigure --apt";};

In general the sample configuration file /usr/share/doc/apt/examples/configure-index is a good guide for how it should look.

Case is not significant in names of configuration items, so in the previous example you could use dpkg::pre-install-pkgs.

Names for the configuration items are optional if a list is defined as can be seen in the DPkg::Pre-Install-Pkgs example above. If you dont specify a name a new entry will simply add a new option to the list. If you specify a name you can override the option in the same way as any other option by reassigning a new value to the option.

Two special commands are defined: #include (which is deprecated and not supported by alternative implementations) and #clear. #include will include the given file, unless the filename ends in a slash, in which case the whole directory is included. #clear is used to erase a part of the configuration tree. The specified element and all its descendants are erased. (Note that these lines also need to end with a semicolon.)

The #clear command is the only way to delete a list or a complete scope. Reopening a scope (or using the syntax described below with an appended ::) will not override previously written entries. Options can only be overridden by addressing a new value to them - lists and scopes cant be overridden, only cleared.

All of the APT tools take an -o option which allows an arbitrary configuration directive to be specified on the command line. The syntax is a full option name (APT::Get::Assume-Yes for instance) followed by an equals sign then the new value of the option. To append a new element to a list, add a trailing :: to the name of the list. (As you might suspect, the scope syntax cant be used on the command line.)

Note that appending items to a list using :: only works for one item per line, and that you should not use it in combination with the scope syntax (which adds :: implicitly). Using both syntaxes together will trigger a bug which some users unfortunately depend on: an option with the unusual name “::” which acts like every other option with a name. This introduces many problems; for one thing, users who write multiple lines in this wrong syntax in the hope of appending to a list will achieve the opposite, as only the last assignment for this option “::” will be used. Future versions of APT will raise errors and stop working if they encounter this misuse, so please correct such statements now while APT doesnt explicitly complain about them.

THE APT GROUP

This group of options controls general APT behavior as well as holding the options for all of the tools.

Architecture

System Architecture; sets the architecture to use when fetching files and parsing package lists. The internal default is the architecture apt was compiled for.

Architectures

All Architectures the system supports. For instance, CPUs implementing the amd64 (also called x86-64) instruction set are also able to execute binaries compiled for the i386 (x86) instruction set. This list is used when fetching files and parsing package lists. The initial default is always the systems native architecture (APT::Architecture), and foreign architectures are added to the default list when they are registered via dpkg –add-architecture.

Color

This scope defines colors and styles. The basic colors supported are red, green, yellow, blue, magenta, cyan, and white.
The subscope action defines the colors for package lists in install and similar commands. The following options may be set: APT::Color::Action::Upgrade, APT::Color::Action::Install, APT::Color::Action::Install-Dependencies, APT::Color::Action::Downgrade, APT::Color::Action::Remove; corresponding to their lists in the apt(8) output.
Each color may reference one or more other color options by name, relative to APT::Color. Their escape sequences will be combined.
APT::Color::Bold “[1m”; APT::Color::Action::Install “cyan”; APT::Color::Action::Upgrade “bold action::install”;
Colors may be turned on or off completely by setting APT::Color to yes or no, by utilizing NO_COLOR or APT_NO_COLOR environment variables, or using the –color, –no-color command-line options.

Compressor

This scope defines which compression formats are supported, how compression and decompression can be performed if support for this format isnt built into apt directly and a cost-value indicating how costly it is to compress something in this format. As an example the following configuration stanza would allow apt to download and uncompress as well as create and store files with the low-cost .reversed file extension which it will pass to the command rev without additional commandline parameters for compression and uncompression:
APT::Compressor::rev { Name “rev”; Extension “.reversed”; Binary “rev”; CompressArg {}; UncompressArg {}; Cost “10”; };

Build-Profiles

List of all build profiles enabled for build-dependency resolution, without the “profile.” namespace prefix. By default this list is empty. The DEB_BUILD_PROFILES as used by dpkg-buildpackage(1) overrides the list notation.

Default-Release

Default release to install packages from if more than one version is available. Contains release name, codename or release version. Examples: stable, testing, unstable, bookworm, trixie, 4.0, 5.0*. See also apt_preferences(5).

Snapshot

Snapshot to use for all repositories configured with Snapshot: yes. See also sources.list(5), the –snapshot option that sets this value, and Acquire::Snapshots::URI below.

Ignore-Hold

Ignore held packages; this global option causes the problem resolver to ignore held packages in its decision making.

Clean-Installed

Defaults to on. When turned on the autoclean feature will remove any packages which can no longer be downloaded from the cache. If turned off then packages that are locally installed are also excluded from cleaning - but note that APT provides no direct means to reinstall them.

Immediate-Configure

Defaults to on, which will cause APT to install essential and important packages as soon as possible in an install/upgrade operation, in order to limit the effect of a failing dpkg(1) call. If this option is disabled, APT treats an important package in the same way as an extra package: between the unpacking of the package A and its configuration there can be many other unpack or configuration calls for other unrelated packages B, C etc. If these cause the dpkg(1) call to fail (e.g. because package Bs maintainer scripts generate an error), this results in a system state in which package A is unpacked but unconfigured - so any package depending on A is now no longer guaranteed to work, as its dependency on A is no longer satisfied.
The immediate configuration marker is also applied in the potentially problematic case of circular dependencies, since a dependency with the immediate flag is equivalent to a Pre-Dependency. In theory this allows APT to recognise a situation in which it is unable to perform immediate configuration, abort, and suggest to the user that the option should be temporarily deactivated in order to allow the operation to proceed. Note the use of the word “theory” here; in the real world this problem has rarely been encountered, in non-stable distribution versions, and was caused by wrong dependencies of the package in question or by a system in an already broken state; so you should not blindly disable this option, as the scenario mentioned above is not the only problem it can help to prevent in the first place.
Before a big operation like dist-upgrade is run with this option disabled you should try to explicitly install the package APT is unable to configure immediately; but please make sure you also report your problem to your distribution and to the APT team with the bug link below, so they can work on improving or correcting the upgrade process.

Force-LoopBreak

Never enable this option unless you really know what you are doing. It permits APT to temporarily remove an essential package to break a Conflicts/Conflicts or Conflicts/Pre-Depends loop between two essential packages. Such a loop should never exist and is a grave bug. This option will work if the essential packages are not tar, gzip, libc, dpkg, dash or anything that those packages depend on.

Cache-Start, Cache-Grow, Cache-Limit

APT uses since version 0.7.26 a resizable memory mapped cache file to store the available information. Cache-Start acts as a hint of the size the cache will grow to, and is therefore the amount of memory APT will request at startup. The default value is 20971520 bytes (~20 MB). Note that this amount of space needs to be available for APT; otherwise it will likely fail ungracefully, so for memory restricted devices this value should be lowered while on systems with a lot of configured sources it should be increased. Cache-Grow defines in bytes with the default of 1048576 (~1 MB) how much the cache size will be increased in the event the space defined by Cache-Start is not enough. This value will be applied again and again until either the cache is big enough to store all information or the size of the cache reaches the Cache-Limit. The default of Cache-Limit is 0 which stands for no limit. If Cache-Grow is set to 0 the automatic growth of the cache is disabled.

Build-Essential

Defines which packages are considered essential build dependencies.

Get

The Get subsection controls the apt-get(8) tool; please see its documentation for more information about the options here.

Cache

The Cache subsection controls the apt-cache(8) tool; please see its documentation for more information about the options here.

CDROM

The CDROM subsection controls the apt-cdrom(8) tool; please see its documentation for more information about the options here.

NeverAutoRemove

Never autoremove packages that match the regular expression(s).

Protect-Kernels

This option tells apt autoremove that kernels are protected and defaults to true. In case kernels are not protected they are treated as any other package.

VersionedKernelPackages

Define the regular expression(s) for versioned kernel packages. Based on these expressions a rule set is injected into apt similar to APT::NeverAutoRemove regular expressions.

NeverAutoRemove::KernelCount

Keep a custom amount of kernels when autoremoving and defaults to 2, meaning two kernels are kept. Apt will always keep the running kernel and the latest one. If the latest kernel is the same as the running kernel, the second latest kernel is kept. Because of this, any value lower than 2 will be ignored. If you want only the latest kernel, you should set APT::Protect-Kernels to false.

THE ACQUIRE GROUP

The Acquire group of options controls the download of packages as well as the various “acquire methods” responsible for the download itself (see also sources.list(5)).

Check-Date

Security related option defaulting to true, enabling time-related checks. Disabling it means that the machines time cannot be trusted, and APT will hence disable all time-related checks, such as Check-Valid-Until and verifying that the Date field of a release file is not in the future.

Max-FutureTime

Maximum time (in seconds) before its creation (as indicated by the Date header) that the Release file should be considered valid. The default value is 10. Archive specific settings can be made by appending the label of the archive to the option name. Preferably, the same can be achieved for specific sources.list(5) entries by using the Date-Max-Future option there.

Check-Valid-Until

Security related option defaulting to true, as giving a Release files validation an expiration date prevents replay attacks over a long timescale, and can also for example help users to identify mirrors that are no longer updated - but the feature depends on the correctness of the clock on the user system. Archive maintainers are encouraged to create Release files with the Valid-Until header, but if they dont or a stricter value is desired the Max-ValidTime option below can be used. The Check-Valid-Until option of sources.list(5) entries should be preferred to disable the check selectively instead of using this global override.

Max-ValidTime

Maximum time (in seconds) after its creation (as indicated by the Date header) that the Release file should be considered valid. If the Release file itself includes a Valid-Until header the earlier date of the two is used as the expiration date. The default value is 0 which stands for “valid forever”. Archive specific settings can be made by appending the label of the archive to the option name. Preferably, the same can be achieved for specific sources.list(5) entries by using the Valid-Until-Max option there.

Min-ValidTime

Minimum time (in seconds) after its creation (as indicated by the Date header) that the Release file should be considered valid. Use this if you need to use a seldom updated (local) mirror of a more frequently updated archive with a Valid-Until header instead of completely disabling the expiration date checking. Archive specific settings can and should be used by appending the label of the archive to the option name. Preferably, the same can be achieved for specific sources.list(5) entries by using the Valid-Until-Min option there.

AllowTLS

Allow use of the internal TLS support in the http method. If set to false, this completely disables support for TLS in apts own methods (excluding the curl-based https method). No TLS-related functions will be called anymore.

PDiffs

Try to download deltas called PDiffs for indexes (like Packages files) instead of downloading whole ones. True by default. Preferably, this can be set for specific sources.list(5) entries or index files by using the PDiffs option there.
Two sub-options to limit the use of PDiffs are also available: FileLimit can be used to specify a maximum number of PDiff files should be downloaded to update a file. SizeLimit on the other hand is the maximum percentage of the size of all patches compared to the size of the targeted file. If one of these limits is exceeded the complete file is downloaded instead of the patches.

By-Hash

Try to download indexes via an URI constructed from a hashsum of the expected file rather than downloaded via a well-known stable filename. True by default, but automatically disabled if the source indicates no support for it. Usage can be forced with the special value “force”. Preferably, this can be set for specific sources.list(5) entries or index files by using the By-Hash option there.

Queue-Mode

Queuing mode; Queue-Mode can be one of host or access which determines how APT parallelizes outgoing connections. host means that one connection per target host will be opened, access means that one connection per URI type will be opened.

Retries

Number of retries to perform. If this is non-zero APT will retry failed files the given number of times.

Source-Symlinks

Use symlinks for source archives. If set to true then source archives will be symlinked when possible instead of copying. True is the default.

http https

The options in these scopes configure APTs acquire transports for the protocols HTTP and HTTPS and are documented in the apt-transport-http(1) and apt-transport-https(1) manpages respectively.

ftp

ftp::Proxy sets the default proxy to use for FTP URIs. It is in the standard form of ftp://[[user][:pass]@]host[:port]/. Per host proxies can also be specified by using the form ftp::Proxy::<host> with the special keyword DIRECT meaning to use no proxies. If no one of the above settings is specified, ftp_proxy environment variable will be used. To use an FTP proxy you will have to set the ftp::ProxyLogin script in the configuration file. This entry specifies the commands to send to tell the proxy server what to connect to. Please see /usr/share/doc/apt/examples/configure-index for an example of how to do this. The substitution variables representing the corresponding URI component are $(PROXY_USER), $(PROXY_PASS), $(SITE_USER), $(SITE_PASS), $(SITE) and $(SITE_PORT).
The option timeout sets the timeout timer used by the method; this value applies to the connection as well as the data timeout.
Several settings are provided to control passive mode. Generally it is safe to leave passive mode on; it works in nearly every environment. However, some situations require that passive mode be disabled and port mode FTP used instead. This can be done globally or for connections that go through a proxy or for a specific host (see the sample config file for examples).
It is possible to proxy FTP over HTTP by setting the ftp_proxy environment variable to an HTTP URL - see the discussion of the http method above for syntax. You cannot set this in the configuration file and it is not recommended to use FTP over HTTP due to its low efficiency.
The setting ForceExtended controls the use of RFC2428 EPSV and EPRT commands. The default is false, which means these commands are only used if the control connection is IPv6. Setting this to true forces their use even on IPv4 connections. Note that most FTP servers do not support RFC2428.

cdrom

For URIs using the cdrom method, the only configurable option is the mount point, cdrom::Mount, which must be the mount point for the CD-ROM (or DVD, or whatever) drive as specified in /etc/fstab. It is possible to provide alternate mount and unmount commands if your mount point cannot be listed in the fstab. The syntax is to put
/cdrom/::Mount “foo”;
within the cdrom block. It is important to have the trailing slash. Unmount commands can be specified using UMount.

gpgv

For GPGV URIs the only configurable option is gpgv::Options, which passes additional parameters to gpgv.

CompressionTypes

List of compression types which are understood by the acquire methods. Files like Packages can be available in various compression formats. By default the acquire methods can decompress and recompress many common formats like xz and gzip; with this scope the supported formats can be queried, modified as well as support for more formats added (see also APT::Compressor). The syntax for this is:
Acquire::CompressionTypes::FileExtension “Methodname”;
Also, the Order subgroup can be used to define in which order the acquire system will try to download the compressed files. The acquire system will try the first and proceed with the next compression type in this list on error, so to prefer one over the other type simply add the preferred type first - types not already added will be implicitly appended to the end of the list, so e.g.
Acquire::CompressionTypes::Order:: “gz”;
can be used to prefer gzip compressed files over all other compression formats. If xz should be preferred over gzip and bzip2 the configure setting should look like this:
Acquire::CompressionTypes::Order { “xz”; “gz”; };
It is not needed to add bz2 to the list explicitly as it will be added automatically.
Note that the Dir::Bin::Methodname will be checked at run time. If this option has been set and support for this format isnt directly built into apt, the method will only be used if this file exists; e.g. for the bzip2 method (the inbuilt) setting is:
Dir::Bin::bzip2 “/bin/bzip2”;
Note also that list entries specified on the command line will be added at the end of the list specified in the configuration files, but before the default entries. To prefer a type in this case over the ones specified in the configuration files you can set the option direct - not in list style. This will not override the defined list; it will only prefix the list with this type.
The special type uncompressed can be used to give uncompressed files a preference, but note that most archives dont provide uncompressed files so this is mostly only usable for local mirrors.

GzipIndexes

When downloading gzip compressed indexes (Packages, Sources, or Translations), keep them gzip compressed locally instead of unpacking them. This saves quite a lot of disk space at the expense of more CPU requirements when building the local package caches. False by default.

Languages

The Languages subsection controls which Translation files are downloaded and in which order APT tries to display the description-translations. APT will try to display the first available description in the language which is listed first. Languages can be defined with their short or long language codes. Note that not all archives provide Translation files for every language - the long language codes are especially rare.
The default list includes “environment” and “en”. “environment” has a special meaning here: it will be replaced at runtime with the language codes extracted from the LC_MESSAGES environment variable. It will also ensure that these codes are not included twice in the list. If LC_MESSAGES is set to “C” only the Translation-en file (if available) will be used. To force APT to use no Translation file use the setting Acquire::Languages=none. “none” is another special meaning code which will stop the search for a suitable Translation file. This tells APT to download these translations too, without actually using them unless the environment specifies the languages. So the following example configuration will result in the order “en, de” in an English locale or “de, en” in a German one. Note that “fr” is downloaded, but not used unless APT is used in a French locale (where the order would be “fr, de, en”).
Acquire::Languages { “environment”; “de”; “en”; “none”; “fr”; };
Note: To prevent problems resulting from APT being executed in different environments (e.g. by different users or by other programs) all Translation files which are found in /var/lib/apt/lists/ will be added to the end of the list (after an implicit “none”).

ForceIPv4

When downloading, force to use only the IPv4 protocol.

ForceIPv6

When downloading, force to use only the IPv6 protocol.

MaxReleaseFileSize

The maximum file size of Release/Release.gpg/InRelease files. The default is 10MB.

EnableSrvRecords

This option controls if apt will use the DNS SRV server record as specified in RFC 2782 to select an alternative server to connect to. The default is “true”.

AllowInsecureRepositories

Allow update operations to load data files from repositories without sufficient security information. The default value is “false”. Concept, implications as well as alternatives are detailed in apt-secure(8).

AllowWeakRepositories

Allow update operations to load data files from repositories which provide security information, but these are deemed no longer cryptographically strong enough. The default value is “false”. Concept, implications as well as alternatives are detailed in apt-secure(8).

AllowDowngradeToInsecureRepositories

Allow that a repository that was previously gpg signed to become unsigned during an update operation. When there is no valid signature for a previously trusted repository apt will refuse the update. This option can be used to override this protection. You almost certainly never want to enable this. The default is false. Concept, implications as well as alternatives are detailed in apt-secure(8).

Changelogs::URI scope

Acquiring changelogs can only be done if an URI is known from where to get them. Preferable the Release file indicates this in a Changelogs field. If this isnt available the Label/Origin field of the Release file is used to check if a Acquire::Changelogs::URI::Label::LABEL or Acquire::Changelogs::URI::Origin::ORIGIN option exists and if so this value is taken. The value in the Release file can be overridden with Acquire::Changelogs::URI::Override::Label::LABEL or Acquire::Changelogs::URI::Override::Origin::ORIGIN. The value should be a normal URI to a text file, except that package specific data is replaced with the placeholder @CHANGEPATH@. The value for it is: 1. if the package is from a component (e.g. main) this is the first part otherwise it is omitted, 2. the first letter of source package name, except if the source package name starts with lib in which case it will be the first four letters. 3. The complete source package name. 4. the complete name again and 5. the source version. The first (if present), second, third and fourth part are separated by a slash (/) and between the fourth and fifth part is an underscore (_). The special value no is available for this option indicating that this source cant be used to acquire changelog files from. Another source will be tried if available in this case.

Snapshots::URI scope

Like changelogs, snapshots can only be acquired if an URI is known from where to get them. Preferable the Release file indicates this in a Snapshots field. If this isnt available the Label/Origin field of the Release file is used to check if a Acquire::Snapshots::URI::Label::LABEL or Acquire::Snapshots::URI::Origin::ORIGIN option exists and if so this value is taken. The value in the Release file can be overridden with Acquire::Snapshots::URI::Override::Label::LABEL or Acquire::Snapshots::URI::Override::Origin::ORIGIN. The value should be a normal URI to a directory, except that the snapshot ID replaced with the placeholder @SNAPSHOTID@. The special value no is available for this option indicating that this source cannot be used to acquire snapshots from. Another source will be tried if available in this case.

BINARY SPECIFIC CONFIGURATION

Especially with the introduction of the apt binary it can be useful to set certain options only for a specific binary as even options which look like they would effect only a certain binary like APT::Get::Show-Versions effect apt-get as well as apt.

Setting an option for a specific binary only can be achieved by setting the option inside the **Binary::**specific-binary scope. Setting the option APT::Get::Show-Versions for the apt only can e.g. by done by setting Binary::apt::APT::Get::Show-Versions instead.

Note that as seen in the DESCRIPTION section further above you cant set binary-specific options on the commandline itself nor in configuration files loaded via the commandline.

DIRECTORIES

The Dir::State section has directories that pertain to local state information. lists is the directory to place downloaded package lists in and status is the name of the dpkg(1) status file. preferences is the name of the APT preferences file. Dir::State contains the default directory to prefix on all sub-items if they do not start with / or ./.

Dir::Cache contains locations pertaining to local cache information, such as the two package caches srcpkgcache and pkgcache as well as the location to place downloaded archives, Dir::Cache::archives. Generation of caches can be turned off by setting pkgcache or srcpkgcache to “”. This will slow down startup but save disk space. It is probably preferable to turn off the pkgcache rather than the srcpkgcache. Like Dir::State the default directory is contained in Dir::Cache

Dir::Etc contains the location of configuration files, sourcelist gives the location of the sourcelist and main is the default configuration file (setting has no effect, unless it is done from the config file specified by APT_CONFIG).

The Dir::Parts setting reads in all the config fragments in lexical order from the directory specified. After this is done then the main config file is loaded.

Binary programs are pointed to by Dir::Bin. Dir::Bin::Methods specifies the location of the method handlers and gzip, bzip2, lzma, dpkg, apt-get dpkg-source dpkg-buildpackage and apt-cache specify the location of the respective programs.

The configuration item RootDir has a special meaning. If set, all paths will be relative to RootDir, even paths that are specified absolutely. So, for instance, if RootDir is set to /tmp/staging and Dir::State::status is set to /var/lib/dpkg/status, then the status file will be looked up in /tmp/staging/var/lib/dpkg/status. If you want to prefix only relative paths, set Dir instead.

The Ignore-Files-Silently list can be used to specify which files APT should silently ignore while parsing the files in the fragment directories. Per default a file which ends with .disabled, ~, .bak or .dpkg-[a-z]+ is silently ignored. As seen in the last default value these patterns can use regular expression syntax.

APT IN DSELECT

When APT is used as a dselect(1) method several configuration directives control the default behavior. These are in the DSelect section.

Clean

Cache Clean mode; this value may be one of always, prompt, auto, pre-auto and never. always and prompt will remove all packages from the cache after upgrading, prompt (the default) does so conditionally. auto removes only those packages which are no longer downloadable (replaced with a new version for instance). pre-auto performs this action before downloading new packages.

options

The contents of this variable are passed to apt-get(8) as command line options when it is run for the install phase.

Updateoptions

The contents of this variable are passed to apt-get(8) as command line options when it is run for the update phase.

PromptAfterUpdate

If true the [U]pdate operation in dselect(1) will always prompt to continue. The default is to prompt only on error.

HOW APT CALLS DPKG(1)

Several configuration directives control how APT invokes dpkg(1). These are in the DPkg section.

options

This is a list of options to pass to dpkg(1). The options must be specified using the list notation and each list item is passed as a single argument to dpkg(1).

Path

This is a string that defines the PATH environment variable used when running dpkg. It may be set to any valid value of that environment variable; or the empty string, in which case the variable is not changed.

Pre-Invoke, Post-Invoke

This is a list of shell commands to run before/after invoking dpkg(1). Like options this must be specified in list notation. The commands are invoked in order using /bin/sh; should any fail APT will abort.

Pre-Install-Pkgs

This is a list of shell commands to run before invoking dpkg(1). Like options this must be specified in list notation. The commands are invoked in order using /bin/sh; should any fail APT will abort. APT will pass the filenames of all .deb files it is going to install to the commands, one per line on the requested file descriptor, defaulting to standard input.
Version 2 of this protocol sends more information through the requested file descriptor: a line with the text VERSION 2, the APT configuration space, and a list of package actions with filename and version information.
Each configuration directive line has the form key=value. Special characters (equal signs, newlines, nonprintable characters, quotation marks, and percent signs in key and newlines, nonprintable characters, and percent signs in value) are %-encoded. Lists are represented by multiple key::=value lines with the same key. The configuration section ends with a blank line.
Package action lines consist of five fields in Version 2: package name (without architecture qualification even if foreign), old version, direction of version change (< for upgrades, > for downgrades, = for no change), new version, action. The version fields are “-” for no version at all (for example when installing a package for the first time; no version is treated as earlier than any real version, so that is an upgrade, indicated as - < 1.23.4). The action field is “**CONFIGURE**” if the package is being configured, “**REMOVE**” if it is being removed, or the filename of a .deb file if it is being unpacked.
In Version 3 after each version field follows the architecture of this version, which is “-” if there is no version, and a field showing the MultiArch type “same”, “foreign”, “allowed” or “none”. Note that “none” is an incorrect typename which is just kept to remain compatible, it should be read as “no” and users are encouraged to support both.
The version of the protocol to be used for the command cmd can be chosen by setting DPkg::Tools::options::cmd::Version accordingly, the default being version 1. If APT isnt supporting the requested version it will send the information in the highest version it has support for instead.
The file descriptor to be used to send the information can be requested with DPkg::Tools::options::cmd::InfoFD which defaults to 0 for standard input and is available since version 0.9.11. Support for the option can be detected by looking for the environment variable APT_HOOK_INFO_FD which contains the number of the used file descriptor as a confirmation.

Run-Directory

APT chdirs to this directory before invoking dpkg(1), the default is /.

Build-options

These options are passed to dpkg-buildpackage(1) when compiling packages; the default is to disable signing and produce all binaries.

DPkg::ConfigurePending

If this option is set APT will call dpkg –configure –pending to let dpkg(1) handle all required configurations and triggers. This option is activated by default, but deactivating it could be useful if you want to run APT multiple times in a row - e.g. in an installer. In this scenario you could deactivate this option in all but the last run.

PERIODIC AND ARCHIVES OPTIONS

APT::Periodic and APT::Archives groups of options configure behavior of apt periodic updates, which is done by the /usr/lib/apt/apt.systemd.daily script. See the top of this script for the brief documentation of these options.

DEBUG OPTIONS

Enabling options in the Debug:: section will cause debugging information to be sent to the standard error stream of the program utilizing the apt libraries, or enable special program modes that are primarily useful for debugging the behavior of apt. Most of these options are not interesting to a normal user, but a few may be:

·
Debug::pkgProblemResolver enables output about the decisions made by dist-upgrade, upgrade, install, remove, purge.

·
Debug::NoLocking disables all file locking. This can be used to run some operations (for instance, apt-get -s install) as a non-root user.

·
Debug::pkgDPkgPM prints out the actual command line each time that apt invokes dpkg(1).

·
Debug::IdentCdrom disables the inclusion of statfs data in CD-ROM IDs.

A full list of debugging options to apt follows.

Debug::Acquire::cdrom

Print information related to accessing cdrom:// sources.

Debug::Acquire::ftp

Print information related to downloading packages using FTP.

Debug::Acquire::http

Print information related to downloading packages using HTTP.

Debug::Acquire::https

Print information related to downloading packages using HTTPS.

Debug::Acquire::gpgv

Print information related to verifying cryptographic signatures using gpg.

Debug::aptcdrom

Output information about the process of accessing collections of packages stored on CD-ROMs.

Debug::Hashes

Output each cryptographic hash that is generated by the apt libraries.

Debug::IdentCDROM

Do not include information from statfs, namely the number of used and free blocks on the CD-ROM filesystem, when generating an ID for a CD-ROM.

Debug::NoLocking

Disable all file locking. For instance, this will allow two instances of “apt-get update” to run at the same time.

Debug::pkgAcquire

Log when items are added to or removed from the global download queue.

Debug::pkgAcquire::Auth

Output status messages and errors related to verifying checksums and cryptographic signatures of downloaded files.

Debug::pkgAcquire::Diffs

Output information about downloading and applying package index list diffs, and errors relating to package index list diffs.

Debug::pkgAcquire::RRed

Output information related to patching apt package lists when downloading index diffs instead of full indices.

Debug::pkgAcquire::Worker

Log all interactions with the sub-processes that actually perform downloads.

Debug::pkgAutoRemove

Log events related to the automatically-installed status of packages and to the removal of unused packages.

Debug::pkgDepCache::AutoInstall

Generate debug messages describing which packages are being automatically installed to resolve dependencies. This corresponds to the initial auto-install pass performed in, e.g., apt-get install, and not to the full apt dependency resolver; see Debug::pkgProblemResolver for that.

Debug::pkgDepCache::Marker

Generate debug messages describing which packages are marked as keep/install/remove while the ProblemResolver does his work. Each addition or deletion may trigger additional actions; they are shown indented two additional spaces under the original entry. The format for each line is MarkKeep, MarkDelete or MarkInstall followed by package-name <a.b.c -> d.e.f | x.y.z> (section) where a.b.c is the current version of the package, d.e.f is the version considered for installation and x.y.z is a newer version, but not considered for installation (because of a low pin score). The later two can be omitted if there is none or if it is the same as the installed version. section is the name of the section the package appears in.

Debug::pkgDPkgPM

When invoking dpkg(1), output the precise command line with which it is being invoked, with arguments separated by a single space character.

Debug::pkgDPkgProgressReporting

Output all the data received from dpkg(1) on the status file descriptor and any errors encountered while parsing it.

Debug::pkgOrderList

Generate a trace of the algorithm that decides the order in which apt should pass packages to dpkg(1).

Debug::pkgPackageManager

Output status messages tracing the steps performed when invoking dpkg(1).

Debug::pkgPolicy

Output the priority of each package list on startup.

Debug::pkgProblemResolver

Trace the execution of the dependency resolver (this applies only to what happens when a complex dependency problem is encountered).

Debug::pkgProblemResolver::ShowScores

Display a list of all installed packages with their calculated score used by the pkgProblemResolver. The description of the package is the same as described in Debug::pkgDepCache::Marker

Debug::sourceList

Print information about the vendors read from /etc/apt/vendors.list.

Debug::RunScripts

Display the external commands that are called by apt hooks. This includes e.g. the config options DPkg::{Pre,Post}-Invoke or APT::Update::{Pre,Post}-Invoke.

EXAMPLES

/usr/share/doc/apt/examples/configure-index is a configuration file showing example values for all possible options.

FILES

/etc/apt/apt.conf

APT configuration file. Configuration Item: Dir::Etc::Main.

/etc/apt/apt.conf.d/

APT configuration file fragments. Configuration Item: Dir::Etc::Parts.

BUGS

APT bug page[1]. If you wish to report a bug in APT, please see /usr/share/doc/debian/bug-reporting.txt or the reportbug(1) command.

AUTHORS

Jason Gunthorpe

APT team

Daniel Burrows <[email protected]>

Initial documentation of Debug::*.

NOTES

APT bug page

https://bugs.debian.org/src:apt

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

13 - Linux cli command proc_cmdline

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_cmdline and provides detailed information about the command proc_cmdline, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_cmdline.

NAME 🖥️ proc_cmdline 🖥️

kernel boot arguments

DESCRIPTION

/proc/cmdline
Arguments passed to the Linux kernel at boot time. Often done via a boot manager such as lilo(8) or grub(8). Any arguments embedded in the kernel image or initramfs via CONFIG_BOOT_CONFIG will also be displayed.

14 - Linux cli command mib2c.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command mib2c.conf and provides detailed information about the command mib2c.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the mib2c.conf.

NAME 🖥️ mib2c.conf 🖥️

How to write mib2c.conf files to do ANYTHING based on MIB input.

SYNOPSIS

% cat > mib2c.test.conf << EOF @foreach $t table@ Starting table $t @foreach $c column@ echo $t has column $c which has a syntax of $c.syntax @end@

@end@ EOF

% mib2c -c mib2c.test.conf internet

DESCRIPTION

The mib2c.conf script language is a MIB-particular language designed to easily process MIB nodes in ways that you want. mib2c is a misnomer (for historical purposes), because you can produce anything (not just C code). Look in the Net-SNMP “local” directory for a bunch of example mib2c.*.conf files and behold the power before you.

COMMANDS

All commands within mib2c.conf files are embraced by @ signs. Anything with an @ sign at the front and back of the line is generally supposed to be a mib2c specific command. These are detailed here:

@open FILE@
writes generated output to FILE note that for file specifications, opening ‘-’ will print to stdout.

@append FILE@
appends the given FILE

@close FILE@
closes the given FILE

@push@
save the current outputs, then clear outputs. Use with @open@ and @pop@ to write to a new file without interfering with current outputs.

@pop@
pop up the process() stack one level. Use after a @push@ to return to the previous set of open files.

@foreach $VAR scalar@
repeat iterate over code until @end@ setting $VAR to all known scalars

@foreach $VAR table@
repeat iterate over code until @end@ setting $VAR to all known tables

@foreach $VAR column@
repeat iterate over code until @end@ setting $VAR to all known columns within a given table. Obviously this must be called within a foreach-table clause.

@foreach $VAR nonindex@
repeat iterate over code until @end@ setting $VAR to all known non-index columns within a given table. Obviously this must be called within a foreach-table clause.

@foreach $VAR internalindex@
repeat iterate over code until @end@ setting $VAR to all known internal index columns within a given table. Obviously this must be called within a foreach-table clause.

@foreach $VAR externalindex@
repeat iterate over code until @end@ setting $VAR to all known external index columns within a given table. Obviously this must be called within a foreach-table clause.

@foreach $VAR index@
repeat iterate over code until @end@ setting $VAR to all known indexes within a given table. Obviously this must be called within a foreach-table clause.

@foreach $VAR notifications@
repeat iterate over code until @end@ setting $VAR to all known notifications

@foreach $VAR varbinds@
repeat iterate over code until @end@ setting $VAR to all known varbinds Obviously this must be called within a foreach-notifications clause.

@foreach $LABEL, $VALUE enum@
repeat iterate over code until @end@ setting $LABEL and $VALUE to the label and values from the enum list.

@foreach $RANGE_START, $RANGE_END range NODE@
repeat iterate over code until @end@ setting $RANGE_START and $RANGE_END to the legal accepted range set for a given mib NODE.

@foreach $var stuff a b c d@
repeat iterate over values a, b, c, d as assigned generically (ie, the values are taken straight from the list with no mib-expansion, etc).

@while expression@
repeat iterate over code until the expression is false

@eval $VAR = expression@
evaluates expression and assigns the results to $VAR. This is not a full perl eval, but sort of a ““psuedo”” eval useful for simple expressions while keeping the same variable name space. See below for a full-blown export to perl.

@perleval STUFF@
evaluates STUFF directly in perl. Note that all mib2c variables interpereted within .conf files are in $vars{NAME} and that a warning will be printed if STUFF does not return 0. (adding a ‘return 0;’ at the end of STUFF is a workaround.

@startperl@

@endperl@
treats everything between these tags as perl code, and evaluates it.

@next@
restart foreach; should only be used inside a conditional. skips out of current conditional, then continues to skip to end for the current foreach clause.

@if expression@
evaluates expression, and if expression is true processes contained part until appropriate @end@ is reached. If the expression is false, the next @elsif expression@ expression (if it exists) will be evaluated, until an expression is true. If no such expression exists and an @else@ clause is found, it will be evaluated.

@ifconf file@
If the specified file can be found in the conf file search path, and if found processes contained part until an appropriate @end@ is found. As with a regular @if expression@, @elsif expression@ and @else@ can be used.

@ifdir dir@
If the specified directory exists, process contained part until an appropriate @end@ is found. As with a regular @if expression@, @elsif expression@ and @else@ can be used.

@define NAME@

@enddefine@
Memorizes ““stuff”” between the define and enddefine tags for later calling as NAME by @calldefine NAME@.

@calldefine NAME@
Executes stuff previously memorized as NAME.

@printf “expression” stuff1, stuff2, …@
Like all the other printf’s you know and love.

@run FILE@
Sources the contents of FILE as a mib2c file, but does not affect current files opened.

@include FILE@
Sources the contents of FILE as a mib2c file and appends its output to the current output.

@prompt $var QUESTION@
Presents the user with QUESTION, expects a response and puts it in $var

@print STUFF@
Prints stuff directly to the users screen (ie, not to where normal mib2c output goes)

@quit@
Bail out (silently)

@exit@
Bail out!

VARIABLES

Variables in the mib2c language look very similar to perl variables, in that they start with a “$”. They can be used for anything you want, but most typically they’ll hold mib node names being processed by @foreach …@ clauses.

They also have a special properties when they are a mib node, such that adding special suffixes to them will allow them to be interpreted in some fashion. The easiest way to understand this is through an example. If the variable ‘x’ contained the word ‘ifType’ then some magical things happen. In mib2c output, anytime $x is seen it is replaced with “ifType”. Additional suffixes can be used to get other aspects of that mib node though. If $x.objectID is seen, it’ll be replaced by the OID for ifType: “.1.3.6.1.2.1.2.2.1.3”. Other suffixes that can appear after a dot are listed below.

One last thing: you can use things like $vartext immediately ending in some other text, you can use {}s to get proper expansion of only part of the mib2c input. IE, $xtext will produce “$xtext”, but ${x}text will produce “ifTypetext” instead.

$var.uc
all upper case version of $var

$var.objectID
dotted, fully-qualified, and numeric OID

$var.commaoid
comma separated numeric OID for array initialization

$var.oidlength
length of the oid

$var.subid
last number component of oid

$var.module
MIB name that the object comes from

$var.parent
contains the label of the parent node of $var.

$var.isscalar
returns 1 if var contains the name of a scalar

$var.iscolumn
returns 1 if var contains the name of a column

$var.children
returns 1 if var has children

$var.perltype
node’s perl SYNTAX ($SNMP::MIB{node}{‘syntax’})

$var.type
node’s ASN_XXX type (Net-SNMP specific #define)

$var.decl
C data type (char, u_long, …)

$var.readable
1 if an object is readable, 0 if not

$var.settable
1 if an object is writable, 0 if not

$var.creatable
1 if a column object can be created as part of a new row, 0 if not

$var.noaccess
1 if not-accessible, 0 if not

$var.accessible
1 if accessible, 0 if not

$var.storagetype
1 if an object is a StorageType object, 0 if not

$var.rowstatus
1 if an object is a RowStatus object, 0 if not ‘settable’, ‘creatable’, ’lastchange’, ‘storagetype’ and ‘rowstatus’ can also be used with table variables to indicate whether it contains writable, creatable, LastChange, StorageType or RowStatus column objects

$var.hasdefval
returns 1 if var has a DEFVAL clause

$var.defval
node’s DEFVAL

$var.hashint
returns 1 if var has a HINT clause

$var.hint
node’s HINT

$var.ranges
returns 1 if var has a value range defined

$var.enums
returns 1 if var has enums defined for it.

$var.access
node’s access type

$var.status
node’s status

$var.syntax
node’s syntax

$var.reference
node’s reference

$var.description
node’s description

15 - Linux cli command proc_kallsyms

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_kallsyms and provides detailed information about the command proc_kallsyms, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_kallsyms.

NAME 🖥️ proc_kallsyms 🖥️

kernel exported symbols

DESCRIPTION

/proc/kallsyms (since Linux 2.5.71)
This holds the kernel exported symbol definitions used by the modules(X) tools to dynamically link and bind loadable modules. In Linux 2.5.47 and earlier, a similar file with slightly different syntax was named ksyms.

HISTORY

/proc/ksyms (Linux 1.1.23–2.5.47)
See /proc/kallsyms.

16 - Linux cli command proc_pid_status

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_status and provides detailed information about the command proc_pid_status, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_status.

NAME 🖥️ proc_pid_status 🖥️

memory usage and status information

DESCRIPTION

/proc/pid/status
Provides much of the information in /proc/pid/stat and /proc/pid/statm in a format that’s easier for humans to parse. Here’s an example:

$ cat /proc/$$/status
Name:   bash
Umask:  0022
State:  S (sleeping)
Tgid:   17248
Ngid:   0
Pid:    17248
PPid:   17200
TracerPid:      0
Uid:    1000    1000    1000    1000
Gid:    100     100     100     100
FDSize: 256
Groups: 16 33 100
NStgid: 17248
NSpid:  17248
NSpgid: 17248
NSsid:  17200
VmPeak:	  131168 kB
VmSize:	  131168 kB
VmLck:	       0 kB
VmPin:	       0 kB
VmHWM:	   13484 kB
VmRSS:	   13484 kB
RssAnon:	   10264 kB
RssFile:	    3220 kB
RssShmem:	       0 kB
VmData:	   10332 kB
VmStk:	     136 kB
VmExe:	     992 kB
VmLib:	    2104 kB
VmPTE:	      76 kB
VmPMD:	      12 kB
VmSwap:	       0 kB
HugetlbPages:          0 kB		# 4.4
CoreDumping:	0                       # 4.15
Threads:        1
SigQ:   0/3067
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000010000
SigIgn: 0000000000384004
SigCgt: 000000004b813efb
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff
CapAmb:	0000000000000000
NoNewPrivs:     0
Seccomp:        0
Seccomp_filters:        0
Speculation_Store_Bypass:       vulnerable
Cpus_allowed:   00000001
Cpus_allowed_list:      0
Mems_allowed:   1
Mems_allowed_list:      0
voluntary_ctxt_switches:        150
nonvoluntary_ctxt_switches:     545

The fields are as follows:

Name
Command run by this process. Strings longer than TASK_COMM_LEN (16) characters (including the terminating null byte) are silently truncated.

Umask
Process umask, expressed in octal with a leading zero; see umask(2). (Since Linux 4.7.)

State
Current state of the process. One of “R (running)”, “S (sleeping)”, “D (disk sleep)”, “T (stopped)”, “t (tracing stop)”, “Z (zombie)”, or “X (dead)”.

Tgid
Thread group ID (i.e., Process ID).

Ngid
NUMA group ID (0 if none; since Linux 3.13).

Pid
Thread ID (see gettid(2)).

PPid
PID of parent process.

TracerPid
PID of process tracing this process (0 if not being traced).

Uid
Gid
Real, effective, saved set, and filesystem UIDs (GIDs).

FDSize
Number of file descriptor slots currently allocated.

Groups
Supplementary group list.

NStgid
Thread group ID (i.e., PID) in each of the PID namespaces of which pid is a member. The leftmost entry shows the value with respect to the PID namespace of the process that mounted this procfs (or the root namespace if mounted by the kernel), followed by the value in successively nested inner namespaces. (Since Linux 4.1.)

NSpid
Thread ID in each of the PID namespaces of which pid is a member. The fields are ordered as for NStgid. (Since Linux 4.1.)

NSpgid
Process group ID in each of the PID namespaces of which pid is a member. The fields are ordered as for NStgid. (Since Linux 4.1.)

NSsid
descendant namespace session ID hierarchy Session ID in each of the PID namespaces of which pid is a member. The fields are ordered as for NStgid. (Since Linux 4.1.)

VmPeak
Peak virtual memory size.

VmSize
Virtual memory size.

VmLck
Locked memory size (see mlock(2)).

VmPin
Pinned memory size (since Linux 3.2). These are pages that can’t be moved because something needs to directly access physical memory.

VmHWM
Peak resident set size (“high water mark”). This value is inaccurate; see /proc/pid/statm above.

VmRSS
Resident set size. Note that the value here is the sum of RssAnon, RssFile, and RssShmem. This value is inaccurate; see /proc/pid/statm above.

RssAnon
Size of resident anonymous memory. (since Linux 4.5). This value is inaccurate; see /proc/pid/statm above.

RssFile
Size of resident file mappings. (since Linux 4.5). This value is inaccurate; see /proc/pid/statm above.

RssShmem
Size of resident shared memory (includes System V shared memory, mappings from tmpfs(5), and shared anonymous mappings). (since Linux 4.5).

VmData
VmStk
VmExe
Size of data, stack, and text segments. This value is inaccurate; see /proc/pid/statm above.

VmLib
Shared library code size.

VmPTE
Page table entries size (since Linux 2.6.10).

VmPMD
Size of second-level page tables (added in Linux 4.0; removed in Linux 4.15).

VmSwap
Swapped-out virtual memory size by anonymous private pages; shmem swap usage is not included (since Linux 2.6.34). This value is inaccurate; see /proc/pid/statm above.

HugetlbPages
Size of hugetlb memory portions (since Linux 4.4).

CoreDumping
Contains the value 1 if the process is currently dumping core, and 0 if it is not (since Linux 4.15). This information can be used by a monitoring process to avoid killing a process that is currently dumping core, which could result in a corrupted core dump file.

Threads
Number of threads in process containing this thread.

SigQ
This field contains two slash-separated numbers that relate to queued signals for the real user ID of this process. The first of these is the number of currently queued signals for this real user ID, and the second is the resource limit on the number of queued signals for this process (see the description of RLIMIT_SIGPENDING in getrlimit(2)).

SigPnd
ShdPnd
Mask (expressed in hexadecimal) of signals pending for thread and for process as a whole (see pthreads(7) and signal(7)).

SigBlk
SigIgn
SigCgt
Masks (expressed in hexadecimal) indicating signals being blocked, ignored, and caught (see signal(7)).

CapInh
CapPrm
CapEff
Masks (expressed in hexadecimal) of capabilities enabled in inheritable, permitted, and effective sets (see capabilities(7)).

CapBnd
Capability bounding set, expressed in hexadecimal (since Linux 2.6.26, see capabilities(7)).

CapAmb
Ambient capability set, expressed in hexadecimal (since Linux 4.3, see capabilities(7)).

NoNewPrivs
Value of the no_new_privs bit (since Linux 4.10, see prctl(2)).

Seccomp
Seccomp mode of the process (since Linux 3.8, see seccomp(2)). 0 means SECCOMP_MODE_DISABLED; 1 means SECCOMP_MODE_STRICT; 2 means SECCOMP_MODE_FILTER. This field is provided only if the kernel was built with the CONFIG_SECCOMP kernel configuration option enabled.

Seccomp_filters
Number of seccomp filters attached to the process (since Linux 5.9, see seccomp(2)).

Speculation_Store_Bypass
Speculation flaw mitigation state (since Linux 4.17, see prctl(2)).

Cpus_allowed
Hexadecimal mask of CPUs on which this process may run (since Linux 2.6.24, see cpuset(7)).

Cpus_allowed_list
Same as previous, but in “list format” (since Linux 2.6.26, see cpuset(7)).

Mems_allowed
Mask of memory nodes allowed to this process (since Linux 2.6.24, see cpuset(7)).

Mems_allowed_list
Same as previous, but in “list format” (since Linux 2.6.26, see cpuset(7)).

voluntary_ctxt_switches
nonvoluntary_ctxt_switches
Number of voluntary and involuntary context switches (since Linux 2.6.23).

17 - Linux cli command Xsession

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command Xsession and provides detailed information about the command Xsession, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the Xsession.

NAME 🖥️ Xsession 🖥️

initialize X session

SYNOPSIS

Xsession [ session-type ]

DESCRIPTION

/etc/X11/Xsession is a Bourne shell (sh(1)) script which is run when an X Window System session is begun by startx(1) or a display manager such as xdm(1). (Some display managers only invoke Xsession when specifically directed to so by the user; see the documentation for your display manager to find out more.) Administrators unfamiliar with the Bourne shell will likely find the Xsession.options(5) configuration file easier to deal with than Xsession itself.

Xsession is not intended to be invoked directly by the user; to be effective it needs to run in a special environment associated with X server initialization. startx, xdm, xinit(1), and other similar programs handle this.

By default on a Debian system, Xsession is used by both common methods of starting the X Window System, xdm (or another X display manager) and startx. To change this for xdm, edit the ‘DisplayManager*session’ resource in the /etc/X11/xdm/xdm-config file — for other display managers, consult their documentation. To stop startx from using Xsession by default, replace the contents of the /etc/X11/xinit/xinitrc file.

The Xsession script is quite flexible, and extensive customization of the X startup procedure is possible without modifying the script itself. See “CUSTOMIZING THE STARTUP PROCEDURE” below.

SESSION TYPES

Xsession may optionally be passed a single argument indicating the type of X session to be started. It is up to the display manager to set the argument. To pass Xsession an argument from startx or xinit, /etc/X11/Xsession (or /etc/X11/xinit/xinitrc) must be called explicitly with a path, as in startx /etc/X11/Xsession failsafe. By default, three different arguments are supported:

failsafe
invokes a session consisting solely of an x-terminal-emulator(1) (no window manager is launched). If the x-terminal-emulator program cannot be found, the session exits. The ‘failsafe’ argument is ignored if there is no ‘allow-failsafe’ line in Xsession.options.

default
produces the same behavior as if no session type argument had been given at all.

program
starts program if it can be found in the $PATH. This is usually a session manager or a very featureful window manager. If program is not found, the Xsession script proceeds with its default behavior. This argument is ignored if there is no ‘allow-user-xsession’ line in Xsession.options. (If the administrator does not want users writing their own .xsession files, it makes little sense to permit them to specify the names of arbitrary programs to run.) Note that the restriction may be easy to bypass, e.g. by using a .gnomerc file instead.

DEFAULT STARTUP PROCEDURE

Initially, Xsession performs some housekeeping. It declares a set of built-in functions (see “BUILT-IN SHELL FUNCTIONS” below) and variables, then attempts to create a log file for the X session, or append to an existing one. Historically this is called an ‘error’ file, but it catches all sorts of diagnostic output from various X clients run in the user’s session, not just error messages. If it is impossible to write to an error file, the script (and thus the X session) aborts. For convenience, once the error file is successfully opened, Xsession reports the fact that the session has started, the invoking username, and the date to the error file. This makes it easier to discern which X session produced a particular line of output in the file.

Xsession next confirms that its script directory, Xsession.d, exists. If it does not, the script aborts. After the script directory is confirmed to be present, Xsession uses run-parts(1) to identify files in that directory that should be sourced (executed) in the shell’s environment. Only files named in a certain way are sourced; see the run-parts manual page for a description of valid characters in the filename. (This restriction enables the administrator to move experimental or problematic files out of the way of the script but keep them in an obvious place, for instance by renaming them with ‘.old’ or ‘.broken’ appended to the filename.)

SUPPLIED SCRIPTS

Five shell script portions are supplied by default to handle the details of the session startup procedure.

/etc/X11/Xsession.d/20x11-common_process-args
Arguments are processed as described in “SESSION TYPES” above. The startup program, if one is identified at this point, is merely stored for later reference, and not immediately executed.

/etc/X11/Xsession.d/30x11-common_xresources
X resources are merged. run-parts is again used, this time to identify files in the /etc/X11/Xresources directory that should be processed with ‘xrdb -merge’. Next, if the line ‘allow-user-resources’ is present in Xsession.options, the user’s $HOME/.Xresources file is merged in the same way.

/etc/X11/Xsession.d/35x11-common_xhost-local
Give access to the X server to the same user on the local host. If the xhost command is available, it will use it to allow any process of the same user running on the local host to access the X server.

/etc/X11/Xsession.d/40x11-common_xsessionrc
Source global environment variables. This script will source anything in $HOME/.xsessionrc if the file is present. This allows the user to set global environment variables for their X session, such as locale information.

/etc/X11/Xsession.d/50x11-common_determine-startup
Determine startup program. The X client to launch as the controlling process (the one that, upon exiting, causes the X server to exit as well) is determined next. If a program or failsafe argument was given and is allowed (see above), it is used as the controlling process. Otherwise, if the line ‘allow-user-xsession’ is present in Xsession.options, a user-specified session program or script is used. In the latter case, two historically popular names for user X session scripts are searched for: $HOME/.xsession and $HOME/.Xsession (note the difference in case). The first one found is used. If the script is not executable, it is marked to be executed with the Bourne shell interpreter, sh. Finally, if none of the above succeeds, the following programs are searched for: /usr/bin/x-session-manager, /usr/bin/x-window-manager, and /usr/bin/x-terminal-emulator. The first one found is used. If none are found, Xsession aborts with an error.

/etc/X11/Xsession.d/90x11-common_ssh-agent
Start ssh-agent(1), if needed. If the line ‘use-ssh-agent’ is present in Xsession.options, and no SSH agent process appears to be running already, ssh-agent is marked to be used to execute the startup program determined previously. Note: this functionality may move to the ssh package in the future.

/etc/X11/Xsession.d/99x11-common_start
Start the X session. The startup program is executed, inside a Bourne shell if it is not executable, and inside an ssh-agent if necessary. The shell’s exec command is used to spare a slot in the process table.

CUSTOMIZING THE STARTUP PROCEDURE

Of course, any of the existing files can be edited in place.

Because the order in which the various scripts in /etc/X11/Xsession.d are executed is important, files to be added to this directory should have a well-formed name. The following format is recommended:

* a two-digit number denoting sequence;

* the name of the package providing the script (or ‘custom’ for locally-created scripts);

* an underscore;

* a description of the script’s basic function, using only characters allowed by run-parts.

Here is an example of how one might write a script, named 40custom_load-xmodmap, to invoke xmodmap(1):

SYSMODMAP="/etc/X11/Xmodmap"
USRMODMAP="$HOME/.Xmodmap"

if [ -x /usr/bin/X11/xmodmap ]; then
    if [ -f "$SYSMODMAP" ]; then
        xmodmap "$SYSMODMAP"
    fi
fi

if [ -x /usr/bin/X11/xmodmap ]; then
    if [ -f "$USRMODMAP" ]; then
        xmodmap "$USRMODMAP"
    fi
fi

Those writing scripts for Xsession to execute should avail themselves of its built-in shell functions, described below.

BUILT-IN SHELL FUNCTIONS

message is used for communicating with the user. It is a wrapper for the echo(1) command and relies upon echo for its argument processing. This function may be given an arbitrarily long message string, which is formatted to the user’s terminal width (breaking lines at whitespace) and sent to standard error. If the DISPLAY environment variable is set and the xmessage(1) program is available, xmessage is also used to display the message.

message_nonl is used for communicating with the user when a trailing newline is undesirable; it omits a trailing newline from the message text. It otherwise works as message.

errormsg is used for indicating an error condition and aborting the script. It works as message, above, except that after displaying the message, it will exit Xsession with status 1.

ENVIRONMENT

The following environment variables affect the execution of Xsession:

HOME
specifies the user’s home directory; various files are searched for here.

TMPDIR
names a default directory for temporary files; if the standard X session error file cannot be opened, this variable is used to locate a place for one.

COLUMNS
indicates the width of terminal device in character cells. This value is used for formatting diagnostic messages.

INPUT FILES

/etc/X11/Xsession.d/
is a directory containing Bourne shell scripts to be executed by Xsession. Files in this directory are matched using run-parts and are sourced, not executed in a subshell.

/etc/X11/Xresources/
is a directory containing files corresponding to Debian package names, each of which contains system-wide X resource settings for X clients from the corresponding package. The settings are loaded with xrdb -merge. Files in this directory are matched using run-parts.

/etc/X11/Xsession.options
contains configuration options for the /etc/X11/Xsession script. See Xsession.options(5) for more information.

$HOME/.Xresources
contains X resources specific to the invoking user’s environment. The settings are loaded with xrdb -merge. Note that $HOME/.Xdefaults is a relic from X Version 10 (and X11R1) days, before app-defaults files were implemented. It has been deprecated for over ten years at the time of this writing. .Xresources should be used instead.

$HOME/.xsession
is a sequence of commands invoking X clients (or a session manager such as xsm(1)). See the manual page for xinit for tips on writing an .xsession file.

OUTPUT FILES

$HOME/.xsession-errors
is where standard output and standard error for Xsession script and all X client processes are directed by default.

$TMPDIR/filename
is where the X session error file is placed if $HOME/.xsession-errors cannot be opened. For security reasons, the exact filename is randomly generated by tempfile(1).

AUTHORS

Stephen Early, Mark Eichin, and Branden Robinson developed Debian’s X session handling scripts. Branden Robinson wrote this manual page.

18 - Linux cli command sudo_plugin

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command sudo_plugin and provides detailed information about the command sudo_plugin, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the sudo_plugin.

Starting with version 1.8,

supports a plugin API for policy and session logging. Plugins may be compiled as dynamic shared objects (the default on systems that support them) or compiled statically into the

binary itself. By default, the

plugin provides audit, security policy and I/O logging capabilities. Via the plugin API,

can be configured to use alternate plugins provided by third parties. The plugins to be used are specified in the

file.

The API is versioned with a major and minor number. The minor version number is incremented when additions are made. The major number is incremented when incompatible changes are made. A plugin should be check the version passed to it and make sure that the major version matches.

The plugin API is defined by the

header file.

A policy plugin must declare and populate a

in the global scope. This structure contains pointers to the functions that implement the

policy checks. The name of the symbol should be specified in

along with a path to the plugin so that

can load it.

struct policy_plugin { #define SUDO_POLICY_PLUGIN 1 unsigned int type; /* always SUDO_POLICY_PLUGIN */ unsigned int version; /* always SUDO_API_VERSION */ int (*open)(unsigned int version, sudo_conv_t conversation, sudo_printf_t sudo_plugin_printf, char * const settings[], char * const user_info[], char * const user_env[], char * const plugin_options[], const char **errstr); void (*close)(int exit_status, int error); int (*show_version)(int verbose); int (*check_policy)(int argc, char * const argv[], char *env_add[], char **command_info[], char **argv_out[], char **user_env_out[], const char **errstr); int (*list)(int argc, char * const argv[], int verbose, const char *user, const char **errstr); int (*validate)(const char **errstr); void (*invalidate)(int rmcred); int (*init_session)(struct passwd *pwd, char **user_env[], const char **errstr); void (*register_hooks)(int version, int (*register_hook)(struct sudo_hook *hook)); void (*deregister_hooks)(int version, int (*deregister_hook)(struct sudo_hook *hook)); struct sudo_plugin_event * (*event_alloc)(void); };

has the following fields:

The

field should always be set to SUDO_POLICY_PLUGIN.

The

field should be set to

This allows

to determine the API version the plugin was built against.

int (*open)(unsigned int version, sudo_conv_t conversation, sudo_printf_t sudo_plugin_printf, char * const settings[], char * const user_info[], char * const user_env[], char * const plugin_options[], const char **errstr);

Returns 1 on success, 0 on failure, -1 if a general error occurred, or -2 if there was a usage error. In the latter case,

will print a usage message before it exits. If an error occurs, the plugin may optionally call the

function with

to present additional error information to the user.

The function arguments are as follows:

The version passed in by

allows the plugin to determine the major and minor version number of the plugin API supported by

A pointer to the

function that can be used by the plugin to interact with the user (see

for details). Returns 0 on success and -1 on failure.

A pointer to a

function that may be used to display informational or error messages (see

for details). Returns the number of characters printed on success and -1 on failure.

A vector of user-supplied

settings in the form of

strings. The vector is terminated by a

pointer. These settings correspond to options the user specified when running

As such, they will only be present when the corresponding option has been specified on the command line.

When parsing

the plugin should split on the

equal sign

since the

field will never include one itself but the

might.

The following values may be set by

Authentication type, if specified by the

option, to use on systems where

authentication is supported.

If specified, the user has requested via the

option that

close all files descriptors with a value of

or higher. The plugin may optionally pass this, or another value, back in the

list.

The root directory (see

to run the command in, as specified by the user via the

option. The plugin may ignore or restrict the user’s ability to specify a new root directory. Only available starting with API version 1.16.

The working directory to run the command in, as specified by the user via the

option. The plugin may ignore or restrict the user’s ability to specify a new working directory. Only available starting with API version 1.16.

A debug file path name followed by a space and a comma-separated list of debug flags that correspond to the plugin’s

entry in

if there is one. The flags are passed to the plugin exactly as they appear in

The syntax used by

and the

plugin is

but a plugin is free to use a different format so long as it does not include a comma

Prior to

1.8.12, there was no way to specify plugin-specific

so the value was always the same as that used by the

front-end and did not include a path name, only the flags themselves. As of version 1.7 of the plugin interface,

will only pass

contains a plugin-specific

entry.

Set to true if the user specified the

option along with a command, indicating that the user wishes to ignore any cached authentication credentials.

to true. This allows

with no arguments to be used similarly to

If the plugin does not to support this usage, it may return a value of -2 from the

function, which will cause

to print a usage message and exit.

If the user does not specify a program on the command line,

will pass the plugin the path to the user’s shell and set

Indicates whether or not the system supports intercept mode using

This is currently only true for Linux systems that support

filtering and the

action. Other systems will use a dynamic shared object to implement intercept. Only available starting with API version 1.19.

Indicates whether or not the system supports running set-user-ID and set-group-ID binaries in intercept mode. This is currently only true for Linux systems that support

filtering and the

action. On systems that use a dynamic shared object to implement intercept, the dynamic linker (ld.so or the equivalent) will disable preloading of shared objects when executing a set-user-ID or set-group-ID binary. This will disable intercept mode for that program and any other programs that it executes. The policy plugin may refuse to execute a set-user-ID or set-group-ID binary in intercept mode to avoid this. Only available starting with API version 1.19.

option.

Set to true if the user specified the

option, indicating that the user wishes to run a login shell.

The maximum number of groups a user may belong to. This will only be present if there is a corresponding setting in

A space-separated list of IP network addresses and netmasks in the form

e.g.,

The address and netmask pairs may be either IPv4 or IPv6, depending on what the operating system supports. If the address contains a colon

it is an IPv6 address, else it is IPv4.

Set to true if the user specified the

option, indicating that

should operate in non-interactive mode. The plugin may reject a command run in non-interactive mode if user interaction is required.

The default plugin directory used by the

front-end. This is the default directory set at compile time and may not correspond to the directory the running plugin was loaded from. It may be used by a plugin to locate support files.

The path name of plugin loaded by the

front-end. The path name will be a fully-qualified unless the plugin was statically compiled into

Set to true if the user specified the

option, indicating that the user wishes to preserve the environment.

Set to true if the user specified the

option, indicating that the user wishes to preserve the group vector instead of setting it based on the runas user.

The command name that sudo was run as, typically

The prompt to use when requesting a password, if specified via the

option.

The name of the remote host to run the command on, if specified via the

option. Support for running the command on a remote host is meant to be implemented via a helper program that is executed in place of the user-specified command. The

front-end is only capable of executing commands on the local host. Only available starting with API version 1.4.

Set to true if the user specified the

option, indicating that the user wishes to run a shell.

The group name or group-ID to run the command as, if specified via the

option.

The user name or user-ID to run the command as, if specified via the

option.

SELinux role to use when executing the command, if specified by the

option.

SELinux type to use when executing the command, if specified by the

option.

Set to true if the user specified the

option. If true, set the

environment variable to the target user’s home directory.

Set to true when the

option is specified or if invoked as

The plugin shall substitute an editor into

in the

function or return -2 with a usage error if the plugin does not support

For more information, see the

section.

Command timeout specified by the user via the

option. Not all plugins support command timeouts and the ability of the user to set a timeout may be restricted by policy. The format of the timeout string is plugin-specific.

Set to false if the user specified the

option, indicating that the user wishes to avoid updating any cached authentication credentials. Only available starting with API version 1.20.

Additional settings may be added in the future so the plugin should silently ignore settings that it does not recognize.

A vector of information about the user running the command in the form of

strings. The vector is terminated by a

pointer.

When parsing

the plugin should split on the

equal sign

since the

field will never include one itself but the

might.

The following values may be set by

The number of columns the user’s terminal supports. If there is no terminal device available, a default value of 80 is used.

The user’s current working directory.

The effective group-ID of the user invoking

The effective user-ID of the user invoking

The real group-ID of the user invoking

The user’s supplementary group list formatted as a string of comma-separated group-IDs.

The local machine’s hostname as returned by the

system call.

The number of lines the user’s terminal supports. If there is no terminal device available, a default value of 24 is used.

The ID of the process group that the running

process is a member of. Only available starting with API version 1.2.

The process ID of the running

process. Only available starting with API version 1.2.

The parent process ID of the running

process. Only available starting with API version 1.2.

The maximum size to which the process’s address space may grow (in bytes), if supported by the operating system. The soft and hard limits are separated by a comma. A value of

indicates that there is no limit. Only available starting with API version 1.16.

The largest size core dump file that may be created (in bytes). The soft and hard limits are separated by a comma. A value of

indicates that there is no limit. Only available starting with API version 1.16.

The maximum amount of CPU time that the process may use (in seconds). The soft and hard limits are separated by a comma. A value of

indicates that there is no limit. Only available starting with API version 1.16.

The maximum size of the data segment for the process (in bytes). The soft and hard limits are separated by a comma. A value of

indicates that there is no limit. Only available starting with API version 1.16.

The largest size file that the process may create (in bytes). The soft and hard limits are separated by a comma. A value of

indicates that there is no limit. Only available starting with API version 1.16.

The maximum number of locks that the process may establish, if supported by the operating system. The soft and hard limits are separated by a comma. A value of

indicates that there is no limit. Only available starting with API version 1.16.

The maximum size that the process may lock in memory (in bytes), if supported by the operating system. The soft and hard limits are separated by a comma. A value of

indicates that there is no limit. Only available starting with API version 1.16.

The maximum number of files that the process may have open. The soft and hard limits are separated by a comma. A value of

indicates that there is no limit. Only available starting with API version 1.16.

The maximum number of processes that the user may run simultaneously. The soft and hard limits are separated by a comma. A value of

indicates that there is no limit. Only available starting with API version 1.16.

The maximum size to which the process’s resident set size may grow (in bytes). The soft and hard limits are separated by a comma. A value of

indicates that there is no limit. Only available starting with API version 1.16.

The maximum size to which the process’s stack may grow (in bytes). The soft and hard limits are separated by a comma. A value of

indicates that there is no limit. Only available starting with API version 1.16.

The session ID of the running

process or 0 if

is not part of a POSIX job control session. Only available starting with API version 1.2.

The ID of the foreground process group associated with the terminal device associated with the

process or 0 if there is no terminal present. Only available starting with API version 1.2.

The path to the user’s terminal device. If the user has no terminal device associated with the session, the value will be empty, as in

The real user-ID of the user invoking

The invoking user’s file creation mask. Only available starting with API version 1.10.

The name of the user invoking

The user’s environment in the form of a

strings.

When parsing

the plugin should split on the

equal sign

since the

field will never include one itself but the

might.

Any (non-comment) strings immediately after the plugin path are passed as arguments to the plugin. These arguments are split on a white space boundary and are passed to the plugin in the form of a

array of strings. If no arguments were specified,

will be the

pointer.

The

parameter is only available starting with API version 1.2. A plugin

check the API version specified by the

front-end before using

Failure to do so may result in a crash.

If the

function returns a value other than 1, the plugin may store a message describing the failure or error in

The

front-end will then pass this value to any registered audit plugins. The string stored in

must remain valid until the plugin’s

function is called.

The

parameter is only available starting with API version 1.15. A plugin

check the API version specified by the

front-end before using

Failure to do so may result in a crash.

void (*close)(int exit_status, int error);

The

function is called when

is finished, shortly before it exits. Starting with API version 1.15,

is called regardless of whether or not a command was actually executed. This makes it possible for plugins to perform cleanup even when a command was not run. It is not possible to tell whether a command was run based solely on the arguments passed to the

function. To determine if a command was actually run, the plugin must keep track of whether or not the

function returned successfully.

The function arguments are as follows:

The command’s exit status, as returned by the

system call, or zero if no command was run. The value of

is undefined if

is non-zero.

If the command could not be executed, this is set to the value of

set by the

system call. The plugin is responsible for displaying error information via the

function. If the command was successfully executed, the value of

is zero.

If no

function is defined, no I/O logging plugins are loaded, and neither the

nor

options are set in the

list, the

front-end may execute the command directly instead of running it as a child process.

int (*show_version)(int verbose);

The

function is called by

when the user specifies the

option. The plugin may display its version information to the user via the

function using

If the user requests detailed version information, the

flag will be non-zero.

Returns 1 on success, 0 on failure, -1 if a general error occurred, or -2 if there was a usage error, although the return value is currently ignored.

int (*check_policy)(int argc, char * const argv[], char *env_add[], char **command_info[], char **argv_out[], char **user_env_out[], const char **errstr);

The

function is called by

to determine whether the user is allowed to run the specified commands.

If the

option was enabled in the

array passed to the

function, the user has requested

mode.

is a mechanism for editing one or more files where an editor is run with the user’s credentials instead of with elevated privileges.

achieves this by creating user-writable temporary copies of the files to be edited and then overwriting the originals with the temporary copies after editing is complete. If the plugin supports

it must set

in the

list. The plugin is responsible for choosing the editor to be used, potentially from a variable in the user’s environment, such as

and should be stored in

(environment variables may include command line options). The files to be edited should be copied from

separated from the editor and its arguments by a

element. The

will be removed by

before the editor is executed. The plugin may also set

to the number of files to be edited in the

list; this will only be used by the

front-end starting with API version 1.21.

The

function returns 1 if the command is allowed, 0 if not allowed, -1 for a general error, or -2 for a usage error or if

was specified but is unsupported by the plugin. In the latter case,

will print a usage message before it exits. If an error occurs, the plugin may optionally call the

function with

to present additional error information to the user.

The function arguments are as follows:

The number of elements in

not counting the final

pointer.

The argument vector describing the command the user wishes to run, in the same form as what would be passed to the

system call. The vector is terminated by a

pointer.

Additional environment variables specified by the user on the command line in the form of a

vector of

strings. The plugin may reject the command if one or more variables are not allowed to be set, or it may silently ignore such variables.

When parsing

the plugin should split on the

equal sign

since the

field will never include one itself but the

might.

Information about the command being run in the form of

strings. These values are used by

to set the execution environment when running a command. The plugin is responsible for creating and populating the vector, which must be terminated with a

pointer. The following values are recognized by

AppArmor profile to transition to when executing the command. Only available starting with API version 1.19.

The root directory to use when running the command.

If specified,

will close all files descriptors with a value of

or higher.

Fully qualified path to the command to be executed.

The current working directory to change to when executing the command. If

is unable to change to the new working directory, the command will not be run unless

is also set (see below).

If set,

will treat an inability to change to the new working directory as a non-fatal error. This setting has no effect unless

is also set.

By default,

runs a command as the foreground process as long as

itself is running in the foreground. When

is enabled and the command is being run in a pseudo-terminal (due to I/O logging or the

setting), the command will be run as a background process. Attempts to read from the controlling terminal (or to change terminal settings) will result in the command being suspended with the

signal (or

in the case of terminal settings). If this happens when

is a foreground process, the command will be granted the controlling terminal and resumed in the foreground with no user intervention required. The advantage of initially running the command in the background is that

need not read from the terminal unless the command explicitly requests it. Otherwise, any terminal input must be passed to the command, whether it has required it or not (the kernel buffers terminals so it is not possible to tell whether the command really wants the input). This is different from historic

behavior or when the command is not being run in a pseudo-terminal.

For this to work seamlessly, the operating system must support the automatic restarting of system calls. Unfortunately, not all operating systems do this by default, and even those that do may have bugs. For example, macOS fails to restart the

and

system calls (this is a bug in macOS). Furthermore, because this behavior depends on the command stopping with the

signals, programs that catch these signals and suspend themselves with a different signal (usually

will not be automatically foregrounded. Some versions of the linux

command behave this way. Because of this, a plugin should not set

unless it is explicitly enabled by the administrator and there should be a way to enabled or disable it on a per-command basis.

This setting has no effect unless I/O logging is enabled or

is enabled.

If specified,

will use the

system call to execute the command instead of

The specified

must refer to an open file descriptor.

If set,

will intercept attempts to execute a subsequent command and perform a policy check via the policy plugin’s

function to determine whether or not the command is permitted. This can be used to prevent shell escapes on supported platforms but it has a number of limitations. See

for details. Only available starting with API version 1.18.

If set,

will attempt to verify that a command run in intercept mode has the expected path name, command line arguments and environment. This setting has no effect unless

is also enabled. Only available starting with API version 1.20.

Set to true if the I/O logging plugins, if any, should compress the log data. This is a hint to the I/O logging plugin which may choose to ignore it.

The group that will own newly created I/O log files and directories. This is a hint to the I/O logging plugin which may choose to ignore it.

The file permission mode to use when creating I/O log files and directories. This is a hint to the I/O logging plugin which may choose to ignore it.

The user that will own newly created I/O log files and directories. This is a hint to the I/O logging plugin which may choose to ignore it.

Fully qualified path to the file or directory in which I/O log is to be stored. This is a hint to the I/O logging plugin which may choose to ignore it. If no I/O logging plugin is loaded, this setting has no effect.

Set to true if the I/O logging plugins, if any, should log the standard input if it is not connected to a terminal device. This is a hint to the I/O logging plugin which may choose to ignore it.

Set to true if the I/O logging plugins, if any, should log the standard output if it is not connected to a terminal device. This is a hint to the I/O logging plugin which may choose to ignore it.

Set to true if the I/O logging plugins, if any, should log the standard error if it is not connected to a terminal device. This is a hint to the I/O logging plugin which may choose to ignore it.

Set to true if the I/O logging plugins, if any, should log all terminal input. This only includes input typed by the user and not from a pipe or redirected from a file. This is a hint to the I/O logging plugin which may choose to ignore it.

Set to true if the I/O logging plugins, if any, should log all terminal output. This only includes output to the screen, not output to a pipe or file. This is a hint to the I/O logging plugin which may choose to ignore it.

login class to use when setting resource limits and nice value (optional). This option is only set on systems that support login classes.

Nice value (priority) to use when executing the command. The nice value, if specified, overrides the priority associated with the

systems.

If set,

will call the audit plugin’s

function to log when the command runs a subsequent command, if supported by the system. If

is also specified,

will be ignored. See

for more information. Only available starting with API version 1.18.

If set, prevent the command from executing other programs.

A comma-separated list of file descriptors that should be preserved, regardless of the value of the

setting. Only available starting with API version 1.5.

If set,

will preserve the user’s group vector instead of initializing the group vector based on

The maximum size to which the process’s address space may grow (in bytes), if supported by the operating system. The soft and hard limits are separated by a comma. If only a single value is specified, both the hard and soft limits are set. A value of

indicates that there is no limit. A value of

will cause the invoking user’s resource limit to be preserved. A value of

will cause the target user’s default resource limit to be used on systems that allow per-user resource limits to be configured. Only available starting with API version 1.18.

The largest size core dump file that may be created (in bytes). The soft and hard limits are separated by a comma. If only a single value is specified, both the hard and soft limits are set. A value of

indicates that there is no limit. A value of

will cause the invoking user’s resource limit to be preserved. A value of

will cause the target user’s default resource limit to be used on systems that allow per-user resource limits to be configured. Only available starting with API version 1.18.

The maximum amount of CPU time that the process may use (in seconds). The soft and hard limits are separated by a comma. If only a single value is specified, both the hard and soft limits are set. A value of

indicates that there is no limit. A value of

will cause the invoking user’s resource limit to be preserved. A value of

will cause the target user’s default resource limit to be used on systems that allow per-user resource limits to be configured. Only available starting with API version 1.18.

The maximum size of the data segment for the process (in bytes). The soft and hard limits are separated by a comma. If only a single value is specified, both the hard and soft limits are set. A value of

indicates that there is no limit. A value of

will cause the invoking user’s resource limit to be preserved. A value of

will cause the target user’s default resource limit to be used on systems that allow per-user resource limits to be configured. Only available starting with API version 1.18.

The largest size file that the process may create (in bytes). The soft and hard limits are separated by a comma. If only a single value is specified, both the hard and soft limits are set. A value of

indicates that there is no limit. A value of

will cause the invoking user’s resource limit to be preserved. A value of

will cause the target user’s default resource limit to be used on systems that allow per-user resource limits to be configured. Only available starting with API version 1.18.

The maximum number of locks that the process may establish, if supported by the operating system. The soft and hard limits are separated by a comma. If only a single value is specified, both the hard and soft limits are set. A value of

indicates that there is no limit. A value of

will cause the invoking user’s resource limit to be preserved. A value of

will cause the target user’s default resource limit to be used on systems that allow per-user resource limits to be configured. Only available starting with API version 1.18.

The maximum size that the process may lock in memory (in bytes), if supported by the operating system. The soft and hard limits are separated by a comma. If only a single value is specified, both the hard and soft limits are set. A value of

indicates that there is no limit. A value of

will cause the invoking user’s resource limit to be preserved. A value of

will cause the target user’s default resource limit to be used on systems that allow per-user resource limits to be configured. Only available starting with API version 1.18.

The maximum number of files that the process may have open. The soft and hard limits are separated by a comma. If only a single value is specified, both the hard and soft limits are set. A value of

indicates that there is no limit. A value of

will cause the invoking user’s resource limit to be preserved. A value of

will cause the target user’s default resource limit to be used on systems that allow per-user resource limits to be configured. Only available starting with API version 1.18.

The maximum number of processes that the user may run simultaneously. The soft and hard limits are separated by a comma. If only a single value is specified, both the hard and soft limits are set. A value of

indicates that there is no limit. A value of

will cause the invoking user’s resource limit to be preserved. A value of

will cause the target user’s default resource limit to be used on systems that allow per-user resource limits to be configured. Only available starting with API version 1.18.

The maximum size to which the process’s resident set size may grow (in bytes). The soft and hard limits are separated by a comma. If only a single value is specified, both the hard and soft limits are set. A value of

indicates that there is no limit. A value of

will cause the invoking user’s resource limit to be preserved. A value of

will cause the target user’s default resource limit to be used on systems that allow per-user resource limits to be configured. Only available starting with API version 1.18.

The maximum size to which the process’s stack may grow (in bytes). The soft and hard limits are separated by a comma. If only a single value is specified, both the hard and soft limits are set. A value of

indicates that there is no limit. A value of

will cause the invoking user’s resource limit to be preserved. A value of

will cause the target user’s default resource limit to be used on systems that allow per-user resource limits to be configured. Only available starting with API version 1.18.

Effective group-ID to run the command as. If not specified, the value of

is used.

Effective user-ID to run the command as. If not specified, the value of

is used.

Group-ID to run the command as.

The name of the group the command will run as, if it is different from the

default group. This value is provided for auditing purposes only, the

front-end uses

and

when executing the command.

The supplementary group vector to use for the command in the form of a comma-separated list of group-IDs. If

is set, this option is ignored.

User-ID to run the command as.

The name of the user the command will run as, which should correspond to

(or

is not set). This value is provided for auditing purposes only, the

front-end uses

and

when executing the command.

SELinux role to use when executing the command.

SELinux type to use when executing the command.

Create a utmp (or utmpx) entry when a pseudo-terminal is allocated. By default, the new entry will be a copy of the user’s existing utmp entry (if any), with the tty, time, type, and pid fields updated.

Set to true when in

mode. The plugin may enable

mode even if

was not invoked as

This allows the plugin to perform command substitution and transparently enable

when the user attempts to run an editor.

Set to false to disable directory writability checks in

By default,

1.8.16 and higher will check all directory components of the path to be edited for writability by the invoking user. Symbolic links will not be followed in writable directories and

will refuse to edit a file located in a writable directory. These restrictions are not enforced when

is run by root. The

option can be set to false to disable this check. Only available starting with API version 1.8.

Set to true to allow

to edit files that are symbolic links. By default,

1.8.15 and higher will refuse to open a symbolic link. The

option can be used to restore the older behavior and allow

to open symbolic links. Only available starting with API version 1.8.

The number of files to be edited by the user. If present, this is will be used by the

front-end to determine which elements of the

vector are files to be edited. The

element must immediately precede the first file to be editied. If

is not specified, the

front-end will use the position of the

element to determine where the file list begins. Only available starting with API version 1.21.

Command timeout. If non-zero then when the timeout expires the command will be killed.

The file creation mask to use when executing the command. This value may be overridden by PAM or login.conf on some systems unless the

option is also set.

Force the value specified by the

option to override any umask set by PAM or login.conf.

If set,

will use

to implement intercept mode if supported by the system. This setting has no effect unless

is also set. Only available starting with API version 1.19.

Allocate a pseudo-terminal to run the command in, regardless of whether or not I/O logging is in use. By default,

will only run the command in a pseudo-terminal when an I/O log plugin is loaded.

User name to use when constructing a new utmp (or utmpx) entry when

is enabled. This option can be used to set the user field in the utmp entry to the user the command runs as rather than the invoking user. If not set,

will base the new entry on the invoking user’s existing entry.

Unsupported values will be ignored.

The

argument vector to pass to the

system call when executing the command. The plugin is responsible for allocating and populating the vector.

The

environment vector to use when executing the command. The plugin is responsible for allocating and populating the vector.

If the

function returns a value other than 1, the plugin may store a message describing the failure or error in

The

front-end will then pass this value to any registered audit plugins. The string stored in

must remain valid until the plugin’s

function is called.

The

parameter is only available starting with API version 1.15. A plugin

check the API version specified by the

front-end before using

Failure to do so may result in a crash.

int (*list)(int argc, char * const argv[], int verbose, const char *user, const char **errstr);

List available privileges for the invoking user. Returns 1 on success, 0 on failure, and -1 on error. On error, the plugin may optionally call the

function with

to present additional error information to the user.

Privileges should be output via the

function using

The function arguments are as follows:

The number of elements in

not counting the final

pointer.

an argument vector describing a command the user wishes to check against the policy in the same form as what would be passed to the

system call. If the command is permitted by the policy, the fully-qualified path to the command should be displayed along with any command line arguments.

Flag indicating whether to list in verbose mode or not.

The name of a different user to list privileges for if the policy allows it. If

the plugin should list the privileges of the invoking user.

If the

function returns a value other than 1, the plugin may store a message describing the failure or error in

The

front-end will then pass this value to any registered audit plugins. The string stored in

must remain valid until the plugin’s

function is called.

The

parameter is only available starting with API version 1.15. A plugin

check the API version specified by the

front-end before using

Failure to do so may result in a crash.

int (*validate)(const char **errstr);

The

function is called when

is run with the

option. For policy plugins such as

that cache authentication credentials, this function will validate and cache the credentials.

The

function should be

if the plugin does not support credential caching.

Returns 1 on success, 0 on failure, and -1 on error. On error, the plugin may optionally call the

function with

to present additional error information to the user.

The function arguments are as follows:

If the

function returns a value other than 1, the plugin may store a message describing the failure or error in

The

front-end will then pass this value to any registered audit plugins. The string stored in

must remain valid until the plugin’s

function is called.

The

parameter is only available starting with API version 1.15. A plugin

check the API version specified by the

front-end before using

Failure to do so may result in a crash.

void (*invalidate)(int rmcred);

The

function is called when

is run with the

option. For policy plugins such as

that cache authentication credentials, this function will invalidate the credentials. If the

flag is non-zero, the plugin may remove the credentials instead of simply invalidating them.

The

function should be

if the plugin does not support credential caching.

int (*init_session)(struct passwd *pwd, char **user_env[], const char **errstr);

The

function is called before

sets up the execution environment for the command. It is run in the parent

process before any user-ID or group-ID changes. This can be used to perform session setup that is not supported by

such as opening the PAM session. The

function can be used to tear down the session that was opened by

Returns 1 on success, 0 on failure, and -1 on error. On error, the plugin may optionally call the

function with

to present additional error information to the user.

The function arguments are as follows:

If the user-ID the command will run as was found in the password database,

will describe that user, otherwise it will be

The

environment vector to use when executing the command. This is the same string passed back to the front-end via the Policy Plugin’s

parameter. If the

function needs to modify the user environment, it should update the pointer stored in

The expected use case is to merge the contents of the PAM environment (if any) with the contents of

The

parameter is only available starting with API version 1.2. A plugin

check the API version specified by the

front-end before using

Failure to do so may result in a crash.

If the

function returns a value other than 1, the plugin may store a message describing the failure or error in

The

front-end will then pass this value to any registered audit plugins. The string stored in

must remain valid until the plugin’s

function is called.

The

parameter is only available starting with API version 1.15. A plugin

check the API version specified by the

front-end before using

Failure to do so may result in a crash.

void (*register_hooks)(int version, int (*register_hook)(struct sudo_hook *hook));

The

function is called by the sudo front-end to register any hooks the plugin needs. If the plugin does not support hooks,

should be set to the

pointer.

The

argument describes the version of the hooks API supported by the

front-end.

The

function should be used to register any supported hooks the plugin needs. It returns 0 on success, 1 if the hook type is not supported, and -1 if the major version in

does not match the front-end’s major hook API version.

See the

section below for more information about hooks.

The

function is only available starting with API version 1.2. If the

front-end doesn’t support API version 1.2 or higher,

will not be called.

void (*deregister_hooks)(int version, int (*deregister_hook)(struct sudo_hook *hook));

The

function is called by the sudo front-end to deregister any hooks the plugin has registered. If the plugin does not support hooks,

should be set to the

pointer.

The

argument describes the version of the hooks API supported by the

front-end.

The

function should be used to deregister any hooks that were put in place by the

function. If the plugin tries to deregister a hook that the front-end does not support,

will return an error.

See the

section below for more information about hooks.

The

function is only available starting with API version 1.2. If the

front-end doesn’t support API version 1.2 or higher,

will not be called.

struct sudo_plugin_event * (*event_alloc)(void);

The

function is used to allocate a

which provides access to the main

event loop. Unlike the other fields, the

pointer is filled in by the

front-end, not by the plugin.

See the

section below for more information about events.

The

function is only available starting with API version 1.15. If the

front-end doesn’t support API version 1.15 or higher,

will not be set.

/* Plugin API version major/minor. */ #define SUDO_API_VERSION_MAJOR 1 #define SUDO_API_VERSION_MINOR 13 #define SUDO_API_MKVERSION(x, y) ((x << 16) | y) #define SUDO_API_VERSION SUDO_API_MKVERSION(SUDO_API_VERSION_MAJOR,\ SUDO_API_VERSION_MINOR)

/* Getters and setters for API version */ #define SUDO_API_VERSION_GET_MAJOR(v) ((v) >> 16) #define SUDO_API_VERSION_GET_MINOR(v) ((v) & 0xffff) #define SUDO_API_VERSION_SET_MAJOR(vp, n) do { \ *(vp) = (*(vp) & 0x0000ffff) | ((n) << 16); \ } while(0) #define SUDO_API_VERSION_SET_MINOR(vp, n) do { \ *(vp) = (*(vp) & 0xffff0000) | (n); \ } while(0)

struct io_plugin { #define SUDO_IO_PLUGIN 2 unsigned int type; /* always SUDO_IO_PLUGIN */ unsigned int version; /* always SUDO_API_VERSION */ int (*open)(unsigned int version, sudo_conv_t conversation, sudo_printf_t sudo_plugin_printf, char * const settings[], char * const user_info[], char * const command_info[], int argc, char * const argv[], char * const user_env[], char * const plugin_options[], const char **errstr); void (*close)(int exit_status, int error); /* wait status or error */ int (*show_version)(int verbose); int (*log_ttyin)(const char *buf, unsigned int len, const char **errstr); int (*log_ttyout)(const char *buf, unsigned int len, const char **errstr); int (*log_stdin)(const char *buf, unsigned int len, const char **errstr); int (*log_stdout)(const char *buf, unsigned int len, const char **errstr); int (*log_stderr)(const char *buf, unsigned int len, const char **errstr); void (*register_hooks)(int version, int (*register_hook)(struct sudo_hook *hook)); void (*deregister_hooks)(int version, int (*deregister_hook)(struct sudo_hook *hook)); int (*change_winsize)(unsigned int lines, unsigned int cols, const char **errstr); int (*log_suspend)(int signo, const char **errstr); struct sudo_plugin_event * (*event_alloc)(void); };

When an I/O plugin is loaded,

runs the command in a pseudo-terminal. This makes it possible to log the input and output from the user’s session. If any of the standard input, standard output, or standard error do not correspond to a tty,

will open a pipe to capture the I/O for logging before passing it on.

The

function receives the raw user input from the terminal device (this will include input even when echo is disabled, such as when a password is read). The

function receives output from the pseudo-terminal that is suitable for replaying the user’s session at a later time. The

and

functions are only called if the standard input, standard output, or standard error respectively correspond to something other than a tty.

Any of the logging functions may be set to the

pointer if no logging is to be performed. If the open function returns 0, no I/O will be sent to the plugin.

If a logging function returns an error

the running command will be terminated and all of the plugin’s logging functions will be disabled. Other I/O logging plugins will still receive any remaining input or output that has not yet been processed.

If an input logging function rejects the data by returning 0, the command will be terminated and the data will not be passed to the command, though it will still be sent to any other I/O logging plugins. If an output logging function rejects the data by returning 0, the command will be terminated and the data will not be written to the terminal, though it will still be sent to any other I/O logging plugins.

has the following fields:

The

field should always be set to

The

field should be set to

This allows

to determine the API version the plugin was built against.

int (*open)(unsigned int version, sudo_conv_t conversation, sudo_printf_t sudo_plugin_printf, char * const settings[], char * const user_info[], char * const command_info[], int argc, char * const argv[], char * const user_env[], char * const plugin_options[]);

The

function is run before the

functions are called. It is only called if the version is being requested or if the policy plugin’s

function has returned successfully. It returns 1 on success, 0 on failure, -1 if a general error occurred, or -2 if there was a usage error. In the latter case,

will print a usage message before it exits. If an error occurs, the plugin may optionally call the

function with

to present additional error information to the user.

The function arguments are as follows:

The version passed in by

allows the plugin to determine the major and minor version number of the plugin API supported by

A pointer to the

function that may be used by the

function to display version information (see

below). The

function may also be used to display additional error message to the user. The

function returns 0 on success and -1 on failure.

A pointer to a

function that may be used by the

function to display version information (see show_version below). The

function may also be used to display additional error message to the user. The

function returns number of characters printed on success and -1 on failure.

A vector of user-supplied

settings in the form of

strings. The vector is terminated by a

pointer. These settings correspond to options the user specified when running

As such, they will only be present when the corresponding option has been specified on the command line.

When parsing

the plugin should split on the

equal sign

since the

field will never include one itself but the

might.

See the

section for a list of all possible settings.

A vector of information about the user running the command in the form of

strings. The vector is terminated by a

pointer.

When parsing

the plugin should split on the

equal sign

since the

field will never include one itself but the

might.

See the

section for a list of all possible strings.

A vector of information describing the command being run in the form of

strings. The vector is terminated by a

pointer.

When parsing

the plugin should split on the

equal sign

since the

field will never include one itself but the

might.

See the

section for a list of all possible strings.

The number of elements in

not counting the final

pointer. It can be zero, such as when

is called with the

option.

an argument vector describing a command the user wishes to run in the same form as what would be passed to the

system call.

The user’s environment in the form of a

vector of

strings.

When parsing

the plugin should split on the

equal sign

since the

field will never include one itself but the

might.

Any (non-comment) strings immediately after the plugin path are treated as arguments to the plugin. These arguments are split on a white space boundary and are passed to the plugin in the form of a

array of strings. If no arguments were specified,

will be the

pointer.

The

parameter is only available starting with API version 1.2. A plugin

check the API version specified by the

front-end before using

Failure to do so may result in a crash.

If the

function returns a value other than 1, the plugin may store a message describing the failure or error in

The

front-end will then pass this value to any registered audit plugins. The string stored in

must remain valid until the plugin’s

function is called.

The

parameter is only available starting with API version 1.15. A plugin

check the API version specified by the

front-end before using

Failure to do so may result in a crash.

void (*close)(int exit_status, int error);

The

function is called when

is finished, shortly before it exits.

The function arguments are as follows:

The command’s exit status, as returned by the

system call, or zero if no command was run. The value of

is undefined if

is non-zero.

If the command could not be executed, this is set to the value of

set by the

system call. If the command was successfully executed, the value of

is zero.

int (*show_version)(int verbose);

The

function is called by

when the user specifies the

option. The plugin may display its version information to the user via the

function using

If the user requests detailed version information, the

flag will be non-zero.

Returns 1 on success, 0 on failure, -1 if a general error occurred, or -2 if there was a usage error, although the return value is currently ignored.

int (*log_ttyin)(const char *buf, unsigned int len, const char **errstr);

The

function is called whenever data can be read from the user but before it is passed to the running command. This allows the plugin to reject data if it chooses to (for instance if the input contains banned content). Returns 1 if the data should be passed to the command, 0 if the data is rejected (which will terminate the running command), or -1 if an error occurred.

The function arguments are as follows:

The buffer containing user input.

The length of

in bytes.

If the

function returns a value other than 1, the plugin may store a message describing the failure or error in

The

front-end will then pass this value to any registered audit plugins. The string stored in

must remain valid until the plugin’s

function is called.

The

parameter is only available starting with API version 1.15. A plugin

check the API version specified by the

front-end before using

Failure to do so may result in a crash.

int (*log_ttyout)(const char *buf, unsigned int len, const char **errstr);

The

function is called whenever data can be read from the command but before it is written to the user’s terminal. This allows the plugin to reject data if it chooses to (for instance if the output contains banned content). Returns 1 if the data should be passed to the user, 0 if the data is rejected (which will terminate the running command), or -1 if an error occurred.

The function arguments are as follows:

The buffer containing command output.

The length of

in bytes.

If the

function returns a value other than 1, the plugin may store a message describing the failure or error in

The

front-end will then pass this value to any registered audit plugins. The string stored in

must remain valid until the plugin’s

function is called.

The

parameter is only available starting with API version 1.15. A plugin

check the API version specified by the

front-end before using

Failure to do so may result in a crash.

int (*log_stdin)(const char *buf, unsigned int len, const char **errstr);

The

function is only used if the standard input does not correspond to a tty device. It is called whenever data can be read from the standard input but before it is passed to the running command. This allows the plugin to reject data if it chooses to (for instance if the input contains banned content). Returns 1 if the data should be passed to the command, 0 if the data is rejected (which will terminate the running command), or -1 if an error occurred.

The function arguments are as follows:

The buffer containing user input.

The length of

in bytes.

If the

function returns a value other than 1, the plugin may store a message describing the failure or error in

The

front-end will then pass this value to any registered audit plugins. The string stored in

must remain valid until the plugin’s

function is called.

The

parameter is only available starting with API version 1.15. A plugin

check the API version specified by the

front-end before using

Failure to do so may result in a crash.

int (*log_stdout)(const char *buf, unsigned int len, const char **errstr);

The

function is only used if the standard output does not correspond to a tty device. It is called whenever data can be read from the command but before it is written to the standard output. This allows the plugin to reject data if it chooses to (for instance if the output contains banned content). Returns 1 if the data should be passed to the user, 0 if the data is rejected (which will terminate the running command), or -1 if an error occurred.

The function arguments are as follows:

The buffer containing command output.

The length of

in bytes.

If the

function returns a value other than 1, the plugin may store a message describing the failure or error in

The

front-end will then pass this value to any registered audit plugins. The string stored in

must remain valid until the plugin’s

function is called.

The

parameter is only available starting with API version 1.15. A plugin

check the API version specified by the

front-end before using

Failure to do so may result in a crash.

int (*log_stderr)(const char *buf, unsigned int len, const char **errstr);

The

function is only used if the standard error does not correspond to a tty device. It is called whenever data can be read from the command but before it is written to the standard error. This allows the plugin to reject data if it chooses to (for instance if the output contains banned content). Returns 1 if the data should be passed to the user, 0 if the data is rejected (which will terminate the running command), or -1 if an error occurred.

The function arguments are as follows:

The buffer containing command output.

The length of

in bytes.

If the

function returns a value other than 1, the plugin may store a message describing the failure or error in

The

front-end will then pass this value to any registered audit plugins. The string stored in

must remain valid until the plugin’s

function is called.

The

parameter is only available starting with API version 1.15. A plugin

check the API version specified by the

front-end before using

Failure to do so may result in a crash.

See the

section for a description of

See the

section for a description of

int (*change_winsize)(unsigned int lines, unsigned int cols, const char **errstr);

The

function is called whenever the window size of the terminal changes from the initial values specified in the

list. Returns -1 if an error occurred, in which case no further calls to

will be made,

The function arguments are as follows:

The number of lines (rows) in the re-sized terminal.

The number of columns in the re-sized terminal.

If the

function returns a value other than 1, the plugin may store a message describing the failure or error in

The

front-end will then pass this value to any registered audit plugins. The string stored in

must remain valid until the plugin’s

function is called.

The

parameter is only available starting with API version 1.15. A plugin

check the API version specified by the

front-end before using

Failure to do so may result in a crash.

int (*log_suspend)(int signo, const char **errstr);

The

function is called whenever a command is suspended or resumed. Logging this information makes it possible to skip the period of time when the command was suspended during playback of a session. Returns -1 if an error occurred, in which case no further calls to

will be made,

The function arguments are as follows:

The signal that caused the command to be suspended, or

if the command was resumed.

If the

function returns a value other than 1, the plugin may store a message describing the failure or error in

The

front-end will then pass this value to any registered audit plugins. The string stored in

must remain valid until the plugin’s

function is called.

The

parameter is only available starting with API version 1.15. A plugin

check the API version specified by the

front-end before using

Failure to do so may result in a crash.

struct sudo_plugin_event * (*event_alloc)(void);

The

function is used to allocate a

which provides access to the main

event loop. Unlike the other fields, the

pointer is filled in by the

front-end, not by the plugin.

See the

section below for more information about events.

The

function is only available starting with API version 1.15. If the

front-end doesn’t support API version 1.15 or higher,

will not be set.

Same as for the

/* Audit plugin close function status types. */ #define SUDO_PLUGIN_NO_STATUS 0 #define SUDO_PLUGIN_WAIT_STATUS 1 #define SUDO_PLUGIN_EXEC_ERROR 2 #define SUDO_PLUGIN_SUDO_ERROR 3

#define SUDO_AUDIT_PLUGIN 3 struct audit_plugin { unsigned int type; /* always SUDO_AUDIT_PLUGIN */ unsigned int version; /* always SUDO_API_VERSION */ int (*open)(unsigned int version, sudo_conv_t conversation, sudo_printf_t sudo_plugin_printf, char * const settings[], char * const user_info[], int submit_optind, char * const submit_argv[], char * const submit_envp[], char * const plugin_options[], const char **errstr); void (*close)(int status_type, int status); int (*accept)(const char *plugin_name, unsigned int plugin_type, char * const command_info[], char * const run_argv[], char * const run_envp[], const char **errstr); int (*reject)(const char *plugin_name, unsigned int plugin_type, const char *audit_msg, char * const command_info[], const char **errstr); int (*error)(const char *plugin_name, unsigned int plugin_type, const char *audit_msg, char * const command_info[], const char **errstr); int (*show_version)(int verbose); void (*register_hooks)(int version, int (*register_hook)(struct sudo_hook *hook)); void (*deregister_hooks)(int version, int (*deregister_hook)(struct sudo_hook *hook)); struct sudo_plugin_event * (*event_alloc)(void); }

An audit plugin can be used to log successful and unsuccessful attempts to run

independent of the policy or any I/O plugins. Multiple audit plugins may be specified in

has the following fields:

The

field should always be set to

The

field should be set to

This allows

to determine the API version the plugin was built against.

int (*open)(unsigned int version, sudo_conv_t conversation, sudo_printf_t sudo_plugin_printf, char * const settings[], char * const user_info[], int submit_optind, char * const submit_argv[], char * const submit_envp[], char * const plugin_options[], const char **errstr);

The audit

function is run before any other

plugin API functions. This makes it possible to audit failures in the other plugins. It returns 1 on success, 0 on failure, -1 if a general error occurred, or -2 if there was a usage error. In the latter case,

will print a usage message before it exits. If an error occurs, the plugin may optionally call the

function with

to present additional error information to the user.

The function arguments are as follows:

The version passed in by

allows the plugin to determine the major and minor version number of the plugin API supported by

A pointer to the

function that may be used by the

function to display version information (see

below). The

function may also be used to display additional error message to the user. The

function returns 0 on success, and -1 on failure.

A pointer to a

function that may be used by the

function to display version information (see show_version below). The

function may also be used to display additional error message to the user. The

function returns number of characters printed on success and -1 on failure.

A vector of user-supplied

settings in the form of

strings. The vector is terminated by a

pointer. These settings correspond to options the user specified when running

As such, they will only be present when the corresponding option has been specified on the command line.

When parsing

the plugin should split on the

equal sign

since the

field will never include one itself but the

might.

See the

section for a list of all possible settings.

A vector of information about the user running the command in the form of

strings. The vector is terminated by a

pointer.

When parsing

the plugin should split on the

equal sign

since the

field will never include one itself but the

might.

See the

section for a list of all possible strings.

The index into

that corresponds to the first entry that is not a command line option. If

only consists of options, which may be the case with the

options,

will evaluate to the NULL pointer.

The argument vector

was invoked with, including all command line options. The

argument can be used to determine the end of the command line options.

The invoking user’s environment in the form of a

vector of

strings.

When parsing

the plugin should split on the

equal sign

since the

field will never include one itself but the

might.

Any (non-comment) strings immediately after the plugin path are treated as arguments to the plugin. These arguments are split on a white space boundary and are passed to the plugin in the form of a

array of strings. If no arguments were specified,

will be the

pointer.

If the

function returns a value other than 1, the plugin may store a message describing the failure or error in

The

front-end will then pass this value to any registered audit plugins. The string stored in

must remain valid until the plugin’s

function is called.

void (*close)(int status_type, int status);

The

function is called when

is finished, shortly before it exits.

The function arguments are as follows:

The type of status being passed. One of

Depending on the value of

this value is either ignored, the command’s exit status as returned by the

system call, the value of

set by the

system call, or the value of

resulting from an error in the

front-end.

int (*accept)(const char *plugin_name, unsigned int plugin_type, char * const command_info[], char * const run_argv[], char * const run_envp[], const char **errstr);

The

function is called when a command or action is accepted by a policy or approval plugin. The function arguments are as follows:

The name of the plugin that accepted the command or

for the

front-end.

The type of plugin that accepted the command, currently either

The

function is called multiple times–once for each policy or approval plugin that succeeds and once for the sudo front-end. When called on behalf of the sudo front-end,

may include information from an I/O logging plugin as well.

Typically, an audit plugin is interested in either the accept status from the

front-end or from the various policy and approval plugins, but not both. It is possible for the policy plugin to accept a command that is later rejected by an approval plugin, in which case the audit plugin’s

and

functions will

be called.

An optional vector of information describing the command being run in the form of

strings. The vector is terminated by a

pointer.

When parsing

the plugin should split on the

equal sign

since the

field will never include one itself but the

might.

See the

section for a list of all possible strings.

argument vector describing a command that will be run in the same form as what would be passed to the

system call.

The environment the command will be run with in the form of a

vector of

strings.

When parsing

the plugin should split on the

equal sign

since the

field will never include one itself but the

might.

If the

function returns a value other than 1, the plugin may store a message describing the failure or error in

The

front-end will then pass this value to any registered audit plugins. The string stored in

must remain valid until the plugin’s

function is called.

int (*reject)(const char *plugin_name, unsigned int plugin_type, const char *audit_msg, char * const command_info[], const char **errstr);

The

function is called when a command or action is rejected by a plugin. The function arguments are as follows:

The name of the plugin that rejected the command.

The type of plugin that rejected the command, currently either

Unlike the

function, the

function is not called on behalf of the

front-end.

An optional string describing the reason the command was rejected by the plugin. If the plugin did not provide a reason,

will be the

pointer.

An optional vector of information describing the command being run in the form of

strings. The vector is terminated by a

pointer.

When parsing

the plugin should split on the

equal sign

since the

field will never include one itself but the

might.

See the

section for a list of all possible strings.

If the

function returns a value other than 1, the plugin may store a message describing the failure or error in

The

front-end will then pass this value to any registered audit plugins. The string stored in

must remain valid until the plugin’s

function is called.

int (*error)(const char *plugin_name, unsigned int plugin_type, const char *audit_msg, char * const command_info[], const char **errstr);

The

function is called when a plugin or the

front-end returns an error. The function arguments are as follows:

The name of the plugin that generated the error or

for the

front-end.

The type of plugin that generated the error, or

for the

front-end.

An optional string describing the plugin error. If the plugin did not provide a description,

will be the

pointer.

An optional vector of information describing the command being run in the form of

strings. The vector is terminated by a

pointer.

When parsing

the plugin should split on the

equal sign

since the

field will never include one itself but the

might.

See the

section for a list of all possible strings.

If the

function returns a value other than 1, the plugin may store a message describing the failure or error in

The

front-end will then pass this value to any registered audit plugins. The string stored in

must remain valid until the plugin’s

function is called.

int (*show_version)(int verbose);

The

function is called by

when the user specifies the

option. The plugin may display its version information to the user via the

function using

If the user requests detailed version information, the verbose flag will be set.

Returns 1 on success, 0 on failure, -1 if a general error occurred, or -2 if there was a usage error, although the return value is currently ignored.

See the

section for a description of

See the

section for a description of

struct sudo_plugin_event * (*event_alloc)(void);

The

function is used to allocate a

which provides access to the main

event loop. Unlike the other fields, the

pointer is filled in by the

front-end, not by the plugin.

See the

section below for more information about events.

The

function is only available starting with API version 1.17. If the

front-end doesn’t support API version 1.17 or higher,

will not be set.

struct approval_plugin { #define SUDO_APPROVAL_PLUGIN 4 unsigned int type; /* always SUDO_APPROVAL_PLUGIN */ unsigned int version; /* always SUDO_API_VERSION */ int (*open)(unsigned int version, sudo_conv_t conversation, sudo_printf_t sudo_plugin_printf, char * const settings[], char * const user_info[], int submit_optind, char * const submit_argv[], char * const submit_envp[], char * const plugin_options[], const char **errstr); void (*close)(void); int (*check)(char * const command_info[], char * const run_argv[], char * const run_envp[], const char **errstr); int (*show_version)(int verbose); };

An approval plugin can be used to apply extra constraints after a command has been accepted by the policy plugin. Unlike the other plugin types, it does not remain open until the command completes. The plugin is opened before a call to

and closed shortly thereafter (audit plugin functions must be called before the plugin is closed). Multiple approval plugins may be specified in

has the following fields:

The

field should always be set to

The

field should be set to

This allows

to determine the API version the plugin was built against.

The approval

function is run immediately before a call to the plugin’s

functions. It is only called if the version is being requested or if the policy plugin’s

function has returned successfully. It returns 1 on success, 0 on failure, -1 if a general error occurred, or -2 if there was a usage error. In the latter case,

will print a usage message before it exits. If an error occurs, the plugin may optionally call the

function with

to present additional error information to the user.

The function arguments are as follows:

The version passed in by

allows the plugin to determine the major and minor version number of the plugin API supported by

A pointer to the

function that can be used by the plugin to interact with the user (see

for details). Returns 0 on success and -1 on failure.

A pointer to a

function that may be used to display informational or error messages (see

for details). Returns the number of characters printed on success and -1 on failure.

A vector of user-supplied

settings in the form of

strings. The vector is terminated by a

pointer. These settings correspond to options the user specified when running

As such, they will only be present when the corresponding option has been specified on the command line.

When parsing

the plugin should split on the

equal sign

since the

field will never include one itself but the

might.

See the

section for a list of all possible settings.

A vector of information about the user running the command in the form of

strings. The vector is terminated by a

pointer.

When parsing

the plugin should split on the

equal sign

since the

field will never include one itself but the

might.

See the

section for a list of all possible strings.

The index into

that corresponds to the first entry that is not a command line option. If

only consists of options, which may be the case with the

options,

will evaluate to the NULL pointer.

The argument vector

was invoked with, including all command line options. The

argument can be used to determine the end of the command line options.

The invoking user’s environment in the form of a

vector of

strings.

When parsing

the plugin should split on the

equal sign

since the

field will never include one itself but the

might.

Any (non-comment) strings immediately after the plugin path are treated as arguments to the plugin. These arguments are split on a white space boundary and are passed to the plugin in the form of a

array of strings. If no arguments were specified,

will be the

pointer.

If the

function returns a value other than 1, the plugin may store a message describing the failure or error in

The

front-end will then pass this value to any registered audit plugins. The string stored in

must remain valid until the plugin’s

function is called.

void (*close)(void);

The

function is called after the approval plugin’s

functions have been called. It takes no arguments. The

function is typically used to perform plugin-specific cleanup, such as the freeing of memory objects allocated by the plugin. If the plugin does not need to perform any cleanup,

may be set to the

pointer.

int (*check)(char * const command_info[], char * const run_argv[], char * const run_envp[], const char **errstr);

The approval

function is run after the policy plugin

function and before any I/O logging plugins. If multiple approval plugins are loaded, they must all succeed for the command to be allowed. It returns 1 on success, 0 on failure, -1 if a general error occurred, or -2 if there was a usage error. In the latter case,

will print a usage message before it exits. If an error occurs, the plugin may optionally call the

function with

to present additional error information to the user.

The function arguments are as follows:

A vector of information describing the command being run in the form of

strings. The vector is terminated by a

pointer.

When parsing

the plugin should split on the

equal sign

since the

field will never include one itself but the

might.

See the

section for a list of all possible strings.

argument vector describing a command that will be run in the same form as what would be passed to the

system call.

The environment the command will be run with in the form of a

vector of

strings.

When parsing

the plugin should split on the

equal sign

since the

field will never include one itself but the

might.

If the

function returns a value other than 1, the plugin may store a message describing the failure or error in

The

front-end will then pass this value to any registered audit plugins. The string stored in

must remain valid until the plugin’s

function is called.

int (*show_version)(int verbose);

The

function is called by

when the user specifies the

option. The plugin may display its version information to the user via the

function using

If the user requests detailed version information, the verbose flag will be set.

Returns 1 on success, 0 on failure, -1 if a general error occurred, or -2 if there was a usage error, although the return value is currently ignored.

The

front-end installs default signal handlers to trap common signals while the plugin functions are run. The following signals are trapped by default before the command is executed:

If a fatal signal is received before the command is executed,

will call the plugin’s

function with an exit status of 128 plus the value of the signal that was received. This allows for consistent logging of commands killed by a signal for plugins that log such information in their

function. An exception to this is

which is ignored until the command is executed.

A plugin may temporarily install its own signal handlers but must restore the original handler before the plugin function returns.

Beginning with plugin API version 1.2, it is possible to install hooks for certain functions called by the

front-end.

Currently, the only supported hooks relate to the handling of environment variables. Hooks can be used to intercept attempts to get, set, or remove environment variables so that these changes can be reflected in the version of the environment that is used to execute a command. A future version of the API will support hooking internal

front-end functions as well.

Hooks in

are described by the following structure:

typedef int (*sudo_hook_fn_t)();

struct sudo_hook { unsigned int hook_version; unsigned int hook_type; sudo_hook_fn_t hook_fn; void *closure; };

has the following fields:

The

field should be set to

The

field may be one of the following supported hook types:

The C library

function. Any registered hooks will run before the C library implementation. The

field should be a function that matches the following typedef:

typedef int (*sudo_hook_fn_setenv_t)(const char *name, const char *value, int overwrite, void *closure);

If the registered hook does not match the typedef the results are unspecified.

The C library

function. Any registered hooks will run before the C library implementation. The

field should be a function that matches the following typedef:

typedef int (*sudo_hook_fn_unsetenv_t)(const char *name, void *closure);

The C library

function. Any registered hooks will run before the C library implementation. The

field should be a function that matches the following typedef:

typedef int (*sudo_hook_fn_getenv_t)(const char *name, char **value, void *closure);

If the registered hook does not match the typedef the results are unspecified.

The C library

function. Any registered hooks will run before the C library implementation. The

field should be a function that matches the following typedef:

typedef int (*sudo_hook_fn_putenv_t)(char *string, void *closure);

If the registered hook does not match the typedef the results are unspecified.

sudo_hook_fn_t hook_fn;

The

field should be set to the plugin’s hook implementation. The actual function arguments will vary depending on the

(see

above). In all cases, the

field of

is passed as the last function parameter. This can be used to pass arbitrary data to the plugin’s hook implementation.

The function return value may be one of the following:

The hook function encountered an error.

The hook completed without error, go on to the next hook (including the system implementation if applicable). For example, a

hook might return

if the specified variable was not found in the private copy of the environment.

The hook completed without error, stop processing hooks for this invocation. This can be used to replace the system implementation. For example, a

hook that operates on a private copy of the environment but leaves

unchanged.

Care must be taken when hooking C library functions, it is very easy to create an infinite loop. For example, a

hook that calls the

function may create a loop if the

implementation calls

to check the locale. To prevent this, you may wish to use a static variable in the hook function to guard against nested calls. For example:

static int in_progress = 0; /* avoid recursion */ if (in_progress) return SUDO_HOOK_RET_NEXT; in_progress = 1; … in_progress = 0; return SUDO_HOOK_RET_STOP;

/* Hook API version major/minor */ #define SUDO_HOOK_VERSION_MAJOR 1 #define SUDO_HOOK_VERSION_MINOR 0 #define SUDO_HOOK_VERSION SUDO_API_MKVERSION(SUDO_HOOK_VERSION_MAJOR,\ SUDO_HOOK_VERSION_MINOR)

For getters and setters see the

When

runs a command, it uses an event loop to service signals and I/O. Events may be triggered based on time, a file or socket descriptor becoming ready, or due to receipt of a signal. Starting with API version 1.15, it is possible for a plugin to participate in this event loop by calling the

function.

Events are described by the following structure:

typedef void (*sudo_plugin_ev_callback_t)(int fd, int what, void *closure);

struct sudo_plugin_event { int (*set)(struct sudo_plugin_event *pev, int fd, int events, sudo_plugin_ev_callback_t callback, void *closure); int (*add)(struct sudo_plugin_event *pev, struct timespec *timeout); int (*del)(struct sudo_plugin_event *pev); int (*pending)(struct sudo_plugin_event *pev, int events, struct timespec *ts); int (*fd)(struct sudo_plugin_event *pev); void (*setbase)(struct sudo_plugin_event *pev, void *base); void (*loopbreak)(struct sudo_plugin_event *pev); void (*free)(struct sudo_plugin_event *pev); };

contains the following function pointers:

int (*set)(struct sudo_plugin_event *pev, int fd, int events, sudo_plugin_ev_callback_t callback, void *closure);

The

function takes the following arguments:

A pointer to the

itself.

The file or socket descriptor for I/O-based events or the signal number for signal events. For time-based events,

must be -1.

The following values determine what will trigger the event callback:

callback is run after the specified timeout expires

callback is run when the file descriptor is readable

callback is run when the file descriptor is writable

event is persistent and remains enabled until explicitly deleted

callback is run when the specified signal is received

The

flag may be ORed with any of the event types. It is also possible to OR

and

together to run the callback when a descriptor is ready to be either read from or written to. All other event values are mutually exclusive.

typedef void (*sudo_plugin_ev_callback_t)(int fd, int what, void *closure);

The function to call when an event is triggered. The

function is run with the following arguments:

The file or socket descriptor for I/O-based events or the signal number for signal events.

The event type that triggered that callback. For events that have multiple event types (for example

and

or have an associated timeout,

can be used to determine why the callback was run.

The generic pointer that was specified in the

function.

A generic pointer that will be passed to the callback function.

The

function returns 1 on success, and -1 if a error occurred.

int (*add)(struct sudo_plugin_event *pev, struct timespec *timeout);

The

function adds the event

event loop. The event must have previously been initialized via the

function. If the

argument is not NULL, it should specify a (relative) timeout after which the event will be triggered if the main event criteria has not been met. This is often used to implement an I/O timeout where the event will fire if a descriptor is not ready within a certain time period. If the event is already present in the event loop, its

will be adjusted to match the new value, if any.

The

function returns 1 on success, and -1 if a error occurred.

int (*del)(struct sudo_plugin_event *pev);

The

function deletes the event

from

event loop. Deleted events can be added back via the

function.

The

function returns 1 on success, and -1 if a error occurred.

int (*pending)(struct sudo_plugin_event *pev, int events, struct timespec *ts);

The

function can be used to determine whether one or more events is pending. The

argument specifies which events to check for. See the

function for a list of valid event types. If

is specified in

the event has an associated timeout and the

pointer is non-NULL, it will be filled in with the remaining time.

int (*fd)(struct sudo_plugin_event *pev);

The

function returns the descriptor or signal number associated with the event

void (*setbase)(struct sudo_plugin_event *pev, void *base);

The

function sets the underlying event

for

to the specified value. This can be used to move an event created via

to a new event loop allocated by sudo’s event subsystem. If

event base is reset to the default value, which corresponds to

main event loop. Using this function requires linking the plugin with the sudo_util library. It is unlikely to be used outside of the

plugin.

void (*loopbreak)(struct sudo_plugin_event *pev);

The

function causes

event loop to exit immediately and the running command to be terminated.

void (*free)(struct sudo_plugin_event *pev);

The

function deletes the event

from the event loop and frees the memory associated with it.

The

front-end does not support running remote commands. However, starting with

1.8.8, the

option may be used to specify a remote host that is passed to the policy plugin. A plugin may also accept a

in the form of

which will work with older versions of

It is anticipated that remote commands will be supported by executing a

program. The policy plugin should setup the execution environment such that the

front-end will run the helper which, in turn, will connect to the remote host and run the command.

For example, the policy plugin could utilize

to perform remote command execution. The helper program would be responsible for running

with the proper options to use a private key or certificate that the remote host will accept and run a program on the remote host that would setup the execution environment accordingly.

Remote

functionality must be handled by the policy plugin, not

itself as the front-end has no knowledge that a remote command is being executed. This may be addressed in a future revision of the plugin API.

If the plugin needs to interact with the user, it may do so via the

function. A plugin should not attempt to read directly from the standard input or the user’s terminal (neither of which are guaranteed to exist). The caller must include a trailing newline in

if one is to be printed.

function is also available that can be used to display informational or error messages to the user, which is usually more convenient for simple messages where no use input is required.

The conversation function takes as arguments pointers to the following structures:

struct sudo_conv_message { #define SUDO_CONV_PROMPT_ECHO_OFF 0x0001 /* do not echo user input */ #define SUDO_CONV_PROMPT_ECHO_ON 0x0002 /* echo user input */ #define SUDO_CONV_ERROR_MSG 0x0003 /* error message */ #define SUDO_CONV_INFO_MSG 0x0004 /* informational message */ #define SUDO_CONV_PROMPT_MASK 0x0005 /* mask user input */ #define SUDO_CONV_PROMPT_ECHO_OK 0x1000 /* flag: allow echo if no tty */ #define SUDO_CONV_PREFER_TTY 0x2000 /* flag: use tty if possible */ int msg_type; int timeout; const char *msg; };

#define SUDO_CONV_REPL_MAX 1023

struct sudo_conv_reply { char *reply; };

typedef int (*sudo_conv_callback_fn_t)(int signo, void *closure); struct sudo_conv_callback { unsigned int version; void *closure; sudo_conv_callback_fn_t on_suspend; sudo_conv_callback_fn_t on_resume; };

Pointers to the

and

functions are passed in to the plugin’s

function when the plugin is initialized. The following type definitions can be used in the declaration of the

function:

typedef int (*sudo_conv_t)(int num_msgs, const struct sudo_conv_message msgs[], struct sudo_conv_reply replies[], struct sudo_conv_callback *callback);

typedef int (*sudo_printf_t)(int msg_type, const char * restrict fmt, …);

To use the

function, the plugin must pass an array of

and

There must be a

and

for each message in the conversation, that is, both arrays must have the same number of elements. Each

must have its

member initialized to

The

pointer, if not

should contain function pointers to be called when the

process is suspended and/or resumed during conversation input. The

and

functions are called with the signal that caused

to be suspended and the

pointer from the

These functions should return 0 on success and -1 on error. On error, the conversation will end and the conversation function will return a value of -1. The intended use is to allow the plugin to release resources, such as locks, that should not be held indefinitely while suspended and then reacquire them when the process is resumed. The functions are not actually invoked from within a signal handler.

The

must be set to one of the following values:

Prompt the user for input with echo disabled; this is generally used for passwords. The reply will be stored in the

array, and it will never be

Prompt the user for input with echo enabled. The reply will be stored in the

array, and it will never be

Display an error message. The message is written to the standard error unless the

flag is set, in which case it is written to the user’s terminal if possible.

Display a message. The message is written to the standard output unless the

flag is set, in which case it is written to the user’s terminal if possible.

Prompt the user for input but echo an asterisk character for each character read. The reply will be stored in the

array, and it will never be

This can be used to provide visual feedback to the user while reading sensitive information that should not be displayed.

In addition to the above values, the following flag bits may also be set:

Allow input to be read when echo cannot be disabled when the message type is

By default,

will refuse to read input if the echo cannot be disabled for those message types.

When displaying a message via

try to write the message to the user’s terminal. If the terminal is unavailable, the standard error or standard output will be used, depending upon whether

was used. The user’s terminal is always used when possible for input, this flag is only used for output.

The

in seconds until the prompt will wait for no more input. A zero value implies an infinite timeout.

The plugin is responsible for freeing the reply buffer located in each

if it is not

represents the maximum length of the reply buffer (not including the trailing NUL character). In practical terms, this is the longest password

will support.

The

function uses the same underlying mechanism as the

function but only supports

and

for the

parameter. It can be more convenient than using the

function if no user reply is needed and supports standard

escape sequences.

See the sample plugin for an example of the

function usage.

As of

1.9.0, the plugin

and

functions are called in the following order:

audit open

policy open

approval open

approval close

I/O log open

command runs

command exits

I/O log close

policy close

audit close

sudo exits

Prior to

1.9.0, the I/O log

function was called

the policy

function.

The

plugin supports its own plugin interface to allow non-Unix group lookups. This can be used to query a group source other than the standard Unix group database. Two sample group plugins are bundled with

and

are detailed in

Third party group plugins include a QAS AD plugin available from Quest Software.

A group plugin must declare and populate a

in the global scope. This structure contains pointers to the functions that implement plugin initialization, cleanup, and group lookup.

struct sudoers_group_plugin { unsigned int version; int (*init)(int version, sudo_printf_t sudo_plugin_printf, char *const argv[]); void (*cleanup)(void); int (*query)(const char *user, const char *group, const struct passwd *pwd); };

has the following fields:

The

field should be set to GROUP_API_VERSION.

This allows

to determine the API version the group plugin was built against.

int (*init)(int version, sudo_printf_t sudo_plugin_printf, char *const argv[]);

The

function is called after

has been parsed but before any policy checks. It returns 1 on success, 0 on failure (or if the plugin is not configured), and -1 if a error occurred. If an error occurs, the plugin may call the

function with

to present additional error information to the user.

The function arguments are as follows:

The version passed in by

allows the plugin to determine the major and minor version number of the group plugin API supported by

A pointer to a

function that may be used to display informational or error message to the user. Returns the number of characters printed on success and -1 on failure.

array of arguments generated from the

option in

If no arguments were given,

will be

void (*cleanup)();

The

function is called when

has finished its group checks. The plugin should free any memory it has allocated and close open file handles.

int (*query)(const char *user, const char *group, const struct passwd *pwd);

The

function is used to ask the group plugin whether

is a member of

The function arguments are as follows:

The name of the user being looked up in the external group database.

The name of the group being queried.

The password database entry for

if any. If

is not present in the password database,

will be

/* Sudoers group plugin version major/minor */ #define GROUP_API_VERSION_MAJOR 1 #define GROUP_API_VERSION_MINOR 0 #define GROUP_API_VERSION ((GROUP_API_VERSION_MAJOR << 16) | \ GROUP_API_VERSION_MINOR)

For getters and setters see the

The following revisions have been made to the Sudo Plugin API.

Initial API version.

The I/O logging plugin’s

function was modified to take the

list as an argument.

The Policy and I/O logging plugins'

functions are now passed a list of plugin parameters if any are specified in

A simple hooks API has been introduced to allow plugins to hook in to the system’s environment handling functions.

The

Policy plugin function is now passed a pointer to the user environment which can be updated as needed. This can be used to merge in environment variables stored in the PAM handle before a command is run.

Support for the

entry has been added to the

list.

The

and

entries were added to the

list.

The

and

functions are now optional. Previously, a missing

function would result in a crash. If no policy plugin

function is defined, a default

function will be provided by the

front-end that displays a warning if the command could not be executed.

The

front-end now installs default signal handlers to trap common signals while the plugin functions are run.

The

entry was added to the

list.

The

entry was added to the

list.

The behavior when an I/O logging plugin returns an error

has changed. Previously, the

front-end took no action when the

function returned an error.

The behavior when an I/O logging plugin returns 0 has changed. Previously, output from the command would be displayed to the terminal even if an output logging function returned 0.

The

entry was added to the

list.

The

entry now starts with a debug file path name and may occur multiple times if there are multiple plugin-specific Debug lines in the

The

and

entries were added to the

list. The default value of

was changed to true in sudo 1.8.16.

The sudo

function now takes a pointer to a

as its fourth argument. The

definition has been updated to match. The plugin must specify that it supports plugin API version 1.8 or higher to receive a conversation function pointer that supports this argument.

The

entry was added to the

list.

The

entry was added to the

list. The

and

entries were added to the

list.

The

entry was added to the

list.

The

function was added to

The

function was added to

The

entry was added to the

list.

The

entry was added to the

list.

The

function was added to

and

The

argument was added to the policy and I/O plugin functions which the plugin function can use to return an error string. This string may be used by the audit plugin to report failure or error conditions set by the other plugins.

The

function is now is called regardless of whether or not a command was actually executed. This makes it possible for plugins to perform cleanup even when a command was not run.

has increased from 255 to 1023 bytes.

Support for audit and approval plugins was added.

Initial resource limit values were added to the

list.

The

and

entries were added to the

list.

The

function was added to

and

The policy may now set resource limit values in the

list. The

and

entries were added to the

list.

The

and

entries were added to the

list. The

and

entries were added to the

list.

The

entry was added to the

list. The

entry was added to the

list.

The

entry was added to the

list.

Many people have worked on

over the years; this version consists of code written primarily by:

See the CONTRIBUTORS.md file in the

distribution (https://www.sudo.ws/about/contributors/) for an exhaustive list of people who have contributed to

If you believe you have found a bug in

you can submit a bug report at https://bugzilla.sudo.ws/

Limited free support is available via the sudo-users mailing list, see https://www.sudo.ws/mailman/listinfo/sudo-users to subscribe or search the archives.

is provided

and any express or implied warranties, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose are disclaimed. See the LICENSE.md file distributed with

or https://www.sudo.ws/about/license/ for complete details.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

19 - Linux cli command deb-extra-override

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command deb-extra-override and provides detailed information about the command deb-extra-override, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the deb-extra-override.

NAME 🖥️ deb-extra-override 🖥️

extra-override - Debian archive extra override file

SYNOPSIS

override

DESCRIPTION

While most information about a binary/source package can be found in the control/.dsc file, all of it can be overridden when it’s exported to Packages/Sources files. The extra override file contains those overrides.

The extra override file has a simple whitespace-delimited format. Comments are allowed (denoted with a #).

package field-name value

package is the name of the binary/source package.

field-name is the name of the field that is overridden.

value is the value to put in the field. It can contain spaces as the line is split in no more than 3 columns when it’s parsed.

The extra override files used to make the official Packages lists may be found in the indices directory on any Debian mirror.

20 - Linux cli command org.bluez.obex.PhonebookAccess

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.obex.PhonebookAccess and provides detailed information about the command org.bluez.obex.PhonebookAccess, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.obex.PhonebookAccess.

NAME 🖥️ org.bluez.obex.PhonebookAccess 🖥️

BlueZ D-Bus OBEX PhonebookAccess API documentation

INTERFACE

Service
org.bluez.obex
Interface
org.bluez.obex.PhonebookAccess1
Object path
[Session object path]

Methods

void Select(string location, string phonebook)

Selects the phonebook object for other operations. Should be call before all the other operations.
Possible location values:
“int”, “internal” (default)
Store in the Internal memory.
“sim{#}”
Store in the sim number.
Possible phonebook values:
“pb”
Store as contact.
“ich”
Store as incoming call.
“och”
Store as outgoing call.
“mch”
Store as missing call.
“cch”
Store as a combination of incoming, outgoing and missing call.
“spd”:
Store as speed dials entry ( only for “internal” )
“fav”:
Store as favorites entry ( only for “internal” )
Possible errors:
org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Error.Failed

object, dict PullAll(string targetfile, dict filters)

Returns the entire phonebook object from the PSE server in plain string with vcard format, and store it in a local file.
If an empty target file is given, a name will be automatically generated for the temporary file.
The returned path represents the newly created transfer, which should be used to find out if the content has been successfully transferred or if the operation fails.
The properties of this transfer are also returned along with the object path, to avoid a call to GetProperties, see org.bluez.obex.Transfer(5) for the possible list of properties.
Possible filters:
string Format
Items vcard format.
Possible values:
“vcard21” (default)
“vcard30”
string Order
Items order.
Possible values:
""
“indexed”
“alphanumeric”
“phonetic”
uint16 Offset (default 0)
Offset of the first item.
uint16 MaxCount (default 65535)
Maximum number of items.
array{string} Fields (default all fields)
Item vcard fields.
See ListFilterFields() for possible values.
array{string} FilterAll
Filter items by fields using AND logic, cannot be used together with FilterAny.
See ListFilterFields() for possible values.
array{string} FilterAny
Filter items by fields using OR logic, cannot be used together with FilterAll.
See ListFilterFields() for possible values.
bool ResetNewMissedCalls
Reset new the missed calls items, shall only be used for folders mch and cch.
Possible errors:
org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Forbidden

array{string vcard, string name} List(dict filters)

Returns array of vcard-listing data where every entry consists of a pair of strings containing the vcard handle and the contact name. For example:
“1.vcf”
“John”
Possible filters:
string Order
Contact order.
Possible values:
""
“indexed”
“alphanumeric”
“phonetic”
uint16 Offset
Start offset.
uint16 MaxCount
Maximum number of contacts.
Possible errors:
org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Forbidden

object, dict Pull(string vcard, string targetfile, dict filters)

Retrieves the vcard in the current phonebook object and store it in a local file.
If an empty target file is given, a name will be automatically generated for the temporary file.
The returned path represents the newly created transfer, which should be used to find out if the content has been successfully transferred or if the operation fails.
The properties of this transfer are also returned along with the object path, to avoid a call to GetProperties, see org.bluez.obex.Transfer(5) for the possible list of properties.
Possible filters:
string Format
Contact data format.
Possible values:
""
“vcard21”
“vcard30”
array{string} Fields
See ListFilterFields() for possible values.
Possible errors:
org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Error.Forbidden
org.bluez.obex.Error.Failed

array{string vcard, string name} Search(string field, string value, dict filters)

Searches for entries matching the given condition and return an array of vcard-listing data where every entry consists of a pair of strings containing the vcard handle and the contact name.
Possible field values:
“name” (default)
Search by name.
“number”
Search by number.
“sound”
Search by sound.
value: the string value to search for
Possible filters:
string Order
Contact order.
Possible values:
""
“indexed”
“alphanumeric”
“phonetic”
uint16 Offset
Start offset.
uint16 MaxCount
Maximum number of contacts.
Possible errors:
org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Error.Forbidden
org.bluez.obex.Error.Failed

uint16 GetSize()

Returns the number of entries in the selected phonebook object that are actually used (i.e. indexes that correspond to non-NULL entries).
Possible errors:
org.bluez.obex.Error.Forbidden
org.bluez.obex.Error.Failed

void UpdateVersion()

Attempts to update PrimaryCounter and SecondaryCounter.
Possible errors:
org.bluez.obex.Error.NotSupported
org.bluez.obex.Error.Forbidden
org.bluez.obex.Error.Failed

array{string} ListFilterFields()

Returns all Available fields that can be used in Fields filter.
Possible return:
“VERSION”
“FN”
“N”
“PHOTO”
“BDAY”
“ADR”
“LABEL”
“TEL”
“EMAIL”
“MAILER”
“TZ”
“GEO”
“TITLE”
“ROLE”
“LOGO”
“AGENT”
“ORG”
“NOTE”
“REV”
“SOUND”
“URL”
“UID”
“KEY”
“NICKNAME”
“CATEGORIES”
“PROID”
“CLASS”
“SORT-STRING”
“X-IRMC-CALL-DATETIME”
“X-BT-SPEEDDIALKEY”
“X-BT-UCI”
“X-BT-UID”
“BIT-{#}”
Possible errors: None

Properties

string Folder [readonly]

Current folder.

string DatabaseIdentifier [readonly, optional]

128 bits persistent database identifier.
Possible values:
32-character hexadecimal such as A1A2A3A4B1B2C1C2D1D2E1E2E3E4E5E6

string PrimaryCounter [readonly, optional]

128 bits primary version counter.
Possible values:
32-character hexadecimal such as A1A2A3A4B1B2C1C2D1D2E1E2E3E4E5E6

string SecondaryCounter [readonly, optional]

128 bits secondary version counter.
Possible values:
32-character hexadecimal such as A1A2A3A4B1B2C1C2D1D2E1E2E3E4E5E6

bool FixedImageSize [readonly, optional]

Indicate support for fixed image size.
Possible values:
True if image is JPEG 300x300 pixels otherwise False.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

21 - Linux cli command org.freedesktop.LogControl1

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.freedesktop.LogControl1 and provides detailed information about the command org.freedesktop.LogControl1, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.freedesktop.LogControl1.

NAME 🖥️ org.freedesktop.LogControl1 🖥️

D-Bus interface to query and set logging configuration

INTRODUCTION

org.freedesktop.LogControl1 is a generic interface that is intended to be used by any daemon which allows the log level and target to be set over D-Bus. It is implemented by various daemons that are part of the systemd(1) suite.

It is assumed that those settings are global for the whole program, so a fixed object path is used. The interface should always be available under the path /org/freedesktop/LogControl1.

DESCRIPTION

The following interface is exposed:

node /org/freedesktop/LogControl1 { interface org.freedesktop.LogControl1 { properties: @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) @org.freedesktop.systemd1.Privileged(“true”) readwrite s LogLevel = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) @org.freedesktop.systemd1.Privileged(“true”) readwrite s LogTarget = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s SyslogIdentifier = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; };

Properties

LogLevel describes the syslog(3)-style log-level, and should be one of “emerg”, “alert”, “crit”, “err”, “warning”, “notice”, “info”, “debug”, in order of increasing verbosity.

LogTarget describes the log target (mechanism). It should be one of “console” (log to the console or standard output), “kmsg” (log to the kernel ring buffer), “journal” (log to the journal natively, see systemd-journald.service(8)), “syslog” (log using the syslog(3) call).

Those two properties are writable, so they may be set by sufficiently privileged users.

SyslogIdentifier is a read-only property that shows the “syslog identifier”. It is a short string that identifies the program that is the source of log messages that is passed to the syslog(3) call.

TOOLS

journalctl option -p/–priority= may be used to filter log messages by log level, option -t/–identifier= may be used to by the syslog identifier, and filters like “_TRANSPORT=syslog”, “_TRANSPORT=journal”, and “_TRANSPORT=kernel” may be used to filter messages by the mechanism through which they reached systemd-journald.

systemctl log-level and systemctl log-target verbs may be used to query and set the LogLevel and LogTarget properties of the service manager. systemctl service-log-level and systemctl service-log-target may similarly be used for individual services. (Services must have the BusName= property set and must implement the interface described here. See systemd.service(5) for details about BusName=.)

EXAMPLE

Example 1. Create a simple listener on the bus that implements LogControl1

/* SPDX-License-Identifier: MIT-0 */

/* Implements the LogControl1 interface as per specification:
 * https://www.freedesktop.org/software/systemd/man/org.freedesktop.LogControl1.html
 *
 * Compile with cc logcontrol-example.c $(pkg-config --libs --cflags libsystemd)
 *
 * To get and set properties via busctl:
 *
 * $ busctl --user get-property org.freedesktop.Example \
 *                              /org/freedesktop/LogControl1 \
 *                              org.freedesktop.LogControl1 \
 *                              SyslogIdentifier
 *   s "example"
 * $ busctl --user get-property org.freedesktop.Example \
 *                              /org/freedesktop/LogControl1 \
 *                              org.freedesktop.LogControl1 \
 *                              LogTarget
 *   s "journal"
 * $ busctl --user get-property org.freedesktop.Example \
 *                              /org/freedesktop/LogControl1 \
 *                              org.freedesktop.LogControl1 \
 *                              LogLevel
 *   s "info"
 * $ busctl --user set-property org.freedesktop.Example \
 *                              /org/freedesktop/LogControl1 \
 *                              org.freedesktop.LogControl1 \
 *                              LogLevel \
 *                              "s" debug
 * $ busctl --user get-property org.freedesktop.Example \
 *                              /org/freedesktop/LogControl1 \
 *                              org.freedesktop.LogControl1 \
 *                              LogLevel
 *   s "debug"
 */

#include <errno.h>
#include <stdlib.h>
#include <stdio.h>
#include <syslog.h>
#include <systemd/sd-bus.h>
#include <systemd/sd-journal.h>

#define _cleanup_(f) __attribute__((cleanup(f)))

static int log_error(int log_level, int error, const char *str) {
  sd_journal_print(log_level, "%s failed: %s", str, strerror(-error));
  return error;
}

typedef enum LogTarget {
  LOG_TARGET_JOURNAL,
  LOG_TARGET_KMSG,
  LOG_TARGET_SYSLOG,
  LOG_TARGET_CONSOLE,
  _LOG_TARGET_MAX,
} LogTarget;

static const char* const log_target_table[_LOG_TARGET_MAX] = {
  [LOG_TARGET_JOURNAL] = "journal",
  [LOG_TARGET_KMSG]    = "kmsg",
  [LOG_TARGET_SYSLOG]  = "syslog",
  [LOG_TARGET_CONSOLE] = "console",
};

static const char* const log_level_table[LOG_DEBUG + 1] = {
  [LOG_EMERG]   = "emerg",
  [LOG_ALERT]   = "alert",
  [LOG_CRIT]    = "crit",
  [LOG_ERR]     = "err",
  [LOG_WARNING] = "warning",
  [LOG_NOTICE]  = "notice",
  [LOG_INFO]    = "info",
  [LOG_DEBUG]   = "debug",
};

typedef struct object {
  const char *syslog_identifier;
  LogTarget log_target;
  int log_level;
} object;

static int property_get(
                sd_bus *bus,
                const char *path,
                const char *interface,
                const char *property,
                sd_bus_message *reply,
                void *userdata,
                sd_bus_error *error) {

  object *o = userdata;

  if (strcmp(property, "LogLevel") == 0)
    return sd_bus_message_append(reply, "s", log_level_table[o->log_level]);

  if (strcmp(property, "LogTarget") == 0)
    return sd_bus_message_append(reply, "s", log_target_table[o->log_target]);

  if (strcmp(property, "SyslogIdentifier") == 0)
    return sd_bus_message_append(reply, "s", o->syslog_identifier);

  return sd_bus_error_setf(error,
                           SD_BUS_ERROR_UNKNOWN_PROPERTY,
                           "Unknown property %s",
                           property);
}

static int property_set(
                sd_bus *bus,
                const char *path,
                const char *interface,
                const char *property,
                sd_bus_message *message,
                void *userdata,
                sd_bus_error *error) {

  object *o = userdata;
  const char *value;
  int r;

  r = sd_bus_message_read(message, "s", &value);
  if (r < 0)
    return r;

  if (strcmp(property, "LogLevel") == 0) {
    int i;
    for (i = 0; i < LOG_DEBUG + 1; i++)
      if (strcmp(value, log_level_table[i]) == 0) {
        o->log_level = i;
        setlogmask(LOG_UPTO(i));
        return 0;
      }

    return sd_bus_error_setf(error,
                             SD_BUS_ERROR_INVALID_ARGS,
                             "Invalid value for LogLevel: %s",
                             value);
  }

  if (strcmp(property, "LogTarget") == 0) {
    LogTarget i;
    for (i = 0; i < _LOG_TARGET_MAX; i++)
      if (strcmp(value, log_target_table[i]) == 0) {
        o->log_target = i;
        return 0;
      }

    return sd_bus_error_setf(error,
                             SD_BUS_ERROR_INVALID_ARGS,
                             "Invalid value for LogTarget: %s",
                             value);
  }

  return sd_bus_error_setf(error,
                           SD_BUS_ERROR_UNKNOWN_PROPERTY,
                           "Unknown property %s",
                           property);
}

/* https://www.freedesktop.org/software/systemd/man/sd_bus_add_object.html
 */
static const sd_bus_vtable vtable[] = {
  SD_BUS_VTABLE_START(0),
  SD_BUS_WRITABLE_PROPERTY(
    "LogLevel", "s",
    property_get, property_set,
    0,
    0),
  SD_BUS_WRITABLE_PROPERTY(
    "LogTarget", "s",
    property_get, property_set,
    0,
    0),
  SD_BUS_PROPERTY(
    "SyslogIdentifier", "s",
    property_get,
    0,
    SD_BUS_VTABLE_PROPERTY_CONST),
  SD_BUS_VTABLE_END
};

int main(int argc, char **argv) {
  /* The bus should be relinquished before the program terminates. The cleanup
   * attribute allows us to do it nicely and cleanly whenever we exit the
   * block.
   */
  _cleanup_(sd_bus_flush_close_unrefp) sd_bus *bus = NULL;

  object o = {
    .log_level = LOG_INFO,
    .log_target = LOG_TARGET_JOURNAL,
    .syslog_identifier = "example",
  };
  int r;

  /* https://man7.org/linux/man-pages/man3/setlogmask.3.html
   * Programs using syslog() instead of sd_journal can use this API to cut logs
   * emission at the source.
   */
  setlogmask(LOG_UPTO(o.log_level));

  /* Acquire a connection to the bus, letting the library work out the details.
   * https://www.freedesktop.org/software/systemd/man/sd_bus_default.html
   */
  r = sd_bus_default(&bus);
  if (r < 0)
    return log_error(o.log_level, r, "sd_bus_default()");

  /* Publish an interface on the bus, specifying our well-known object access
   * path and public interface name.
   * https://www.freedesktop.org/software/systemd/man/sd_bus_add_object.html
   * https://dbus.freedesktop.org/doc/dbus-tutorial.html
   */
  r = sd_bus_add_object_vtable(bus, NULL,
                               "/org/freedesktop/LogControl1",
                               "org.freedesktop.LogControl1",
                               vtable,
                               &o);
  if (r < 0)
    return log_error(o.log_level, r, "sd_bus_add_object_vtable()");

  /* By default the service is assigned an ephemeral name. Also add a fixed
   * one, so that clients know whom to call.
   * https://www.freedesktop.org/software/systemd/man/sd_bus_request_name.html
   */
  r = sd_bus_request_name(bus, "org.freedesktop.Example", 0);
  if (r < 0)
    return log_error(o.log_level, r, "sd_bus_request_name()");

  for (;;) {
    /* https://www.freedesktop.org/software/systemd/man/sd_bus_wait.html
     */
    r = sd_bus_wait(bus, UINT64_MAX);
    if (r < 0)
      return log_error(o.log_level, r, "sd_bus_wait()");
    /* https://www.freedesktop.org/software/systemd/man/sd_bus_process.html
     */
    r = sd_bus_process(bus, NULL);
    if (r < 0)
      return log_error(o.log_level, r, "sd_bus_process()");
  }

  /* https://www.freedesktop.org/software/systemd/man/sd_bus_release_name.html
   */
  r = sd_bus_release_name(bus, "org.freedesktop.Example");
  if (r < 0)
    return log_error(o.log_level, r, "sd_bus_release_name()");

  return 0;
}

This creates a simple server on the bus. It implements the LogControl1 interface by providing the required properties and allowing to set the writable ones. It logs at the configured log level using sd_journal_print(3).

22 - Linux cli command proc_tid

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_tid and provides detailed information about the command proc_tid, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_tid.

NAME 🖥️ proc_tid 🖥️

self/ - thread information

DESCRIPTION

/proc/pid/task/ (since Linux 2.6.0)
This is a directory that contains one subdirectory for each thread in the process. The name of each subdirectory is the numerical thread ID (tid) of the thread (see gettid(2)).

Within each of these subdirectories, there is a set of files with the same names and contents as under the */proc/*pid directories. For attributes that are shared by all threads, the contents for each of the files under the *task/*tid subdirectories will be the same as in the corresponding file in the parent */proc/*pid directory (e.g., in a multithreaded process, all of the task/tid/cwd files will have the same value as the /proc/pid/cwd file in the parent directory, since all of the threads in a process share a working directory). For attributes that are distinct for each thread, the corresponding files under *task/*tid may have different values (e.g., various fields in each of the task/tid/status files may be different for each thread), or they might not exist in */proc/*pid at all.

In a multithreaded process, the contents of the /proc/pid/task directory are not available if the main thread has already terminated (typically by calling pthread_exit(3)).

/proc/tid/
There is a numerical subdirectory for each running thread that is not a thread group leader (i.e., a thread whose thread ID is not the same as its process ID); the subdirectory is named by the thread ID. Each one of these subdirectories contains files and subdirectories exposing information about the thread with the thread ID tid. The contents of these directories are the same as the corresponding */proc/pid/task/*tid directories.

The */proc/*tid subdirectories are not visible when iterating through /proc with getdents(2) (and thus are not visible when one uses ls(1) to view the contents of /proc). However, the pathnames of these directories are visible to (i.e., usable as arguments in) system calls that operate on pathnames.

/proc/thread-self/ (since Linux 3.17)
This directory refers to the thread accessing the /proc filesystem, and is identical to the */proc/self/task/*tid directory named by the process thread ID (tid) of the same thread.

23 - Linux cli command exim4-config_files

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command exim4-config_files and provides detailed information about the command exim4-config_files, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the exim4-config_files.

NAME 🖥️ exim4-config_files 🖥️

config_files - Files in use by the Debian exim4 packages

SYNOPSIS

/etc/aliases
/etc/email-addresses
/etc/exim4/local_host_blacklist
/etc/exim4/host_local_deny_exceptions
/etc/exim4/local_sender_blacklist
/etc/exim4/sender_local_deny_exceptions
/etc/exim4/local_sender_callout
/etc/exim4/local_rcpt_callout
/etc/exim4/local_domain_dnsbl_whitelist
/etc/exim4/hubbed_hosts
/etc/exim4/passwd
/etc/exim4/passwd.client
/etc/exim4/exim.crt
/etc/exim4/exim.key
/etc/mailname

DESCRIPTION

This manual page describes the files that are in use by the Debian exim4 packages and which are not part of an exim installation done from source.

/etc/aliases

is a table providing a mechanism to redirect mail for local recipients. /etc/aliases is a text file which is roughly compatible with Sendmail. The file should contain lines of the form
name: address, address, …
The name is a local address without domain part. All local domains are handled equally. For more detailed documentation, please refer to /usr/share/doc/exim4-base/spec.txt.gz, chapter 22, and to /usr/share/doc/exim4-base/README.Debian.gz. Please note that it is not possible to use delivery to arbitrary files, directories and to pipes. This is forbidden in Debian’s exim4 default configuration.

You should at least set up an alias for postmaster in the /etc/aliases file.

/etc/email-addresses

is used to rewrite the email addresses of users. This is particularly useful for users who use their ISP’s domain for email.

The file should contain lines of the form

user: [email protected]
otheruser: [email protected]

This way emails from user will appear to be from [email protected] to the outside world. Technically, the from, reply-to, and sender addresses, along with the envelope sender, are rewritten for users that appear to be in the local domain.

/etc/exim4/local_host_blacklist

[exim host list] is an optional file containing a list of IP addresses, networks and host names whose messages will be denied with the error message “locally blacklisted”. This is a full exim 4 host list, and all available features can be used. This includes negative items, and so it is possible to exclude addresses from being blacklisted. For convenience, as an additional method to whitelist addresses from being blocked, an explicit whitelist is read in from /etc/exim4/host_local_deny_exceptions. Entries in the whitelist override corresponding blacklist entries.

In the blacklist, the trick is to read a line break as “or” if it follows a positive item, and as “and” if it follows a negative item.

For example, a /etc/exim4/local_host_blacklist

192.168.10.0/24
!172.16.10.128/26
172.16.10.0/24
10.0.0.0/8

Exim just evaluates left to right (or up-down in the file listing context), so you don’t get the same kind of operator binding as in a programming language.

/etc/exim4/host_local_deny_exceptions

[exim host list] contains a list of IP addresses, networks and host names whose messages will be accepted despite the address is also listed in /etc/exim4/local_host_blacklist, overriding a blacklisting.

/etc/exim4/local_sender_blacklist

[exim address list] is an optional files containing a list of envelope senders whose messages will be denied with the error message “locally blacklisted”. This is a full exim 4 address list, and all available features can be used. This includes negative items, and so it is possible to exclude addresses from being blacklisted. For convenience, as an additional method to whitelist addresses from being blocked, an explicit whitelist is read in from /etc/exim4/sender_local_deny_exceptions. Entries in the whitelist override corresponding blacklist entries.

In the blacklist, the trick is to read a line break as “or” if it follows a positive item, and as “and” if it follows a negative item.

For example, a /etc/exim4/local_sender_blacklist

domain1.example
[email protected]
domain2.example
domain3.example

Exim just evaluates left to right (or up-down in the file listing context), so you don’t get the same kind of operator binding as in a programming language.

/etc/exim4/sender_local_deny_exceptions

[exim address list] is an optional file containing a list of envelope senders whose messages will be accepted despite the address being also listed in /etc/exim4/local_sender_blacklist, overriding a blacklisting.

/etc/exim4/local_sender_callout

[exim address list] is an optional file containing a list of envelope senders whose messages are subject to sender verification with a callout. This is a full exim4 address list, and all available features can be used.

/etc/exim4/local_rcpt_callout

[exim address list] is an optional file containing a list of envelope recipients for which incoming messages are subject to recipient verification with a callout. This is a full exim4 address list, and all available features can be used.

/etc/exim4/local_domain_dnsbl_whitelist

[exim address list] is an optional file containing a list of envelope senders whose messages are exempt from blacklisting via a domain-based DNSBL. This is a full exim4 address list, and all available features can be used. This feature is intended to be used in case of a domain-based DNSBL being too heavy handed, for example listing entire top-level domains for their registry policies.

/etc/exim4/hubbed_hosts

[exim domain list] is an optional file containing a list of route_data records which can be used to override or augment MX information from the DNS. This is particularly useful for mail hubs which are highest-priority MX for a domain in the DNS but are not final destination of the messages, passing them on to a host which is not publicly reachable, or to temporarily fix mail routing in case of broken DNS setups.

The file should contain key-value pairs of domain pattern and route data of the form

domain: host-list options
dict.ref.example: mail-1.ref.example:mail-2.ref.example
foo.example: internal.mail.example.com
bar.example: 192.168.183.3

which will cause mail for foo.example to be sent to the host internal.mail.example (IP address derived from A record only), and mail to bar.example to be sent to 192.168.183.3.

See spec.txt chapter 20.3 through 20.7 for a more detailed explanation of host list format and available options.

/etc/exim4/passwd

contains account and password data for SMTP authentication when the local exim is SMTP server and clients authenticate to the local exim.

The file should contain lines of the form

username:crypted-password:clear-password

crypted-password is the crypt(3)-created hash of your password. You can, for example, use the mkpasswd program from the whois package to create a crypted password. It is recommended to use a modern hash algorithm, see mkpasswd –method=help. Consider not using crypt or MD5.

clear-password is only necessary if you want to offer CRAM-MD5 authentication. If you don’t plan on doing so, the third column can be omitted completely.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim 640.

/etc/exim4/passwd.client

contains account and password data for SMTP authentication when exim is authenticating as a client to some remote server.

The file should contain lines of the form

target.mail.server.example:login-user-name:password

which will cause exim to use login-user-name and password when sending messages to a server with the canonical host name target.mail.server.example. Please note that this does not configure the mail server to send to (this is determined in Debconf), but only creates the correlation between host name and authentication credentials to avoid exposing passwords to the wrong host.

Please note that target.mail.server.example is currently the value that exim can read from reverse DNS: It first follows the host name of the target system until it finds an IP address, and then looks up the reverse DNS for that IP address to use the outcome of this query (or the IP address itself should the query fail) as index into /etc/exim4/passwd.client.

This goes inevitably wrong if the host name of the mail server is a CNAME (a DNS alias), or the reverse lookup does not fit the forward one.

Currently, you need to manually lookup all reverse DNS names for all IP addresses that your SMTP server host name points to, for example by using the host command. If the SMTP smarthost alias expands to multiple IPs, you need to have multiple lines for all the hosts. When your ISP changes the alias, you will need to manually fix that.

You may minimize this trouble by using a wild card entry or regular expressions, thus reducing the risk of divulging the password to the wrong SMTP server while reducing the number of necessary lines. For a deeper discussion, see the Debian BTS #244724.

password is your SMTP password in clear text. If you do not know about your SMTP password, you can try using your POP3 password as a first guess.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim 640.

# example for CONFDIR/passwd.client
# this will only match if the server’s generic name matches exactly
mail.server.example:user:password
# this will deliver the password to any server
*:username:password
# this will deliver the password to servers whose generic name ends in
# mail.server.example
*.mail.server.example:user:password
# this will deliver the password to servers whose generic name matches
# the regular expression
^smtp[0-9]*\mail\server\example:user:password

/etc/exim4/exim.crt

contains the certificate that exim uses to initiate TLS connections. This is public information and can be world readable. /usr/share/doc/exim4-base/examples/exim-gencert can be used to generate a private key and self-signed certificate.

/etc/exim4/exim.key

contains the private key belonging to the certificate in exim.crt. This file’s contents must be kept secret and should have mode root:Debian-exim 640. /usr/share/doc/exim4-base/examples/exim-gencert can be used to generate a private key and self-signed certificate.

/etc/mailname

The “mail name” of the system. See Debian policy Chapter Customized programs and exim4-base’s README.Debian for further details.

BUGS

Plenty. Please report them through the Debian BTS

This manual page needs a major re-work. If somebody knows better groff than us and has more experience in writing manual pages, any patches would be greatly appreciated.

NOTES

Unresolvable items in host lists

Adding or keeping items in the abovementioned host lists which are not resolvable by DNS has severe consequences.

e.g. if resolving a hostname in local_host_blacklist returns a temporary error (DNS timeout) exim will not be able to check whether a connecting host is part of the list. Exim will therefore return a temporary SMTP error for every connecting host.

On the other hand if there is a permanent error in resolving a name in the host list (the record was removed from DNS) exim behaves as if the host does not match the list. e.g. a local_host_blacklist consisting of

notresolvable.example.com:rejectme.example.com

is equivalent to an empty one. - Exim tries to match the IP-address of the connecting host to notresolvable.example.com, resolving this IP by DNS fails, exim behaves as if the connecting host does not match the list. List processing stops at this point!

Starting the list with the special pattern +ignore_unknown as a safeguard against this behavior is strongly recommended if hostnames are used in hostlists.

See Exim specification Chapter Domain, host, address, and local part lists , section Behaviour when an IP address or name cannot be found. <http://www.exim.org/exim-html-current/doc/html/spec_html/ch-domain_host_address_and_local_part_lists.html>

AUTHOR

Marc Haber <[email protected]> with help from Ross Boylan.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

24 - Linux cli command os-release

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command os-release and provides detailed information about the command os-release, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the os-release.

NAME 🖥️ os-release 🖥️

release, initrd-release, extension-release - Operating system identification

SYNOPSIS

/etc/os-release

/usr/lib/os-release

/etc/initrd-release

/usr/lib/extension-release.d/extension-release.IMAGE

DESCRIPTION

The /etc/os-release and /usr/lib/os-release files contain operating system identification data.

os-release contains data that is defined by the operating system vendor and should generally not be changed by the administrator.

As this file only encodes names and identifiers it should not be localized.

For a longer rationale for os-release please refer to the Announcement of /etc/os-release[1].

/etc/initrd-release

The rest of this document that talks about os-release should be understood to apply to initrd-release too.

/usr/lib/extension-release.d/extension-release.IMAGE

The rest of this document that talks about os-release should be understood to apply to extension-release too.

OPTIONS

The following OS identifications parameters may be set using os-release:

General information identifying the operating system

NAME=

A string identifying the operating system, without a version component, and suitable for presentation to the user. If not set, a default of “NAME=Linux” may be used.
Examples: “NAME=Fedora”, “NAME=“Debian GNU/Linux””.

ID=

A lower-case string (no spaces or other characters outside of 0–9, a–z, “.”, “_” and “-”) identifying the operating system, excluding any version information and suitable for processing by scripts or usage in generated filenames. If not set, a default of “ID=linux” may be used. Note that even though this string may not include characters that require shell quoting, quoting may nevertheless be used.
Examples: “ID=fedora”, “ID=debian”.

ID_LIKE=

A space-separated list of operating system identifiers in the same syntax as the ID= setting. It should list identifiers of operating systems that are closely related to the local operating system in regards to packaging and programming interfaces, for example listing one or more OS identifiers the local OS is a derivative from. An OS should generally only list other OS identifiers it itself is a derivative of, and not any OSes that are derived from it, though symmetric relationships are possible. Build scripts and similar should check this variable if they need to identify the local operating system and the value of ID= is not recognized. Operating systems should be listed in order of how closely the local operating system relates to the listed ones, starting with the closest. This field is optional.
Examples: for an operating system with “ID=centos”, an assignment of “ID_LIKE=“rhel fedora”” would be appropriate. For an operating system with “ID=ubuntu”, an assignment of “ID_LIKE=debian” is appropriate.

PRETTY_NAME=

A pretty operating system name in a format suitable for presentation to the user. May or may not contain a release code name or OS version of some kind, as suitable. If not set, a default of “PRETTY_NAME=“Linux”” may be used
Example: “PRETTY_NAME=“Fedora 17 (Beefy Miracle)””.

CPE_NAME=

A CPE name for the operating system, in URI binding syntax, following the Common Platform Enumeration Specification[4] as proposed by the NIST. This field is optional.
Example: “CPE_NAME=“cpe:/o:fedoraproject:fedora:17"”

VARIANT=

A string identifying a specific variant or edition of the operating system suitable for presentation to the user. This field may be used to inform the user that the configuration of this system is subject to a specific divergent set of rules or default configuration settings. This field is optional and may not be implemented on all systems.
Examples: “VARIANT=“Server Edition””, “VARIANT=“Smart Refrigerator Edition””.
Note: this field is for display purposes only. The VARIANT_ID field should be used for making programmatic decisions.
Added in version 220.

VARIANT_ID=

A lower-case string (no spaces or other characters outside of 0–9, a–z, “.”, “_” and “-”), identifying a specific variant or edition of the operating system. This may be interpreted by other packages in order to determine a divergent default configuration. This field is optional and may not be implemented on all systems.
Examples: “VARIANT_ID=server”, “VARIANT_ID=embedded”.
Added in version 220.

Information about the version of the operating system

VERSION=

A string identifying the operating system version, excluding any OS name information, possibly including a release code name, and suitable for presentation to the user. This field is optional.
Examples: “VERSION=17”, “VERSION=“17 (Beefy Miracle)””.

VERSION_ID=

A lower-case string (mostly numeric, no spaces or other characters outside of 0–9, a–z, “.”, “_” and “-”) identifying the operating system version, excluding any OS name information or release code name, and suitable for processing by scripts or usage in generated filenames. This field is optional.
Examples: “VERSION_ID=17”, “VERSION_ID=11.04”.

VERSION_CODENAME=

A lower-case string (no spaces or other characters outside of 0–9, a–z, “.”, “_” and “-”) identifying the operating system release code name, excluding any OS name information or release version, and suitable for processing by scripts or usage in generated filenames. This field is optional and may not be implemented on all systems.
Examples: “VERSION_CODENAME=buster”, “VERSION_CODENAME=xenial”.
Added in version 231.

BUILD_ID=

A string uniquely identifying the system image originally used as the installation base. In most cases, VERSION_ID or IMAGE_ID+IMAGE_VERSION are updated when the entire system image is replaced during an update. BUILD_ID may be used in distributions where the original installation image version is important: VERSION_ID would change during incremental system updates, but BUILD_ID would not. This field is optional.
Examples: “BUILD_ID=“2013-03-20.3"”, “BUILD_ID=201303203”.
Added in version 200.

IMAGE_ID=

A lower-case string (no spaces or other characters outside of 0–9, a–z, “.”, “_” and “-”), identifying a specific image of the operating system. This is supposed to be used for environments where OS images are prepared, built, shipped and updated as comprehensive, consistent OS images. This field is optional and may not be implemented on all systems, in particularly not on those that are not managed via images but put together and updated from individual packages and on the local system.
Examples: “IMAGE_ID=vendorx-cashier-system”, “IMAGE_ID=netbook-image”.
Added in version 249.

IMAGE_VERSION=

A lower-case string (mostly numeric, no spaces or other characters outside of 0–9, a–z, “.”, “_” and “-”) identifying the OS image version. This is supposed to be used together with IMAGE_ID described above, to discern different versions of the same image.
Examples: “IMAGE_VERSION=33”, “IMAGE_VERSION=47.1rc1”.
Added in version 249.

Presentation information and links

HOME_URL=, DOCUMENTATION_URL=, SUPPORT_URL=, BUG_REPORT_URL=, PRIVACY_POLICY_URL=

Links to resources on the Internet related to the operating system. HOME_URL= should refer to the homepage of the operating system, or alternatively some homepage of the specific version of the operating system. DOCUMENTATION_URL= should refer to the main documentation page for this operating system. SUPPORT_URL= should refer to the main support page for the operating system, if there is any. This is primarily intended for operating systems which vendors provide support for. BUG_REPORT_URL= should refer to the main bug reporting page for the operating system, if there is any. This is primarily intended for operating systems that rely on community QA. PRIVACY_POLICY_URL= should refer to the main privacy policy page for the operating system, if there is any. These settings are optional, and providing only some of these settings is common. These URLs are intended to be exposed in “About this system” UIs behind links with captions such as “About this Operating System”, “Obtain Support”, “Report a Bug”, or “Privacy Policy”. The values should be in RFC3986 format[5], and should be “http:” or “https:” URLs, and possibly “mailto:” or “tel:”. Only one URL shall be listed in each setting. If multiple resources need to be referenced, it is recommended to provide an online landing page linking all available resources.
Examples: “HOME_URL=“https://fedoraproject.org/"", “BUG_REPORT_URL=“https://bugzilla.redhat.com/"".

SUPPORT_END=

The date at which support for this version of the OS ends. (What exactly “lack of support” means varies between vendors, but generally users should assume that updates, including security fixes, will not be provided.) The value is a date in the ISO 8601 format “YYYY-MM-DD”, and specifies the first day on which support is not provided.
For example, “SUPPORT_END=2001-01-01” means that the system was supported until the end of the last day of the previous millennium.
Added in version 252.

LOGO=

A string, specifying the name of an icon as defined by freedesktop.org Icon Theme Specification[6]. This can be used by graphical applications to display an operating systems or distributors logo. This field is optional and may not necessarily be implemented on all systems.
Examples: “LOGO=fedora-logo”, “LOGO=distributor-logo-opensuse”
Added in version 240.

ANSI_COLOR=

A suggested presentation color when showing the OS name on the console. This should be specified as string suitable for inclusion in the ESC [ m ANSI/ECMA-48 escape code for setting graphical rendition. This field is optional.
Examples: “ANSI_COLOR=“0;31"” for red, “ANSI_COLOR=“1;34"” for light blue, or “ANSI_COLOR=“0;38;2;60;110;180"” for Fedora blue.

VENDOR_NAME=

The name of the OS vendor. This is the name of the organization or company which produces the OS. This field is optional.
This name is intended to be exposed in “About this system” UIs or software update UIs when needed to distinguish the OS vendor from the OS itself. It is intended to be human readable.
Examples: “VENDOR_NAME=“Fedora Project”” for Fedora Linux, “VENDOR_NAME=“Canonical”” for Ubuntu.
Added in version 254.

VENDOR_URL=

The homepage of the OS vendor. This field is optional. The VENDOR_NAME= field should be set if this one is, although clients must be robust against either field not being set.
The value should be in RFC3986 format[5], and should be “http:” or “https:” URLs. Only one URL shall be listed in the setting.
Examples: “VENDOR_URL=“https://fedoraproject.org/"", “VENDOR_URL=“https://canonical.com/"".
Added in version 254.

Distribution-level defaults and metadata

DEFAULT_HOSTNAME=

A string specifying the hostname if hostname(5) is not present and no other configuration source specifies the hostname. Must be either a single DNS label (a string composed of 7-bit ASCII lower-case characters and no spaces or dots, limited to the format allowed for DNS domain name labels), or a sequence of such labels separated by single dots that forms a valid DNS FQDN. The hostname must be at most 64 characters, which is a Linux limitation (DNS allows longer names).
See org.freedesktop.hostname1(5) for a description of how systemd-hostnamed.service(8) determines the fallback hostname.
Added in version 248.

ARCHITECTURE=

A string that specifies which CPU architecture the userspace binaries require. The architecture identifiers are the same as for ConditionArchitecture= described in systemd.unit(5). The field is optional and should only be used when just single architecture is supported. It may provide redundant information when used in a GPT partition with a GUID type that already encodes the architecture. If this is not the case, the architecture should be specified in e.g., an extension image, to prevent an incompatible host from loading it.
Added in version 252.

SYSEXT_LEVEL=

A lower-case string (mostly numeric, no spaces or other characters outside of 0–9, a–z, “.”, “_” and “-”) identifying the operating system extensions support level, to indicate which extension images are supported. See /usr/lib/extension-release.d/extension-release.IMAGE, initrd[2] and systemd-sysext(8)) for more information.
Examples: “SYSEXT_LEVEL=2”, “SYSEXT_LEVEL=15.14”.
Added in version 248.

CONFEXT_LEVEL=

Semantically the same as SYSEXT_LEVEL= but for confext images. See /etc/extension-release.d/extension-release.IMAGE for more information.
Examples: “CONFEXT_LEVEL=2”, “CONFEXT_LEVEL=15.14”.
Added in version 254.

SYSEXT_SCOPE=

Takes a space-separated list of one or more of the strings “system”, “initrd” and “portable”. This field is only supported in extension-release.d/ files and indicates what environments the system extension is applicable to: i.e. to regular systems, to initrds, or to portable service images. If unspecified, “SYSEXT_SCOPE=system portable” is implied, i.e. any system extension without this field is applicable to regular systems and to portable service environments, but not to initrd environments.
Added in version 250.

CONFEXT_SCOPE=

Semantically the same as SYSEXT_SCOPE= but for confext images.
Added in version 254.

PORTABLE_PREFIXES=

Takes a space-separated list of one or more valid prefix match strings for the Portable Services[3] logic. This field serves two purposes: it is informational, identifying portable service images as such (and thus allowing them to be distinguished from other OS images, such as bootable system images). It is also used when a portable service image is attached: the specified or implied portable service prefix is checked against the list specified here, to enforce restrictions how images may be attached to a system.
Added in version 250.

Notes

Example: “DEBIAN_BTS=“debbugs://bugs.debian.org/””.

EXAMPLES

Example 1. os-release file for Fedora Workstation

NAME=Fedora VERSION=“32 (Workstation Edition)” ID=fedora VERSION_ID=32 PRETTY_NAME=“Fedora 32 (Workstation Edition)” ANSI_COLOR=“0;38;2;60;110;180” LOGO=fedora-logo-icon CPE_NAME=“cpe:/o:fedoraproject:fedora:32” HOME_URL=“https://fedoraproject.org/" DOCUMENTATION_URL=“https://docs.fedoraproject.org/en-US/fedora/f32/system-administrators-guide/" SUPPORT_URL=“https://fedoraproject.org/wiki/Communicating_and_getting_help" BUG_REPORT_URL=“https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT=“Fedora” REDHAT_BUGZILLA_PRODUCT_VERSION=32 REDHAT_SUPPORT_PRODUCT=“Fedora” REDHAT_SUPPORT_PRODUCT_VERSION=32 PRIVACY_POLICY_URL=“https://fedoraproject.org/wiki/Legal:PrivacyPolicy" VARIANT=“Workstation Edition” VARIANT_ID=workstation

Example 2. extension-release file for an extension for Fedora Workstation 32

ID=fedora VERSION_ID=32

Example 3. Reading os-release in sh(1)

#!/bin/sh -eu # SPDX-License-Identifier: MIT-0

test -e /etc/os-release && os_release=/etc/os-release || os_release=/usr/lib/os-release
. "${os_release}"

echo "Running on ${PRETTY_NAME:-Linux}"

if [ "${ID:-linux}" = "debian" ] || [ "${ID_LIKE#*debian*}" != "${ID_LIKE}" ]; then
    echo "Looks like Debian!"
fi

Example 4. Reading os-release in python(1) (versions >= 3.10)

#!/usr/bin/python # SPDX-License-Identifier: MIT-0

import platform
os_release = platform.freedesktop_os_release()

pretty_name = os_release.get(PRETTY_NAME, Linux)
print(fRunning on {pretty_name!r})

if fedora in [os_release.get(ID, linux),
                *os_release.get(ID_LIKE, ).split()]:
    print(Looks like Fedora!)

See docs for platform.freedesktop_os_release[7] for more details.

Example 5. Reading os-release in python(1) (any version)

#!/usr/bin/python # SPDX-License-Identifier: MIT-0

import ast
import re
import sys

def read_os_release():
    try:
        filename = /etc/os-release
        f = open(filename)
    except FileNotFoundError:
        filename = /usr/lib/os-release
        f = open(filename)

    for line_number, line in enumerate(f, start=1):
        line = line.rstrip()
        if not line or line.startswith(#):
            continue
        m = re.match(r([A-Z][A-Z_0-9]+)=(.*), line)
        if m:
            name, val = m.groups()
            if val and val[0] in "\:
                val = ast.literal_eval(val)
            yield name, val
        else:
            print(f{filename}:{line_number}: bad line {line!r},
                  file=sys.stderr)

os_release = dict(read_os_release())

pretty_name = os_release.get(PRETTY_NAME, Linux)
print(fRunning on {pretty_name!r})

if debian in [os_release.get(ID, linux),
                *os_release.get(ID_LIKE, ).split()]:
    print(Looks like Debian!)

Note that the above version that uses the built-in implementation is preferred in most cases, and the open-coded version here is provided for reference.

NOTES

Announcement of /etc/os-release

https://0pointer.de/blog/projects/os-release

initrd

https://docs.kernel.org/admin-guide/initrd.html

Portable Services

https://systemd.io/PORTABLE_SERVICES

Common Platform Enumeration Specification

http://scap.nist.gov/specifications/cpe/

RFC3986 format

https://tools.ietf.org/html/rfc3986

freedesktop.org Icon Theme Specification

https://standards.freedesktop.org/icon-theme-spec/latest

platform.freedesktop_os_release

https://docs.python.org/3/library/platform.html#platform.freedesktop_os_release

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

25 - Linux cli command proc_pid_clear_refs

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_clear_refs and provides detailed information about the command proc_pid_clear_refs, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_clear_refs.

NAME 🖥️ proc_pid_clear_refs 🖥️

reset the PG_Referenced and ACCESSED/YOUNG bits

DESCRIPTION

/proc/pid/clear_refs (since Linux 2.6.22)

This is a write-only file, writable only by owner of the process.

The following values may be written to the file:

1 (since Linux 2.6.22)
Reset the PG_Referenced and ACCESSED/YOUNG bits for all the pages associated with the process. (Before Linux 2.6.32, writing any nonzero value to this file had this effect.)

2 (since Linux 2.6.32)
Reset the PG_Referenced and ACCESSED/YOUNG bits for all anonymous pages associated with the process.

3 (since Linux 2.6.32)
Reset the PG_Referenced and ACCESSED/YOUNG bits for all file-mapped pages associated with the process.

Clearing the PG_Referenced and ACCESSED/YOUNG bits provides a method to measure approximately how much memory a process is using. One first inspects the values in the “Referenced” fields for the VMAs shown in /proc/pid/smaps to get an idea of the memory footprint of the process. One then clears the PG_Referenced and ACCESSED/YOUNG bits and, after some measured time interval, once again inspects the values in the “Referenced” fields to get an idea of the change in memory footprint of the process during the measured interval. If one is interested only in inspecting the selected mapping types, then the value 2 or 3 can be used instead of 1.

Further values can be written to affect different properties:

4 (since Linux 3.11)
Clear the soft-dirty bit for all the pages associated with the process. This is used (in conjunction with /proc/pid/pagemap) by the check-point restore system to discover which pages of a process have been dirtied since the file /proc/pid/clear_refs was written to.

5 (since Linux 4.0)
Reset the peak resident set size (“high water mark”) to the process’s current resident set size value.

Writing any value to /proc/pid/clear_refs other than those listed above has no effect.

The /proc/pid/clear_refs file is present only if the CONFIG_PROC_PAGE_MONITOR kernel configuration option is enabled.

26 - Linux cli command gitweb.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitweb.conf and provides detailed information about the command gitweb.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitweb.conf.

NAME 🖥️ gitweb.conf 🖥️

Gitweb (Git web interface) configuration file

SYNOPSIS

/etc/gitweb.conf, /etc/gitweb-common.conf, $GITWEBDIR/gitweb_config.perl

DESCRIPTION

The gitweb CGI script for viewing Git repositories over the web uses a perl script fragment as its configuration file. You can set variables using “our $variable = value”; text from a “#” character until the end of a line is ignored. See perlsyn(1) for details.

An example:

gitweb configuration file for http://git.example.org
#
our $projectroot = "/srv/git"; # FHS recommendation
our $site_name = Example.org >> Repos;

The configuration file is used to override the default settings that were built into gitweb at the time the gitweb.cgi script was generated.

While one could just alter the configuration settings in the gitweb CGI itself, those changes would be lost upon upgrade. Configuration settings might also be placed into a file in the same directory as the CGI script with the default name gitweb_config.perl — allowing one to have multiple gitweb instances with different configurations by the use of symlinks.

Note that some configuration can be controlled on per-repository rather than gitweb-wide basis: see “Per-repository gitweb configuration” subsection on gitweb(1) manpage.

DISCUSSION

Gitweb reads configuration data from the following sources in the following order:

·
built-in values (some set during build stage),

·
common system-wide configuration file (defaults to /etc/gitweb-common.conf),

·
either per-instance configuration file (defaults to gitweb_config.perl in the same directory as the installed gitweb), or if it does not exist then fallback system-wide configuration file (defaults to /etc/gitweb.conf).

Values obtained in later configuration files override values obtained earlier in the above sequence.

Locations of the common system-wide configuration file, the fallback system-wide configuration file and the per-instance configuration file are defined at compile time using build-time Makefile configuration variables, respectively GITWEB_CONFIG_COMMON, GITWEB_CONFIG_SYSTEM and GITWEB_CONFIG.

You can also override locations of gitweb configuration files during runtime by setting the following environment variables: GITWEB_CONFIG_COMMON, GITWEB_CONFIG_SYSTEM and GITWEB_CONFIG to a non-empty value.

The syntax of the configuration files is that of Perl, since these files are handled by sourcing them as fragments of Perl code (the language that gitweb itself is written in). Variables are typically set using the our qualifier (as in “our $variable = <value>;”) to avoid syntax errors if a new version of gitweb no longer uses a variable and therefore stops declaring it.

You can include other configuration file using read_config_file() subroutine. For example, one might want to put gitweb configuration related to access control for viewing repositories via Gitolite (one of Git repository management tools) in a separate file, e.g. in /etc/gitweb-gitolite.conf. To include it, put

read_config_file("/etc/gitweb-gitolite.conf");

somewhere in gitweb configuration file used, e.g. in per-installation gitweb configuration file. Note that read_config_file() checks itself that the file it reads exists, and does nothing if it is not found. It also handles errors in included file.

The default configuration with no configuration file at all may work perfectly well for some installations. Still, a configuration file is useful for customizing or tweaking the behavior of gitweb in many ways, and some optional features will not be present unless explicitly enabled using the configurable %features variable (see also “Configuring gitweb features” section below).

CONFIGURATION VARIABLES

Some configuration variables have their default values (embedded in the CGI script) set during building gitweb — if that is the case, this fact is put in their description. See gitweb’s INSTALL file for instructions on building and installing gitweb.

Location of repositories

The configuration variables described below control how gitweb finds Git repositories, and how repositories are displayed and accessed.

See also “Repositories” and later subsections in gitweb(1) manpage.

$projectroot

Absolute filesystem path which will be prepended to project path; the path to repository is $projectroot/$project. Set to $GITWEB_PROJECTROOT during installation. This variable has to be set correctly for gitweb to find repositories.
For example, if $projectroot is set to “/srv/git” by putting the following in gitweb config file:
our $projectroot = “/srv/git”;
then
http://git.example.com/gitweb.cgi?p=foo/bar.git
and its path_info based equivalent
http://git.example.com/gitweb.cgi/foo/bar.git
will map to the path /srv/git/foo/bar.git on the filesystem.

$projects_list

Name of a plain text file listing projects, or a name of directory to be scanned for projects.
Project list files should list one project per line, with each line having the following format
SP
The default value of this variable is determined by the GITWEB_LIST makefile variable at installation time. If this variable is empty, gitweb will fall back to scanning the $projectroot directory for repositories.

$project_maxdepth

If $projects_list variable is unset, gitweb will recursively scan filesystem for Git repositories. The $project_maxdepth is used to limit traversing depth, relative to $projectroot (starting point); it means that directories which are further from $projectroot than $project_maxdepth will be skipped.
It is purely performance optimization, originally intended for MacOS X, where recursive directory traversal is slow. Gitweb follows symbolic links, but it detects cycles, ignoring any duplicate files and directories.
The default value of this variable is determined by the build-time configuration variable GITWEB_PROJECT_MAXDEPTH, which defaults to 2007.

$export_ok

Show repository only if this file exists (in repository). Only effective if this variable evaluates to true. Can be set when building gitweb by setting GITWEB_EXPORT_OK. This path is relative to GIT_DIR. git-daemon[1] uses git-daemon-export-ok, unless started with –export-all. By default this variable is not set, which means that this feature is turned off.

$export_auth_hook

Function used to determine which repositories should be shown. This subroutine should take one parameter, the full path to a project, and if it returns true, that project will be included in the projects list and can be accessed through gitweb as long as it fulfills the other requirements described by $export_ok, $projects_list, and $projects_maxdepth. Example:
our $export_auth_hook = sub { return -e “$_[0]/git-daemon-export-ok”; };
though the above might be done by using $export_ok instead
our $export_ok = “git-daemon-export-ok”;
If not set (default), it means that this feature is disabled.
See also more involved example in “Controlling access to Git repositories” subsection on gitweb(1) manpage.

$strict_export

Only allow viewing of repositories also shown on the overview page. This for example makes $export_ok file decide if repository is available and not only if it is shown. If $projects_list points to file with list of project, only those repositories listed would be available for gitweb. Can be set during building gitweb via GITWEB_STRICT_EXPORT. By default this variable is not set, which means that you can directly access those repositories that are hidden from projects list page (e.g. the are not listed in the $projects_list file).

Finding files

The following configuration variables tell gitweb where to find files. The values of these variables are paths on the filesystem.

$GIT

Core git executable to use. By default set to $GIT_BINDIR/git, which in turn is by default set to $(bindir)/git. If you use Git installed from a binary package, you should usually set this to “/usr/bin/git”. This can just be “git” if your web server has a sensible PATH; from security point of view it is better to use absolute path to git binary. If you have multiple Git versions installed it can be used to choose which one to use. Must be (correctly) set for gitweb to be able to work.

$mimetypes_file

File to use for (filename extension based) guessing of MIME types before trying /etc/mime.types. NOTE that this path, if relative, is taken as relative to the current Git repository, not to CGI script. If unset, only /etc/mime.types is used (if present on filesystem). If no mimetypes file is found, mimetype guessing based on extension of file is disabled. Unset by default.

$highlight_bin

Path to the highlight executable to use (it must be the one from http://www.andre-simon.de due to assumptions about parameters and output). By default set to highlight; set it to full path to highlight executable if it is not installed on your web server’s PATH. Note that highlight feature must be set for gitweb to actually use syntax highlighting.
NOTE: for a file to be highlighted, its syntax type must be detected and that syntax must be supported by “highlight”. The default syntax detection is minimal, and there are many supported syntax types with no detection by default. There are three options for adding syntax detection. The first and second priority are %highlight_basename and %highlight_ext, which detect based on basename (the full filename, for example “Makefile”) and extension (for example “sh”). The keys of these hashes are the basename and extension, respectively, and the value for a given key is the name of the syntax to be passed via –syntax <syntax> to “highlight”. The last priority is the “highlight” configuration of Shebang regular expressions to detect the language based on the first line in the file, (for example, matching the line “#!/bin/bash”). See the highlight documentation and the default config at /etc/highlight/filetypes.conf for more details.
For example if repositories you are hosting use “phtml” extension for PHP files, and you want to have correct syntax-highlighting for those files, you can add the following to gitweb configuration:
our %highlight_ext; $highlight_ext{phtml} = php;

Links and their targets

The configuration variables described below configure some of gitweb links: their target and their look (text or image), and where to find page prerequisites (stylesheet, favicon, images, scripts). Usually they are left at their default values, with the possible exception of @stylesheets variable.

@stylesheets

List of URIs of stylesheets (relative to the base URI of a page). You might specify more than one stylesheet, for example to use “gitweb.css” as base with site specific modifications in a separate stylesheet to make it easier to upgrade gitweb. For example, you can add a site stylesheet by putting
push @stylesheets, “gitweb-site.css”;
in the gitweb config file. Those values that are relative paths are relative to base URI of gitweb.
This list should contain the URI of gitweb’s standard stylesheet. The default URI of gitweb stylesheet can be set at build time using the GITWEB_CSS makefile variable. Its default value is static/gitweb.css (or static/gitweb.min.css if the CSSMIN variable is defined, i.e. if CSS minifier is used during build).
Note: there is also a legacy $stylesheet configuration variable, which was used by older gitweb. If $stylesheet variable is defined, only CSS stylesheet given by this variable is used by gitweb.

$logo

Points to the location where you put git-logo.png on your web server, or to be more the generic URI of logo, 72x27 size). This image is displayed in the top right corner of each gitweb page and used as a logo for the Atom feed. Relative to the base URI of gitweb (as a path). Can be adjusted when building gitweb using GITWEB_LOGO variable By default set to static/git-logo.png.

$favicon

Points to the location where you put git-favicon.png on your web server, or to be more the generic URI of favicon, which will be served as “image/png” type. Web browsers that support favicons (website icons) may display them in the browser’s URL bar and next to the site name in bookmarks. Relative to the base URI of gitweb. Can be adjusted at build time using GITWEB_FAVICON variable. By default set to static/git-favicon.png.

$javascript

Points to the location where you put gitweb.js on your web server, or to be more generic the URI of JavaScript code used by gitweb. Relative to the base URI of gitweb. Can be set at build time using the GITWEB_JS build-time configuration variable.
The default value is either static/gitweb.js, or static/gitweb.min.js if the JSMIN build variable was defined, i.e. if JavaScript minifier was used at build time. Note that this single file is generated from multiple individual JavaScript “modules”.

$home_link

Target of the home link on the top of all pages (the first part of view “breadcrumbs”). By default it is set to the absolute URI of a current page (to the value of $my_uri variable, or to “/” if $my_uri is undefined or is an empty string).

$home_link_str

Label for the “home link” at the top of all pages, leading to $home_link (usually the main gitweb page, which contains the projects list). It is used as the first component of gitweb’s “breadcrumb trail”: <home link> / <project> / <action>. Can be set at build time using the GITWEB_HOME_LINK_STR variable. By default it is set to “projects”, as this link leads to the list of projects. Another popular choice is to set it to the name of site. Note that it is treated as raw HTML so it should not be set from untrusted sources.

@extra_breadcrumbs

Additional links to be added to the start of the breadcrumb trail before the home link, to pages that are logically “above” the gitweb projects list, such as the organization and department which host the gitweb server. Each element of the list is a reference to an array, in which element 0 is the link text (equivalent to $home_link_str) and element 1 is the target URL (equivalent to $home_link).
For example, the following setting produces a breadcrumb trail like “home / dev / projects / …” where “projects” is the home link.
our @extra_breadcrumbs = (
      [ home => https://www.example.org/ ],
      [ dev  => https://dev.example.org/ ],
    );

$logo_url, $logo_label

URI and label (title) for the Git logo link (or your site logo, if you chose to use different logo image). By default, these both refer to Git homepage, https://git-scm.com; in the past, they pointed to Git documentation at https://www.kernel.org.

Changing gitweb’s look

You can adjust how pages generated by gitweb look using the variables described below. You can change the site name, add common headers and footers for all pages, and add a description of this gitweb installation on its main page (which is the projects list page), etc.

$site_name

Name of your site or organization, to appear in page titles. Set it to something descriptive for clearer bookmarks etc. If this variable is not set or is, then gitweb uses the value of the SERVER_NAME CGI environment variable, setting site name to “$SERVER_NAME Git”, or “Untitled Git” if this variable is not set (e.g. if running gitweb as standalone script).
Can be set using the GITWEB_SITENAME at build time. Unset by default.

$site_html_head_string

HTML snippet to be included in the <head> section of each page. Can be set using GITWEB_SITE_HTML_HEAD_STRING at build time. No default value.

$site_header

Name of a file with HTML to be included at the top of each page. Relative to the directory containing the gitweb.cgi script. Can be set using GITWEB_SITE_HEADER at build time. No default value.

$site_footer

Name of a file with HTML to be included at the bottom of each page. Relative to the directory containing the gitweb.cgi script. Can be set using GITWEB_SITE_FOOTER at build time. No default value.

$home_text

Name of a HTML file which, if it exists, is included on the gitweb projects overview page (“projects_list” view). Relative to the directory containing the gitweb.cgi script. Default value can be adjusted during build time using GITWEB_HOMETEXT variable. By default set to indextext.html.

$projects_list_description_width

The width (in characters) of the “Description” column of the projects list. Longer descriptions will be truncated (trying to cut at word boundary); the full description is available in the title attribute (usually shown on mouseover). The default is 25, which might be too small if you use long project descriptions.

$default_projects_order

Default value of ordering of projects on projects list page, which means the ordering used if you don’t explicitly sort projects list (if there is no “o” CGI query parameter in the URL). Valid values are “none” (unsorted), “project” (projects are by project name, i.e. path to repository relative to $projectroot), “descr” (project description), “owner”, and “age” (by date of most current commit).
Default value is “project”. Unknown value means unsorted.

Changing gitweb’s behavior

These configuration variables control internal gitweb behavior.

$default_blob_plain_mimetype

Default mimetype for the blob_plain (raw) view, if mimetype checking doesn’t result in some other type; by default “text/plain”. Gitweb guesses mimetype of a file to display based on extension of its filename, using $mimetypes_file (if set and file exists) and /etc/mime.types files (see mime.types(5) manpage; only filename extension rules are supported by gitweb).

$default_text_plain_charset

Default charset for text files. If this is not set, the web server configuration will be used. Unset by default.

$fallback_encoding

Gitweb assumes this charset when a line contains non-UTF-8 characters. The fallback decoding is used without error checking, so it can be even “utf-8”. The value must be a valid encoding; see the Encoding::Supported(3pm) man page for a list. The default is “latin1”, aka. “iso-8859-1”.

@diff_opts

Rename detection options for git-diff and git-diff-tree. The default is (-M); set it to (-C) or (-C, -C) to also detect copies, or set it to () i.e. empty list if you don’t want to have renames detection.
Note that rename and especially copy detection can be quite CPU-intensive. Note also that non Git tools can have problems with patches generated with options mentioned above, especially when they involve file copies (-C) or criss-cross renames (-B).

Some optional features and policies

Most of features are configured via %feature hash; however some of extra gitweb features can be turned on and configured using variables described below. This list beside configuration variables that control how gitweb looks does contain variables configuring administrative side of gitweb (e.g. cross-site scripting prevention; admittedly this as side effect affects how “summary” pages look like, or load limiting).

@git_base_url_list

List of Git base URLs. These URLs are used to generate URLs describing from where to fetch a project, which are shown on project summary page. The full fetch URL is “$git_base_url/$project”, for each element of this list. You can set up multiple base URLs (for example one for git:// protocol, and one for http:// protocol).
Note that per repository configuration can be set in $GIT_DIR/cloneurl file, or as values of multi-value gitweb.url configuration variable in project config. Per-repository configuration takes precedence over value composed from @git_base_url_list elements and project name.
You can setup one single value (single entry/item in this list) at build time by setting the GITWEB_BASE_URL build-time configuration variable. By default it is set to (), i.e. an empty list. This means that gitweb would not try to create project URL (to fetch) from project name.

$projects_list_group_categories

Whether to enable the grouping of projects by category on the project list page. The category of a project is determined by the $GIT_DIR/category file or the gitweb.category variable in each repository’s configuration. Disabled by default (set to 0).

$project_list_default_category

Default category for projects for which none is specified. If this is set to the empty string, such projects will remain uncategorized and listed at the top, above categorized projects. Used only if project categories are enabled, which means if $projects_list_group_categories is true. By default set to "" (empty string).

$prevent_xss

If true, some gitweb features are disabled to prevent content in repositories from launching cross-site scripting (XSS) attacks. Set this to true if you don’t trust the content of your repositories. False by default (set to 0).

$maxload

Used to set the maximum load that we will still respond to gitweb queries. If the server load exceeds this value then gitweb will return “503 Service Unavailable” error. The server load is taken to be 0 if gitweb cannot determine its value. Currently it works only on Linux, where it uses /proc/loadavg; the load there is the number of active tasks on the system — processes that are actually running — averaged over the last minute.
Set $maxload to undefined value (undef) to turn this feature off. The default value is 300.

$omit_age_column

If true, omit the column with date of the most current commit on the projects list page. It can save a bit of I/O and a fork per repository.

$omit_owner

If true prevents displaying information about repository owner.

$per_request_config

If this is set to code reference, it will be run once for each request. You can set parts of configuration that change per session this way. For example, one might use the following code in a gitweb configuration file
our $per_request_config = sub { $ENV{GL_USER} = $cgi->remote_user || “gitweb”; };
If $per_request_config is not a code reference, it is interpreted as boolean value. If it is true gitweb will process config files once per request, and if it is false gitweb will process config files only once, each time it is executed. True by default (set to 1).
NOTE: $my_url, $my_uri, and $base_url are overwritten with their default values before every request, so if you want to change them, be sure to set this variable to true or a code reference effecting the desired changes.
This variable matters only when using persistent web environments that serve multiple requests using single gitweb instance, like mod_perl, FastCGI or Plackup.

Other variables

Usually you should not need to change (adjust) any of configuration variables described below; they should be automatically set by gitweb to correct value.

$version

Gitweb version, set automatically when creating gitweb.cgi from gitweb.perl. You might want to modify it if you are running modified gitweb, for example
our $version .= " with caching";
if you run modified version of gitweb with caching support. This variable is purely informational, used e.g. in the “generator” meta header in HTML header.

$my_url, $my_uri

Full URL and absolute URL of the gitweb script; in earlier versions of gitweb you might have need to set those variables, but now there should be no need to do it. See $per_request_config if you need to set them still.

$base_url

Base URL for relative URLs in pages generated by gitweb, (e.g. $logo, $favicon, @stylesheets if they are relative URLs), needed and used <base href="$base_url"> only for URLs with nonempty PATH_INFO. Usually gitweb sets its value correctly, and there is no need to set this variable, e.g. to $my_uri or “/”. See $per_request_config if you need to override it anyway.

CONFIGURING GITWEB FEATURES

Many gitweb features can be enabled (or disabled) and configured using the %feature hash. Names of gitweb features are keys of this hash.

Each %feature hash element is a hash reference and has the following structure:

“<feature_name>” => { “sub” => <feature-sub (subroutine)>, “override” => <allow-override (boolean)>, “default” => [ … ] },

Some features cannot be overridden per project. For those features the structure of appropriate %feature hash element has a simpler form:

“<feature_name>” => { “override” => 0, “default” => [ … ] },

As one can see it lacks the sub element.

The meaning of each part of feature configuration is described below:

default

List (array reference) of feature parameters (if there are any), used also to toggle (enable or disable) given feature.
Note that it is currently always an array reference, even if feature doesn’t accept any configuration parameters, and default is used only to turn it on or off. In such case you turn feature on by setting this element to [1], and torn it off by setting it to [0]. See also the passage about the “blame” feature in the “Examples” section.
To disable features that accept parameters (are configurable), you need to set this element to empty list i.e. [].

override

If this field has a true value then the given feature is overridable, which means that it can be configured (or enabled/disabled) on a per-repository basis.
Usually given “<feature>” is configurable via the gitweb.<feature> config variable in the per-repository Git configuration file.
Note that no feature is overridable by default.

sub

Internal detail of implementation. What is important is that if this field is not present then per-repository override for given feature is not supported.
You wouldn’t need to ever change it in gitweb config file.

Features in %feature

The gitweb features that are configurable via %feature hash are listed below. This should be a complete list, but ultimately the authoritative and complete list is in gitweb.cgi source code, with features described in the comments.

blame

Enable the “blame” and “blame_incremental” blob views, showing for each line the last commit that modified it; see git-blame(1). This can be very CPU-intensive and is therefore disabled by default.
This feature can be configured on a per-repository basis via repository’s gitweb.blame configuration variable (boolean).

snapshot

Enable and configure the “snapshot” action, which allows user to download a compressed archive of any tree or commit, as produced by git-archive(1) and possibly additionally compressed. This can potentially generate high traffic if you have large project.
The value of default is a list of names of snapshot formats, defined in %known_snapshot_formats hash, that you wish to offer. Supported formats include “tgz”, “tbz2”, “txz” (gzip/bzip2/xz compressed tar archive) and “zip”; please consult gitweb sources for a definitive list. By default only “tgz” is offered.
This feature can be configured on a per-repository basis via repository’s gitweb.snapshot configuration variable, which contains a comma separated list of formats or “none” to disable snapshots. Unknown values are ignored.

grep

Enable grep search, which lists the files in currently selected tree (directory) containing the given string; see git-grep(1). This can be potentially CPU-intensive, of course. Enabled by default.
This feature can be configured on a per-repository basis via repository’s gitweb.grep configuration variable (boolean).

pickaxe

Enable the so called pickaxe search, which will list the commits that introduced or removed a given string in a file. This can be practical and quite faster alternative to “blame” action, but it is still potentially CPU-intensive. Enabled by default.
The pickaxe search is described in git-log(1) (the description of -S<string> option, which refers to pickaxe entry in gitdiffcore(7) for more details).
This feature can be configured on a per-repository basis by setting repository’s gitweb.pickaxe configuration variable (boolean).

show-sizes

Enable showing size of blobs (ordinary files) in a “tree” view, in a separate column, similar to what ls -l does; see description of -l option in git-ls-tree(1) manpage. This costs a bit of I/O. Enabled by default.
This feature can be configured on a per-repository basis via repository’s gitweb.showSizes configuration variable (boolean).

patches

Enable and configure “patches” view, which displays list of commits in email (plain text) output format; see also git-format-patch(1). The value is the maximum number of patches in a patchset generated in “patches” view. Set the default field to a list containing single item of or to an empty list to disable patch view, or to a list containing a single negative number to remove any limit. Default value is 16.
This feature can be configured on a per-repository basis via repository’s gitweb.patches configuration variable (integer).

avatar

Avatar support. When this feature is enabled, views such as “shortlog” or “commit” will display an avatar associated with the email of each committer and author.
Currently available providers are “gravatar” and “picon”. Only one provider at a time can be selected (default is one element list). If an unknown provider is specified, the feature is disabled. Note that some providers might require extra Perl packages to be installed; see gitweb/INSTALL for more details.
This feature can be configured on a per-repository basis via repository’s gitweb.avatar configuration variable.
See also %avatar_size with pixel sizes for icons and avatars (“default” is used for one-line like “log” and “shortlog”, “double” is used for two-line like “commit”, “commitdiff” or “tag”). If the default font sizes or lineheights are changed (e.g. via adding extra CSS stylesheet in @stylesheets), it may be appropriate to change these values.

email-privacy

Redact e-mail addresses from the generated HTML, etc. content. This obscures e-mail addresses retrieved from the author/committer and comment sections of the Git log. It is meant to hinder web crawlers that harvest and abuse addresses. Such crawlers may not respect robots.txt. Note that users and user tools also see the addresses as redacted. If Gitweb is not the final step in a workflow then subsequent steps may misbehave because of the redacted information they receive. Disabled by default.

highlight

Server-side syntax highlight support in “blob” view. It requires $highlight_bin program to be available (see the description of this variable in the “Configuration variables” section above), and therefore is disabled by default.
This feature can be configured on a per-repository basis via repository’s gitweb.highlight configuration variable (boolean).

remote_heads

Enable displaying remote heads (remote-tracking branches) in the “heads” list. In most cases the list of remote-tracking branches is an unnecessary internal private detail, and this feature is therefore disabled by default. git-instaweb(1), which is usually used to browse local repositories, enables and uses this feature.
This feature can be configured on a per-repository basis via repository’s gitweb.remote_heads configuration variable (boolean).

The remaining features cannot be overridden on a per project basis.

Enable text search, which will list the commits which match author, committer or commit text to a given string; see the description of –author, –committer and –grep options in git-log(1) manpage. Enabled by default.
Project specific override is not supported.

forks

If this feature is enabled, gitweb considers projects in subdirectories of project root (basename) to be forks of existing projects. For each project $projname.git, projects in the $projname/ directory and its subdirectories will not be shown in the main projects list. Instead, a + mark is shown next to $projname, which links to a “forks” view that lists all the forks (all projects in $projname/ subdirectory). Additionally a “forks” view for a project is linked from project summary page.
If the project list is taken from a file ($projects_list points to a file), forks are only recognized if they are listed after the main project in that file.
Project specific override is not supported.

actions

Insert custom links to the action bar of all project pages. This allows you to link to third-party scripts integrating into gitweb.
The “default” value consists of a list of triplets in the form ‘("<label>", “<link>”, “<position>”)` where “position” is the label after which to insert the link, “link” is a format string where %n expands to the project name, %f to the project path within the filesystem (i.e. “$projectroot/$project”), %h to the current hash (h’ gitweb parameter) and ‘%b` to the current hash base (hb’ gitweb parameter); ‘%%` expands to %’.
For example, at the time this page was written, the http://repo.or.cz Git hosting site set it to the following to enable graphical log (using the third party tool git-browser):
$feature{actions}{default} = [ (graphiclog, /git-browser/by-commit.html?r=%n, summary)];
This adds a link titled “graphiclog” after the “summary” link, leading to git-browser script, passing r=<project> as a query parameter.
Project specific override is not supported.

timed

Enable displaying how much time and how many Git commands it took to generate and display each page in the page footer (at the bottom of page). For example the footer might contain: “This page took 6.53325 seconds and 13 Git commands to generate.” Disabled by default.
Project specific override is not supported.

javascript-timezone

Enable and configure the ability to change a common time zone for dates in gitweb output via JavaScript. Dates in gitweb output include authordate and committerdate in “commit”, “commitdiff” and “log” views, and taggerdate in “tag” view. Enabled by default.
The value is a list of three values: a default time zone (for if the client hasn’t selected some other time zone and saved it in a cookie), a name of cookie where to store selected time zone, and a CSS class used to mark up dates for manipulation. If you want to turn this feature off, set “default” to empty list: [].
Typical gitweb config files will only change starting (default) time zone, and leave other elements at their default values:
$feature{javascript-timezone}{default}[0] = “utc”;
The example configuration presented here is guaranteed to be backwards and forward compatible.
Time zone values can be “local” (for local time zone that browser uses), “utc” (what gitweb uses when JavaScript or this feature is disabled), or numerical time zones in the form of “+/-HHMM”, such as “+0200”.
Project specific override is not supported.

extra-branch-refs

List of additional directories under “refs” which are going to be used as branch refs. For example if you have a gerrit setup where all branches under refs/heads/ are official, push-after-review ones and branches under refs/sandbox/, refs/wip and refs/other are user ones where permissions are much wider, then you might want to set this variable as follows:
$feature{extra-branch-refs}{default} = [sandbox, wip, other];
This feature can be configured on per-repository basis after setting $feature{extra-branch-refs}{override} to true, via repository’s gitweb.extraBranchRefs configuration variable, which contains a space separated list of refs. An example:
[gitweb] extraBranchRefs = sandbox wip other
The gitweb.extraBranchRefs is actually a multi-valued configuration variable, so following example is also correct and the result is the same as of the snippet above:
[gitweb] extraBranchRefs = sandbox extraBranchRefs = wip other
It is an error to specify a ref that does not pass “git check-ref-format” scrutiny. Duplicated values are filtered.

EXAMPLES

To enable blame, pickaxe search, and snapshot support (allowing “tar.gz” and “zip” snapshots), while allowing individual projects to turn them off, put the following in your GITWEB_CONFIG file:

$feature{blame}{default} = [1]; $feature{blame}{override} = 1;

$feature{pickaxe}{default} = [1];
$feature{pickaxe}{override} = 1;

$feature{snapshot}{default} = [zip, tgz];
$feature{snapshot}{override} = 1;

If you allow overriding for the snapshot feature, you can specify which snapshot formats are globally disabled. You can also add any command-line options you want (such as setting the compression level). For instance, you can disable Zip compressed snapshots and set gzip(1) to run at level 6 by adding the following lines to your gitweb configuration file:

$known_snapshot_formats{zip}{disabled} = 1; $known_snapshot_formats{tgz}{compressor} = [gzip,-6];

BUGS

Debugging would be easier if the fallback configuration file (/etc/gitweb.conf) and environment variable to override its location (GITWEB_CONFIG_SYSTEM) had names reflecting their “fallback” role. The current names are kept to avoid breaking working setups.

ENVIRONMENT

The location of per-instance and system-wide configuration files can be overridden using the following environment variables:

GITWEB_CONFIG

Sets location of per-instance configuration file.

GITWEB_CONFIG_SYSTEM

Sets location of fallback system-wide configuration file. This file is read only if per-instance one does not exist.

GITWEB_CONFIG_COMMON

Sets location of common system-wide configuration file.

FILES

gitweb_config.perl

This is default name of per-instance configuration file. The format of this file is described above.

/etc/gitweb.conf

This is default name of fallback system-wide configuration file. This file is used only if per-instance configuration variable is not found.

/etc/gitweb-common.conf

This is default name of common system-wide configuration file.

GIT

Part of the git(1) suite

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

27 - Linux cli command smartd.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command smartd.conf and provides detailed information about the command smartd.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the smartd.conf.

SPDX-License-Identifier: GPL-2.0-or-later

$Id: smartd.conf.5.in 5521 2023-07-24 16:44:49Z chrfranke $

NAME 🖥️ smartd.conf 🖥️

SMART Disk Monitoring Daemon Configuration File

DESCRIPTION

[This man page is generated for the Linux version of smartmontools. It does not contain info specific to other platforms.]

/etc/smartd.conf is the configuration file for the smartd daemon.

If the configuration file /etc/smartd.conf is present, smartd reads it at startup. If smartd subsequently receives a HUP signal, it will then re-read the configuration file. If smartd is running in debug mode, then an INT signal will also make it re-read the configuration file. This signal can be generated by typing <CONTROL-C> in the terminal window where smartd is running.

In the absence of a configuration file smartd will try to open all available devices (see smartd(8) man page). A configuration file with a single line DEVICESCAN -a would have the same effect.

This can be annoying if you have an ATA or SCSI device that hangs or misbehaves when receiving SMART commands. Even if this causes no problems, you may be annoyed by the string of error log messages about devices that can’t be opened.

One can avoid this problem, and gain more control over the types of events monitored by smartd, by using the configuration file /etc/smartd.conf. This file contains a list of devices to monitor, with one device per line. An example file is included with the smartmontools distribution. You will find this sample configuration file in /usr/share/doc/smartmontools/. For security, the configuration file should not be writable by anyone but root. The syntax of the file is as follows:

There should be one device listed per line, although you may have lines that are entirely comments or white space.
Any text following a hash sign # and up to the end of the line is taken to be a comment, and ignored.
Lines may be continued by using a backslash \ as the last non-whitespace or non-comment item on a line.
Note: a line whose first character is a hash sign # is treated as a white-space blank line, not as a non-existent line, and will end a continuation line.

Here is an example configuration file. It’s for illustrative purposes only; please don’t copy it onto your system without reading to the end of the DIRECTIVES Section below!

################################################ # This is an example smartd startup config file # /etc/smartd.conf # # On the second disk, start a long self-test every # Sunday between 3 and 4 am. # /dev/sda -a -m [email protected],root@localhost /dev/sdb -a -I 194 -I 5 -i 12 -s L/../../7/03 # # Send a TEST warning email to admin on startup. # /dev/sdc -m [email protected] -M test # # An ATA disk may appear as a SCSI device to the # OS. If a SCSI to ATA Translation (SAT) layer # is between the OS and the device then this can be # flagged with the ‘-d sat’ option. /dev/sda -a -d sat # # Disks connected to a MegaRAID controller # Start short self-tests daily between 1-2, 2-3, and # 3-4 am. # Linux: /dev/sda -d megaraid,0 -a -s S/../.././01 /dev/sda -d megaraid,1 -a -s S/../.././02 /dev/sda -d megaraid,2 -a -s S/../.././03 /dev/bus/0 -d megaraid,2 -a -s S/../.././03 # # Three disks connected to an AacRaid controller # Start short self-tests daily between 1-2, 2-3, and # 3-4 am. /dev/sda -d aacraid,0,0,66 -a -s S/../.././01 /dev/sda -d aacraid,0,0,67 -a -s S/../.././02 /dev/sda -d aacraid,0,0,68 -a -s S/../.././03 # # Two SATA (not SAS) disks on a 3ware 9750 controller. # Start long self-tests Sundays between midnight and # 1 am and 2-3 am # under Linux /dev/twl0 -d 3ware,0 -a -s L/../../7/00 /dev/twl0 -d 3ware,1 -a -s L/../../7/02 # # Two disks connected to the first HP SmartArray controller # which uses the Linux cciss driver. Start long self-tests # on Sunday nights and short self-tests every night and send # errors to root. /dev/sda -d cciss,0 -a -s (L/../../7/02|S/../.././02) -m root /dev/sda -d cciss,1 -a -s (L/../../7/03|S/../.././03) -m root # # Monitor 2 disks connected to the first HP SmartArray controller which # uses the cciss driver. Start long tests on Sunday nights and short # self-tests every night and send errors to root # /dev/sda -d cciss,0 -a -s (L/../../7/02|S/../.././02) -m root # /dev/sda -d cciss,1 -a -s (L/../../7/03|S/../.././03) -m root # # Three SATA disks on a HighPoint RocketRAID controller. # Start short self-tests daily between 1-2, 2-3, and # 3-4 am. # under Linux /dev/sde -d hpt,1/1 -a -s S/../.././01 /dev/sde -d hpt,1/2 -a -s S/../.././02 /dev/sde -d hpt,1/3 -a -s S/../.././03 # # Two SATA disks connected to a HighPoint RocketRAID # via a pmport device. Start long self-tests Sundays # between midnight and 1 am and 2-3 am. # under Linux /dev/sde -d hpt,1/4/1 -a -s L/../../7/00 /dev/sde -d hpt,1/4/2 -a -s L/../../7/02 # # Three SATA disks connected to an Areca # RAID controller. Start long self-tests Sundays # between midnight and 3 am. # under Linux /dev/sg2 -d areca,1 -a -s L/../../7/00 /dev/sg2 -d areca,2 -a -s L/../../7/01 /dev/sg2 -d areca,3 -a -s L/../../7/02 # # The following line enables monitoring of the # ATA Error Log and the Self-Test Error Log. # It also tracks changes in both Prefailure # and Usage Attributes, apart from Attributes # 9, 194, and 231, and shows continued lines: # /dev/sdd -l error \ -l selftest \ -t \ # Attributes not tracked: -I 194 \ # temperature -I 231 \ # also temperature -I 9 # power-on hours # ################################################ If a cciss controller is used then the corresponding block device (/dev/sd?) must be listed, along with the ‘-d cciss,N’ Directive (see below).

DEVICESCAN

If a non-comment entry in the configuration file is the text string DEVICESCAN in capital letters, then smartd will ignore any remaining lines in the configuration file, and will scan for devices. If DEVICESCAN is not followed by any Directives, then -a will apply to all devices.

DEVICESCAN may optionally be followed by Directives that will apply to all devices that are found in the scan. For example

DEVICESCAN -m [email protected]

will scan for all devices, and then monitor them. It will send one email warning per device for any problems that are found.

DEVICESCAN -H -m [email protected]

will do the same, but only monitors the SMART health status of the devices, rather than the default -a.

Multiple -d TYPE options may be specified with DEVICESCAN to combine the scan results of more than one TYPE.

Configuration entries for specific devices may precede the DEVICESCAN entry. For example

DEFAULT -m [email protected] /dev/sda -s S/../.././02 /dev/sdc -d ignore DEVICESCAN -s L/../.././02

will scan for all devices except /dev/sda and /dev/sdc, monitor them, and run a long test between 2–3 am every morning. Device /dev/sda will also be monitored, but only a short test will be run. Device /dev/sdc will be ignored. Warning emails will be sent for all monitored devices.

A device is ignored by DEVICESCAN if a configuration line with the same device name exists. Symbolic links are resolved before this check is done. A device name is also ignored if another device with same identify information (vendor, model, firmware version, serial number, WWN) already exists.

DEFAULT SETTINGS

If an entry in the configuration file starts with DEFAULT instead of a device name, then all directives in this entry are set as defaults for the next device entries.

This configuration:

DEFAULT -a -R5! -W 2,40,45 -I 194 -s L/../../7/00 -m [email protected] /dev/sda /dev/sdb /dev/sdc DEFAULT -H -m [email protected] /dev/sdd /dev/sde -d removable

has the same effect as:

/dev/sda -a -R5! -W 2,40,45 -I 194 -s L/../../7/00 -m [email protected] /dev/sdb -a -R5! -W 2,40,45 -I 194 -s L/../../7/00 -m [email protected] /dev/sdc -a -R5! -W 2,40,45 -I 194 -s L/../../7/00 -m [email protected] /dev/sdd -H -m [email protected] /dev/sde -d removable -H -m [email protected]

CONFIGURATION FILE DIRECTIVES

The following are the Directives that may appear following the device name or DEVICESCAN or DEFAULT on any line of the /etc/smartd.conf configuration file. Note that these are NOT command-line options for smartd. The Directives below may appear in any order, following the device name.

For an ATA device, if no Directives appear, then the device will be monitored as if the -a Directive (monitor all SMART properties) had been given.

If a SCSI disk is listed, it will be monitored at the maximum implemented level: roughly equivalent to using the -H -l selftest options for an ATA disk. So with the exception of -d, -m, -l selftest, -s, and -M, the Directives below are ignored for SCSI disks. For SCSI disks, the -m Directive sends a warning email if the SMART status indicates a disk failure or problem, if the SCSI inquiry about disk status fails, or if new errors appear in the self-test log.

If a 3ware controller is used then the corresponding SCSI (/dev/sd?) or character device (/dev/twe?, /dev/twa?, /dev/twl? or /dev/tws?) must be listed, along with the -d 3ware,N Directive (see below). The individual ATA disks hosted by the 3ware controller appear to smartd as normal ATA devices. Hence all the ATA directives can be used for these disks (but see note below).

If an Areca controller is used then the corresponding device (SCSI /dev/sg? on Linux or /dev/arcmsr0 on FreeBSD) must be listed, along with the -d areca,N Directive (see below). The individual SATA disks hosted by the Areca controller appear to smartd as normal ATA devices. Hence all the ATA directives can be used for these disks. Areca firmware version 1.46 or later which supports smartmontools must be used; Please see the smartctl(8) man page for further details.

-d TYPE
Specifies the type of the device. The valid arguments to this directive are: auto - attempt to guess the device type from the device name or from controller type info provided by the operating system or from a matching USB ID entry in the drive database. This is the default. ata - the device type is ATA. This prevents smartd from issuing SCSI commands to an ATA device. scsi - the device type is SCSI. This prevents smartd from issuing ATA commands to a SCSI device. nvme[,NSID] - the device type is NVM Express (NVMe). The optional parameter NSID specifies the namespace id (in hex) passed to the driver. Use 0xffffffff for the broadcast namespace id. The default for NSID is the namespace id addressed by the device name. sat[,auto][,N] - the device type is SCSI to ATA Translation (SAT). This is for ATA disks that have a SCSI to ATA Translation Layer (SATL) between the disk and the operating system. SAT defines two ATA PASS THROUGH SCSI commands, one 12 bytes long and the other 16 bytes long. The default is the 16 byte variant which can be overridden with either -d sat,12 or -d sat,16. If -d sat,auto is specified, device type SAT (for ATA/SATA disks) is only used if the SCSI INQUIRY data reports a SATL (VENDOR: “ATA “). Otherwise device type SCSI (for SCSI/SAS disks) is used. usbasm1352r,PORT - [NEW EXPERIMENTAL SMARTD 7.4 FEATURE] this device type is for one or two SATA disks that are behind an ASMedia ASM1352R USB to SATA (RAID) bridge. The parameter PORT (0 or 1) selects the disk to monitor.
Note: This USB bridge also supports -d sat. This monitors either the first disk or the second disk if no disk is connected to the first port. usbcypress - this device type is for ATA disks that are behind a Cypress USB to PATA bridge. This will use the ATACB proprietary scsi pass through command. The default SCSI operation code is 0x24, but although it can be overridden with -d usbcypress,0xN, where N is the scsi operation code, you’re running the risk of damage to the device or filesystems on it. usbjmicron[,p][,x][,PORT] - this device type is for SATA disks that are behind a JMicron USB to PATA/SATA bridge. The 48-bit ATA commands (required e.g. for -l xerror, see below) do not work with all of these bridges and are therefore disabled by default. These commands can be enabled by -d usbjmicron,x. If two disks are connected to a bridge with two ports, an error message is printed if no PORT (0 or 1) is specified.
The PORT parameter is not necessary if the device uses a port multiplier to connect multiple disks to one port. The disks appear under separate /dev/ice names then.
CAUTION: Specifying ,x for a device which does not support it results in I/O errors and may disconnect the drive. The same applies if the specified PORT does not exist or is not connected to a disk. The Prolific PL2507/3507 USB bridges with older firmware support a pass-through command similar to JMicron and work with -d usbjmicron,0. Newer Prolific firmware requires a modified command which can be selected by -d usbjmicron,p. Note that this does not yet support the SMART status command. usbprolific - this device type is for SATA disks that are behind a Prolific PL2571/2771/2773/2775 USB to SATA bridge. usbsunplus - this device type is for SATA disks that are behind a SunplusIT USB to SATA bridge. sntasmedia - [NEW EXPERIMENTAL SMARTD 7.3 FEATURE] this device type is for NVMe disks that are behind an ASMedia USB to NVMe bridge. sntjmicron[,NSID] - this device type is for NVMe disks that are behind a JMicron USB to NVMe bridge. The optional parameter NSID specifies the namespace id (in hex) passed to the driver. The default namespace id is the broadcast namespace id (0xffffffff). sntrealtek - this device type is for NVMe disks that are behind a Realtek USB to NVMe bridge. marvell - [Linux only] (deprecated and subject to remove). megaraid,N - [FreeBSD and Linux only] the device consists of one or more SCSI/SAS disks connected to a MegaRAID controller. The non-negative integer N (in the range of 0 to 127 inclusive) denotes which disk on the controller is monitored. This interface will also work for Dell PERC controllers. In log files and email messages this disk will be identified as megaraid_disk_XXX with XXX in the range from 000 to 127 inclusive. Please see the smartctl(8) man page for further details. aacraid,H,L,ID - [Linux, Windows and Cygwin only] the device consists of one or more SCSI/SAS or SATA disks connected to an AacRaid controller. The non-negative integers H,L,ID (Host number, Lun, ID) denote which disk on the controller is monitored. In log files and email messages this disk will be identified as aacraid_disk_HH_LL_ID. Please see the smartctl(8) man page for further details. 3ware,N - [FreeBSD and Linux only] the device consists of one or more ATA disks connected to a 3ware RAID controller. The non-negative integer N (in the range from 0 to 127 inclusive) denotes which disk on the controller is monitored. In log files and email messages this disk will be identified as 3ware_disk_XXX with XXX in the range from 000 to 127 inclusive. Note that while you may use any of the 3ware SCSI logical devices /dev/tw* to address any of the physical disks (3ware ports), error and log messages will make the most sense if you always list the 3ware SCSI logical device corresponding to the particular physical disks. Please see the smartctl(8) man page for further details. areca,N - [FreeBSD, Linux, Windows and Cygwin only] the device consists of one or more SATA disks connected to an Areca SATA RAID controller. The positive integer N (in the range from 1 to 24 inclusive) denotes which disk on the controller is monitored. In log files and email messages this disk will be identified as areca_disk_XX with XX in the range from 01 to 24 inclusive. Please see the smartctl(8) man page for further details. areca,N/E - [FreeBSD, Linux, Windows and Cygwin only] the device consists of one or more SATA or SAS disks connected to an Areca SAS RAID controller. The integer N (range 1 to 128) denotes the channel (slot) and E (range 1 to 8) denotes the enclosure. Important: This requires Areca SAS controller firmware version 1.51 or later. cciss,N - [FreeBSD and Linux only] the device consists of one or more SCSI/SAS or SATA disks connected to a cciss RAID controller. The non-negative integer N (in the range from 0 to 15 inclusive) denotes which disk on the controller is monitored. In log files and email messages this disk will be identified as cciss_disk_XX with XX in the range from 00 to 15 inclusive. Please see the smartctl(8) man page for further details. hpt,L/M/N - [FreeBSD and Linux only] the device consists of one or more ATA disks connected to a HighPoint RocketRAID controller. The integer L is the controller id, the integer M is the channel number, and the integer N is the PMPort number if it is available. The allowed values of L are from 1 to 4 inclusive, M are from 1 to 128 inclusive and N from 1 to 4 if PMPort available. And also these values are limited by the model of the HighPoint RocketRAID controller. In log files and email messages this disk will be identified as hpt_X/X/X and X/X/X is the same as L/M/N, note if no N indicated, N set to the default value 1. Please see the smartctl(8) man page for further details. sssraid,E,S - [Linux only: NEW EXPERIMENTAL SMARTD 7.4 FEATURE] the device consists of one or more SCSI/SAS or SATA disks connected to a SSSRAID controller. The non-negative integer E (in the range of 0 to 8) denotes the enclosure and S(range 0 to 128) denotes the slot. Please see the smartctl(8) man page for further details. intelliprop,N[+TYPE] - (deprecated and subject to remove). jmb39x[-q],N[,sLBA][,force][+TYPE] - the device consists of multiple SATA disks connected to a JMicron JMB39x RAID port multiplier. The suffix -q selects a slightly different command variant used by some QNAP NAS devices. The integer N is the port number from 0 to 4. Please see the smartctl(8) man page for further details. jms56x,N[,sLBA][,force][+TYPE] - the device consists of multiple SATA disks connected to a JMicron JMS56x USB to SATA RAID bridge. See jmb39x… above for valid arguments. ignore - the device specified by this configuration entry should be ignored. This allows one to ignore specific devices which are detected by a following DEVICESCAN configuration line. It may also be used to temporary disable longer multi-line configuration entries. This Directive may be used in conjunction with the other -d Directives. removable - the device or its media is removable. This indicates to smartd that it should continue (instead of exiting, which is the default behavior) if the device does not appear to be present when smartd is started. This directive also suppresses warning emails and repeated log messages if the device is removed after startup. This Directive may be used in conjunction with the other -d Directives.
WARNING: Removing a device and connecting a different one to same interface is not supported and may result in bogus warnings until smartd is restarted.

-n POWERMODE[,N][,q]
[ATA only] This nocheck Directive is used to prevent a disk from being spun-up when it is periodically polled by smartd. ATA disks have five different power states. In order of increasing power consumption they are: OFF, SLEEP, STANDBY, IDLE, and ACTIVE. Typically in the OFF, SLEEP, and STANDBY modes the disk’s platters are not spinning. But usually, in response to SMART commands issued by smartd, the disk platters are spun up. So if this option is not used, then a disk which is in a low-power mode may be spun up and put into a higher-power mode when it is periodically polled by smartd. Note that if the disk is in SLEEP mode when smartd is started, then it won’t respond to smartd commands, and so the disk won’t be registered as a device for smartd to monitor. If a disk is in any other low-power mode, then the commands issued by smartd to register the disk will probably cause it to spin-up. The -n (nocheck) Directive specifies if smartd’s periodic checks should still be carried out when the device is in a low-power mode. It may be used to prevent a disk from being spun-up by periodic smartd polling. The allowed values of POWERMODE are: never - smartd will poll (check) the device regardless of its power mode. This may cause a disk which is spun-down to be spun-up when smartd checks it. This is the default behavior if the ‘-n’ Directive is not given. sleep - check the device unless it is in SLEEP mode. standby - check the device unless it is in SLEEP or STANDBY mode. In these modes most disks are not spinning, so if you want to prevent a laptop disk from spinning up each time that smartd polls, this is probably what you want. idle - check the device unless it is in SLEEP, STANDBY or IDLE mode. In the IDLE state, most disks are still spinning, so this is probably not what you want. Maximum number of skipped checks (in a row) can be specified by appending positive number ,N to POWERMODE (like -n standby,15). After N checks are skipped in a row, powermode is ignored and the check is performed anyway. When a periodic test is skipped, smartd normally writes an informal log message. The message can be suppressed by appending the option ,q to POWERMODE (like -n standby,q). This prevents a laptop disk from spinning up due to this message. Both ,N and ,q can be specified together.

-T TYPE
Specifies how tolerant smartd should be of SMART command failures. The valid arguments to this Directive are: normal - do not try to monitor the disk if a mandatory SMART command fails, but continue if an optional SMART command fails. This is the default. permissive - try to monitor the disk even if it appears to lack SMART capabilities. This may be required for some old disks (prior to ATA-3 revision 4) that implemented SMART before the SMART standards were incorporated into the ATA/ATAPI Specifications. [Please see the smartctl -T command-line option.]

-o VALUE
[ATA only] Enables or disables SMART Automatic Offline Testing when smartd starts up and has no further effect. The valid arguments to this Directive are on and off**.** The delay between tests is vendor-specific, but is typically four hours. Note that SMART Automatic Offline Testing is not part of the ATA Specification. Please see the smartctl -o command-line option documentation for further information about this feature.

-S VALUE
Enables or disables Attribute Autosave when smartd starts up and has no further effect. The valid arguments to this Directive are on and off**. Also affects SCSI devices.** [Please see the smartctl -S command-line option.]

-H
[ATA] Check the health status of the disk with the SMART RETURN STATUS command. If this command reports a failing health status, then disk failure is predicted in less than 24 hours, and a message at loglevel LOG_CRIT will be logged to syslog. [Please see the smartctl -H command-line option.] [NVMe] Checks the “Critical Warning” byte from the SMART/Health Information log. If any warning bit is set, a message at loglevel LOG_CRIT will be logged to syslog.

-l TYPE
Reports increases in the number of errors in one of three SMART logs. The valid arguments to this Directive are: error - [ATA] report if the number of ATA errors reported in the Summary SMART error log has increased since the last check. error - [NVMe] report if the “Number of Error Information Log Entries” from the SMART/Health Information log has increased since the last check.
[NEW EXPERIMENTAL SMARTD 7.4 FEATURE] This will only be logged as LOG_CRIT if at least one of the new errors is still present in the Error Information log and its status indicates a device related error. Up to eight of the most recent of these errors are logged as LOG_INFO then. This is useful because the NVMe Error Information log is not persistent across power cycles or device resets.
If all new errors are either no longer present in the log or are not device related (e.g. invalid command, invalid field in command, …), a LOG_INFO message is generated instead. This avoids misleading warnings if the operating system issues unsupported commands and the device firmware also logs these kind of errors. xerror - [ATA] report if the number of ATA errors reported in the Extended Comprehensive SMART error log has increased since the last check. If both -l error and -l xerror are specified, smartd checks the maximum of both values. [Please see the smartctl -l xerror command-line option.] xerror - [NVMe] same as -l error. selftest - report if the number of failed tests reported in the SMART Self-Test Log has increased since the last check, or if the timestamp associated with the most recent failed test has increased. Note that such errors will only be logged if you run self-tests on the disk (and it fails a test!). Self-Tests can be run automatically by smartd: please see the -s Directive below. Self-Tests can also be run manually by using the -t short and -t long options of smartctl and the results of the testing can be observed using the smartctl -l selftest command-line option. [Please see the smartctl -l and -t command-line options.] [ATA only] Failed self-tests outdated by a newer successful extended self-test are ignored. The warning email counter is reset if the number of failed self tests dropped to 0. This typically happens when an extended self-test is run after all bad sectors have been reallocated. offlinests[,ns] - [ATA only] report if the Offline Data Collection status has changed since the last check. The report will be logged as LOG_CRIT if the new status indicates an error. With some drives the status often changes, therefore -l offlinests is not enabled by -a Directive. Appending ‘,ns’ (no standby) to this directive is not implemented on Linux. selfteststs[,ns] - [ATA only] report if the Self-Test execution status has changed since the last check. The report will be logged as LOG_CRIT if the new status indicates an error. Appending ‘,ns’ (no standby) to this directive is not implemented on Linux. scterc,READTIME,WRITETIME - [ATA only] sets the SCT Error Recovery Control settings to the specified values (deciseconds) when smartd starts up and has no further effect. Values of 0 disable the feature, other values less than 65 are probably not supported. For RAID configurations, this is typically set to 70,70 deciseconds. [Please see the smartctl -l scterc command-line option.]

-e NAME[,VALUE]
Sets non-SMART device settings when smartd starts up and has no further effect. [Please see the smartctl –set command-line option.] Valid arguments are: aam,[N|off] - [ATA only] Sets the Automatic Acoustic Management (AAM) feature. apm,[N|off] - [ATA only] Sets the Advanced Power Management (APM) feature. lookahead,[on|off] - [ATA only] Sets the read look-ahead feature. security-freeze - [ATA only] Sets ATA Security feature to frozen mode. standby,[N|off] - [ATA only] Sets the standby (spindown) timer and places the drive in the IDLE mode. wcache,[on|off] - [ATA only] Sets the volatile write cache feature. dsn,[on|off] - [ATA only] Sets the DSN feature.

-s REGEXP
Run Self-Tests or Offline Immediate Tests, at scheduled times. A Self- or Offline Immediate Test will be run at the end of periodic device polling, if all 12 characters of the string T/MM/DD/d/HH match the extended regular expression REGEXP. Here:

is the type of the test. The values that smartd will try to match (in turn) are: L for a Long Self-Test, S for a Short Self-Test, C for a Conveyance Self-Test (ATA only), and O for an Offline Immediate Test (ATA only). As soon as a match is found, the test will be started and no additional matches will be sought for that device and that polling cycle. To run scheduled Selective Self-Tests, use n for next span, r to redo last span, or c to continue with next span or redo last span based on status of last test. The LBA range is based on the first span from the last test. See the smartctl -t select,[next|redo|cont] options for further info. Some disks (e.g. WD) do not preserve the selective self test log across power cycles. If state persistence (-s option) is enabled, the last test span is preserved by smartd and used if (and only if) the selective self test log is empty.
is the month of the year, expressed with two decimal digits. The range is from 01 (January) to 12 (December) inclusive. Do not use a single decimal digit or the match will always fail!

DD
is the day of the month, expressed with two decimal digits. The range is from 01 to 31 inclusive. Do not use a single decimal digit or the match will always fail!

is the day of the week, expressed with one decimal digit. The range is from 1 (Monday) to 7 (Sunday) inclusive.

HH
is the hour of the day, written with two decimal digits, and given in hours after midnight. The range is 00 (midnight to just before 1 am) to 23 (11pm to just before midnight) inclusive. Do not use a single decimal digit or the match will always fail!

If the regular expression contains substrings of the form :NNN or :NNN-LLL, where NNN and LLL are three decimal digits, staggered tests are enabled. Then a test will also be run if all 16 (or 20) characters of the string T/MM/DD/d/HH:NNN (or T/MM/DD/d/HH:NNN-LLL) match the regular expression. This check is done for up to seven :NNN or :NNN-LLL found in the regular expression. The time used for the check is adjusted to the past such that tests of the first drive are not delayed, tests of the second drive are delayed by NNN hours, tests of the third drive are delayed by 2*NNN hours, and so on.
If LLL is also specified, delays are limited to LLL hours by calculating each individual delay as:
((DRIVE_INDEX * NNN) mod (LLL + 1)). Some examples follow. In reading these, keep in mind that in extended regular expressions a dot . matches any single character, and a parenthetical expression such as (A|B|C) denotes any one of the three possibilities A, B, or C. To schedule a short Self-Test between 2–3 am every morning, use:
-s S/../.././02
To schedule a long Self-Test between 4–5 am every Sunday morning, use:
-s L/../../7/04
To enable staggered tests with delays in three hour steps, use:
-s L/../../7/04:003
To enable staggered tests with delays 0, 3, 6, 9, 1, 4, 7, 10, 2, 5, 8, 0, … hours, use:
-s L/../../7/04:003-010
To enable staggered tests with delays 0, 1, 2, …, 9, 10, 0, … hours, use:
-s L/../../7/04:001-010
To schedule a long Self-Test between 10–11 pm on the first and fifteenth day of each month, use:
-s L/../(01|15)/./22
To schedule an Offline Immediate test after every midnight, 6 am, noon, and 6 pm, plus a Short Self-Test daily at 1–2 am and a Long Self-Test every Saturday at 3–4 am, use:
-s (O/../.././(00|06|12|18)|S/../.././01|L/../../6/03)
To enable staggered Long Self-Tests with delays in three hour steps, use:
-s (O/../.././(00|06|12|18)|S/../.././01|L/../../6/03:003)
If Long Self-Tests of a large disks take longer than the system uptime, a full disk test can be performed by several Selective Self-Tests. To setup a full test of a 1 TB disk within 20 days (one 50 GB span each day), run this command once:

  smartctl -t select,0-99999999 /dev/sda

To run the next test spans on Monday–Friday between 12–13 am, run smartd with this directive:
-s n/../../[1-5]/12 Scheduled tests are run immediately following the regularly-scheduled device polling, if the current local date, time, and test type, match REGEXP. By default the regularly-scheduled device polling occurs every thirty minutes after starting smartd. Take caution if you use the -i option to make this polling interval more than sixty minutes: the poll times may fail to coincide with any of the testing times that you have specified with REGEXP. In this case the test will be run following the next device polling. Before running an offline or self-test, smartd checks to be sure that a self-test is not already running. If a self-test is already running, then this running self test will not be interrupted to begin another test. smartd will not attempt to run any type of test if another test was already started or run in the same hour. To avoid performance problems during system boot, smartd will not attempt to run any scheduled tests following the very first device polling (unless -q onecheck is specified). Each time a test is run, smartd will log an entry to SYSLOG. You can use these or the -q showtests command-line option to verify that you constructed REGEXP correctly. The matching order (L before S before C before O) ensures that if multiple test types are all scheduled for the same hour, the longer test type has precedence. This is usually the desired behavior. If the scheduled tests are used in conjunction with state persistence (-s option), smartd will also try to match the hours since last shutdown (or 90 days at most). If any test would have been started during downtime, the longest (see above) of these tests is run after second device polling. If the -n directive is used and any test would have been started during disk standby time, the longest of these tests is run when the disk is active again. Unix users: please beware that the rules for extended regular expressions [regex(7)] are not the same as the rules for file-name pattern matching by the shell [glob(7)]. smartd will issue harmless informational warning messages if it detects characters in REGEXP that appear to indicate that you have made this mistake.

-m ADD
Send a warning email to the email address ADD if the -H, -l error, -l xerror, -l selftest, -f, -C, -U, or -W Directives detect a failure or a new error, or if a SMART command to the disk fails. This Directive only works in conjunction with these other Directives (or with the equivalent default -a Directive). To prevent your email in-box from getting filled up with warning messages, by default only a single warning and (depending on -s option) daily reminder emails will be sent for each of the enabled alert types. See the -M Directive below for details. To send email to more than one user, please use the following “comma separated” form for the address: user1@add1,user2@add2,…,userN@addN (with no spaces). To test that email is being sent correctly, use the -M test Directive described below to send one test email message on smartd startup. By default, email is sent using the system mail(1) command. In order that smartd find this command (normally /usr/bin/mail) the executable must be in the path of the shell or environment from which smartd was started. If you wish to specify an explicit path to the mail executable (for example /usr/local/bin/mail) or a custom script to run, please use the -M exec Directive below. Note also that there is a special argument <nomailer> which can be given to the -m Directive in conjunction with the -M exec Directive. Please see below for an explanation of its effect. If the mailer or the shell running it produces any STDERR/STDOUT output, then a snippet of that output will be copied to SYSLOG. The remainder of the output is discarded. If problems are encountered in sending mail, this should help you to understand and fix them. If you have mail problems, we recommend running smartd in debug mode with the -d flag, using the -M test Directive described below. If a word of the comma separated list has the form @plugin, a custom script /etc/smartmontools/smartd_warning.d/plugin is run and the word is removed from the list before sending mail. The string plugin may be any valid name except ALL. If @ALL is specified, all scripts in /etc/smartmontools/smartd_warning.d/* are run instead. This is handled by the script /usr/share/smartmontools/smartd_warning.sh (see also -M exec below). Plugin scripts without execute permission are silently ignored. If any plugin script is missing or fails with a nonzero exit status, the warning script exits immediately without sending mail.

-M TYPE
These Directives modify the behavior of the smartd email warnings enabled with the -m email Directive described above. These -M Directives only work in conjunction with the -m Directive and can not be used without it. Multiple -M Directives may be given. If more than one of the following three -M Directives are given (example: -M once -M daily) then the final one (in the example, -M daily) is used. The valid arguments to the -M Directive are (one of the following three): once - send only one warning email for each type of disk problem detected. This is the default unless state persistence (-s option) is enabled. always - [NEW EXPERIMENTAL SMARTD 7.4 FEATURE] send additional warning reminder emails, upon each check, for each type of disk problem detected. daily - send additional warning reminder emails, once per day, for each type of disk problem detected. This is the default if state persistence (-s option) is enabled. diminishing - send additional warning reminder emails, after a one-day interval, then a two-day interval, then a four-day interval, and so on for each type of disk problem detected. Each interval is twice as long as the previous interval.
[NEW EXPERIMENTAL SMARTD 7.4 FEATURE] The interval length will stay at 32 days after 5 warning reminder emails. If a disk problem is no longer detected, the internal email counter is reset. If the problem reappears a new warning email is sent immediately. In addition, one may add zero or more of the following Directives: test - send a single test email immediately upon smartd startup. This allows one to verify that email is delivered correctly. Note that if this Directive is used, smartd will also send the normal email warnings that were enabled with the -m Directive, in addition to the single test email! exec PATH - run the executable PATH instead of the default mail command, when smartd needs to send email. PATH must point to an executable binary file or script. By setting PATH to point to a customized script, you can make smartd perform useful tricks when a disk problem is detected (beeping the console, shutting down the machine, broadcasting warnings to all logged-in users, etc.) But please be careful. smartd will block until the executable PATH returns, so if your executable hangs, then smartd will also hang. Some sample scripts are included in /usr/share/doc/smartmontools/examples//. The exit status of the executable is recorded by smartd in SYSLOG. The executable is not expected to write to STDOUT or STDERR. If it does, then this is interpreted as indicating that something is going wrong with your executable, and a fragment of this output is logged to SYSLOG to help you to understand the problem. Normally, if you wish to leave some record behind, the executable should send mail or write to a file or device. Before running the executable, smartd sets a number of environment variables. These environment variables may be used to control the executable’s behavior. The environment variables exported by smartd are:

SMARTD_MAILER
is set to the argument of -M exec, if present or else to mail (examples: /usr/local/bin/mail, mail).

SMARTD_DEVICE
is set to the device path (example: /dev/sda).

SMARTD_DEVICETYPE
is set to the device type specified by -d directive or auto if none.

SMARTD_DEVICESTRING
is set to the device description. It starts with SMARTD_DEVICE and may be followed by an optional controller identification (example: /dev/sda [SAT]). The string may contain a space and is NOT quoted.

SMARTD_DEVICEINFO
is set to device identify information. It includes most of the info printed by smartctl -i but uses a brief single line format. This device info is also logged when smartd starts up. The string contains space characters and is NOT quoted.

SMARTD_FAILTYPE
gives the reason for the warning or message email. The possible values that it takes and their meanings are:
EmailTest**: this is an email test message.**
Health**: the SMART health status indicates imminent failure.**
Usage**: a usage Attribute has failed.**
SelfTest**: the number of self-test failures has increased.**
ErrorCount**: the number of errors in the ATA error log has increased.**
CurrentPendingSector**: one of more disk sectors could not be** read and are marked to be reallocated (replaced with spare sectors).
OfflineUncorrectableSector**: during off-line testing, or self-testing,** one or more disk sectors could not be read.
Temperature**: Temperature reached critical limit (see -W directive).**
FailedHealthCheck**: the SMART health status command failed.**
FailedReadSmartData**: the command to read SMART Attribute data failed.**
FailedReadSmartErrorLog**: the command to read the SMART error log failed.**
FailedReadSmartSelfTestLog**: the command to read the SMART self-test log** failed.
FailedOpenDevice**: the open() command to the device failed.**

SMARTD_ADDRESS
is determined by the address argument ADD of the -m Directive. If ADD is <nomailer>, then SMARTD_ADDRESS is not set. Otherwise, it is set to the comma-separated-list of email addresses given by the argument ADD, with the commas replaced by spaces (example:[email protected] root). If more than one email address is given, then this string will contain space characters and is NOT quoted, so to use it in a shell script you may want to enclose it in double quotes.

SMARTD_ADDRESS_ORIG
is set to the original value of SMARTD_ADDRESS with @plugin strings still present. If there are no such strings in the -m Directive, this variable is NOT set.

SMARTD_MESSAGE
is set to the one sentence summary warning email message string from smartd. This message string contains space characters and is NOT quoted. So to use $SMARTD_MESSAGE in a shell script you should probably enclose it in double quotes.

SMARTD_FULLMESSAGE
is set to the contents of the entire email warning message string from smartd. This message string contains space and return characters and is NOT quoted. So to use $SMARTD_FULLMESSAGE in a shell script you should probably enclose it in double quotes.

SMARTD_TFIRST
is a text string giving the time and date at which the first problem of this type was reported. This text string contains space characters and no newlines, and is NOT quoted. For example:
Sun Feb 9 14:58:19 2003 CST

SMARTD_TFIRSTEPOCH
is an integer, which is the unix epoch (number of seconds since Jan 1, 1970) for SMARTD_TFIRST.

SMARTD_PREVCNT
is an integer specifying the number of previous messages sent. It is set to 0 for the first message.

SMARTD_NEXTDAYS
is an integer specifying the number of days until the next message will be sent. It is set to empty on -M once, set to 0 on -M always and set to 1 on -M daily.

If the -m ADD Directive is given with a normal address argument, then the executable pointed to by PATH will be run in a shell with STDIN receiving the body of the email message, and with the same command-line arguments: -s “$SMARTD_SUBJECT” $SMARTD_ADDRESS that would normally be provided to mail. Examples include:
-m user@home -M exec /usr/bin/mail
-m admin@work -M exec /usr/local/bin/mailto
-m root -M exec /Example_1/shell/script/below If the -m ADD Directive is given with the special address argument <nomailer> then the executable pointed to by PATH is run in a shell with no STDIN and no command-line arguments, for example: -m <nomailer> -M exec /Example_2/shell/script/below If the executable produces any STDERR/STDOUT output, then smartd assumes that something is going wrong, and a snippet of that output will be copied to SYSLOG. The remainder of the output is then discarded. Some EXAMPLES of scripts that can be used with the -M exec Directive are given below. Some sample scripts are also included in /usr/share/doc/smartmontools/examples//. The executable is run by the script /usr/share/smartmontools/smartd_warning.sh. This script formats subject and full message based on SMARTD_MESSAGE and other environment variables set by smartd. The environment variables SMARTD_SUBJECT and SMARTD_FULLMESSAGE are set by the script before running the executable.

-f
[ATA only] Check for failure of any Usage Attributes. If these Attributes are less than or equal to the threshold, it does NOT indicate imminent disk failure. It “indicates an advisory condition where the usage or age of the device has exceeded its intended design life period.” [Please see the smartctl -A command-line option.]

-p
[ATA only] Report anytime that a Prefail Attribute has changed its value since the last check. [Please see the smartctl -A command-line option.]

-u
[ATA only] Report anytime that a Usage Attribute has changed its value since the last check. [Please see the smartctl -A command-line option.]

-t
[ATA only] Equivalent to turning on the two previous flags -p and -u. Tracks changes in all device Attributes (both Prefailure and Usage). [Please see the smartctl -A command-line option.]

-i ID
[ATA only] Ignore device Attribute number ID when checking for failure of Usage Attributes. ID must be a decimal integer in the range from 1 to 255. This Directive modifies the behavior of the -f Directive and has no effect without it. This is useful, for example, if you have a very old disk and don’t want to keep getting messages about the hours-on-lifetime Attribute (usually Attribute 9) failing. This Directive may appear multiple times for a single device, if you want to ignore multiple Attributes.

-I ID
[ATA only] Ignore device Attribute ID when tracking changes in the Attribute values. ID must be a decimal integer in the range from 1 to 255. This Directive modifies the behavior of the -p, -u, and -t tracking Directives and has no effect without one of them. This is useful, for example, if one of the device Attributes is the disk temperature (usually Attribute 194 or 231). It’s annoying to get reports each time the temperature changes. This Directive may appear multiple times for a single device, if you want to ignore multiple Attributes.

-r ID[!]
[ATA only] When tracking, report the Raw value of Attribute ID along with its (normally reported) Normalized value. ID must be a decimal integer in the range from 1 to 255. This Directive modifies the behavior of the -p, -u, and -t tracking Directives and has no effect without one of them. This Directive may be given multiple times. A common use of this Directive is to track the device Temperature (often ID=194 or 231). If the optional flag ! is appended, a change of the Normalized value is considered critical. The report will be logged as LOG_CRIT and a warning email will be sent if -m is specified.

-R ID[!]
[ATA only] When tracking, report whenever the Raw value of Attribute ID changes. (Normally smartd only tracks/reports changes of the Normalized Attribute values.) ID must be a decimal integer in the range from 1 to 255. This Directive modifies the behavior of the -p, -u, and -t tracking Directives and has no effect without one of them. This Directive may be given multiple times. If this Directive is given, it automatically implies the -r Directive for the same Attribute, so that the Raw value of the Attribute is reported. A common use of this Directive is to track the device Temperature (often ID=194 or 231). It is also useful for understanding how different types of system behavior affects the values of certain Attributes. If the optional flag ! is appended, a change of the Raw value is considered critical. The report will be logged as LOG_CRIT and a warning email will be sent if -m is specified. An example is -R 5! to warn when new sectors are reallocated.

-C ID[+]
[ATA only] Report if the current number of pending sectors is non-zero. Here ID is the id number of the Attribute whose raw value is the Current Pending Sector count. The allowed range of ID is 0 to 255 inclusive. To turn off this reporting, use ID = 0. If the -C ID option is not given, then it defaults to -C 197 (since Attribute 197 is generally used to monitor pending sectors). If the name of this Attribute is changed by a -v 197,FORMAT,NAME directive, the default is changed to -C 0. If + is specified, a report is only printed if the number of sectors has increased between two check cycles. Some disks do not reset this attribute when a bad sector is reallocated. See also -v 197,increasing below. The warning email counter is reset if the number of pending sectors dropped to 0. This typically happens when all pending sectors have been reallocated or could be read again. A pending sector is a disk sector (containing 512 bytes of your data) which the device would like to mark as “bad” and reallocate. Typically this is because your computer tried to read that sector, and the read failed because the data on it has been corrupted and has inconsistent Error Checking and Correction (ECC) codes. This is important to know, because it means that there is some unreadable data on the disk. The problem of figuring out what file this data belongs to is operating system and file system specific. You can typically force the sector to reallocate by writing to it (translation: make the device substitute a spare good sector for the bad one) but at the price of losing the 512 bytes of data stored there.

-U ID[+]
[ATA only] Report if the number of offline uncorrectable sectors is non-zero. Here ID is the id number of the Attribute whose raw value is the Offline Uncorrectable Sector count. The allowed range of ID is 0 to 255 inclusive. To turn off this reporting, use ID = 0. If the -U ID option is not given, then it defaults to -U 198 (since Attribute 198 is generally used to monitor offline uncorrectable sectors). If the name of this Attribute is changed by a -v 198,FORMAT,NAME (except -v 198,FORMAT,Offline_Scan_UNC_SectCt), directive, the default is changed to -U 0. If + is specified, a report is only printed if the number of sectors has increased since the last check cycle. Some disks do not reset this attribute when a bad sector is reallocated. See also -v 198,increasing below. The warning email counter is reset if the number of offline uncorrectable sectors dropped to 0. This typically happens when all offline uncorrectable sectors have been reallocated or could be read again. An offline uncorrectable sector is a disk sector which was not readable during an off-line scan or a self-test. This is important to know, because if you have data stored in this disk sector, and you need to read it, the read will fail. Please see the previous -C option for more details.

-W DIFF[,INFO[,CRIT]]
Report if the current temperature had changed by at least DIFF degrees since last report, or if new min or max temperature is detected. Report or Warn if the temperature is greater or equal than one of INFO or CRIT degrees Celsius. If the limit CRIT is reached, a message with loglevel LOG_CRIT will be logged to syslog and a warning email will be send if -m is specified. If only the limit INFO is reached, a message with loglevel LOG_INFO will be logged. The warning email counter is reset if the temperature dropped below INFO or CRIT-5 if INFO is not specified. If this directive is used in conjunction with state persistence (-s option), the min and max temperature values are preserved across boot cycles. The minimum temperature value is not updated during the first 30 minutes after startup. To disable any of the 3 reports, set the corresponding limit to 0. Trailing zero arguments may be omitted. By default, all temperature reports are disabled (-W 0). To track temperature changes of at least 2 degrees, use:
-W 2
To log informal messages on temperatures of at least 40 degrees, use:
-W 0,40
For warning messages/mails on temperatures of at least 45 degrees, use:
-W 0,0,45
To combine all of the above reports, use:
-W 2,40,45 For ATA devices, smartd interprets Attribute 194 or 190 as Temperature Celsius by default. This can be changed to Attribute 9 or 220 by the drive database or by the -v 9,temp or -v 220,temp directive. For NVMe devices, smartd checks the maximum of the Composite Temperature value and all Temperature Sensor values reported by SMART/Health Information log.

-F TYPE
[ATA only] Modifies the behavior of smartd to compensate for some known and understood device firmware bug. This directive may be used multiple times. The valid arguments are: none - Assume that the device firmware obeys the ATA specifications. This is the default, unless the device has presets for -F in the drive database. Using this directive will override any preset values. nologdir - Suppresses read attempts of SMART or GP Log Directory. Support for all standard logs is assumed without an actual check. Some Intel SSDs may freeze if log address 0 is read. samsung - In some Samsung disks (example: model SV4012H Firmware Version: RM100-08) some of the two- and four-byte quantities in the SMART data structures are byte-swapped (relative to the ATA specification). Enabling this option tells smartd to evaluate these quantities in byte-reversed order. Some signs that your disk needs this option are (1) no self-test log printed, even though you have run self-tests; (2) very large numbers of ATA errors reported in the ATA error log; (3) strange and impossible values for the ATA error log timestamps. samsung2 - In some Samsung disks the number of ATA errors reported is byte swapped. Enabling this option tells smartd to evaluate this quantity in byte-reversed order. samsung3 - Some Samsung disks (at least SP2514N with Firmware VF100-37) report a self-test still in progress with 0% remaining when the test was already completed. If this directive is specified, smartd will not skip the next scheduled self-test (see Directive -s above) in this case. xerrorlba - This only affects smartctl. [Please see the smartctl -F command-line option.]

-v ID,FORMAT[:BYTEORDER][,NAME]
[ATA only] Sets a vendor-specific raw value print FORMAT, an optional BYTEORDER and an optional NAME for Attribute ID. This directive may be used multiple times. Please see smartctl -v command-line option for further details. The following arguments affect smartd warning output: 197,increasing - Raw Attribute number 197 (Current Pending Sector Count) is not reset if uncorrectable sectors are reallocated. This sets -C 197+ if no other -C directive is specified. 198,increasing - Raw Attribute number 198 (Offline Uncorrectable Sector Count) is not reset if uncorrectable sectors are reallocated. This sets -U 198+ if no other -U directive is specified.

-P TYPE
[ATA only] Specifies whether smartd should use any preset options that are available for this drive. The valid arguments to this Directive are: use - use any presets that are available for this drive. This is the default. ignore - do not use any presets for this drive. show - show the presets listed for this drive in the database. showall - show the presets that are available for all drives and then exit. [Please see the smartctl -P command-line option.]

-a
Equivalent to turning on all of the following Directives: -H to check the SMART health status, -f to report failures of Usage (rather than Prefail) Attributes, -t to track changes in both Prefailure and Usage Attributes, -l error to report increases in the number of ATA errors, -l selftest to report increases in the number of Self-Test Log errors, -l selfteststs to report changes of Self-Test execution status, -C 197 to report nonzero values of the current pending sector count, and -U 198 to report nonzero values of the offline pending sector count. Note that -a is the default for ATA devices. If none of these other Directives is given, then -a is assumed.

-c OPTION=VALUE
Allows one to override smartd command line options for specific devices. Only the following OPTION is currently supported:

-c i=N, -c interval=N
[NEW EXPERIMENTAL SMARTD 7.3 FEATURE] Sets the interval between disk checks to N seconds, where N is a decimal integer. The minimum allowed value is ten. The default is the value from the -i N, –interval=N command line option or its default of 1800 seconds.

#
Comment: ignore the remainder of the line.

**
Continuation character: if this is the last non-white or non-comment character on a line, then the following line is a continuation of the current one.

If you are not sure which Directives to use, I suggest experimenting for a few minutes with smartctl to see what SMART functionality your disk(s) support(s). If you do not like voluminous syslog messages, a good choice of smartd configuration file Directives might be:
-H -l selftest -l error -f.
If you want more frequent information, use: -a.

EXAMPLES OF SHELL SCRIPTS FOR -M exec
These are two examples of shell scripts that can be used with the -M exec PATH Directive described previously. The paths to these scripts and similar executables is the PATH argument to the -M exec PATH Directive. Example 1: This script is for use with -m ADDRESS -M exec PATH. It appends the output of smartctl -a to the output of the smartd email warning message and sends it to ADDRESS. #! /bin/sh

# Save the email message (STDIN) to a file: cat > /root/msg

# Append the output of smartctl -a to the message: /usr/sbin/smartctl -a -d $SMART_DEVICETYPE \ $SMARTD_DEVICE >> /root/msg

# Now email the message to the user at address ADD: /usr/bin/mail -s “$SMARTD_SUBJECT” $SMARTD_ADDRESS \ < /root/msg Example 2: This script is for use with -m <nomailer> -M exec PATH. It warns all users about a disk problem, waits 30 seconds, and then powers down the machine. #! /bin/sh

# Warn all users of a problem wall <<EOF Problem detected with disk: $SMARTD_DEVICESTRING Warning message from smartd is: $SMARTD_MESSAGE Shutting down machine in 30 seconds… EOF

# Wait half a minute sleep 30

# Power down the machine /sbin/shutdown -hf now Some example scripts are distributed with the smartmontools package, in /usr/share/doc/smartmontools/examples/. Please note that these scripts typically run as root, so any files that they read/write should not be writable by ordinary users or reside in directories like /tmp that are writable by ordinary users and may expose your system to symlink attacks. As previously described, if the scripts write to STDOUT or STDERR, this is interpreted as indicating that there was an internal error within the script, and a snippet of STDOUT/STDERR is logged to SYSLOG. The remainder is flushed.

FILES

/etc/smartd.conf
full path of this file.

PACKAGE VERSION

smartmontools-7.4 2023-08-01 r5530
$Id: smartd.conf.5.in 5521 2023-07-24 16:44:49Z chrfranke $

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

28 - Linux cli command smbpasswd

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command smbpasswd and provides detailed information about the command smbpasswd, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the smbpasswd.

NAME 🖥️ smbpasswd 🖥️

The Samba encrypted password file

SYNOPSIS

smbpasswd

DESCRIPTION

This tool is part of the samba(7) suite.

smbpasswd is the Samba encrypted password file. It contains the username, Unix user id and the SMB hashed passwords of the user, as well as account flag information and the time the password was last changed. This file format has been evolving with Samba and has had several different formats in the past.

FILE FORMAT

The format of the smbpasswd file used by Samba 2.2 is very similar to the familiar Unix passwd(5) file. It is an ASCII file containing one line for each user. Each field within each line is separated from the next by a colon. Any entry beginning with # is ignored. The smbpasswd file contains the following information for each user:

name

This is the user name. It must be a name that already exists in the standard UNIX passwd file.

uid

This is the UNIX uid. It must match the uid field for the same user entry in the standard UNIX passwd file. If this does not match then Samba will refuse to recognize this smbpasswd file entry as being valid for a user.

Lanman Password Hash

This is the LANMAN hash of the users password, encoded as 32 hex digits. The LANMAN hash is created by DES encrypting a well known string with the users password as the DES key. This is the same password used by Windows 95/98 machines. Note that this password hash is regarded as weak as it is vulnerable to dictionary attacks and if two users choose the same password this entry will be identical (i.e. the password is not “salted” as the UNIX password is). If the user has a null password this field will contain the characters “NO PASSWORD” as the start of the hex string. If the hex string is equal to 32 X characters then the users account is marked as disabled and the user will not be able to log onto the Samba server.
WARNING !! Note that, due to the challenge-response nature of the SMB/CIFS authentication protocol, anyone with a knowledge of this password hash will be able to impersonate the user on the network. For this reason these hashes are known as plain text equivalents and must NOT be made available to anyone but the root user. To protect these passwords the smbpasswd file is placed in a directory with read and traverse access only to the root user and the smbpasswd file itself must be set to be read/write only by root, with no other access.

NT Password Hash

This is the Windows NT hash of the users password, encoded as 32 hex digits. The Windows NT hash is created by taking the users password as represented in 16-bit, little-endian UNICODE and then applying the MD4 (internet rfc1321) hashing algorithm to it.
This password hash is considered more secure than the LANMAN Password Hash as it preserves the case of the password and uses a much higher quality hashing algorithm. However, it is still the case that if two users choose the same password this entry will be identical (i.e. the password is not “salted” as the UNIX password is).
WARNING !!. Note that, due to the challenge-response nature of the SMB/CIFS authentication protocol, anyone with a knowledge of this password hash will be able to impersonate the user on the network. For this reason these hashes are known as plain text equivalents and must NOT be made available to anyone but the root user. To protect these passwords the smbpasswd file is placed in a directory with read and traverse access only to the root user and the smbpasswd file itself must be set to be read/write only by root, with no other access.

Account Flags

This section contains flags that describe the attributes of the users account. This field is bracketed by [ and ] characters and is always 13 characters in length (including the [ and ] characters). The contents of this field may be any of the following characters:
·
U - This means this is a “User” account, i.e. an ordinary user.
·
N - This means the account has no password (the passwords in the fields LANMAN Password Hash and NT Password Hash are ignored). Note that this will only allow users to log on with no password if the null passwords parameter is set in the smb.conf(5) config file.
·
D - This means the account is disabled and no SMB/CIFS logins will be allowed for this user.
·
X - This means the password does not expire.
·
W - This means this account is a “Workstation Trust” account. This kind of account is used in the Samba PDC code stream to allow Windows NT Workstations and Servers to join a Domain hosted by a Samba PDC.
Other flags may be added as the code is extended in future. The rest of this field space is filled in with spaces. For further information regarding the flags that are supported please refer to the man page for the pdbedit command.

Last Change Time

This field consists of the time the account was last modified. It consists of the characters LCT- (standing for “Last Change Time”) followed by a numeric encoding of the UNIX time in seconds since the epoch (1970) that the last change was made.

All other colon separated fields are ignored at this time.

VERSION

This man page is part of version 4.20.1-Debian of the Samba suite.

AUTHOR

The original Samba software and related utilities were created by Andrew Tridgell. Samba is now developed by the Samba Team as an Open Source project similar to the way the Linux kernel is developed.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

29 - Linux cli command avahi-daemon.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command avahi-daemon.conf and provides detailed information about the command avahi-daemon.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the avahi-daemon.conf.

NAME 🖥️ avahi-daemon.conf 🖥️

daemon.conf - avahi-daemon configuration file

SYNOPSIS

/etc/avahi/avahi-daemon.conf

DESCRIPTION

avahi-daemon.conf is the configuration file for avahi-daemon.

SECTION [SERVER]

host-name= Set the host name avahi-daemon tries to register on the LAN. If omited defaults to the system host name as set with the sethostname() system call.
host-name-from-machine-id= Takes a boolean value (“yes” or “no”). If set to “yes” avahi-daemon will use the machine-id as name on the LAN.
domain-name= Set the default domain name avahi-daemon tries to register its host name and services on the LAN in. If omitted defaults to “.local”.
browse-domains= Set a comma separated list of browsing domains (in addition to the default one and those announced inside the default browsing domain). Please note that the user may specify additional browsing domains on the client side, either by setting $AVAHI_BROWSE_DOMAINS to a list of colon separated domains or by adding them to the XDG config file ~/.config/avahi/browse-domains (separated by newlines).
use-ipv4= Takes a boolean value (“yes” or “no”). If set to “no” avahi-daemon will not use IPv4 sockets. Default is “yes”.
use-ipv6= Takes a boolean value (“yes” or “no”). If set to “no” avahi-daemon will not use IPv6 sockets. Default is “yes”.
allow-interfaces= Set a comma separated list of allowed network interfaces that should be used by the avahi-daemon. Traffic on other interfaces will be ignored. If set to an empty list all local interfaces except loopback and point-to-point will be used.
deny-interfaces= Set a comma separated list of network interfaces that should be ignored by avahi-daemon. Other not specified interfaces will be used, unless allow-interfaces= is set. This option takes precedence over allow-interfaces=.
check-response-ttl= Takes a boolean value (“yes” or “no”). If set to “yes”, an additional security check is activated: incoming IP packets will be ignored unless the IP TTL is 255. Earlier mDNS specifications required this check. Since this feature may be incompatible with newer implementations of mDNS it defaults to “no”. On the other hand it provides extra security.
use-iff-running= Takes a boolean value (“yes” or “no”). If set to “yes” avahi-daemon monitors the IFF_RUNNING flag bit which is used by some (modern) network drivers to tell user space if a network cable is plugged in (in case of copper ethernet), or the network card is associated with some kind of network (in case of WLAN). If IFF_RUNNING is set avahi-daemon will automatically announce its services on that network. Unfortunately far too many network drivers do not support this flag or support it in a broken way. Therefore this option defaults to “no”.
enable-dbus= Takes either “yes”, “no” or “warn”. If set to “yes” avahi-daemon connects to D-Bus, offering an object oriented client API. It is only available if Avahi has been compiled with –enable-dbus in which case it defaults to “yes”. “warn” behaves like “yes”, but the daemon starts up even when it fails to connect to a D-Bus daemon. In addition, if the connection to the D-Bus daemon is terminated we try to reconnect. (Unless we are in a chroot() environment where this definitely will fail.)
disallow-other-stacks= Takes a boolean value (“yes” or “no”). If set to “yes” no other process is allowed to bind to UDP port 5353. This effectively impedes other mDNS stacks from running on the host. Use this as a security measure to make sure that only Avahi is responsible for mDNS traffic. Please note that we do not recommend running multiple mDNS stacks on the same host simultaneously. This hampers reliability and is a waste of resources. However, to not annoy people this option defaults to “no”.
allow-point-to-point= Takes a boolean value (“yes” or “no”). If set to “yes” avahi-daemon will make use of interfaces with the POINTOPOINT flag set. This option defaults to “no” as it might make mDNS unreliable due to usually large latencies with such links and opens a potential security hole by allowing mDNS access from Internet connections. Use with care and YMMV!
cache-entries-max= Takes an unsigned integer specifying how many resource records are cached per interface. Bigger values allow mDNS work correctly in large LANs but also increase memory consumption.
clients-max= Takes an unsigned integer. The maximum number of concurrent D-Bus clients allowed. If the maximum number is reached further clients will be refused until at least one existing client disconnects.
objects-per-client-max= Takes an unsigned integer. The maximum number of objects (entry groups, browsers, resolvers) that may be registered per D-Bus client at a time. If the maximum number is reached further object creation will be refused until at least one object is freed.
entries-per-entry-group-max= Takes an unsigned integer. The maximum number of entries (resource records) per entry group registered by a D-Bus client at a time. If the maximum number is reached further resource records may not be added to an entry group.
ratelimit-interval-usec= Takes an unsigned integer. Sets the per-interface packet rate-limiting interval parameter. Together with ratelimit-burst= this may be used to control the maximum number of packets Avahi will generated in a specific period of time on an interface.
ratelimit-burst= Takes an unsigned integer. Sets the per-interface packet rate-limiting burst parameter. Together with ratelimit-interval-usec= this may be used to control the maximum number of packets Avahi will generated in a specific period of time on an interface.

SECTION [WIDE-AREA]

enable-wide-area= Takes a boolean value (“yes” or “no”). Enable wide-area DNS-SD, aka DNS-SD over unicast DNS. If this is enabled only domains ending in .local will be resolved on mDNS, all other domains are resolved via unicast DNS. If you want to maintain multiple different multicast DNS domains even with this option enabled we encourage you to use subdomains of .local, such as “kitchen.local”. This option defaults to “yes”.

SECTION [PUBLISH]

disable-publishing= Takes a boolean value (“yes” or “no”). If set to “yes”, no record will be published by Avahi, not even address records for the local host. Avahi will be started in a querying-only mode. Use this is a security measure. This option defaults to “no”
disable-user-service-publishing= Takes a boolean value (“yes” or “no”). If set to “yes”, Avahi will still publish address records and suchlike but will not allow user applications to publish services. Use this is a security measure. This option defaults to “no”
add-service-cookie= Takes a boolean value (“yes” or “no”). If set to “yes” an implicit TXT entry will be added to all locally registered services, containing a cookie value which is chosen randomly on daemon startup. This can be used to detect if two services on two different interfaces/protocols are actually identical. Defaults to “no”.
publish-addresses= Takes a boolean value (“yes” or “no”). If set to “yes” avahi-daemon will register mDNS address records for all local IP addresses. Unless you want to use avahi-daemon exclusively for browsing it’s recommended to enable this. If you plan to register local services you need to enable this option. Defaults to “yes”.
publish-hinfo= Takes a boolean value (“yes” or “no”). If set to “yes” avahi-daemon will register an mDNS HINFO record on all interfaces which contains information about the local operating system and CPU, which might be useful for administrative purposes. This is recommended by the mDNS specification but not required. For the sake of privacy you might choose to disable this feature. Defaults to “no”.
publish-workstation= Takes a boolean value (“yes” or “no”). If set to “yes” avahi-daemon will register a service of type “_workstation._tcp” on the local LAN. This might be useful for administrative purposes (i.e. browse for all PCs on the LAN), but is not required or recommended by any specification. Newer MacOS X releases register a service of this type. Defaults to “no”.
publish-domain= Takes a boolean value (“yes” or “no”). If set to “yes” avahi-daemon will announce the locally used domain name (see above) for browsing by other hosts. Defaults to “yes”.
publish-dns-servers= Takes a comma separated list of IP addresses for unicast DNS servers. You can use this to announce unicast DNS servers via mDNS. When used in conjunction with avahi-dnsconfd on the client side this allows DHCP-like configuration of unicast DNS servers.
publish-resolv-conf-dns-servers= Takes a boolean value (“yes” or “no”). If set to “yes” avahi-daemon will publish the unicast DNS servers specified in /etc/resolv.conf in addition to those specified with publish-dns-servers. Send avahi-daemon a SIGHUP to have it reload this file. Defaults to “no”.
publish-aaaa-on-ipv4= Takes a boolean value (“yes” or “no”). If set to “yes” avahi-daemon will publish an IPv6 AAAA record via IPv4, i.e. the local IPv6 addresses can be resolved using an IPv4 transport. Only useful when IPv4 is enabled with use-ipv4=true. Defaults to “yes”.
publish-a-on-ipv6= Takes a boolean value (“yes” or “no”). If set to “yes” avahi-daemon will publish an IPv4 A record via IPv6, i.e. the local IPv4 addresses can be resolved using an IPv6 transport. Only useful when IPv6 is enabled with use-ipv6=true. Defaults to “no”.

SECTION [REFLECTOR]

enable-reflector= Takes a boolean value (“yes” or “no”). If set to “yes” avahi-daemon will reflect incoming mDNS requests to all local network interfaces, effectively allowing clients to browse mDNS/DNS-SD services on all networks connected to the gateway. The gateway is somewhat intelligent and should work with all kinds of mDNS traffic, though some functionality is lost (specifically the unicast reply bit, which is used rarely anyway). Make sure to not run multiple reflectors between the same networks, this might cause them to play Ping Pong with mDNS packets. Defaults to “no”.
reflect-ipv= Takes a boolean value (“yes” or “no”). If set to “yes” and enable-reflector is enabled, avahi-daemon will forward mDNS traffic between IPv4 and IPv6, which is usually not recommended. Defaults to “no”.
reflect-filters= Set a comma separated list of allowed service names to be reflected. Each service that is seen must match an entry in this list to be reflected to other networks. This list can match the type of service or the name of the machine providing the service. Defaults to allowing all services.

SECTION [RLIMITS]

This section is used to define system resource limits for the daemon. See setrlimit(2) for more information. If any of the options is not specified in the configuration file, avahi-daemon does not change it from the system defaults.

rlimit-as= Value in bytes for RLIMIT_AS (maximum size of the process’s virtual memory). Sensible values are heavily system dependent.
rlimit-core= Value in bytes for RLIMIT_CORE (maximum core file size). Unless you want to debug avahi-daemon, it is safe to set this to 0.
rlimit-data= Value in bytes for RLIMIT_DATA (maximum size of the process’s data segment). Sensible values are heavily system dependent.
rlimit-fsize= Value for RLIMIT_FSIZE (maximum size of files the process may create). Since avahi-daemon shouldn’t write any files to disk, it is safe to set this to 0.
rlimit-nofile= Value for RLIMIT_NOFILE (open file descriptors). avahi-daemon shouldn’t need more than 15 to 20 open file descriptors concurrently.
rlimit-stack= Value in bytes for RLIMIT_STACK (maximum size of the process stack). Sensible values are heavily system dependent.
rlimit-nproc= Value for RLIMIT_NPROC (max number of processes a user can launch). avahi-daemon forks of a helper process on systems where chroot(2) is available therefore this value should not be set below 2. Note that while the process limit only applies to this process, the total count of processes to reach that limit includes all processes on the system with the same UID, including any containers without UID remapping (such as lxd containers with security.privileged=true). The default configuration of 3 was removed to prevent problems in this scenario.

AUTHORS

The Avahi Developers <avahi (at) lists (dot) freedesktop (dot) org>; Avahi is available from http://avahi.org/

COMMENTS

This man page was written using xml2man(1) by Oliver Kurth.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

30 - Linux cli command libaudit.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command libaudit.conf and provides detailed information about the command libaudit.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the libaudit.conf.

NAME 🖥️ libaudit.conf 🖥️

libaudit configuration file

DESCRIPTION

The file /etc/libaudit.conf contains configuration information for user space applications that link to libaudit. The applications are responsible for querying the settings in this file and obeying the admin’s preferences. This file contains one configuration keyword per line, an equal sign, and then followed by appropriate configuration information. The keywords recognized are: failure_action". These keywords are described below.

failure_action
This keyword specifies what action the admin wishes a user space application to take when there is a failure to send an audit event to the kernel. The possible values are: IGNORE - meaning do nothing, LOG - write to syslog the inability to send an audit event, and TERMINATE - the user space application should exit.

AUTHOR

Steve Grubb

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

31 - Linux cli command systemd.device

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.device and provides detailed information about the command systemd.device, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.device.

NAME 🖥️ systemd.device 🖥️

Device unit configuration

SYNOPSIS

device.device

DESCRIPTION

A unit configuration file whose name ends in “.device” encodes information about a device unit as exposed in the sysfs/udev(7) device tree. This may be used to define dependencies between devices and other units.

This unit type has no specific options. See systemd.unit(5) for the common options of all unit configuration files. The common configuration items are configured in the generic [Unit] and [Install] sections. A separate [Device] section does not exist, since no device-specific options may be configured.

systemd will dynamically create device units for all kernel devices that are marked with the “systemd” udev tag (by default all block and network devices, and a few others). Note that if systemd-udevd.service is not running, no device units will be available (for example in a typical container).

Device units are named after the /sys/ and /dev/ paths they control. Example: the device /dev/sda5 is exposed in systemd as dev-sda5.device. For details about the escaping logic used to convert a file system path to a unit name see systemd.unit(5).

To tag a udev device, use “TAG+=“systemd”” in the udev rules file, see udev(7) for details.

Device units will be reloaded by systemd whenever the corresponding device generates a “changed” event. Other units can use ReloadPropagatedFrom= to react to that event.

AUTOMATIC DEPENDENCIES

Implicit Dependencies

Many unit types automatically acquire dependencies on device units of devices they require. For example, .socket unit acquire dependencies on the device units of the network interface specified in BindToDevice=. Similar, swap and mount units acquire dependencies on the units encapsulating their backing block devices.

Default Dependencies

There are no default dependencies for device units.

THE UDEV DATABASE

Unit settings of device units may either be configured via unit files, or directly from the udev database. The following udev device properties are understood by the service manager:

SYSTEMD_WANTS=, SYSTEMD_USER_WANTS=

Adds dependencies of type Wants= from the device unit to the specified units. SYSTEMD_WANTS= is read by the system service manager, SYSTEMD_USER_WANTS= by user service manager instances. These properties may be used to activate arbitrary units when a specific device becomes available.
Note that this and the other udev device properties are not taken into account unless the device is tagged with the “systemd” tag in the udev database, because otherwise the device is not exposed as a systemd unit (see above).
Note that systemd will only act on Wants= dependencies when a device first becomes active. It will not act on them if they are added to devices that are already active. Use SYSTEMD_READY= (see below) to configure when a udev device shall be considered active, and thus when to trigger the dependencies.
The specified property value should be a space-separated list of valid unit names. If a unit template name is specified (that is, a unit name containing an “@” character indicating a unit name to use for multiple instantiation, but with an empty instance name following the “@”), it will be automatically instantiated by the devices “sysfs” path (that is: the path is escaped and inserted as instance name into the template unit name). This is useful in order to instantiate a specific template unit once for each device that appears and matches specific properties.

SYSTEMD_ALIAS=

Adds an additional alias name to the device unit. This must be an absolute path that is automatically transformed into a unit name. (See above.)

SYSTEMD_READY=

If set to 0, systemd will consider this device unplugged even if it shows up in the udev tree. If this property is unset or set to 1, the device will be considered plugged if it is visible in the udev tree.
This option is useful for devices that initially show up in an uninitialized state in the tree, and for which a “changed” event is generated the moment they are fully set up. Note that SYSTEMD_WANTS= (see above) is not acted on as long as SYSTEMD_READY=0 is set for a device.

ID_MODEL_FROM_DATABASE=, ID_MODEL=

If set, this property is used as description string for the device unit.

OPTIONS

Device unit files may include [Unit] and [Install] sections, which are described in systemd.unit(5). No options specific to this file type are supported.

32 - Linux cli command proc_stat

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_stat and provides detailed information about the command proc_stat, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_stat.

NAME 🖥️ proc_stat 🖥️

kernel system statistics

DESCRIPTION

/proc/stat
kernel/system statistics. Varies with architecture. Common entries include:

cpu 10132153 290696 3084719 46828483 16683 0 25195 0 175628 0
cpu0 1393280 32966 572056 13343292 6130 0 17875 0 23933 0
The amount of time, measured in units of USER_HZ (1/100ths of a second on most architectures, use sysconf(_SC_CLK_TCK) to obtain the right value), that the system (“cpu” line) or the specific CPU (“cpuN” line) spent in various states:

user
(1) Time spent in user mode.

nice
(2) Time spent in user mode with low priority (nice).

system
(3) Time spent in system mode.

idle
(4) Time spent in the idle task. This value should be USER_HZ times the second entry in the /proc/uptime pseudo-file.

iowait (since Linux 2.5.41)
(5) Time waiting for I/O to complete. This value is not reliable, for the following reasons:

The CPU will not wait for I/O to complete; iowait is the time that a task is waiting for I/O to complete. When a CPU goes into idle state for outstanding task I/O, another task will be scheduled on this CPU.
On a multi-core CPU, the task waiting for I/O to complete is not running on any CPU, so the iowait of each CPU is difficult to calculate.
The value in this field may decrease in certain conditions.

irq (since Linux 2.6.0)
(6) Time servicing interrupts.

softirq (since Linux 2.6.0)
(7) Time servicing softirqs.

steal (since Linux 2.6.11)
(8) Stolen time, which is the time spent in other operating systems when running in a virtualized environment

guest (since Linux 2.6.24)
(9) Time spent running a virtual CPU for guest operating systems under the control of the Linux kernel.

guest_nice (since Linux 2.6.33)
(10) Time spent running a niced guest (virtual CPU for guest operating systems under the control of the Linux kernel).

page 5741 1808
The number of pages the system paged in and the number that were paged out (from disk).

swap 1 0
The number of swap pages that have been brought in and out.

intr 1462898
This line shows counts of interrupts serviced since boot time, for each of the possible system interrupts. The first column is the total of all interrupts serviced including unnumbered architecture specific interrupts; each subsequent column is the total for that particular numbered interrupt. Unnumbered interrupts are not shown, only summed into the total.

disk_io: (2,0):(31,30,5764,1,2) (3,0):…
(major,disk_idx):(noinfo, read_io_ops, blks_read, write_io_ops, blks_written)
(Linux 2.4 only)

ctxt 115315
The number of context switches that the system underwent.

btime 769041601
boot time, in seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC).

processes 86031
Number of forks since boot.

procs_running 6
Number of processes in runnable state. (Linux 2.5.45 onward.)

procs_blocked 2
Number of processes blocked waiting for I/O to complete. (Linux 2.5.45 onward.)

softirq 229245889 94 60001584 13619 5175704 2471304 28 51212741 59130143 0 51240672
This line shows the number of softirq for all CPUs. The first column is the total of all softirqs and each subsequent column is the total for particular softirq. (Linux 2.6.31 onward.)

33 - Linux cli command acct

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command acct and provides detailed information about the command acct, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the acct.

NAME 🖥️ acct 🖥️

process accounting file

SYNOPSIS

#include <sys/acct.h>

DESCRIPTION

If the kernel is built with the process accounting option enabled (CONFIG_BSD_PROCESS_ACCT), then calling acct(2) starts process accounting, for example:

acct("/var/log/pacct");

When process accounting is enabled, the kernel writes a record to the accounting file as each process on the system terminates. This record contains information about the terminated process, and is defined in <sys/acct.h> as follows:

#define ACCT_COMM 16
typedef u_int16_t comp_t;
struct acct {
    char ac_flag;           /* Accounting flags */
    u_int16_t ac_uid;       /* Accounting user ID */
    u_int16_t ac_gid;       /* Accounting group ID */
    u_int16_t ac_tty;       /* Controlling terminal */
    u_int32_t ac_btime;     /* Process creation time
                               (seconds since the Epoch) */
    comp_t    ac_utime;     /* User CPU time */
    comp_t    ac_stime;     /* System CPU time */
    comp_t    ac_etime;     /* Elapsed time */
    comp_t    ac_mem;       /* Average memory usage (kB) */
    comp_t    ac_io;        /* Characters transferred (unused) */
    comp_t    ac_rw;        /* Blocks read or written (unused) */
    comp_t    ac_minflt;    /* Minor page faults */
    comp_t    ac_majflt;    /* Major page faults */
    comp_t    ac_swaps;     /* Number of swaps (unused) */
    u_int32_t ac_exitcode;  /* Process termination status
                               (see wait(2)) */
    char      ac_comm[ACCT_COMM+1];
                            /* Command name (basename of last
                               executed command; null-terminated) */
    char      ac_pad[X];    /* padding bytes */
};
enum {          /* Bits that may be set in ac_flag field */
    AFORK = 0x01,           /* Has executed fork, but no exec */
    ASU   = 0x02,           /* Used superuser privileges */
    ACORE = 0x08,           /* Dumped core */
    AXSIG = 0x10            /* Killed by a signal */
};

The comp_t data type is a floating-point value consisting of a 3-bit, base-8 exponent, and a 13-bit mantissa. A value, c, of this type can be converted to a (long) integer as follows:

    v = (c & 0x1fff) << (((c >> 13) & 0x7) * 3);

The ac_utime, ac_stime, and ac_etime fields measure time in “clock ticks”; divide these values by sysconf(_SC_CLK_TCK) to convert them to seconds.

Version 3 accounting file format

Since Linux 2.6.8, an optional alternative version of the accounting file can be produced if the CONFIG_BSD_PROCESS_ACCT_V3 option is set when building the kernel. With this option is set, the records written to the accounting file contain additional fields, and the width of c_uid and ac_gid fields is widened from 16 to 32 bits (in line with the increased size of UID and GIDs in Linux 2.4 and later). The records are defined as follows:

struct acct_v3 {
    char      ac_flag;      /* Flags */
    char      ac_version;   /* Always set to ACCT_VERSION (3) */
    u_int16_t ac_tty;       /* Controlling terminal */
    u_int32_t ac_exitcode;  /* Process termination status */
    u_int32_t ac_uid;       /* Real user ID */
    u_int32_t ac_gid;       /* Real group ID */
    u_int32_t ac_pid;       /* Process ID */
    u_int32_t ac_ppid;      /* Parent process ID */
    u_int32_t ac_btime;     /* Process creation time */
    float     ac_etime;     /* Elapsed time */
    comp_t    ac_utime;     /* User CPU time */
    comp_t    ac_stime;     /* System time */
    comp_t    ac_mem;       /* Average memory usage (kB) */
    comp_t    ac_io;        /* Characters transferred (unused) */
    comp_t    ac_rw;        /* Blocks read or written
                               (unused) */
    comp_t    ac_minflt;    /* Minor page faults */
    comp_t    ac_majflt;    /* Major page faults */
    comp_t    ac_swaps;     /* Number of swaps (unused) */
    char      ac_comm[ACCT_COMM]; /* Command name */
};

VERSIONS

Although it is present on most systems, it is not standardized, and the details vary somewhat between systems.

STANDARDS

None.

HISTORY

glibc 2.6.

Process accounting originated on BSD.

NOTES

Records in the accounting file are ordered by termination time of the process.

Up to and including Linux 2.6.9, a separate accounting record is written for each thread created using the NPTL threading library; since Linux 2.6.10, a single accounting record is written for the entire process on termination of the last thread in the process.

The /proc/sys/kernel/acct file, described in proc(5), defines settings that control the behavior of process accounting when disk space runs low.

34 - Linux cli command securetty

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command securetty and provides detailed information about the command securetty, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the securetty.

NAME 🖥️ securetty 🖥️

list of terminals on which root is allowed to login

DESCRIPTION

The file /etc/securetty contains the names of terminals (one per line, without leading /dev/) which are considered secure for the transmission of certain authentication tokens.

It is used by (some versions of) login(1) to restrict the terminals on which root is allowed to login. See login.defs(5) if you use the shadow suite.

On PAM enabled systems, it is used for the same purpose by pam_securetty(8) to restrict the terminals on which empty passwords are accepted.

FILES

/etc/securetty

35 - Linux cli command org.bluez.obex.Transfer

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.obex.Transfer and provides detailed information about the command org.bluez.obex.Transfer, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.obex.Transfer.

NAME 🖥️ org.bluez.obex.Transfer 🖥️

BlueZ D-Bus OBEX Transfer API documentation

INTERFACE

Service
org.bluez.obex
Interface
org.bluez.obex.Transfer1
Object path
[Session object path]/transfer{#}

Methods

void Cancel()

Cancels the current transference.
Possible errors:
org.bluez.obex.Error.NotAuthorized
org.bluez.obex.Error.InProgress
org.bluez.obex.Error.Failed

void Suspend()

Suspends transference.
Possible errors:
org.bluez.obex.Error.NotAuthorized
org.bluez.obex.Error.NotInProgress
If transfer is still in with Status “queued”.

void Resume()

Resumes transference previously suspended with use of Suspend() method.
Possible errors:
org.bluez.obex.Error.NotAuthorized
org.bluez.obex.Error.NotInProgress
If transfer is still in with Status “queued”.

Properties

string Status [readonly]

Indicates the current status of the transfer.
Possible values:
“queued”
“active”
“suspended”
“complete”
“error”

object Session [readonly]

The object path of the session the transfer belongs to.

string Name [readonly, optional]

Name of the object being transferred.
Either Name or Type or both will be present.

string Type [readonly, optional]

Type of the object transferred being transferred.
Either Name or Type or both will be present.

uint64 Time [readonly, optional]

Time of the object being transferred if this is provided by the remote party.

uint64 Size [readonly, optional]

Size of the object being transferred.
If the size is unknown, then this property will not be present.

uint64 Transferred [readonly, optional]

Number of bytes transferred.
For transfers with Status set to “queued”, this value will not be present.

string Filename [readonly, optional]

Complete name of the file being received or sent.
For incoming object push transaction, this will be the proposed default location and name. It can be overwritten by the AuthorizePush() in org.bluez.obex.Agent(5) and will be then updated accordingly.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

36 - Linux cli command pfm

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command pfm and provides detailed information about the command pfm, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the pfm.

NAME 🖥️ pfm 🖥️

PFM graphic image file format

DESCRIPTION

This document describes the PFM graphic image file format as understood by the Netpbm converters pamtopfm(1) and pfmtopam(1) .

There are multiple similar formats known as PFM in the world, none of them authoritatively documented. The format described here is one that Bryan Henderson deduced from a program he found somewhere that dealt with a “PFM” format. This format appears to be the one Gimp calls PFM.

Another important PFM is used by Adobe Photoshop and appears to be identical to this except that rows are ordered from top to bottom in the Adobe version. If you interchange images between systems that use these two formats, it will work except that your image gets flipped upside down. You can compensate for that with pamflip -topbottom.

The PFM format is inspired by the Netpbm formats, and you will see lots of similarity. It is not, however, an official Netpbm format. Its goal is not consistent with those of Netpbm formats.

The format

A PFM image is a stream of bytes. The stream consists of a header followed immediately by a raster. These two components are described below. There are no delimiters before or after the sections as described.

PFM header

The PFM header is 3 consecutive “lines” of ASCII text. After each line is a white space character. That character is typically a newline character, hence the term “line,” but doesn’t have to be.

pamtopfm uses a newline in the PFM it generates.

Identifier Line

The identifier line contains the characters “PF” or “Pf”. PF means it’s a color PFM. Pf means it’s a grayscale PFM.

Dimensions Line

The dimensions line contains two positive decimal integers, separated by a blank. The first is the width of the image; the second is the height. Both are in pixels.

Scale Factor / Endianness

The Scale Factor / Endianness line is a queer line that jams endianness information into an otherwise sane description of a scale. The line consists of a nonzero decimal number, not necessarily an integer. If the number is negative, that means the PFM raster is little endian. Otherwise, it is big endian. The absolute value of the number is the scale factor for the image.

The scale factor tells the units of the samples in the raster. You use somehow it along with some separately understood unit information to turn a sample value into something meaningful, such as watts per square meter.

PFM raster

The raster is a sequence of pixels, packed one after another, with no delimiters of any kind. They are grouped by row, with the pixels in each row ordered left to right and the rows ordered bottom to top.

Note: This is the opposite of Netpbm formats, which order rows top to bottom. It is also the opposite of the format Adobe Photoshop calls PFM. See the introduction for more information on this disparity.

Each pixel consists of 1 or 3 samples, packed one after another, with no delimiters of any kind. 1 sample for a grayscale PFM and 3 for a color PFM (see the Identifier Line of the PFM header).

Each sample consists of 4 consecutive bytes. The bytes represent a 32 bit string, in either big endian or little endian format, as determined by the Scale Factor / Endianness line of the PFM header. That string is an IEEE 32 bit floating point number code. Since that’s the same format that most CPUs and compiler use, you can usually just make a program use the bytes directly as a floating point number, after taking care of the endianness variation.

DOCUMENT SOURCE

This manual page was generated by the Netpbm tool ‘makeman’ from HTML source. The master documentation is at

http://netpbm.sourceforge.net/doc/pfm.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

37 - Linux cli command ntp.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ntp.conf and provides detailed information about the command ntp.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ntp.conf.

NAME 🖥️ ntp.conf 🖥️

Network Time Protocol (NTP) daemon configuration file format

SYNOPSIS

/etc/ntpsec/ntp.conf

DESCRIPTION

The ntp.conf configuration file is read at initial startup by the ntpd(8) daemon in order to specify the synchronization sources, modes, and other related information. Usually, it is installed in the /etc directory, but could be installed elsewhere (see the daemon’s -c command line option).

The file format is similar to other UNIX configuration files. Comments begin with a ‘#’ character and extend to the end of the line; blank lines are ignored. Configuration commands consist of an initial keyword followed by a list of arguments, some of which may be optional, separated by whitespace. Commands may not be continued over multiple lines. Arguments may be host names, host addresses written in numeric, dotted-quad form, integers, floating point numbers (when specifying times in seconds) and text strings.

Configuration files may have inclusion lines. The syntax is includefile followed by whitespace followed by a file or directory name. The configuration is evaluated as though the text of the file - or all files of the directory with the extension “.conf” - were textually spliced in at the point of the include. Relative paths will work, even when the -c option changes the config directory root.

The rest of this page describes the configuration and control options. The “Notes on Configuring NTP and Setting up an NTP Subnet” page (available as part of the HTML documentation provided under /usr/share/doc/ntp) contains an extended discussion of these options. In addition to the discussion of general Configuration Options, there are sections describing the following supported functionality and the options used to control it:

·
Authentication Support

·
NTS Support

·
Monitoring Support

·
Access Control Support

·
Automatic NTP Configuration Options

·
Reference Clock Support

·
Miscellaneous Options

Following these is a section describing Miscellaneous Options. While there is a rich set of options available, the only required option is one or more pool, server, peer, or broadcast commands.

CONFIGURATION SUPPORT

Following is a description of the configuration commands in NTPv4. There are two classes of commands, association commands that configure a persistent association with a remote server or peer or reference clock, and auxiliary commands that specify environment variables that control various related operations.

Association Commands

Only those options applicable to each command are listed below. Use of options not listed may not be caught as an error, but may result in some weird and even destructive behavior.

In contexts where a host name is expected, a -4 or --ipv4 qualifier preceding the host name forces DNS resolution to the IPv4 namespace, while a -6 or --ipv6 qualifier forces DNS resolution to the IPv6 namespace.

In these commands, an address can be any of (a) an IPV4 address in a.b.c.d format, (b) an IPV6 address in [a:b:c:d:e:f:g:h] format, (c) a link-local IPV6 address with an interface specified in [a:b:c:d:e:f:g:h]%device format, or (d) a DNS hostname.

pool address [burst] [iburst] [version version] [prefer] [minpoll minpoll] [maxpoll maxpoll] [preempt]

server address [key key] [burst] [iburst] [version version] [prefer] [minpoll minpoll] [maxpoll maxpoll]

peer address [key key] [version version] [prefer] [minpoll minpoll] [maxpoll maxpoll]

unpeer [address | associd | clock clocktype [unit unitnum]]

These four commands specify the time server name or address to be used and the mode in which to operate. The address can be either a DNS name or an IP address in dotted-quad notation. If it is a refclock, it can be clock followed by a type-unit pair as in the refclock directive; a missing unit clause is interpreted as unit 0.

pool

For server addresses, this command mobilizes a persistent client mode association with a number of remote servers. In this mode the local clock can synchronized to the remote server, but the remote server can never be synchronized to the local clock.

server

For server addresses, this command mobilizes a persistent client mode association with the specified remote server or local radio clock. In this mode the local clock can synchronized to the remote server, but the remote server can never be synchronized to the local clock.

peer

NTP peer mode has been removed for security reasons. peer is now just an alias for the server keyword. See above.

unpeer

This command removes a previously configured association. An address or association ID can be used to identify the association. Either an IP address or DNS name can be used. This command is most useful when supplied via ntpq runtime configuration commands config and config-from-file.

Association Options

bias

Add the command argument, a floating-point value in seconds, to the time offset (θ) computed for this server; this may be useful if you are a client on a network connection such as an ADSL line where there is a predictable asymmetry between upstream and downstream flight times. One way you might see this is if you use a fixed set of others and one has a stable offset that is an outlier from the others; in that case, you might want to use bias to compensate out the offset.

burst

When the server is reachable, send a burst of eight packets instead of the usual one. The packet spacing is normally 2 s; however, the spacing between the first and second packets can be changed with the calldelay command to allow additional time for a modem or ISDN call to complete; this is designed to improve timekeeping quality with the server command.

iburst

When the server is unreachable, send a burst of six packets instead of the usual one. The packet spacing is normally 2 s; however, the spacing between the first and second packets can be changed with the calldelay command to allow additional time for a modem or ISDN call to complete; this is designed to speed the initial synchronization acquisition with the server command, and when ntpd(8) is started with the -q option.

key key

All packets sent to and received from the server or peer are to include authentication fields encrypted using the specified key identifier with values from 1 to 65535, inclusive. The default is to include no encryption field.

minpoll minpoll, maxpoll maxpoll

These options specify the minimum and maximum poll intervals for NTP messages, as a power of 2 in seconds. The maximum poll interval defaults to 10 (1,024 s), but can be increased by the maxpoll option to an upper limit of 17 (36.4 h). The minimum poll interval defaults to 6 (64 s), but can be decreased by the minpoll option to a lower limit of 0 (1 s).

mode option

Pass the option to a reference clock driver. This option is valid only with refclock addresses.

noselect

Marks the server as unused, except for display purposes. The server is discarded by the selection algorithm.

prefer

Marks the server as preferred. All other things being equal, this host will be chosen for synchronization among a set of correctly operating hosts. See the “Mitigation Rules and the prefer Keyword” page for further information.

true

Mark the association to assume truechimer status; that is, always survive the selection and clustering algorithms. This option can be used with any association but is most useful for reference clocks with large jitter on the serial port and precision pulse-per-second (PPS) signals. Caution: this option defeats the algorithms designed to cast out falsetickers and can allow these sources to set the system clock. This option is valid only with the server command.

version version

Specifies the version number to be used for outgoing NTP packets. Versions 1-4 are the choices, with version 4 the default.

Association Auxiliary Commands

mdnstries number

If we are participating in mDNS, after we have synched for the first time we attempt to register with the mDNS system. If that registration attempt fails, we try again at one minute intervals for up to number times. After all, ntpd may be starting before mDNS. The default value for mdnstries is 5.

Authentication Commands

The following declarations control MAC authentication:

controlkey key

Specifies the key identifier to use with the ntpq(1) utility, which uses the standard protocol defined in RFC 5905. The key argument is the key identifier for a trusted key, where the value can be in the range 1 to 65,535, inclusive.

keys keyfile

Specifies the complete path and location of the key file containing the keys and key identifiers used by ntpd(8), and ntpq(1) when operating with symmetric-key cryptography. This is the same operation as the -k command line option.

trustedkey key…

Specifies the key identifiers which are trusted for the purposes of authenticating servers with symmetric key cryptography, as well as keys used by the ntpq(1) program. Multiple keys on the same line should be separated by spaces. Key ranges can be specified as (first … last). The spaces around the … are necessary. Multiple trustedkey lines are supported and trusted keys can also be specified on the command line.

The MAC authentication procedures require that both the local and remote servers share the same key id, key type, and key text. The easiest way to do this is to copy the whole line. Different keys should be used for each server-client pair. The key_id arguments are integers with values from 1 to 65,535.

NTS Commands

The following command controls NTS authentication. It overrides normal TLS protocol negotiation, which is not usually necessary.

nts [enable|disable] [mintls version] [maxtls version] [tlsciphersuites name] [tlsecdhcurves name]

The options are as follows:

cert file

Present the certificate (chain) in file as our certificate. + Note that there is no checking on the certificate. In particular, it may have expired or may not cover the host name used to get to this server or may not be signed by a CA that is in the clients root-server collection.

key file

Read the private key to our certificate from file.

ca location

Use the file, or directory, specified by location to validate NTS-KE server certificates instead of the system default root certificates. If a directory is specified, it must have files named with their hash, as created by openssl rehash.

cookie location

Use the file (or directory) specified by location to store the keys used to make and decode cookies. The default is /var/lib/ntpsec/nts-keys.

enable

Enable NTS-KE server. When enabled, cert and key are required.

disable

Disable NTS-KE server.

mintls string

Set the lowest allowable TLS version to negotiate. Will be useful in the wake of a TLS compromise. Reasonable values are TLS1.3 if your system supports it. TLS 1.3 was first supported in OpenSSL version 1.1.1.

maxtls string

Set the highest allowable TLS version to negotiate. By setting mintls and maxtls equal, you can force the TLS version for testing. Format is as for mintls.

tlsciphersuites string

An OpenSSL ciphersuite list to configure the allowed ciphersuites for TLS 1.3. A single NULL cipher disables encryption and use of certificates. This sets the ciphers used by both the client and server sides. + The server picks the cipher. The default is client preference. Specifying ciphersuites also switches to server preference.

tlsecdhcurves string

An OpenSSL ecdhcurves list to configure the allowed ecdhcurves for TLS 1.3. A single NULL ecdhcurves disables encryption and use of certificates.

aead string

Specify the crypto algorithm to be used on the wire. The choices come from RFC 5297. The only options supported are AES_SIV_CMAC_256, AES_SIV_CMAC_384, and AES_SIV_CMAC_512. This slot is dual use. It is the server default if the remote client doesn’t request a valid choice and it is also the preference passed to the remote client if the server command doesn’t specify a preference. The default is AES_SIV_CMAC_256.

The following options of the server command configure NTS (as a client).

nts

Use Network Time Security (NTS) for authentication. Normally, this is all you have to do to activate the client side of NTS. + The hostname following the server command is used as the address of the NTS key exchange server (NTS-KE) rather than the address of a NTP server. The NTS-KE exchange defaults to using the same IP address for the NTP server. + Note that the server hostname must match the name on the NTS-KE server’s certificate.

noval

Do not validate the server certificate.

ca location

Use the file, or directory, specified by location to validate the NTS-KE server certificate, overriding the site default. Do not use any other CA. If a directory is specified, it must have files named with their hash, as created by openssl rehash.

aead string

Specify the preferred crypto algorithm to be used on the wire. The only options supported are AES_SIV_CMAC_256, AES_SIV_CMAC_384, and AES_SIV_CMAC_512. The server may ignore the request. See the aead option above. + The same aead algorithms are also used to encrypt cookies. The default is AES_SIV_CMAC_256. There is no config file option to change it, but you can change it by editing the saved cookie key file, probably /var/lib/ntpsec/nts-keys. Adjust the L: slot to be 48 or 64 and adjust the I: slots to have the right number of bytes. Then restart the server. (All old cookies held by clients will be rejected so their next 8 NTP requests will be ignored. They should recover by retrying NTS-KE to get fresh cookies.)

MONITORING SUPPORT

ntpd(8) includes a comprehensive monitoring facility suitable for continuous, long term recording of server and client timekeeping performance. See the statistics command below for a listing and example of each type of statistics currently supported. Statistic files are managed using file generation sets and scripts in the ./scripts directory of this distribution. Using these facilities and UNIX cron(8) jobs, the data can be automatically summarized and archived for retrospective analysis.

Monitoring Commands

statistics name…

Enables writing of statistics records. Currently, ten kinds of name statistics are supported.
clockstats
Enables recording of clock driver statistics information. Each update received from a clock driver appends a line of the following form to the file generation set named clockstats:
49213 525.624 SPECTRACOM(1) 93 226 00:08:29.606
Item Units Description
49213 MJD modified Julian day number
525.624 s time of day (s) past midnight UTC
SPECTRACOM(1) receiver identifier (Spectracom unit 1)
93 226 00:08:29.606 timecode (format varies by refclock)
The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The next normally shows clock type and unit (but if you are running in strict Classic compatibility mode it will show the magic clock address in dotted-quad notation). The final field is the last timecode received from the clock in decoded ASCII format, where meaningful. For some clock drivers, a good deal of additional information can be gathered and displayed as well. See information specific to each clock for further details.
loopstats
Enables recording of loop filter statistics information. Each update of the local clock outputs a line of the following form to the file generation set named loopstats:
50935 75440.031 0.000006019 13.778190 0.000351733 0.0133806
Item Units Description
50935 MJD date
75440.031 s time past midnight
0.000006019 s clock offset
13.778 PPM drift (frequency offset)
0.000351733 s RMS jitter
0.013380 PPM RMS frequency jitter (aka wander)
6 log2 s clock discipline loop time constant
The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The next five fields show time offset (seconds), frequency offset (parts per million - PPM), RMS jitter (seconds), Allan deviation (PPM) and clock discipline time constant.
ntsstats
Enables recording of NTS statistics counters on a periodic basis. Each hour a line of the following form is appended to the file generation set named ntsstats:
60209 77147.187 3600 1320 1239 0 2895 2895 11 4104 0 2897 2885 10 0 0 2 0
Item Units Description
60209 MJD date
77147.187 s time past midnight
3600 s time since reset
1320 packets client requests sent
1239 packets client responses received good
0 packets client responses received bad
2895 packets server responses sent
2895 packets server requests received good
11 packets server requests received bad
4104 packets cookies made
0 packets cookie decodes not server
2897 packets cookie decodes total
2885 packets cookie decodes current
10 packets cookie decodes 1-2 days
0 packets cookie decodes 2-3 days
0 packets cookie decodes 3-10 days
2 packets cookie decodes too old
0 packets cookie decodes error
These counters are also available via ntpqs nts command.
ntskestats
Enables recording of NTS-KE statistics counters on a periodic basis. Each hour a line of the following form is appended to the file generation set named ntskestats:
60209 77147.187 3600 10 2.914 0.026 2 3.218 0.004 0 0.000 0.000 0 0
Item Units Description
60209 MJD date
77147.187 s time past midnight
3600 s time since reset
10 requests server requests good
2.914 seconds server good wall clock time
0.026 seconds server good CPU time
2 requests server requests no-TLS
3.218 seconds server no-TLS wall clock time
0.004 seconds server no-TLS CPU time
0 requests server requests bad
0.000 seconds server bad wall clock time
0.000 seconds server bad CPU time
0 requests client requests good
0 requests client requests bad
These counters are also available via ntpqs nts command.
There are two types of failures for NTS-KE server processing. The no-TLS slots are for the path when the TLS connection doesn’t get setup. The bad slots are for the path when the TLS connection does get setup but there is an error during the NTS-KE exchange.
Both are typically caused by bad guys probing for servers to abuse. A no-TLS event would be caused by a bad guy using unencrypted SMTP while a bad event would be caused by SMTP over TLS.
protostats
Record significant peer and system events. Each significant event appends one line to the protostats file set:
49213 525.624 128.4.1.1 963a 8a message
Item Units Description
49213 MJD date
525.624 s time past midnight
128.4.1.1 IP source address (0.0.0.0 for system)
963a code status word
8a code event message code
message text event message
The event message code and message field are described on the “Event Messages and Status Words” page.
peerstats
Enables recording of peer statistics information. This includes statistics records of all peers of an NTP server and of special signals, where present and configured. Each valid update appends a line of the following form to the current element of a file generation set named peerstats:
48773 10847.650 SPECTRACOM(4) 9714 -0.001605376 0.000000000 0.001424877 0.000958674
Item Units Description
48773 MJD date
10847.650 s time past midnight
SPECTRACOM(4) clock name (unit) or source address
9714 hex status word
-0.001605376 s clock offset
0.000000000 s roundtrip delay
0.001424877 s dispersion
0.000958674 s RMS jitter
The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The third field shows the reference clock type and unit number (but if you are running in the peer address in dotted-quad notation instead) The fourth field is a status word, encoded in hex in the format described in Appendix A of the NTP specification RFC 1305. The final four fields show the offset, delay, dispersion and RMS jitter, all in seconds.
rawstats
Enables recording of raw-timestamp statistics information. This includes statistics records of all peers of an NTP server and of special signals, where present and configured. Each NTP message received from a peer or clock driver appends a line of the following form to the file generation set named rawstats:
59786 36302.768 2610:20:6f15:15::27 2604:a880:1:20::17:5001 3867818701.119346355 3867818701.152009264 3867818701.152010426 3867818702.768490825 0 3 4 1 13 -29 0.000244 0.000488 .NIST. 0 1 2000
Item Units Description
59786 MJD date
36302.768 s time past midnight
2610:20:6f15:15::27 IP source address
2604:a880:1:20::17:5001 IP destination address
3867818701.119346355 NTP s origin timestamp
3867818701.152009264 NTP s receive timestamp
3867818701.152010426 NTP s transmit timestamp
3867818702.768490825 NTP s destination timestamp
0 0: OK, 1: insert pending, 2: delete pending, 3: not synced leap warning indicator
3 4 was current in 2012 NTP version
4 3: client, 4: server, 6: ntpq mode
1 1-15, 16: not synced stratum
13 log2 seconds poll
-29 log2 seconds precision
0.000244 seconds total roundtrip delay from the remote server to the primary reference clock
0.000488 seconds total dispersion from the remote server to the primary reference clock
.NIST. IP or text refid, association ID
0 integer lost packets since last response
1 integer dropped packets since last request
2000 hex integer 0 if packet accecpted, BOGON flag if packet is discarded
The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The next two fields show the remote IP Address followed by the local address. The next four fields show the originate, receive, transmit and final NTP timestamps in order. The timestamp values are as received and before processing by the various data smoothing and mitigation algorithms.
A packet that is accecpted is logged. At most the first dropped packet per request is logged. That avoids DDoSing the log file.
The BOGON flags are decoded here <decode.html#flash>.
sysstats
Enables recording of ntpd statistics counters on a periodic basis. Each hour a line of the following form is appended to the file generation set named sysstats:
59935 82782.547 3600 36082754 31287166 26510580 4779042 113 19698 1997 428 4773352 0 366120
Item Units Description
59935 MJD date
82782.547 s time past midnight
3600 s time since reset
36082754 # packets received
31287166 # packets processed
26510580 # current version
4779042 # old version(s)
113 # access denied
19698 # bad length or format
1997 # bad authentication
428 # declined
4773352 # rate exceeded
0 # kiss-o-death packets sent
366120 # NTPv1 packets received
The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The remaining ten fields show the statistics counter values accumulated since the last generated line.
usestats
Enables recording of ntpd resource usage statistics. Each hour a line of the following form is appended to the file generation set named usestats:
57570 83399.541 3600 0.902 1.451 164 0 0 0 2328 64226 1 0 4308
Item Units Description
57570 MJD date
83399.541 s time past midnight
3600 s time since reset
0.902 s ru_utime: CPU seconds - user mode
1.451 s ru_stime: CPU seconds - system
164 # ru_minflt: page faults - reclaim/soft (no I/O)
0 # ru_majflt: page faults - I/O
0 # ru_nswap: process swapped out
0 # ru_inblock: file blocks in
2328 # ru_oublock: file blocks out
64226 # ru_nvcsw: context switches, wait
1 # ru_nivcsw: context switches, preempts
0 # ru_nsignals: signals
4308 # ru_maxrss: resident set size, kilobytes
The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The ru_ tags are the names from the rusage struct. See man getrusage for details. (The NetBSD and FreeBSD man pages have more details.) The maxrss column is the high water mark since the process was started. The remaining fields show the values used since the last report.

statsdir directory_path

Indicates the full path of a directory where statistics files should be created (see below). This keyword allows the (otherwise constant) filegen filename prefix to be modified for file generation sets, which is useful for handling statistics logs.

filegen name [file filename] [type typename] [link | nolink] [enable | disable]

Configures setting of the generation file set name. Generation file sets provide a means for handling files that are continuously growing during the lifetime of a server. Server statistics are a typical example for such files. Generation file sets provide access to a set of files used to store the actual data. At any time at most one element of the set is being written to. The type given specifies when and how data will be directed to a new element of the set. This way, information stored in elements of a file set that are currently unused are available for administrative operations without the risk of disturbing the operation of ntpd. (Most important: they can be removed to free space for new data produced.)
Note that this command can be sent from the ntpq(1) program running at a remote location.
name
This is the type of the statistics records, as shown in the statistics command.
file filename
This is the file name for the statistics records. Filenames of set members are built from three concatenated elements prefix, filename and suffix:
Attribute Description
prefix This is a constant filename path. It is not subject to modifications via the filegen option. It is defined by the server, usually specified as a compile-time constant. It may, however, be configurable for individual file generation sets via other commands. For example, the prefix used with loopstats and peerstats generation can be configured using the statsdir option explained above.
filename This string is directly concatenated to the prefix mentioned above (no intervening ‘/’). This can be modified using the file argument to the filegen statement. No .. elements are allowed in this component to prevent filenames referring to parts outside the filesystem hierarchy denoted by prefix.
suffix This part is reflects individual elements of a file set. It is generated according to the type of a file set.
type typename
A file generation set is characterized by its type. The following types are supported: // The following are tables only because indent lists cannot be // nested more than 2 deep.
Attribute Description
none The file set is actually a single plain file.
pid One element of file set is used per incarnation of a ntpd server. This type does not perform any changes to file set members during runtime, however it provides an easy way of separating files belonging to different ntpd(8) server incarnations. The set member filename is built by appending a ‘.’ to concatenated prefix and filename strings, and appending the decimal representation of the process ID of the ntpd(8) server process.
day One file generation set element is created per day. A day is defined as the period between 00:00 and 24:00 UTC. The file set member suffix consists of a ‘.’ and a day specification in the form YYYYMMdd. YYYY is a 4-digit year number (e.g., 1992). MM is a two digit month number. dd is a two digit day number. Thus, all information written at 10 December 1992 would end up in a file named prefix filename.19921210.
week Any file set member contains data related to a certain week of a year. The term week is defined by computing day-of-year modulo 7. Elements of such a file generation set are distinguished by appending the following suffix to the file set filename base: A dot, a 4-digit year number, the letter W, and a 2-digit week number. For example, information from January, 10th 1992 would end up in a file with suffix 1992W1.
month One generation file set element is generated per month. The file name suffix consists of a dot, a 4-digit year number, and a 2-digit month.
year One generation file element is generated per year. The filename suffix consists of a dot and a 4 digit year number.
age This type of file generation sets changes to a new element of the file set every 24 hours of server operation. The filename suffix consists of a dot, the letter a, and an 8-digit number. This number is taken to be the number of seconds the server is running at the start of the corresponding 24-hour period.
link | nolink
It is convenient to be able to access the current element of a file generation set by a fixed name. This feature is enabled by specifying link and disabled using nolink. If link is specified, a hard link from the current file set element to a file without suffix is created. When there is already a file with this name and the number of links of this file is one, it is renamed appending a dot, the letter C, and the pid of the ntpd server process. When the number of links is greater than one, the file is unlinked. This allows the current file to be accessed by a constant name.
enable | disable
Enables or disables the recording function. Information is only written to a file generation by specifying enable; output is prevented by specifying disable.

ACCESS CONTROL SUPPORT

The ntpd(8) daemon implements a general purpose address/mask based restriction list. The list contains address/match entries sorted first by increasing address values and then by increasing mask values. A match occurs when the bitwise AND of the mask and the packet source address is equal to the bitwise AND of the mask and address in the list. The list is searched in order with the last match found defining the restriction flags associated with the entry. Additional information and examples can be found in the “Notes on Configuring NTP and Setting up a NTP Subnet” page (available as part of the HTML documentation).

The restriction facility was implemented in conformance with the access policies for the original NSFnet backbone time servers. Later the facility was expanded to deflect cryptographic and clogging attacks. While this facility may be useful for keeping unwanted or broken or malicious clients from congesting innocent servers, it should not be considered an alternative to the NTP authentication facilities. Source address based restrictions are easily circumvented by a determined cracker.

Clients can be denied service because they are explicitly included in the restrict list created by the restrict command or implicitly as the result of cryptographic or rate limit violations. Cryptographic violations include certificate or identity verification failures; rate limit violations generally result from defective NTP implementations that send packets at abusive rates. Some violations cause denied service only for the offending packet, others cause denied service for a timed period and others cause the denied service for an indefinite period. When a client or network is denied access for an indefinite period, the only way at present to remove the restrictions is by restarting the server.

The Kiss-of-Death Packet

Ordinarily, packets denied service are simply dropped with no further action except incrementing statistics counters. Sometimes a more proactive response is needed, such as a server message that explicitly requests the client to stop sending and leave a message for the system operator. A special packet format has been created for this purpose called the “kiss-of-death” (KoD) packet. KoD packets have the leap bits set unsynchronized and stratum set to zero and the reference identifier field set to a four-byte ASCII code. If the noserve or notrust flag of the matching restrict list entry is set, the code is “DENY”; if the limited flag is set and the rate limit is exceeded, the code is “RATE”. Finally, if a cryptographic violation occurs, the code is “CRYP”.

A client receiving a KoD performs a set of sanity checks to minimize security exposure, then updates the stratum and reference identifier peer variables, sets the access denied (BOGON4) bit in the peer flash variable and sends a message to the log. As long as the BOGON4 bit is set, the client will send no further packets to the server. The only way at present to recover from this condition is to restart the protocol at both the client and server. This happens automatically at the client when the association times out. It will happen at the server only if the server operator cooperates.

ACCESS CONTROL COMMANDS

limit [average average] [burst burst] [kod kod]

Set the parameters of the limited facility which protects the server from client abuse. Internally, each MRU <ntpq.html#mrulist> slot contains a score in units of packets per second. It is updated each time a packet arrives from that IP Address. The score decays exponentially at the burst rate and is bumped by 1.0/burst when a packet arrives.
average average
Specify the allowed average rate for response packets in packets per second. The default is 1.0
burst burst
Specify the allowed burst size if the bursts are far enough apart to keep the average rate below average. The default is 20.0
kod kod
Specify the allowed average rate for KoD packets in packets per second. The default is 0.5

restrict address[/cidr] [mask mask] [flag ...]

The address argument expressed in dotted-quad (for IPv4) or :-delimited (for IPv6) form is the address of a host or network. Alternatively, the address argument can be a valid host DNS name. The mask argument expressed in IPv4 or IPv6 numeric address form defaults to all mask bits on, meaning that the address is treated as the address of an individual host. Instead of an explicit mask, the address/cidr may be specified in CIDR notation. A default entry (address 0.0.0.0, mask 0.0.0.0) is always included and is always the first entry in the list. Note that text string default, with no mask option, may be used to indicate the default entry. In the current implementation, flag always restricts access, i.e., an entry with no flags indicates that free access to the server is to be given. The flags are not orthogonal, in that more restrictive flags will often make less restrictive ones redundant. The flags can generally be classed into two categories, those which restrict time service and those which restrict informational queries and attempts to do a run-time reconfiguration of the server. One or more of the following flags may be specified:
flake
Discard received NTP packets with probability 0.1; that is, on average drop one packet in ten. This flag is for testing and amusement. The name comes from Bob Braden’s flakeway, which once did a similar thing for early Internet testing.
ignore
Deny packets of all kinds, including ntpq(1) queries.
kod
If this flag is set when an access violation occurs, a kiss-o-death (KoD) packet is sent. KoD packets are rate limited.
limited
Deny service if the packet spacing violates the lower limits specified in the limit command. A history of clients is kept using the monitoring capability of ntpd(8). Thus, monitoring is always active as long as there is a restriction entry with the limited flag.
mssntp
Enable Microsoft Windows MS-SNTP authentication using Active Directory services. Note: Potential users should be aware that these services involve a TCP connection to another process that could potentially block, denying services to other users. Therefore, this flag should be used only for a dedicated server with no clients other than MS-SNTP.
nomodify
Deny ntpq(1) queries which attempt to modify the state of the server (i.e., run time reconfiguration). Queries which return information are permitted.
nomrulist
Do not accept MRU-list requests. These can be expensive to service and may generate a high volume of response traffic.
nopeer
Deny packets which would result in mobilizing a new association; this includes symmetric active packets when a configured association does not exist. That used to happen when the remote client used the peer command in its config file. We don’t support that mode. It used to include pool servers, but they now poke a hole in any restrictions.
noquery
Deny ntpq(1) queries. Time service is not affected.
noserve
Deny all packets except ntpq(1) and queries.
notrust
Deny service unless the packet is cryptographically authenticated.
ntpport
This is a match algorithm modifier, rather than a restriction flag. Its presence causes the restriction entry to be matched if the source port in the packet is the standard NTP UDP port (123). Both ntpport and non-ntpport may be specified. The ntpport is considered more specific and is sorted later in the list.
version
Deny packets that do not match the current NTP version.

Note: A second restrict line with the same address/mask does not replace the first one. The flags are merged. Thus:

restrict bob X restrict bob Y

is the same as

restrict bob X Y

Default restriction list entries with the flags ignore, interface, ntpport, for each of the local host’s interface addresses are inserted into the table at startup to prevent the server from attempting to synchronize to its own time. A default entry is also always present. It has noquery to avoid packet length amplification which can be used for DDoS with a forged return address and limited to avoid DDoS reflections.

unrestrict address[/cidr] [mask mask] [flag ...]

Like a restrict command, but turns off the specified flags rather than turning them on (expected to be useful mainly with ntpq :config). An unrestrict with no flags specified removes any rule with matching address and mask. Use only on an address/mask or CIDR-format address mentioned in a previous restrict statement.

Note: unrestrict default will not do anything; you can’t remove the builtin defaults. If you want to remove them, use unrestrict default noquery limited to turn off those flags.

AUTOMATIC NTP CONFIGURATION OPTIONS

Manycasting

For a detailed description of manycast operation, see the “Server Discovery” page (available as part of the HTML documentation).

Manycast Options

tos [ceiling ceiling | floor floor | minclock minclock | minsane minsane]

This command affects the clock selection and clustering algorithms. It can be used to select the quality and quantity of peers used to synchronize the system clock and is most useful in manycast mode. The variables operate as follows:
ceiling ceiling
Peers with strata above ceiling will be discarded if there are at least minclock peers remaining. This value defaults to 15, but can be changed to any number from 1 to 15.
floor floor
Peers with strata below floor will be discarded if there are at least minclock peers remaining. This value defaults to 1, but can be changed to any number from 1 to 15.
minclock minclock
The clustering algorithm repeatedly casts out outlier associations until no more than minclock associations remain. This value defaults to 3, but can be changed to any number from 1 to the number of configured sources.
minsane minsane
This is the minimum number of candidates available to the clock selection algorithm in order to produce one or more truechimers for the clustering algorithm. If fewer than this number are available, the clock is undisciplined and allowed to run free. The default is 1 for legacy purposes. However, according to principles of Byzantine agreement, minsane should be at least 4 in order to detect and discard a single falseticker.

REFERENCE CLOCK SUPPORT

For a detailed description of reference-clock configuration, see the “Reference Clock Drivers” page (available as part of the HTML documentation provided in /usr/share/doc/ntp).

REFERENCE CLOCK COMMANDS

refclock drivername [unit u] [prefer] [subtype int] [mode int] [minpoll int] [maxpoll int] [time1 sec] [time2 sec] [stratum int] [refid string] [path filename] [ppspath filename] [baud number] [flag1 {0 | 1}] [flag2 {0 | 1}] [flag3 {0 | 1}] [flag4 {0 | 1}]

This command is used to configure reference clocks. The required drivername argument is the shortname of a driver type (e.g., shm, nmea, generic; see the Reference Clock Drivers <refclock.html> page for a full list. The options are interpreted as follows:
unit
The 0-origin unit number of the device; this modifies the devicename. If not specified, defaults to zero.
prefer
Marks the reference clock as preferred. All other things being equal, this host will be chosen for synchronization among a set of correctly operating hosts and clocks. See the “Mitigation Rules and the prefer Keyword” page (available as part of the HTML documentation provided in /usr/share/doc/ntp) for further information.
subtype int
Some drivers (notably the generic and jjy drivers) support multiple device types. This option selects among them in a driver-dependent way.
mode int
Specifies a mode number which is interpreted in a device-specific fashion. For instance, it selects a dialing protocol in the ACTS driver and a sentence mix in the nmea driver.
minpoll int; maxpoll int
These options specify the minimum and maximum polling interval for reference clock messages, as a power of 2 in seconds. For most directly connected reference clocks, both minpoll and maxpoll default to 6 (64 sec). For modem reference clocks, minpoll defaults to 10 (17.1 min) and maxpoll defaults to 14 (4.5 hours). The allowable range is 0 (1 sec) to 17 (36.4 hours) inclusive.
time1 sec
Specifies a constant to be added to the time offset produced by the driver, a fixed-point decimal number in seconds. Each “g” on the end of the constant adds the number of seconds in a 10-bit GPS era; each “G” adds the number of seconds in a 13-bit GPS era. This is used as a calibration constant to adjust the nominal time offset of a particular clock to agree with an external standard, such as a precision PPS signal. It also provides a way to correct a systematic error or bias due to era wraparound from a GPS device, serial port or operating system latencies, different cable lengths or receiver internal delay. The specified offset is in addition to the propagation delay provided by other means, such as internal DIP switches. Where a calibration for an individual system and driver is available, an approximate correction is noted in the driver documentation pages. Note: To facilitate calibration when more than one radio clock or PPS signal is supported, a special calibration feature is available. It takes the form of an argument to the enable command described in “Miscellaneous Options” page and operates as described in the “Reference Clock Drivers” page.
time2 secs
Specifies a fixed-point decimal number in seconds, which is interpreted in a driver-dependent way. See the descriptions of specific drivers in the “Reference Clock Drivers” page.
stratum int
Specifies the stratum number assigned to the driver, an integer between 0 and 15. This number overrides the default stratum number ordinarily assigned by the driver itself, usually zero.
refid string
Specifies an ASCII string of from one to four characters which defines the reference identifier used by the driver. This string overrides the default identifier ordinarily assigned by the driver itself.
path filepath
Overrides the default device location for this refclock.
ppspath filepath
Overrides the default PPS device location (if any) for this driver.
baud number
Overrides the defaults baud rate for this driver.
flag1 {0 | 1}; flag2 {0 | 1}; flag3 {0 | 1}; flag4 {0 | 1}
These four flags are used for customizing the clock driver. The interpretation of these values, and whether they are used at all, is a function of the particular clock driver. However, by convention flag4 is used to enable recording monitoring data to the clockstats file configured with the filegen command. Further information on the filegen command can be found in “Monitoring Options”.

MISCELLANEOUS OPTIONS

driftfile driftfile

This command specifies the complete path and name of the file used to record the frequency of the local clock oscillator; this is the same operation as the -f command line option. If the file exists, it is read at startup to set the initial frequency and then updated once per hour with the current frequency computed by the daemon. If the file name is specified, but the file itself does not exist, ntpd starts with an initial frequency of zero and creates the file when writing it for the first time. If this command is not given, the daemon will always start with an initial frequency of zero.
The file format consists of a single line containing a single floating point number, which records the frequency offset measured in parts-per-million (PPM). The file is updated by first writing the current drift value into a temporary file and then renaming this file to replace the old version; this implies that ntpd(8) must have write permission for the directory the drift file is located in, and that file system links, symbolic or otherwise, should be avoided.

Provides a way to enable or disable various server options. Flags not mentioned are unaffected. Note that all of these flags can be controlled remotely using the ntpq(1) utility program.
auth
Enables the server to synchronize with unconfigured peers only if the peer has been correctly authenticated. The default for this flag is enable.
calibrate
Enables the calibrate feature for reference clocks. The default for this flag is disable.
kernel
Enables the kernel time discipline, if available. The default for this flag is enable if support is available, otherwise disable.
monitor
Enables the monitoring facility. See the ntpq(1) program and the monlist command for further information. The default for this flag is enable.
ntp
Enables time and frequency discipline. In effect, this switch opens and closes the feedback loop, which is useful for testing. The default for this flag is enable.
stats
Enables the statistics facility. See the “Monitoring Options” section for further information. The default for this flag is disable.

includefile includefile

This command allows additional configuration commands to be included from a separate file. Include files may be nested to a depth of five; upon reaching the end of any include file, command processing resumes in the previous configuration file. Relative pathnames are evaluated not with respect to the current working directory but with respect to the directory name of the last pushed file in the stack. This option is useful for sites that run ntpd(8) on multiple hosts, with (mostly) common options (e.g., a restriction list).

interface [listen | ignore | drop] [all | ipv4 | ipv6 | wildcard | name | address[/prefixlen]]

This command controls which network addresses ntpd opens, and whether the input is dropped without processing. The first parameter determines the action on addresses which match the second parameter. That parameter specifies a class of addresses, or a specific interface name, or an address. In the address case, prefixlen determines how many bits must match for this rule to apply. ignore prevents opening matching addresses, drop causes ntpd to open the address and drop all received packets without examination. Multiple interface commands can be used. The last rule which matches a particular address determines the action for it. interface commands are disabled if any of the -I, --interface,-L, or --novirtualips command-line options are used. If none of those options are used, and no interface actions are specified in the configuration file, all available network addresses are opened. The nic command is an alias for interface.

leapfile leapfile

This command loads the NIST leap seconds file and initializes the leapsecond values for the next leap second time, expiration time and TAI offset. The file can be obtained using ntpleapfetch.
The leapfile is scanned when ntpd processes the leapfile directive or when ntpd detects that leapfile has changed. ntpd checks once a day to see if the leapfile has changed.

leapsmearinterval interval

This experimental option is only available if ntpd was built with the --enable-leap-smear option, It specifies the interval over which a leap second correction will be applied. Recommended values for this option are between 7200 (2 hours) and 86400 (24 hours). DO NOT USE THIS OPTION ON PUBLIC-ACCESS SERVERS! See <http://bugs.ntp.org/2855> for more information.

logconfig configkeyword

This command controls the amount and type of output written to the system syslog(3) facility or the alternate log file. By default, all output is turned on. All configkeyword keywords can be prefixed with ‘=’, ‘’ and ‘-’, where ‘=’ sets the syslog(3) priority mask, ‘’ adds and ‘-’ removes messages. syslog(3) messages can be controlled in four classes (clock,peer,sys and sync). Within these classes four types of messages can be controlled: informational messages (info), event messages (events), statistics messages (statistics) and status messages (status).
Configuration keywords are formed by concatenating the message class with the event class. The all prefix can be used instead of a message class. A message class may also be followed by the all keyword to enable/disable all messages of the respective message class. Thus, a minimal log configuration could look like this:
logconfig =syncstatus +sysevents
This would just list the synchronizations state of ntpd(8) and the major system events. For a simple reference server, the following minimum message configuration could be useful:
logconfig =syncall +clockall
This configuration will list all clock information and synchronization information. All other events and messages about peers, system events and so on is suppressed.

logfile logfile

This command specifies the location of an alternate log file to be used instead of the default system syslog(3) facility; this is the same operation as the -l command line option.

If your ntpd runs for a long time, you probably want to use logrotate or newsyslog to switch to a new log file occasionally. SIGHUP will reopen the log file.

Controls size limits of the monitoring facility Most Recently Used (MRU) list of client addresses, which is also used by the rate control facility.
maxdepth count, maxmem kilobytes
Equivalent upper limits on the size of the MRU list, in terms of entries or kilobytes. The actual limit will be up to incalloc entries or incmem kilobytes larger. As with all of the mru options offered in units of entries or kilobytes, if both maxdepth and maxmem are used, the last one used controls. The default is 1024 kilobytes.
mindepth count
The lower limit on the MRU list size. When the MRU list has fewer than mindepth entries, existing entries are never removed to make room for newer ones, regardless of their age. The default is 600 entries.
maxage seconds, minage seconds
If an address is not in the list, there are several possible ways to find a slot for it.
1.
If the list has fewer than mindepth entries, a slot is allocated from the free list; this is the normal case for a server without a lot of clients. If clients come and go, for example, laptops going between home and work, the default setup shows only the long term average.
2.
If the age of the oldest slot is greater than maxage, the oldest slot is recycled (default 3600 seconds).
3.
If the freelist is not empty, a slot is allocated from the free list.
4.
If the freelist is empty but not full (see maxmem), more memory is allocated (see incmem) and, a new slot is used.
5.
If the age of the oldest slot is more than minage, the oldest slot is recycled (default 64 seconds).
6.
Otherwise, no slot is available.
initalloc count, initmem kilobytes
Initial memory allocation at the time the monitoring facility is first enabled, in terms of entries or kilobytes. The default is 4 kilobytes.
incalloc count, incmem kilobytes
Size of additional memory allocations when growing the MRU list, in entries or kilobytes. The default is 4 kilobytes.

nonvolatile threshold

Specify the threshold in seconds to write the frequency file, with a default of 1e-7 (0.1 PPM). The frequency file is inspected each hour. If the difference between the current frequency and the last value written exceeds the threshold, the file is written, and the threshold becomes the new threshold value. If the threshold is not exceeded, it is reduced by half; this is intended to reduce the frequency of unnecessary file writes for embedded systems with nonvolatile memory.

phone dial …

This command is used in conjunction with the ACTS modem driver (type modem) or the JJY driver (type jjy). For ACTS, the arguments consist of a maximum of 10 telephone numbers used to dial USNO, NIST or European time services. For the jjy driver in modes 100-180, the argument is one telephone number used to dial the telephone JJY service. The Hayes command ATDT is normally prepended to the number, which can contain other modem control codes as well.

reset [allpeers] [auth] [ctl] [io] [mem] [sys] [timer]

Reset one or more groups of counters maintained by ntpd and exposed by ntpq.

setvar variable [default]

This command adds a system variable. These variables can be used to distribute additional information such as the access policy. If the variable of the form name=value is followed by the default keyword, the variable will be listed as part of the default system variables (ntpq(1) rv command). These additional variables serve informational purposes only. They are not related to the protocol other that they can be listed. The known protocol variables will always override any variables defined via the setvar mechanism. There are three special variables that contain the names of all variable of the same group. The sys_var_list holds the names of all system variables. The peer_var_list holds the names of all peer variables and the clock_var_list holds the names of the reference clock variables.

This command can be used to alter several system variables in very exceptional circumstances. It should occur in the configuration file before any other configuration options. The default values of these variables have been carefully optimized for a wide range of network speeds and reliability expectations. In general, they interact in intricate ways that are hard to predict, and some combinations can result in some very nasty behavior. Very rarely is it necessary to change the default values; but, some folks cannot resist twisting the knobs anyway, and this command is for them. Emphasis added: twisters are on their own and can expect no help from the support group.
The variables operate as follows:
allan allan
The argument becomes the new value for the minimum Allan intercept, which is a parameter of the PLL/FLL clock discipline algorithm. The value in log2 seconds defaults to 11 (2048 s), which is also the lower limit.
dispersion dispersion
The argument becomes the new value for the dispersion increase rate, normally .000015 s/s.
freq freq
The argument becomes the initial value of the frequency offset in parts-per-million; this overrides the value in the frequency file, if present, and avoids the initial training state if it is not.
huffpuff huffpuff
The argument becomes the new value for the experimental huff-n-puff filter span, which determines the most recent interval the algorithm will search for a minimum delay. The lower limit is 900 s (15 m), but a more reasonable value is 7200 (2 hours). There is no default since the filter is not enabled unless this command is given.
panic panic
The argument is the panic threshold, normally 1000 s. If set to zero, the panic sanity check is disabled, and a clock offset of any value will be accepted.
step step
The argument is the step threshold, which by default is 0.128 sec. It can be set to any positive number in seconds. If set to zero, step adjustments will never occur. Note: The kernel time discipline is disabled if the step threshold is set to zero or greater than the default.
stepback stepback
The argument is the step threshold for the backward direction, which by default is 0.128 sec. It can be set to any positive number in seconds. If both the forward and backward step thresholds are set to zero, step adjustments will never occur. Note: The kernel time discipline is disabled if each direction of step threshold are either set to zero or greater than .5 second.
stepfwd stepfwd
As for stepback, but for the forward direction.
stepout stepout
The argument is the stepout timeout, which by default is 900 s. It can be set to any positive number in seconds. If set to zero, the stepout pulses will not be suppressed.

rlimit [memlock megabytes | stacksize 4kPages | filenum filedescriptors]

memlock megabytes
Ignored for backward compatibility.
stacksize 4kPages
Specifies the maximum size of the process stack on systems with the mlockall() function. Defaults to 50 4k pages.
filenum filedescriptors
Specifies the maximum number of file descriptors ntpd may have open at once. Defaults to the system default.

FILES

/etc/ntpsec/ntp.conf

the default name of the configuration file

/etc/ntpsec/ntp.keys

private keys

BUGS

The syntax checking is not picky; some combinations of ridiculous and even hilarious options and modes may not be detected.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

38 - Linux cli command gitformat-signature

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitformat-signature and provides detailed information about the command gitformat-signature, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitformat-signature.

NAME 🖥️ gitformat-signature 🖥️

signature - Git cryptographic signature formats

SYNOPSIS

<[tag|commit] object header(s)>
<over-the-wire protocol>

DESCRIPTION

Git uses cryptographic signatures in various places, currently objects (tags, commits, mergetags) and transactions (pushes). In every case, the command which is about to create an object or transaction determines a payload from that, calls an external program to obtain a detached signature for the payload (gpg -bsa in the case of PGP signatures), and embeds the signature into the object or transaction.

Signatures begin with an “ASCII Armor” header line and end with a tail line, which differ depending on signature type (as selected by gpg.format, see git-config(1)). These are, for gpg.format values:

gpg (PGP)

—–BEGIN PGP SIGNATURE—– and —–END PGP SIGNATURE—–. Or, if gpg is told to produce RFC1991 signatures, —–BEGIN PGP MESSAGE—– and —–END PGP MESSAGE—–

ssh (SSH)

—–BEGIN SSH SIGNATURE—– and —–END SSH SIGNATURE—–

x509 (X.509)

—–BEGIN SIGNED MESSAGE—– and —–END SIGNED MESSAGE—–

Signatures sometimes appear as a part of the normal payload (e.g. a signed tag has the signature block appended after the payload that the signature applies to), and sometimes appear in the value of an object header (e.g. a merge commit that merged a signed tag would have the entire tag contents on its “mergetag” header). In the case of the latter, the usual multi-line formatting rule for object headers applies. I.e. the second and subsequent lines are prefixed with a SP to signal that the line is continued from the previous line.

This is even true for an originally empty line. In the following examples, the end of line that ends with a whitespace letter is highlighted with a $ sign; if you are trying to recreate these example by hand, do not cut and paste them—they are there primarily to highlight extra whitespace at the end of some lines.

The signed payload and the way the signature is embedded depends on the type of the object resp. transaction.

TAG SIGNATURES

·
created by: git tag -s

·
payload: annotated tag object

·
embedding: append the signature to the unsigned tag object

·
example: tag signedtag with subject signed tag

object 04b871796dc0420f8e7561a895b52484b701d51a type commit tag signedtag tagger C O Mitter [email protected] 1465981006 +0000

signed tag

signed tag message body
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAABAgAGBQJXYRhOAAoJEGEJLoW3InGJklkIAIcnhL7RwEb/+QeX9enkXhxn
rxfdqrvWd1K80sl2TOt8Bg/NYwrUBw/RWJ+sg/hhHp4WtvE1HDGHlkEz3y11Lkuh
8tSxS3qKTxXUGozyPGuE90sJfExhZlW4knIQ1wt/yWqM+33E9pN4hzPqLwyrdods
q8FWEqPPUbSJXoMbRPw04S5jrLtZSsUWbRYjmJCHzlhSfFWW4eFd37uquIaLUBS0
rkC3Jrx7420jkIpgFcTI2s60uhSQLzgcCwdA2ukSYIRnjg/zDkj8+3h/GaROJ72x
lZyI6HWixKJkWw8lE9aAOD9TmTW9sFJwcVAzmAuFX2kUreDUKMZduGcoRYGpD7E=
=jpXa
-----END PGP SIGNATURE-----

·
verify with: git verify-tag [-v] or git tag -v

gpg: Signature made Wed Jun 15 10:56:46 2016 CEST using RSA key ID B7227189 gpg: Good signature from “Eris Discordia [email protected]” gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: D4BE 2231 1AD3 131E 5EDA 29A4 6109 2E85 B722 7189 object 04b871796dc0420f8e7561a895b52484b701d51a type commit tag signedtag tagger C O Mitter [email protected] 1465981006 +0000
signed tag

signed tag message body

COMMIT SIGNATURES

·
created by: git commit -S

·
payload: commit object

·
embedding: header entry gpgsig (content is preceded by a space)

·
example: commit with subject signed commit

tree eebfed94e75e7760540d1485c740902590a00332 parent 04b871796dc0420f8e7561a895b52484b701d51a author A U Thor [email protected] 1465981137 +0000 committer C O Mitter [email protected] 1465981137 +0000 gpgsig —–BEGIN PGP SIGNATURE—– Version: GnuPG v1 $ iQEcBAABAgAGBQJXYRjRAAoJEGEJLoW3InGJ3IwIAIY4SA6GxY3BjL60YyvsJPh/ HRCJwH+w7wt3Yc/9/bW2F+gF72kdHOOs2jfv+OZhq0q4OAN6fvVSczISY/82LpS7 DVdMQj2/YcHDT4xrDNBnXnviDO9G7am/9OE77kEbXrp7QPxvhjkicHNwy2rEflAA zn075rtEERDHr8nRYiDh8eVrefSO7D+bdQ7gv+7GsYMsd2auJWi1dHOSfTr9HIF4 HJhWXT9d2f8W+diRYXGh4X0wYiGg6na/soXc+vdtDYBzIxanRqjg8jCAeo1eOTk1 EdTwhcTZlI0x5pvJ3H0+4hA2jtldVtmPM4OTB0cTrEWBad7XV6YgiyuII73Ve3I= =jKHM —–END PGP SIGNATURE—–
signed commit

signed commit message body

·
verify with: git verify-commit [-v] (or git show –show-signature)

gpg: Signature made Wed Jun 15 10:58:57 2016 CEST using RSA key ID B7227189 gpg: Good signature from “Eris Discordia [email protected]” gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: D4BE 2231 1AD3 131E 5EDA 29A4 6109 2E85 B722 7189 tree eebfed94e75e7760540d1485c740902590a00332 parent 04b871796dc0420f8e7561a895b52484b701d51a author A U Thor [email protected] 1465981137 +0000 committer C O Mitter [email protected] 1465981137 +0000
signed commit

signed commit message body

MERGETAG SIGNATURES

·
created by: git merge on signed tag

·
payload/embedding: the whole signed tag object is embedded into the (merge) commit object as header entry mergetag

·
example: merge of the signed tag signedtag as above

tree c7b1cff039a93f3600a1d18b82d26688668c7dea parent c33429be94b5f2d3ee9b0adad223f877f174b05d parent 04b871796dc0420f8e7561a895b52484b701d51a author A U Thor [email protected] 1465982009 +0000 committer C O Mitter [email protected] 1465982009 +0000 mergetag object 04b871796dc0420f8e7561a895b52484b701d51a type commit tag signedtag tagger C O Mitter [email protected] 1465981006 +0000 $ signed tag $ signed tag message body —–BEGIN PGP SIGNATURE—– Version: GnuPG v1 $ iQEcBAABAgAGBQJXYRhOAAoJEGEJLoW3InGJklkIAIcnhL7RwEb/+QeX9enkXhxn rxfdqrvWd1K80sl2TOt8Bg/NYwrUBw/RWJ+sg/hhHp4WtvE1HDGHlkEz3y11Lkuh 8tSxS3qKTxXUGozyPGuE90sJfExhZlW4knIQ1wt/yWqM+33E9pN4hzPqLwyrdods q8FWEqPPUbSJXoMbRPw04S5jrLtZSsUWbRYjmJCHzlhSfFWW4eFd37uquIaLUBS0 rkC3Jrx7420jkIpgFcTI2s60uhSQLzgcCwdA2ukSYIRnjg/zDkj8+3h/GaROJ72x lZyI6HWixKJkWw8lE9aAOD9TmTW9sFJwcVAzmAuFX2kUreDUKMZduGcoRYGpD7E= =jpXa —–END PGP SIGNATURE—–
Merge tag signedtag into downstream

signed tag

signed tag message body

# gpg: Signature made Wed Jun 15 08:56:46 2016 UTC using RSA key ID B7227189
# gpg: Good signature from "Eris Discordia <[email protected]>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: D4BE 2231 1AD3 131E 5EDA  29A4 6109 2E85 B722 7189

·
verify with: verification is embedded in merge commit message by default, alternatively with git show –show-signature:

commit 9863f0c76ff78712b6800e199a46aa56afbcbd49 merged tag signedtag gpg: Signature made Wed Jun 15 10:56:46 2016 CEST using RSA key ID B7227189 gpg: Good signature from “Eris Discordia [email protected]” gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: D4BE 2231 1AD3 131E 5EDA 29A4 6109 2E85 B722 7189 Merge: c33429b 04b8717 Author: A U Thor [email protected] Date: Wed Jun 15 09:13:29 2016 +0000
    Merge tag signedtag into downstream

    signed tag

    signed tag message body

    # gpg: Signature made Wed Jun 15 08:56:46 2016 UTC using RSA key ID B7227189
    # gpg: Good signature from "Eris Discordia <[email protected]>"
    # gpg: WARNING: This key is not certified with a trusted signature!
    # gpg:          There is no indication that the signature belongs to the owner.
    # Primary key fingerprint: D4BE 2231 1AD3 131E 5EDA  29A4 6109 2E85 B722 7189

GIT

Part of the git(1) suite

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

39 - Linux cli command proc_partitions

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_partitions and provides detailed information about the command proc_partitions, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_partitions.

NAME 🖥️ proc_partitions 🖥️

major and minor numbers of partitions

DESCRIPTION

/proc/partitions
Contains the major and minor numbers of each partition as well as the number of 1024-byte blocks and the partition name.

40 - Linux cli command exim4_exim_crt

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command exim4_exim_crt and provides detailed information about the command exim4_exim_crt, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the exim4_exim_crt.

NAME 🖥️ exim4_exim_crt 🖥️

config_files - Files in use by the Debian exim4 packages

SYNOPSIS

DESCRIPTION

This manual page describes the files that are in use by the Debian exim4 packages and which are not part of an exim installation done from source.

/etc/aliases

You should at least set up an alias for postmaster in the /etc/aliases file.

/etc/email-addresses

is used to rewrite the email addresses of users. This is particularly useful for users who use their ISP’s domain for email.

The file should contain lines of the form

user: [email protected]
otheruser: [email protected]

/etc/exim4/local_host_blacklist

In the blacklist, the trick is to read a line break as “or” if it follows a positive item, and as “and” if it follows a negative item.

For example, a /etc/exim4/local_host_blacklist

192.168.10.0/24
!172.16.10.128/26
172.16.10.0/24
10.0.0.0/8

Exim just evaluates left to right (or up-down in the file listing context), so you don’t get the same kind of operator binding as in a programming language.

/etc/exim4/host_local_deny_exceptions

/etc/exim4/local_sender_blacklist

In the blacklist, the trick is to read a line break as “or” if it follows a positive item, and as “and” if it follows a negative item.

For example, a /etc/exim4/local_sender_blacklist

domain1.example
[email protected]
domain2.example
domain3.example

Exim just evaluates left to right (or up-down in the file listing context), so you don’t get the same kind of operator binding as in a programming language.

/etc/exim4/sender_local_deny_exceptions

/etc/exim4/local_sender_callout

/etc/exim4/local_rcpt_callout

/etc/exim4/local_domain_dnsbl_whitelist

/etc/exim4/hubbed_hosts

The file should contain key-value pairs of domain pattern and route data of the form

domain: host-list options
dict.ref.example: mail-1.ref.example:mail-2.ref.example
foo.example: internal.mail.example.com
bar.example: 192.168.183.3

which will cause mail for foo.example to be sent to the host internal.mail.example (IP address derived from A record only), and mail to bar.example to be sent to 192.168.183.3.

See spec.txt chapter 20.3 through 20.7 for a more detailed explanation of host list format and available options.

/etc/exim4/passwd

contains account and password data for SMTP authentication when the local exim is SMTP server and clients authenticate to the local exim.

The file should contain lines of the form

username:crypted-password:clear-password

clear-password is only necessary if you want to offer CRAM-MD5 authentication. If you don’t plan on doing so, the third column can be omitted completely.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim 640.

/etc/exim4/passwd.client

contains account and password data for SMTP authentication when exim is authenticating as a client to some remote server.

The file should contain lines of the form

target.mail.server.example:login-user-name:password

This goes inevitably wrong if the host name of the mail server is a CNAME (a DNS alias), or the reverse lookup does not fit the forward one.

password is your SMTP password in clear text. If you do not know about your SMTP password, you can try using your POP3 password as a first guess.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim 640.

/etc/exim4/exim.crt

/etc/exim4/exim.key

/etc/mailname

The “mail name” of the system. See Debian policy Chapter Customized programs and exim4-base’s README.Debian for further details.

BUGS

Plenty. Please report them through the Debian BTS

This manual page needs a major re-work. If somebody knows better groff than us and has more experience in writing manual pages, any patches would be greatly appreciated.

NOTES

Unresolvable items in host lists

Adding or keeping items in the abovementioned host lists which are not resolvable by DNS has severe consequences.

notresolvable.example.com:rejectme.example.com

Starting the list with the special pattern +ignore_unknown as a safeguard against this behavior is strongly recommended if hostnames are used in hostlists.

AUTHOR

Marc Haber <[email protected]> with help from Ross Boylan.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

41 - Linux cli command termcap

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command termcap and provides detailed information about the command termcap, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the termcap.

NAME 🖥️ termcap 🖥️

terminal capability database

DESCRIPTION

The termcap database is an obsolete facility for describing the capabilities of character-cell terminals and printers. It is retained only for compatibility with old programs; new programs should use the terminfo(5) database and associated libraries.

/etc/termcap is an ASCII file (the database master) that lists the capabilities of many different types of terminals. Programs can read termcap to find the particular escape codes needed to control the visual attributes of the terminal actually in use. (Other aspects of the terminal are handled by stty(1).) The termcap database is indexed on the TERM environment variable.

Termcap entries must be defined on a single logical line, with ‘\ used to suppress the newline. Fields are separated by ‘:’. The first field of each entry starts at the left-hand margin, and contains a list of names for the terminal, separated by ‘|’.

The first subfield may (in BSD termcap entries from 4.3BSD and earlier) contain a short name consisting of two characters. This short name may consist of capital or small letters. In 4.4BSD, termcap entries this field is omitted.

The second subfield (first, in the newer 4.4BSD format) contains the name used by the environment variable TERM. It should be spelled in lowercase letters. Selectable hardware capabilities should be marked by appending a hyphen and a suffix to this name. See below for an example. Usual suffixes are w (more than 80 characters wide), am (automatic margins), nam (no automatic margins), and rv (reverse video display). The third subfield contains a long and descriptive name for this termcap entry.

Subsequent fields contain the terminal capabilities; any continued capability lines must be indented one tab from the left margin.

Although there is no defined order, it is suggested to write first boolean, then numeric, and then string capabilities, each sorted alphabetically without looking at lower or upper spelling. Capabilities of similar functions can be written in one line.

Example for:

Head line: vt|vt101|DEC VT 101 terminal in 80 character mode:\
Head line: Vt|vt101-w|DEC VT 101 terminal in (wide) 132 character mode:\
Boolean: :bs:\
Numeric: :co#80:\
String: :sr=[H:\

Boolean capabilities

5i	Printer will not echo on screen
am	Automatic margins which means automatic line wrap
bs	Control-H (8 dec.) performs a backspace
bw	Backspace on left margin wraps to previous line and right margin
da	Display retained above screen
db	Display retained below screen
eo	A space erases all characters at cursor position
es	Escape sequences and special characters work in status line
gn	Generic device
hc	This is a hardcopy terminal
HC	The cursor is hard to see when not on bottom line
hs	Has a status line
hz	Hazeltine bug, the terminal can not print tilde characters
in	Terminal inserts null bytes, not spaces, to fill whitespace
km	Terminal has a meta key
mi	Cursor movement works in insert mode
ms	Cursor movement works in standout/underline mode
NP	No pad character
NR	ti does not reverse te
nx	No padding, must use XON/XOFF
os	Terminal can overstrike
ul	Terminal underlines although it can not overstrike
xb	Beehive glitch, f1 sends ESCAPE, f2 sends ^C
xn	Newline/wraparound glitch
xo	Terminal uses xon/xoff protocol
xs	Text typed over standout text will be displayed in standout
xt	Teleray glitch, destructive tabs and odd standout mode

Numeric capabilities

co	Number of columns
dB	Delay in milliseconds for backspace on hardcopy terminals
dC	Delay in milliseconds for carriage return on hardcopy terminals
dF	Delay in milliseconds for form feed on hardcopy terminals
dN	Delay in milliseconds for new line on hardcopy terminals
dT	Delay in milliseconds for tabulator stop on hardcopy terminals
dV	Delay in milliseconds for vertical tabulator stop on
	hardcopy terminals
it	Difference between tab positions
lh	Height of soft labels
lm	Lines of memory
lw	Width of soft labels
li	Number of lines
Nl	Number of soft labels
pb	Lowest baud rate which needs padding
sg	Standout glitch
ug	Underline glitch
vt	virtual terminal number
ws	Width of status line if different from screen width

String capabilities

!1	shifted save key
!2	shifted suspend key
!3	shifted undo key
#1	shifted help key
#2	shifted home key
#3	shifted input key
#4	shifted cursor left key
%0	redo key
%1	help key
%2	mark key
%3	message key
%4	move key
%5	next-object key
%6	open key
%7	options key
%8	previous-object key
%9	print key
%a	shifted message key
%b	shifted move key
%c	shifted next key
%d	shifted options key
%e	shifted previous key
%f	shifted print key
%g	shifted redo key
%h	shifted replace key
%i	shifted cursor right key
%j	shifted resume key
&0	shifted cancel key
&1	reference key
&2	refresh key
&3	replace key
&4	restart key
&5	resume key
&6	save key
&7	suspend key
&8	undo key
&9	shifted begin key
*0	shifted find key
*1	shifted command key
*2	shifted copy key
*3	shifted create key
*4	shifted delete character
*5	shifted delete line
*6	select key
*7	shifted end key
*8	shifted clear line key
*9	shifted exit key
@0	find key
@1	begin key
@2	cancel key
@3	close key
@4	command key
@5	copy key
@6	create key
@7	end key
@8	enter/send key
@9	exit key
al	Insert one line
AL	Insert %1 lines
ac	Pairs of block graphic characters to map alternate character set
ae	End alternative character set
as	Start alternative character set for block graphic characters
bc	Backspace, if not ^H
bl	Audio bell
bt	Move to previous tab stop
cb	Clear from beginning of line to cursor
cc	Dummy command character
cd	Clear to end of screen
ce	Clear to end of line
ch	Move cursor horizontally only to column %1
cl	Clear screen and cursor home
cm	Cursor move to row %1 and column %2 (on screen)
CM	Move cursor to row %1 and column %2 (in memory)
cr	Carriage return
cs	Scroll region from line %1 to %2
ct	Clear tabs
cv	Move cursor vertically only to line %1
dc	Delete one character
DC	Delete %1 characters
dl	Delete one line
DL	Delete %1 lines
dm	Begin delete mode
do	Cursor down one line
DO	Cursor down #1 lines
ds	Disable status line
eA	Enable alternate character set
ec	Erase %1 characters starting at cursor
ed	End delete mode
ei	End insert mode
ff	Formfeed character on hardcopy terminals
fs	Return character to its position before going to status line
F1	The string sent by function key f11
F2	The string sent by function key f12
F3	The string sent by function key f13
...	...
F9	The string sent by function key f19
FA	The string sent by function key f20
FB	The string sent by function key f21
...	...
FZ	The string sent by function key f45
Fa	The string sent by function key f46
Fb	The string sent by function key f47
...	...
Fr	The string sent by function key f63
hd	Move cursor a half line down
ho	Cursor home
hu	Move cursor a half line up
i1	Initialization string 1 at login
i3	Initialization string 3 at login
is	Initialization string 2 at login
ic	Insert one character
IC	Insert %1 characters
if	Initialization file
im	Begin insert mode
ip	Insert pad time and needed special characters after insert
iP	Initialization program
K1	upper left key on keypad
K2	center key on keypad
K3	upper right key on keypad
K4	bottom left key on keypad
K5	bottom right key on keypad
k0	Function key 0
k1	Function key 1
k2	Function key 2
k3	Function key 3
k4	Function key 4
k5	Function key 5
k6	Function key 6
k7	Function key 7
k8	Function key 8
k9	Function key 9
k;	Function key 10
ka	Clear all tabs key
kA	Insert line key
kb	Backspace key
kB	Back tab stop
kC	Clear screen key
kd	Cursor down key
kD	Key for delete character under cursor
ke	turn keypad off
kE	Key for clear to end of line
kF	Key for scrolling forward/down
kh	Cursor home key
kH	Cursor hown down key
kI	Insert character/Insert mode key
kl	Cursor left key
kL	Key for delete line
kM	Key for exit insert mode
kN	Key for next page
kP	Key for previous page
kr	Cursor right key
kR	Key for scrolling backward/up
ks	Turn keypad on
kS	Clear to end of screen key
kt	Clear this tab key
kT	Set tab here key
ku	Cursor up key
l0	Label of zeroth function key, if not f0
l1	Label of first function key, if not f1
l2	Label of first function key, if not f2
...	...
la	Label of tenth function key, if not f10
le	Cursor left one character
ll	Move cursor to lower left corner
LE	Cursor left %1 characters
LF	Turn soft labels off
LO	Turn soft labels on
mb	Start blinking
MC	Clear soft margins
md	Start bold mode
me	End all mode like so, us, mb, md, and mr
mh	Start half bright mode
mk	Dark mode (Characters invisible)
ML	Set left soft margin
mm	Put terminal in meta mode
mo	Put terminal out of meta mode
mp	Turn on protected attribute
mr	Start reverse mode
MR	Set right soft margin
nd	Cursor right one character
nw	Carriage return command
pc	Padding character
pf	Turn printer off
pk	Program key %1 to send string %2 as if typed by user
pl	Program key %1 to execute string %2 in local mode
pn	Program soft label %1 to show string %2
po	Turn the printer on
pO	Turn the printer on for %1 (<256) bytes
ps	Print screen contents on printer
px	Program key %1 to send string %2 to computer
r1	Reset string 1 to set terminal to sane modes
r2	Reset string 2 to set terminal to sane modes
r3	Reset string 3 to set terminal to sane modes
RA	disable automatic margins
rc	Restore saved cursor position
rf	Reset string filename
RF	Request for input from terminal
RI	Cursor right %1 characters
rp	Repeat character %1 for %2 times
rP	Padding after character sent in replace mode
rs	Reset string
RX	Turn off XON/XOFF flow control
sa	Set %1 %2 %3 %4 %5 %6 %7 %8 %9 attributes
SA	enable automatic margins
sc	Save cursor position
se	End standout mode
sf	Normal scroll one line
SF	Normal scroll %1 lines
so	Start standout mode
sr	Reverse scroll
SR	scroll back %1 lines
st	Set tabulator stop in all rows at current column
SX	Turn on XON/XOFF flow control
ta	move to next hardware tab
tc	Read in terminal description from another entry
te	End program that uses cursor motion
ti	Begin program that uses cursor motion
ts	Move cursor to column %1 of status line
uc	Underline character under cursor and move cursor right
ue	End underlining
up	Cursor up one line
UP	Cursor up %1 lines
us	Start underlining
vb	Visible bell
ve	Normal cursor visible
vi	Cursor invisible
vs	Standout cursor
wi	Set window from line %1 to %2 and column %3 to %4
XF	XOFF character if not ^S

There are several ways of defining the control codes for string capabilities:

Every normal character represents itself, except ‘^’, ‘, and ‘%’.

A ^x means Control-x. Control-A equals 1 decimal.

\x means a special code. x can be one of the following characters:

E Escape (27)
n Linefeed (10)
r Carriage return (13)
t Tabulation (9)
b Backspace (8)
f Form feed (12)
0 Null character. A \xxx specifies the octal character xxx.

i
Increments parameters by one.

r
Single parameter capability

+
Add value of next character to this parameter and do binary output

2
Do ASCII output of this parameter with a field with of 2

d
Do ASCII output of this parameter with a field with of 3

%
Print a ‘%’

If you use binary output, then you should avoid the null character (‘�’) because it terminates the string. You should reset tabulator expansion if a tabulator can be the binary output of a parameter.

Warning:
The above metacharacters for parameters may be wrong: they document Minix termcap which may not be compatible with Linux termcap.

The block graphic characters can be specified by three string capabilities:

as
start the alternative charset

ae
end the alternative charset

ac
pairs of characters. The first character is the name of the block graphic symbol and the second characters is its definition.

The following names are available:

+	right arrow (>)
,	left arrow (<)
.	down arrow (v)
0	full square (#)
I	lantern (#)
-	upper arrow (^)
'	rhombus (+)
a	chess board (:)
f	degree (')
g	plus-minus (#)
h	square (#)
j	right bottom corner (+)
k	right upper corner (+)
l	left upper corner (+)
m	left bottom corner (+)
n	cross (+)
o	upper horizontal line (-)
q	middle horizontal line (-)
s	bottom horizontal line (_)
t	left tee (+)
u	right tee (+)
v	bottom tee (+)
w	normal tee (+)
x	vertical line (|)
~	paragraph (???)

The values in parentheses are suggested defaults which are used by the curses library, if the capabilities are missing.

42 - Linux cli command githooks

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command githooks and provides detailed information about the command githooks, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the githooks.

NAME 🖥️ githooks 🖥️

Hooks used by Git

SYNOPSIS

$GIT_DIR/hooks/* (or `git config core.hooksPath`/*)

DESCRIPTION

Hooks are programs you can place in a hooks directory to trigger actions at certain points in git’s execution. Hooks that don’t have the executable bit set are ignored.

By default the hooks directory is $GIT_DIR/hooks, but that can be changed via the core.hooksPath configuration variable (see git-config(1)).

Before Git invokes a hook, it changes its working directory to either $GIT_DIR in a bare repository or the root of the working tree in a non-bare repository. An exception are hooks triggered during a push (pre-receive, update, post-receive, post-update, push-to-checkout) which are always executed in $GIT_DIR.

Environment variables, such as GIT_DIR, GIT_WORK_TREE, etc., are exported so that Git commands run by the hook can correctly locate the repository. If your hook needs to invoke Git commands in a foreign repository or in a different working tree of the same repository, then it should clear these environment variables so they do not interfere with Git operations at the foreign location. For example:

local_desc=$(git describe) foreign_desc=$(unset $(git rev-parse –local-env-vars); git -C ../foreign-repo describe)

Hooks can get their arguments via the environment, command-line arguments, and stdin. See the documentation for each hook below for details.

git init may copy hooks to the new repository, depending on its configuration. See the “TEMPLATE DIRECTORY” section in git-init(1) for details. When the rest of this document refers to “default hooks” it’s talking about the default template shipped with Git.

The currently supported hooks are described below.

HOOKS

applypatch-msg

This hook is invoked by git-am(1). It takes a single parameter, the name of the file that holds the proposed commit log message. Exiting with a non-zero status causes git am to abort before applying the patch.

The hook is allowed to edit the message file in place, and can be used to normalize the message into some project standard format. It can also be used to refuse the commit after inspecting the message file.

The default applypatch-msg hook, when enabled, runs the commit-msg hook, if the latter is enabled.

pre-applypatch

This hook is invoked by git-am(1). It takes no parameter, and is invoked after the patch is applied, but before a commit is made.

If it exits with non-zero status, then the working tree will not be committed after applying the patch.

It can be used to inspect the current working tree and refuse to make a commit if it does not pass certain tests.

The default pre-applypatch hook, when enabled, runs the pre-commit hook, if the latter is enabled.

post-applypatch

This hook is invoked by git-am(1). It takes no parameter, and is invoked after the patch is applied and a commit is made.

This hook is meant primarily for notification, and cannot affect the outcome of git am.

pre-commit

This hook is invoked by git-commit(1), and can be bypassed with the –no-verify option. It takes no parameters, and is invoked before obtaining the proposed commit log message and making a commit. Exiting with a non-zero status from this script causes the git commit command to abort before creating a commit.

The default pre-commit hook, when enabled, catches introduction of lines with trailing whitespaces and aborts the commit when such a line is found.

All the git commit hooks are invoked with the environment variable GIT_EDITOR=: if the command will not bring up an editor to modify the commit message.

The default pre-commit hook, when enabled—and with the hooks.allownonascii config option unset or set to false—prevents the use of non-ASCII filenames.

pre-merge-commit

This hook is invoked by git-merge(1), and can be bypassed with the –no-verify option. It takes no parameters, and is invoked after the merge has been carried out successfully and before obtaining the proposed commit log message to make a commit. Exiting with a non-zero status from this script causes the git merge command to abort before creating a commit.

The default pre-merge-commit hook, when enabled, runs the pre-commit hook, if the latter is enabled.

This hook is invoked with the environment variable GIT_EDITOR=: if the command will not bring up an editor to modify the commit message.

If the merge cannot be carried out automatically, the conflicts need to be resolved and the result committed separately (see git-merge(1)). At that point, this hook will not be executed, but the pre-commit hook will, if it is enabled.

prepare-commit-msg

This hook is invoked by git-commit(1) right after preparing the default log message, and before the editor is started.

It takes one to three parameters. The first is the name of the file that contains the commit log message. The second is the source of the commit message, and can be: message (if a -m or -F option was given); template (if a -t option was given or the configuration option commit.template is set); merge (if the commit is a merge or a .git/MERGE_MSG file exists); squash (if a .git/SQUASH_MSG file exists); or commit, followed by a commit object name (if a -c, -C or –amend option was given).

If the exit status is non-zero, git commit will abort.

The purpose of the hook is to edit the message file in place, and it is not suppressed by the –no-verify option. A non-zero exit means a failure of the hook and aborts the commit. It should not be used as a replacement for the pre-commit hook.

The sample prepare-commit-msg hook that comes with Git removes the help message found in the commented portion of the commit template.

commit-msg

This hook is invoked by git-commit(1) and git-merge(1), and can be bypassed with the –no-verify option. It takes a single parameter, the name of the file that holds the proposed commit log message. Exiting with a non-zero status causes the command to abort.

The default commit-msg hook, when enabled, detects duplicate Signed-off-by trailers, and aborts the commit if one is found.

post-commit

This hook is invoked by git-commit(1). It takes no parameters, and is invoked after a commit is made.

This hook is meant primarily for notification, and cannot affect the outcome of git commit.

pre-rebase

This hook is called by git-rebase(1) and can be used to prevent a branch from getting rebased. The hook may be called with one or two parameters. The first parameter is the upstream from which the series was forked. The second parameter is the branch being rebased, and is not set when rebasing the current branch.

post-checkout

This hook is invoked when a git-checkout(1) or git-switch(1) is run after having updated the worktree. The hook is given three parameters: the ref of the previous HEAD, the ref of the new HEAD (which may or may not have changed), and a flag indicating whether the checkout was a branch checkout (changing branches, flag=1) or a file checkout (retrieving a file from the index, flag=0). This hook cannot affect the outcome of git switch or git checkout, other than that the hook’s exit status becomes the exit status of these two commands.

It is also run after git-clone(1), unless the –no-checkout (-n) option is used. The first parameter given to the hook is the null-ref, the second the ref of the new HEAD and the flag is always 1. Likewise for git worktree add unless –no-checkout is used.

This hook can be used to perform repository validity checks, auto-display differences from the previous HEAD if different, or set working dir metadata properties.

post-merge

This hook is invoked by git-merge(1), which happens when a git pull is done on a local repository. The hook takes a single parameter, a status flag specifying whether or not the merge being done was a squash merge. This hook cannot affect the outcome of git merge and is not executed, if the merge failed due to conflicts.

This hook can be used in conjunction with a corresponding pre-commit hook to save and restore any form of metadata associated with the working tree (e.g.: permissions/ownership, ACLS, etc). See contrib/hooks/setgitperms.perl for an example of how to do this.

pre-push

This hook is called by git-push(1) and can be used to prevent a push from taking place. The hook is called with two parameters which provide the name and location of the destination remote, if a named remote is not being used both values will be the same.

Information about what is to be pushed is provided on the hook’s standard input with lines of the form:

SP SP SP LF

For instance, if the command git push origin master:foreign were run the hook would receive a line like the following:

refs/heads/master 67890 refs/heads/foreign 12345

although the full object name would be supplied. If the foreign ref does not yet exist the <remote object name> will be the all-zeroes object name. If a ref is to be deleted, the <local ref> will be supplied as (delete) and the <local object name> will be the all-zeroes object name. If the local commit was specified by something other than a name which could be expanded (such as HEAD~, or an object name) it will be supplied as it was originally given.

If this hook exits with a non-zero status, git push will abort without pushing anything. Information about why the push is rejected may be sent to the user by writing to standard error.

pre-receive

This hook is invoked by git-receive-pack(1) when it reacts to git push and updates reference(s) in its repository. Just before starting to update refs on the remote repository, the pre-receive hook is invoked. Its exit status determines the success or failure of the update.

This hook executes once for the receive operation. It takes no arguments, but for each ref to be updated it receives on standard input a line of the format:

SP SP LF

where <old-value> is the old object name stored in the ref, <new-value> is the new object name to be stored in the ref and <ref-name> is the full name of the ref. When creating a new ref, <old-value> is the all-zeroes object name.

If the hook exits with non-zero status, none of the refs will be updated. If the hook exits with zero, updating of individual refs can still be prevented by the update hook.

Both standard output and standard error output are forwarded to git send-pack on the other end, so you can simply echo messages for the user.

The number of push options given on the command line of git push –push-option=… can be read from the environment variable GIT_PUSH_OPTION_COUNT, and the options themselves are found in GIT_PUSH_OPTION_0, GIT_PUSH_OPTION_1,… If it is negotiated to not use the push options phase, the environment variables will not be set. If the client selects to use push options, but doesn’t transmit any, the count variable will be set to zero, GIT_PUSH_OPTION_COUNT=0.

See the section on “Quarantine Environment” in git-receive-pack(1) for some caveats.

update

This hook is invoked by git-receive-pack(1) when it reacts to git push and updates reference(s) in its repository. Just before updating the ref on the remote repository, the update hook is invoked. Its exit status determines the success or failure of the ref update.

The hook executes once for each ref to be updated, and takes three parameters:

·
the name of the ref being updated,

·
the old object name stored in the ref,

·
and the new object name to be stored in the ref.

A zero exit from the update hook allows the ref to be updated. Exiting with a non-zero status prevents git receive-pack from updating that ref.

This hook can be used to prevent forced update on certain refs by making sure that the object name is a commit object that is a descendant of the commit object named by the old object name. That is, to enforce a “fast-forward only” policy.

It could also be used to log the old..new status. However, it does not know the entire set of branches, so it would end up firing one e-mail per ref when used naively, though. The post-receive hook is more suited to that.

In an environment that restricts the users access only to git commands over the wire, this hook can be used to implement access control without relying on filesystem ownership and group membership. See git-shell(1) for how you might use the login shell to restrict the user’s access to only git commands.

Both standard output and standard error output are forwarded to git send-pack on the other end, so you can simply echo messages for the user.

The default update hook, when enabled—and with hooks.allowunannotated config option unset or set to false—prevents unannotated tags from being pushed.

proc-receive

This hook is invoked by git-receive-pack(1). If the server has set the multi-valued config variable receive.procReceiveRefs, and the commands sent to receive-pack have matching reference names, these commands will be executed by this hook, instead of by the internal execute_commands() function. This hook is responsible for updating the relevant references and reporting the results back to receive-pack.

This hook executes once for the receive operation. It takes no arguments, but uses a pkt-line format protocol to communicate with receive-pack to read commands, push-options and send results. In the following example for the protocol, the letter S stands for receive-pack and the letter H stands for this hook.

Version and features negotiation.

S: PKT-LINE(version=1push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1push-options...)
H: flush-pkt

Send commands from server to the hook.

S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the push-options feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt

Receive results from the hook.

# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let receive-pack execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference.  The alternate reference name
# and other status can be given in option directives.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt

Each command for the proc-receive hook may point to a pseudo-reference and always has a zero-old as its old-oid, while the proc-receive hook may update an alternate reference and the alternate reference may exist already with a non-zero old-oid. For this case, this hook will use “option” directives to report extended attributes for the reference given by the leading “ok” directive.

The report of the commands of this hook should have the same order as the input. The exit status of the proc-receive hook only determines the success or failure of the group of commands sent to it, unless atomic push is in use.

post-receive

This hook is invoked by git-receive-pack(1) when it reacts to git push and updates reference(s) in its repository. It executes on the remote repository once after all the refs have been updated.

This hook executes once for the receive operation. It takes no arguments, but gets the same information as the pre-receive hook does on its standard input.

This hook does not affect the outcome of git receive-pack, as it is called after the real work is done.

This supersedes the post-update hook in that it gets both old and new values of all the refs in addition to their names.

Both standard output and standard error output are forwarded to git send-pack on the other end, so you can simply echo messages for the user.

The default post-receive hook is empty, but there is a sample script post-receive-email provided in the contrib/hooks directory in Git distribution, which implements sending commit emails.

post-update

It takes a variable number of parameters, each of which is the name of ref that was actually updated.

This hook is meant primarily for notification, and cannot affect the outcome of git receive-pack.

The post-update hook can tell what are the heads that were pushed, but it does not know what their original and updated values are, so it is a poor place to do log old..new. The post-receive hook does get both original and updated values of the refs. You might consider it instead if you need them.

When enabled, the default post-update hook runs git update-server-info to keep the information used by dumb transports (e.g., HTTP) up to date. If you are publishing a Git repository that is accessible via HTTP, you should probably enable this hook.

Both standard output and standard error output are forwarded to git send-pack on the other end, so you can simply echo messages for the user.

reference-transaction

This hook is invoked by any Git command that performs reference updates. It executes whenever a reference transaction is prepared, committed or aborted and may thus get called multiple times. The hook does not cover symbolic references (but that may change in the future).

The hook takes exactly one argument, which is the current state the given reference transaction is in:

·
“prepared”: All reference updates have been queued to the transaction and references were locked on disk.

·
“committed”: The reference transaction was committed and all references now have their respective new value.

·
“aborted”: The reference transaction was aborted, no changes were performed and the locks have been released.

For each reference update that was added to the transaction, the hook receives on standard input a line of the format:

SP SP LF

where <old-value> is the old object name passed into the reference transaction, <new-value> is the new object name to be stored in the ref and <ref-name> is the full name of the ref. When force updating the reference regardless of its current value or when the reference is to be created anew, <old-value> is the all-zeroes object name. To distinguish these cases, you can inspect the current value of <ref-name> via git rev-parse.

The exit status of the hook is ignored for any state except for the “prepared” state. In the “prepared” state, a non-zero exit status will cause the transaction to be aborted. The hook will not be called with “aborted” state in that case.

push-to-checkout

This hook is invoked by git-receive-pack(1) when it reacts to git push and updates reference(s) in its repository, and when the push tries to update the branch that is currently checked out and the receive.denyCurrentBranch configuration variable is set to updateInstead. Such a push by default is refused if the working tree and the index of the remote repository has any difference from the currently checked out commit; when both the working tree and the index match the current commit, they are updated to match the newly pushed tip of the branch. This hook is to be used to override the default behaviour.

The hook receives the commit with which the tip of the current branch is going to be updated. It can exit with a non-zero status to refuse the push (when it does so, it must not modify the index or the working tree). Or it can make any necessary changes to the working tree and to the index to bring them to the desired state when the tip of the current branch is updated to the new commit, and exit with a zero status.

For example, the hook can simply run git read-tree -u -m HEAD “$1” in order to emulate git fetch that is run in the reverse direction with git push, as the two-tree form of git read-tree -u -m is essentially the same as git switch or git checkout that switches branches while keeping the local changes in the working tree that do not interfere with the difference between the branches.

pre-auto-gc

This hook is invoked by git gc –auto (see git-gc(1)). It takes no parameter, and exiting with non-zero status from this script causes the git gc –auto to abort.

post-rewrite

This hook is invoked by commands that rewrite commits (git-commit(1) when called with –amend and git-rebase(1); however, full-history (re)writing tools like git-fast-import(1) or git-filter-repo[1] typically do not call it!). Its first argument denotes the command it was invoked by: currently one of amend or rebase. Further command-dependent arguments may be passed in the future.

The hook receives a list of the rewritten commits on stdin, in the format

SP [ SP ] LF

The extra-info is again command-dependent. If it is empty, the preceding SP is also omitted. Currently, no commands pass any extra-info.

The hook always runs after the automatic note copying (see “notes.rewrite.<command>” in git-config(1)) has happened, and thus has access to these notes.

The following command-specific comments apply:

rebase

For the squash and fixup operation, all commits that were squashed are listed as being rewritten to the squashed commit. This means that there will be several lines sharing the same new-object-name.
The commits are guaranteed to be listed in the order that they were processed by rebase.

sendemail-validate

This hook is invoked by git-send-email(1).

It takes these command line arguments. They are, 1. the name of the file which holds the contents of the email to be sent. 2. The name of the file which holds the SMTP headers of the email.

The SMTP headers are passed in the exact same way as they are passed to the user’s Mail Transport Agent (MTA). In effect, the email given to the user’s MTA, is the contents of $2 followed by the contents of $1.

An example of a few common headers is shown below. Take notice of the capitalization and multi-line tab structure.

From: Example [email protected] To: [email protected] Cc: [email protected], A [email protected], One [email protected], [email protected] Subject: PATCH-STRING

Exiting with a non-zero status causes git send-email to abort before sending any e-mails.

The following environment variables are set when executing the hook.

GIT_SENDEMAIL_FILE_COUNTER

A 1-based counter incremented by one for every file holding an e-mail to be sent (excluding any FIFOs). This counter does not follow the patch series counter scheme. It will always start at 1 and will end at GIT_SENDEMAIL_FILE_TOTAL.

GIT_SENDEMAIL_FILE_TOTAL

The total number of files that will be sent (excluding any FIFOs). This counter does not follow the patch series counter scheme. It will always be equal to the number of files being sent, whether there is a cover letter or not.

These variables may for instance be used to validate patch series.

The sample sendemail-validate hook that comes with Git checks that all sent patches (excluding the cover letter) can be applied on top of the upstream repository default branch without conflicts. Some placeholders are left for additional validation steps to be performed after all patches of a given series have been applied.

fsmonitor-watchman

This hook is invoked when the configuration option core.fsmonitor is set to .git/hooks/fsmonitor-watchman or .git/hooks/fsmonitor-watchmanv2 depending on the version of the hook to use.

Version 1 takes two arguments, a version (1) and the time in elapsed nanoseconds since midnight, January 1, 1970.

Version 2 takes two arguments, a version (2) and a token that is used for identifying changes since the token. For watchman this would be a clock id. This version must output to stdout the new token followed by a NUL before the list of files.

The hook should output to stdout the list of all files in the working directory that may have changed since the requested time. The logic should be inclusive so that it does not miss any potential changes. The paths should be relative to the root of the working directory and be separated by a single NUL.

It is OK to include files which have not actually changed. All changes including newly-created and deleted files should be included. When files are renamed, both the old and the new name should be included.

Git will limit what files it checks for changes as well as which directories are checked for untracked files based on the path names given.

An optimized way to tell git “all files have changed” is to return the filename /.

The exit status determines whether git will use the data from the hook to limit its search. On error, it will fall back to verifying all files and folders.

p4-changelist

This hook is invoked by git-p4 submit.

The p4-changelist hook is executed after the changelist message has been edited by the user. It can be bypassed with the –no-verify option. It takes a single parameter, the name of the file that holds the proposed changelist text. Exiting with a non-zero status causes the command to abort.

The hook is allowed to edit the changelist file and can be used to normalize the text into some project standard format. It can also be used to refuse the Submit after inspect the message file.

Run git-p4 submit –help for details.

p4-prepare-changelist

This hook is invoked by git-p4 submit.

The p4-prepare-changelist hook is executed right after preparing the default changelist message and before the editor is started. It takes one parameter, the name of the file that contains the changelist text. Exiting with a non-zero status from the script will abort the process.

The purpose of the hook is to edit the message file in place, and it is not suppressed by the –no-verify option. This hook is called even if –prepare-p4-only is set.

Run git-p4 submit –help for details.

p4-post-changelist

This hook is invoked by git-p4 submit.

The p4-post-changelist hook is invoked after the submit has successfully occurred in P4. It takes no parameters and is meant primarily for notification and cannot affect the outcome of the git p4 submit action.

Run git-p4 submit –help for details.

p4-pre-submit

This hook is invoked by git-p4 submit. It takes no parameters and nothing from standard input. Exiting with non-zero status from this script prevent git-p4 submit from launching. It can be bypassed with the –no-verify command line option. Run git-p4 submit –help for details.

post-index-change

This hook is invoked when the index is written in read-cache.c do_write_locked_index.

The first parameter passed to the hook is the indicator for the working directory being updated. “1” meaning working directory was updated or “0” when the working directory was not updated.

The second parameter passed to the hook is the indicator for whether or not the index was updated and the skip-worktree bit could have changed. “1” meaning skip-worktree bits could have been updated and “0” meaning they were not.

Only one parameter should be set to “1” when the hook runs. The hook running passing “1”, “1” should not be possible.

GIT

Part of the git(1) suite

NOTES

git-filter-repo

https://github.com/newren/git-filter-repo

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

43 - Linux cli command proc_pid

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid and provides detailed information about the command proc_pid, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid.

NAME 🖥️ proc_pid 🖥️

process information

DESCRIPTION

/proc/pid/
There is a numerical subdirectory for each running process; the subdirectory is named by the process ID. Each */proc/*pid subdirectory contains the pseudo-files and directories described below.

The files inside each */proc/*pid directory are normally owned by the effective user and effective group ID of the process. However, as a security measure, the ownership is made root:root if the process’s “dumpable” attribute is set to a value other than 1.

Before Linux 4.11, root:root meant the “global” root user ID and group ID (i.e., UID 0 and GID 0 in the initial user namespace). Since Linux 4.11, if the process is in a noninitial user namespace that has a valid mapping for user (group) ID 0 inside the namespace, then the user (group) ownership of the files under */proc/*pid is instead made the same as the root user (group) ID of the namespace. This means that inside a container, things work as expected for the container “root” user.

The process’s “dumpable” attribute may change for the following reasons:

The attribute was explicitly set via the prctl(2) PR_SET_DUMPABLE operation.
The attribute was reset to the value in the file /proc/sys/fs/suid_dumpable (described below), for the reasons described in prctl(2).

Resetting the “dumpable” attribute to 1 reverts the ownership of the /proc/pid/* files to the process’s effective UID and GID. Note, however, that if the effective UID or GID is subsequently modified, then the “dumpable” attribute may be reset, as described in prctl(2). Therefore, it may be desirable to reset the “dumpable” attribute after making any desired changes to the process’s effective UID or GID.

/proc/self/
This directory refers to the process accessing the /proc filesystem, and is identical to the /proc directory named by the process ID of the same process.

44 - Linux cli command deb-old

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command deb-old and provides detailed information about the command deb-old, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the deb-old.

NAME 🖥️ deb-old 🖥️

old - old style Debian binary package format

SYNOPSIS

filename**.deb**

DESCRIPTION

The .deb format is the Debian binary package file format. This manual page describes the old format, used before Debian 0.93. Please see deb (5) for details of the new format.

FORMAT

The file is two lines of format information as ASCII text, followed by two concatenated gzipped ustar files.

The first line is the format version number padded to 8 digits, and is 0.939000 for all old-format archives.

The second line is a decimal string (without leading zeroes) giving the length of the first gzipped tarfile.

Each of these lines is terminated with a single newline character.

The first tarfile contains the control information, as a series of ordinary files. The file control must be present, as it contains the core control information.

In some very old archives, the files in the control tarfile may optionally be in a DEBIAN subdirectory. In that case, the DEBIAN subdirectory will be in the control tarfile too, and the control tarfile will have only files in that directory. Optionally the control tarfile may contain an entry for ‘.’, that is, the current directory.

The second gzipped tarfile is the filesystem archive, containing pathnames relative to the root directory of the system to be installed on. The pathnames do not have leading slashes.

45 - Linux cli command proc_profile

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_profile and provides detailed information about the command proc_profile, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_profile.

NAME 🖥️ proc_profile 🖥️

kernel profiling

DESCRIPTION

/proc/profile (since Linux 2.4)
This file is present only if the kernel was booted with the profile=1 command-line option. It exposes kernel profiling information in a binary format for use by readprofile(1). Writing (e.g., an empty string) to this file resets the profiling counters; on some architectures, writing a binary integer “profiling multiplier” of size sizeof(int) sets the profiling interrupt frequency.

46 - Linux cli command proc_pid_cpuset

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_cpuset and provides detailed information about the command proc_pid_cpuset, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_cpuset.

NAME 🖥️ proc_pid_cpuset 🖥️

CPU affinity sets

DESCRIPTION

/proc/pid/cpuset (since Linux 2.6.12)
See cpuset(7).

47 - Linux cli command proc_pid_mem

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_mem and provides detailed information about the command proc_pid_mem, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_mem.

NAME 🖥️ proc_pid_mem 🖥️

memory

DESCRIPTION

/proc/pid/mem
This file can be used to access the pages of a process’s memory through open(2), read(2), and lseek(2).

Permission to access this file is governed by a ptrace access mode PTRACE_MODE_ATTACH_FSCREDS check; see ptrace(2).

48 - Linux cli command nss

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command nss and provides detailed information about the command nss, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the nss.

NAME 🖥️ nss 🖥️

Name Service Switch configuration file

DESCRIPTION

Each call to a function which retrieves data from a system database like the password or group database is handled by the Name Service Switch implementation in the GNU C library. The various services provided are implemented by independent modules, each of which naturally varies widely from the other.

The default implementations coming with the GNU C library are by default conservative and do not use unsafe data. This might be very costly in some situations, especially when the databases are large. Some modules allow the system administrator to request taking shortcuts if these are known to be safe. It is then the system administrator’s responsibility to ensure the assumption is correct.

There are other modules where the implementation changed over time. If an implementation used to sacrifice speed for memory consumption, it might create problems if the preference is switched.

The /etc/default/nss file contains a number of variable assignments. Each variable controls the behavior of one or more NSS modules. White spaces are ignored. Lines beginning with ‘#’ are treated as comments.

The variables currently recognized are:

NETID_AUTHORITATIVE = TRUE|FALSE
If set to TRUE, the NIS backend for the initgroups(3) function will accept the information from the netid.byname NIS map as authoritative. This can speed up the function significantly if the group.byname map is large. The content of the netid.byname map is used as is. The system administrator has to make sure it is correctly generated.

SERVICES_AUTHORITATIVE = TRUE|FALSE
If set to TRUE, the NIS backend for the getservbyname(3) and getservbyname_r(3) functions will assume that the services.byservicename NIS map exists and is authoritative, particularly that it contains both keys with /proto and without /proto for both primary service names and service aliases. The system administrator has to make sure it is correctly generated.

SETENT_BATCH_READ = TRUE|FALSE
If set to TRUE, the NIS backend for the setpwent(3) and setgrent(3) functions will read the entire database at once and then hand out the requests one by one from memory with every corresponding getpwent(3) or getgrent(3) call respectively. Otherwise, each getpwent(3) or getgrent(3) call might result in a network communication with the server to get the next entry.

FILES

/etc/default/nss

EXAMPLES

The default configuration corresponds to the following configuration file:

NETID_AUTHORITATIVE=FALSE
SERVICES_AUTHORITATIVE=FALSE
SETENT_BATCH_READ=FALSE

49 - Linux cli command openvpn-examples

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command openvpn-examples and provides detailed information about the command openvpn-examples, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the openvpn-examples.

NAME 🖥️ openvpn-examples 🖥️

Secure IP tunnel daemon

INTRODUCTION

This man page gives a few simple examples to create OpenVPN setups and configuration files.

SMALL OPENVPN SETUP WITH PEER-FINGERPRINT

This section consists of instructions how to build a small OpenVPN setup with the peer-fingerprint option. This has the advantage of being easy to setup and should be suitable for most small lab and home setups without the need for a PKI. For bigger scale setup setting up a PKI (e.g. via easy-rsa) is still recommended.

Both server and client configuration can be further modified to customise the setup.

Server setup

Install openvpn
Compile from source-code (see INSTALL file) or install via a distribution (apt/yum/ports) or via installer (Windows).
Generate a self-signed certificate for the server:
openssl req -x509 -newkey ec:<(openssl ecparam -name secp384r1) -keyout server.key -out server.crt -nodes -sha256 -days 3650 -subj ‘/CN=server’
Generate SHA256 fingerprint of the server certificate
Use the OpenSSL command line utility to view the fingerprint of just created certificate:
openssl x509 -fingerprint -sha256 -in server.crt -noout
This output something similar to:
SHA256 Fingerprint=00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff:00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff
Write a server configuration (server.conf):
The server certificate we created in step 1
cert server.crt
key server.key

dh none
dev tun

# Listen on IPv6+IPv4 simultaneously
proto udp6

# The ip address the server will distribute
server 10.8.0.0 255.255.255.0
server-ipv6 fd00:6f76:706e::/64

# A tun-mtu of 1400 avoids problems of too big packets after VPN encapsulation
tun-mtu 1400

# The fingerprints of your clients. After adding/removing one here restart the
# server
<peer-fingerprint>
</peer-fingerprint>

# Notify clients when you restart the server to reconnect quickly
explicit-exit-notify 1

# Ping every 60s, restart if no data received for 5 minutes
keepalive 60 300
Add at least one client as described in the client section.
**Start the server.**  
> -   On systemd based distributions move *server.crt*, *server.key* and *server.conf* to **/etc/openvpn/server** and start it via systemctl
>
>     > sudo mv server.conf server.key server.crt /etc/openvpn/server
>     >
>     >     sudo systemctl start openvpn-server@server

Adding a client

Install OpenVPN
Generate a self-signed certificate for the client. In this example the client name is alice. Each client should have a unique name. Replace alice with a different name for each client.
openssl req -x509 -newkey ec:<(openssl ecparam -name secp384r1) -nodes -sha256 -days 3650 -subj ‘/CN=alice’
This generate a certificate and a key for the client. The output of the command will look something like this:
—–BEGIN PRIVATE KEY—– [base64 content] —–END PRIVATE KEY—– —– —–BEGIN CERTIFICATE—– [base 64 content] —–END CERTIFICATE—–
Create a new client configuration file. In this example we will name the file alice.ovpn:
The name of your server to connect to
remote yourserver.example.net
client
# use a random source port instead the fixed 1194
nobind

# Uncomment the following line if you want to route
# all traffic via the VPN
# redirect-gateway def1 ipv6

# To set a DNS server
# dhcp-option DNS 192.168.234.1

<key>
-----BEGIN PRIVATE KEY-----
[Insert here the key created in step 2]
-----END PRIVATE KEY-----
</key>
<cert>
-----BEGIN CERTIFICATE-----
[Insert here the certificate created in step 2]
-----END CERTIFICATE-----
</cert>

# This is the fingerprint of the server that we trust. We generated this fingerprint
# in step 2 of the server setup
peer-fingerprint 00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff:00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff

# The tun-mtu of the client should match the server MTU
tun-mtu 1400
dev tun
Generate the fingerprint of the client certificate. For that we will let OpenSSL read the client configuration file as the x509 command will ignore anything that is not between the begin and end markers of the certificate:
openssl x509 -fingerprint -sha256 -noout -in alice.ovpn
This will again output something like
SHA256 Fingerprint=ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00:ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00
Edit the server.conf configuration file and add this new client fingerprint as additional line between <peer-fingerprint> and </peer-fingerprint>
After adding two clients the part of configuration would look like this:
ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00:ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00 99:88:77:66:55:44:33:22:11:00:ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00:88:77:66:55:44:33
(optional) if the client is an older client that does not support the peer-fingerprint (e.g. OpenVPN 2.5 and older, OpenVPN Connect 3.3 and older), the client config alice.ovpn can be modified to still work with these clients.
Remove the line starting with peer-fingerprint. Then add a new <ca> section at the end of the configuration file with the contents of the server.crt created in step 2 of the server setup. The end of alice.ovpn file should like:
[…] # Beginning of the file skipped
# The tun-mtu of the client should match the server MTU
tun-mtu 1400
dev tun

<ca>
[contents of the server.crt]
</ca>
Note that we put the <ca> section after the <cert> section to make the fingerprint generation from step 4 still work since it will only use the first certificate it finds.
Import the file into the OpenVPN client or just use the openvpn alice.ovpn to start the VPN.

EXAMPLES

Prior to running these examples, you should have OpenVPN installed on two machines with network connectivity between them. If you have not yet installed OpenVPN, consult the INSTALL file included in the OpenVPN distribution.

Firewall Setup:

If firewalls exist between the two machines, they should be set to forward the port OpenVPN is configured to use, in both directions. The default for OpenVPN is 1194/udp. If you do not have control over the firewalls between the two machines, you may still be able to use OpenVPN by adding –ping 15 to each of the openvpn commands used below in the examples (this will cause each peer to send out a UDP ping to its remote peer once every 15 seconds which will cause many stateful firewalls to forward packets in both directions without an explicit firewall rule).

Please see your operating system guides for how to configure the firewall on your systems.

VPN Address Setup:

For purposes of our example, our two machines will be called bob.example.com and alice.example.com. If you are constructing a VPN over the internet, then replace bob.example.com and alice.example.com with the internet hostname or IP address that each machine will use to contact the other over the internet.

Now we will choose the tunnel endpoints. Tunnel endpoints are private IP addresses that only have meaning in the context of the VPN. Each machine will use the tunnel endpoint of the other machine to access it over the VPN. In our example, the tunnel endpoint for bob.example.com will be 10.4.0.1 and for alice.example.com, 10.4.0.2.

Once the VPN is established, you have essentially created a secure alternate path between the two hosts which is addressed by using the tunnel endpoints. You can control which network traffic passes between the hosts (a) over the VPN or (b) independently of the VPN, by choosing whether to use (a) the VPN endpoint address or (b) the public internet address, to access the remote host. For example if you are on bob.example.com and you wish to connect to alice.example.com via ssh without using the VPN (since ssh has its own built-in security) you would use the command ssh alice.example.com. However in the same scenario, you could also use the command telnet 10.4.0.2 to create a telnet session with alice.example.com over the VPN, that would use the VPN to secure the session rather than ssh.

You can use any address you wish for the tunnel endpoints but make sure that they are private addresses (such as those that begin with 10 or 192.168) and that they are not part of any existing subnet on the networks of either peer, unless you are bridging. If you use an address that is part of your local subnet for either of the tunnel endpoints, you will get a weird feedback loop.

Example 1: A simple tunnel without security (not recommended)

On bob:

openvpn –remote alice.example.com –dev tun1
–ifconfig 10.4.0.1 10.4.0.2 –verb 9

On alice:

openvpn –remote bob.example.com –dev tun1
–ifconfig 10.4.0.2 10.4.0.1 –verb 9

Now verify the tunnel is working by pinging across the tunnel.

On bob:

ping 10.4.0.2

On alice:

ping 10.4.0.1

The –verb 9 option will produce verbose output, similar to the tcpdump(8) program. Omit the –verb 9 option to have OpenVPN run quietly.

Example 2: A tunnel with self-signed certificates and fingerprint

First build a self-signed certificate on bob and display its fingerprint.

openssl req -x509 -newkey ec:<(openssl ecparam -name secp384r1) -keyout bob.pem -out bob.pem -nodes -sha256 -days 3650 -subj ‘/CN=bob’ openssl x509 -noout -sha256 -fingerprint -in bob.pem

and the same on alice:

openssl req -x509 -newkey ec:<(openssl ecparam -name secp384r1) -keyout alice.pem -out alice.pem -nodes -sha256 -days 3650 -subj ‘/CN=alice’ openssl x509 -noout -sha256 -fingerprint -in alice.pem

These commands will build a text file called bob.pem or alice.pem (in ascii format) that contain both self-signed certificate and key and show the fingerprint of the certificates. Transfer the fingerprints over a secure medium such as by using the scp(1) or ssh(1) program.

On bob:

openvpn –ifconfig 10.4.0.1 10.4.0.2 –tls-server –dev tun –dh none
–cert bob.pem –key bob.pem –cipher AES-256-GCM
–peer-fingerprint “$fingerprint_of_alices_cert”

On alice:

openvpn –remote bob.example.com –tls-client –dev tun1
–ifconfig 10.4.0.2 10.4.0.1 –cipher AES-256-GCM
–cert alice.pem –key alice.pem
–peer-fingerprint “$fingerprint_of_bobs_cert”

Now verify the tunnel is working by pinging across the tunnel.

On bob:

ping 10.4.0.2

On alice:

ping 10.4.0.1

Note: This example use a elliptic curve (secp384), which allows –dh to be set to none.

Example 3: A tunnel with full PKI and TLS-based security

For this test, we will designate bob as the TLS client and alice as the TLS server.

Note:
The client or server designation only has meaning for the TLS subsystem. It has no bearing on OpenVPN’s peer-to-peer, UDP-based communication model.*

First, build a separate certificate/key pair for both bob and alice (see above where –cert is discussed for more info). Then construct Diffie Hellman parameters (see above where –dh is discussed for more info). You can also use the included test files client.crt, client.key, server.crt, server.key and ca.crt. The .crt files are certificates/public-keys, the .key files are private keys, and ca.crt is a certification authority who has signed both client.crt and server.crt. For Diffie Hellman parameters you can use the included file dh2048.pem.

WARNING:
All client, server, and certificate authority certificates and keys included in the OpenVPN distribution are totally insecure and should be used for testing only.

On bob:

openvpn –remote alice.example.com –dev tun1
–ifconfig 10.4.0.1 10.4.0.2
–tls-client –ca ca.crt
–cert client.crt –key client.key
–reneg-sec 60 –verb 5

On alice:

openvpn –remote bob.example.com –dev tun1
–ifconfig 10.4.0.2 10.4.0.1
–tls-server –dh dh1024.pem –ca ca.crt
–cert server.crt –key server.key
–reneg-sec 60 –verb 5

Now verify the tunnel is working by pinging across the tunnel.

On bob:

ping 10.4.0.2

On alice:

ping 10.4.0.1

Notice the –reneg-sec 60 option we used above. That tells OpenVPN to renegotiate the data channel keys every minute. Since we used –verb 5 above, you will see status information on each new key negotiation.

For production operations, a key renegotiation interval of 60 seconds is probably too frequent. Omit the –reneg-sec 60 option to use OpenVPN’s default key renegotiation interval of one hour.

Routing:

Assuming you can ping across the tunnel, the next step is to route a real subnet over the secure tunnel. Suppose that bob and alice have two network interfaces each, one connected to the internet, and the other to a private network. Our goal is to securely connect both private networks. We will assume that bob’s private subnet is 10.0.0.0/24 and alice’s is 10.0.1.0/24.

First, ensure that IP forwarding is enabled on both peers. On Linux, enable routing:

echo 1 > /proc/sys/net/ipv4/ip_forward

This setting is not persistent. Please see your operating systems documentation how to properly configure IP forwarding, which is also persistent through system boots.

If your system is configured with a firewall. Please see your operating systems guide on how to configure the firewall. You typically want to allow traffic coming from and going to the tun/tap adapter OpenVPN is configured to use.

On bob:

route add -net 10.0.1.0 netmask 255.255.255.0 gw 10.4.0.2

On alice:

route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.4.0.1

Now any machine on the 10.0.0.0/24 subnet can access any machine on the 10.0.1.0/24 subnet over the secure tunnel (or vice versa).

In a production environment, you could put the route command(s) in a script and execute with the –up option.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

50 - Linux cli command variables

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command variables and provides detailed information about the command variables, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the variables.

NAME 🖥️ variables 🖥️

Format of specifying variable names to SNMP tools.

DESCRIPTION

The syntax and semantics of management information in SNMP is given by the definitions of MIB objects, loaded from one or more MIB files (or “MIB modules”). These definitions are not strictly required for the SNMP protocol to operate correctly, but are typically needed by SNMP client applications to display information in a meaningful manner.

The MIB file also serves as a design document when developing an SNMP agent (or sub-agent) that provides this information, and ensures that client and server share a common understanding about what management information represents.

OIDs

MIB objects are specified using Object Identifiers (OIDs), which can take a number of forms. Note that all of the examples in this section refer to the same MIB object.

Numeric OIDs

The fundamental format of an OID is a sequence of integer values (or “subidentifiers”), typically written using dots to separate the individual subidentifiers.

.1.3.6.1.2.1.1.1

This is the format that is used within the SNMP protocol itself, in the packets that are sent over the network.

This form of representing an OID does not require MIB files or MIB object definitions to be available. However it does rely on the client application and/or network administrator knowing what a given numeric OID refers to. As such, it is not a particularly helpful representation to anyone just starting out with SNMP.

This format can be obtained by giving the command-line option -On to most Net-SNMP commands.

Full OID path

A similar (but somewhat more informative) format uses the same dotted list representation, but with the numeric subidentifiers replaced by names, taken from the relevant MIB file(s).

.iso.org.dod.internet.mgmt.mib-2.system.sysDescr

This uniquely identifies a particular MIB object (as with the numeric OID), but the list of names should hopefully give some indication as to what information this object represents. However it does rely on the relevant MIB files being available (as do all formats other than the purely numeric OID). Such OIDs also tend to be fairly long!

This format can be obtained by giving the command-line option -Of to most Net-SNMP commands.

A variant of this (typically used when writing OIDs in descriptive text, rather than running programs), is to combine the name and numeric subidentifier:

.iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1) .sysDescr(1)

Module-qualified OIDs

An alternative way to (more-or-less) uniquely specify an OID, is to give the name of the MIB object, together with the MIB module where it is defined.

SNMPv2-MIB::sysDescr

MIB object names are unique within a given module, so as long as there are not two MIB modules with the same name (which is unusual, though not unheard of), this format specifies the desired object in a reasonably compact form. It also makes it relatively easy to find the definition of the MIB object.

This is the default format for displaying OIDs in Net-SNMP applications. It can also be specified explicitly by giving the command-line option -OS to most Net-SNMP commands.

Object name

Possibly the most common form for specifying MIB objects is using the name of the object alone - without the full path or the name of the module that defines it.

sysDescr

This is by far the shortest and most convenient way to refer to a MIB object. However the danger is that if two MIB modules each define a MIB object with the same name (which is perfectly legal in some circumstances), then it’s not necessarily clear which MIB object is actually meant. For day-to-day use, particularly when using standard MIB objects, this is probaby safe. But it’s important to be aware of the potential ambiguities.

This format can be obtained by giving the command-line option -Os to most Net-SNMP commands.

UCD-format

Previous versions of the code (UCD v4.x and earlier) used a simple approach to shortening the way OIDs were specified. If the full path of the OID began with .iso.org.dod.internet.mgmt.mib-2 then this prefix was removed from the OID before displaying it. All other OIDs were displayed in full.

Similarly, if an OID was passed to the UCD library that did not begin with a dot (and wasn’t in the module::name format), then the same prefix was prepended. The example OID from the formats listed above would therefore be given or displayed as

system.sysDescr

The inconsistent handling of OIDs, depending on their location within the OID tree, proved to be more trouble than it was worth, and this format is no longer recommended.

The previous behaviour can be obtained by giving the command-line option -Ou (for displaying output), or -Iu (for interpreting input OIDs without a leading dot) to most Net-SNMP commands.

BUGS

The parser of the MIB files file is not expected to handle bizarre (although correct) interpretations of the ASN.1 notation.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

51 - Linux cli command exim4_sender_local_deny_exceptions

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command exim4_sender_local_deny_exceptions and provides detailed information about the command exim4_sender_local_deny_exceptions, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the exim4_sender_local_deny_exceptions.

NAME 🖥️ exim4_sender_local_deny_exceptions 🖥️

config_files - Files in use by the Debian exim4 packages

SYNOPSIS

DESCRIPTION

This manual page describes the files that are in use by the Debian exim4 packages and which are not part of an exim installation done from source.

/etc/aliases

You should at least set up an alias for postmaster in the /etc/aliases file.

/etc/email-addresses

is used to rewrite the email addresses of users. This is particularly useful for users who use their ISP’s domain for email.

The file should contain lines of the form

user: [email protected]
otheruser: [email protected]

/etc/exim4/local_host_blacklist

In the blacklist, the trick is to read a line break as “or” if it follows a positive item, and as “and” if it follows a negative item.

For example, a /etc/exim4/local_host_blacklist

192.168.10.0/24
!172.16.10.128/26
172.16.10.0/24
10.0.0.0/8

Exim just evaluates left to right (or up-down in the file listing context), so you don’t get the same kind of operator binding as in a programming language.

/etc/exim4/host_local_deny_exceptions

/etc/exim4/local_sender_blacklist

In the blacklist, the trick is to read a line break as “or” if it follows a positive item, and as “and” if it follows a negative item.

For example, a /etc/exim4/local_sender_blacklist

domain1.example
[email protected]
domain2.example
domain3.example

Exim just evaluates left to right (or up-down in the file listing context), so you don’t get the same kind of operator binding as in a programming language.

/etc/exim4/sender_local_deny_exceptions

/etc/exim4/local_sender_callout

/etc/exim4/local_rcpt_callout

/etc/exim4/local_domain_dnsbl_whitelist

/etc/exim4/hubbed_hosts

The file should contain key-value pairs of domain pattern and route data of the form

domain: host-list options
dict.ref.example: mail-1.ref.example:mail-2.ref.example
foo.example: internal.mail.example.com
bar.example: 192.168.183.3

which will cause mail for foo.example to be sent to the host internal.mail.example (IP address derived from A record only), and mail to bar.example to be sent to 192.168.183.3.

See spec.txt chapter 20.3 through 20.7 for a more detailed explanation of host list format and available options.

/etc/exim4/passwd

contains account and password data for SMTP authentication when the local exim is SMTP server and clients authenticate to the local exim.

The file should contain lines of the form

username:crypted-password:clear-password

clear-password is only necessary if you want to offer CRAM-MD5 authentication. If you don’t plan on doing so, the third column can be omitted completely.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim 640.

/etc/exim4/passwd.client

contains account and password data for SMTP authentication when exim is authenticating as a client to some remote server.

The file should contain lines of the form

target.mail.server.example:login-user-name:password

This goes inevitably wrong if the host name of the mail server is a CNAME (a DNS alias), or the reverse lookup does not fit the forward one.

password is your SMTP password in clear text. If you do not know about your SMTP password, you can try using your POP3 password as a first guess.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim 640.

/etc/exim4/exim.crt

/etc/exim4/exim.key

/etc/mailname

The “mail name” of the system. See Debian policy Chapter Customized programs and exim4-base’s README.Debian for further details.

BUGS

Plenty. Please report them through the Debian BTS

This manual page needs a major re-work. If somebody knows better groff than us and has more experience in writing manual pages, any patches would be greatly appreciated.

NOTES

Unresolvable items in host lists

Adding or keeping items in the abovementioned host lists which are not resolvable by DNS has severe consequences.

notresolvable.example.com:rejectme.example.com

Starting the list with the special pattern +ignore_unknown as a safeguard against this behavior is strongly recommended if hostnames are used in hostlists.

AUTHOR

Marc Haber <[email protected]> with help from Ross Boylan.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

52 - Linux cli command org.freedesktop.portable1

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.freedesktop.portable1 and provides detailed information about the command org.freedesktop.portable1, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.freedesktop.portable1.

NAME 🖥️ org.freedesktop.portable1 🖥️

The D-Bus interface of systemd-portabled

INTRODUCTION

systemd-portabled.service(8) is a system service that may be used to attach, detach and inspect portable services. This page describes the D-Bus interface.

THE MANAGER OBJECT

The service exposes the following interfaces on the Manager object on the bus:

node /org/freedesktop/portable1 { interface org.freedesktop.portable1.Manager { methods: GetImage(in s image, out o object); ListImages(out a(ssbtttso) images); GetImageOSRelease(in s image, out a{ss} os_release); GetImageMetadata(in s image, in as matches, out s image, out ay os_release, out a{say} units); GetImageMetadataWithExtensions(in s image, in as extensions, in as matches, in t flags, out s image, out ay os_release, out a{say} extensions, out a{say} units); GetImageState(in s image, out s state); GetImageStateWithExtensions(in s image, in as extensions, in t flags, out s state); AttachImage(in s image, in as matches, in s profile, in b runtime, in s copy_mode, out a(sss) changes); AttachImageWithExtensions(in s image, in as extensions, in as matches, in s profile, in s copy_mode, in t flags, out a(sss) changes); DetachImage(in s image, in b runtime, out a(sss) changes); DetachImageWithExtensions(in s image, in as extensions, in t flags, out a(sss) changes); ReattachImage(in s image, in as matches, in s profile, in b runtime, in s copy_mode, out a(sss) changes_removed, out a(sss) changes_updated); ReattachImageWithExtensions(in s image, in as extensions, in as matches, in s profile, in s copy_mode, in t flags, out a(sss) changes_removed, out a(sss) changes_updated); RemoveImage(in s image); MarkImageReadOnly(in s image, in b read_only); SetImageLimit(in s image, in t limit); SetPoolLimit(in t limit); properties: @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s PoolPath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t PoolUsage = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t PoolLimit = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as Profiles = […, …]; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; };

Methods

GetImage() may be used to get the image object path of the image with the specified name.

ListImages() returns an array of all currently known images. The structures in the array consist of the following fields: image name, type, read-only flag, creation time, modification time, current disk space, usage and image object path.

GetImageOSRelease() retrieves the OS release information of an image. This method returns an array of key value pairs read from the os-release(5) file in the image and is useful to identify the operating system used in a portable service.

GetImageMetadata() retrieves metadata associated with an image. This method returns the image name, the images os-release(5) content in the form of a (streamable) array of bytes, and a list of portable units contained in the image, in the form of a string (unit name) and an array of bytes with the content.

GetImageMetadataWithExtensions() retrieves metadata associated with an image. This method is a superset of GetImageMetadata() with the addition of a list of extensions as input parameter, which were overlaid on top of the main image via AttachImageWithExtensions(). The path of each extension and an array of bytes with the content of the respective extension-release file are returned, one such structure for each extension named in the input arguments.

GetImageState() retrieves the image state as one of the following strings:

·
detached

·
attached

·
attached-runtime

·
enabled

·
enabled-runtime

·
running

·
running-runtime

GetImageStateWithExtensions() is a superset of GetImageState(), with additional support for a list of extensions as input parameters, which is necessary to query the state in case the image was attached in that particular way. The flag parameter is currently unused and reserved for future purposes.

AttachImage() attaches a portable image to the system. This method takes an image path or name, a list of strings that will be used to search for unit files inside the image (partial or complete matches), a string indicating which portable profile to use for the image (see Profiles property for a list of available profiles), a boolean indicating whether to attach the image only for the current boot session, and a string representing the preferred copy mode (whether to copy the image or to just symlink it) with the following possible values:

·
(empty)

·
copy

·
symlink

·
mixed

If an empty string is passed the security profile drop-ins and images will be symlinked while unit files will be copied, copy will copy, symlink will prefer linking if possible (e.g.: a unit has to be copied out of an image), and mixed will prefer linking the resources owned by the OS (e.g.: the portable profile located within the hosts /usr/ tree) but will copy the resources owned by the portable image (e.g.: the unit files and the images). This method returns the list of changes applied to the system (for example, which unit was added and is now available as a system service). Each change is represented as a triplet of strings: the type of change applied, the path on which it was applied, and the source (if any). The type of change applied will be one of the following possible values:

·
copy

·
symlink

·
write

·
mkdir

Note that an image cannot be attached if a unit that it contains is already present on the system. Note that this method returns only after all the listed operations are completed, and due to the I/O involved it might take some time.

In place of the image path a “.v/” versioned directory may be specified, see systemd.v(7) for details.

In place of the directory path a “.v/” versioned directory may be specified, see systemd.v(7) for details.

AttachImageWithExtensions() attaches a portable image to the system. This method is a superset of AttachImage() with the addition of a list of extensions as input parameter, which will be overlaid on top of the main image. When this method is used, detaching must be done by passing the same arguments via the DetachImageWithExtensions() method. For more details on this functionality, see the MountImages= entry on systemd.exec(5) and systemd-sysext(8).

DetachImage() detaches a portable image from the system. This method takes an image path or name, and a boolean indicating whether the image to detach was attached only for the current boot session or persistently. This method returns the list of changes applied to the system (for example, which unit was removed and is no longer available as a system service). Each change is represented as a triplet of strings: the type of change applied, the path on which it was applied, and the source (if any). The type of change applied will be one of the following possible values:

·
unlink

Note that an image cannot be detached if a unit that it contains is running. Note that this method returns only after all the listed operations are completed, and due to the I/O involved it might take some time.

DetachImageWithExtensions() detaches a portable image from the system. This method is a superset of DetachImage() with the addition of a list of extensions as input parameter, which were overlaid on top of the main image via AttachImageWithExtensions().

ReattachImage() combines the effects of the AttachImage() method and the DetachImage() method. The difference is that it is allowed to reattach an image while one or more of its units are running. The reattach operation will fail if no matching image is attached. The input parameters match the AttachImage() method, and the return parameters are the combination of the return parameters of the DetachImage() method (first array, units that were removed) and the AttachImage() method (second array, units that were updated or added).

ReattachImageWithExtensions() reattaches a portable image to the system. This method is a superset of ReattachImage() with the addition of a list of extensions as input parameter, which will be overlaid on top of the main image. For more details on this functionality, see the MountImages= entry on systemd.exec(5) and systemd-sysext(8).

RemoveImage() removes the image with the specified name.

MarkImageReadOnly() toggles the read-only flag of an image.

SetPoolLimit() sets an overall quota limit on the pool of images.

SetImageLimit() sets a per-image quota limit.

The AttachImageWithExtensions(), DetachImageWithExtensions() and ReattachImageWithExtensions() methods take in options as flags instead of booleans to allow for extendability. SD_SYSTEMD_PORTABLE_FORCE_ATTACH will bypass the safety checks that ensure the units are not running while the image is attached or detached. SD_SYSTEMD_PORTABLE_FORCE_EXTENSION will bypass the check that ensures the extension-release.NAME file in the extension image matches the image name. They are defined as follows:

#define SD_SYSTEMD_PORTABLE_RUNTIME (UINT64_C(1) « 0) #define SD_SYSTEMD_PORTABLE_FORCE_ATTACH (UINT64_C(1) « 1) #define SD_SYSTEMD_PORTABLE_FORCE_EXTENSION (UINT64_C(1) « 2)

Properties

PoolPath specifies the file system path where images are written to.

PoolUsage specifies the current usage size of the image pool in bytes.

PoolLimit specifies the size limit of the image pool in bytes.

Profiles specifies the available runtime profiles for portable services.

THE IMAGE OBJECT

The service exposes the following interfaces on the Image object on the bus:

node /org/freedesktop/portable1 { interface org.freedesktop.portable1.Image { methods: GetOSRelease(out a{ss} os_release); GetMetadata(in as matches, out s image, out ay os_release, out a{say} units); GetMetadataWithExtensions(in as extensions, in as matches, in t flags, out s image, out ay os_release, out a{say} extensions, out a{say} units); GetState(out s state); GetStateWithExtensions(in as extensions, in t flags, out s state); Attach(in as matches, in s profile, in b runtime, in s copy_mode, out a(sss) changes); AttachWithExtensions(in as extensions, in as matches, in s profile, in s copy_mode, in t flags, out a(sss) changes); Detach(in b runtime, out a(sss) changes); DetachWithExtensions(in as extensions, in t flags, out a(sss) changes); Reattach(in as matches, in s profile, in b runtime, in s copy_mode, out a(sss) changes_removed, out a(sss) changes_updated); ReattachWithExtensions(in as extensions, in as matches, in s profile, in s copy_mode, in t flags, out a(sss) changes_removed, out a(sss) changes_updated); Remove(); MarkReadOnly(in b read_only); SetLimit(in t limit); properties: @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s Name = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s Path = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s Type = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b ReadOnly = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CreationTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t ModificationTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t Usage = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t Limit = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t UsageExclusive = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t LimitExclusive = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; };

Methods

The following methods implement the same operation as the respective methods on the Manager object (see above). However, these methods operate on the image object and hence does not take an image name parameter. Invoking the methods directly on the Manager object has the advantage of not requiring a GetImage() call to get the image object for a specific image name. Calling the methods on the Manager object is hence a round trip optimization. List of methods:

·
GetOSRelease()

·
GetMetadata()

·
GetMetadataWithExtensions()

·
GetState()

·
Attach()

·
AttachWithExtensions()

·
Detach()

·
DetachWithExtensions()

·
Reattach()

·
ReattachWithExtensions()

·
Remove()

·
MarkReadOnly()

·
SetLimit()

Properties

Name specifies the image name.

Path specifies the file system path where image is stored.

Type specifies the image type.

ReadOnly specifies whether the image is read-only.

CreationTimestamp specifies the image creation timestamp.

ModificationTimestamp specifies the image modification timestamp.

Usage specifies the image disk usage.

Limit specifies the image disk usage limit.

UsageExclusive specifies the image disk usage (exclusive).

LimitExclusive specifies the image disk usage limit (exclusive).

VERSIONING

These D-Bus interfaces follow the usual interface versioning guidelines[1].

HISTORY

The Manager Object

GetImageStateWithExtensions() was added in version 251.

The Image Object

GetStateWithExtensions() was added in version 251.

ReattachWithExtensions() was added in version 254.

NOTES

the usual interface versioning guidelines

https://0pointer.de/blog/projects/versioning-dbus.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

53 - Linux cli command proc_timer_stats

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_timer_stats and provides detailed information about the command proc_timer_stats, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_timer_stats.

NAME 🖥️ proc_timer_stats 🖥️

timer statistics

DESCRIPTION

/proc/timer_stats (from Linux 2.6.21 until Linux 4.10)
This is a debugging facility to make timer (ab)use in a Linux system visible to kernel and user-space developers. It can be used by kernel and user-space developers to verify that their code does not make undue use of timers. The goal is to avoid unnecessary wakeups, thereby optimizing power consumption.

If enabled in the kernel (CONFIG_TIMER_STATS), but not used, it has almost zero run-time overhead and a relatively small data-structure overhead. Even if collection is enabled at run time, overhead is low: all the locking is per-CPU and lookup is hashed.

The /proc/timer_stats file is used both to control sampling facility and to read out the sampled information.

The timer_stats functionality is inactive on bootup. A sampling period can be started using the following command:

# echo 1 > /proc/timer_stats

The following command stops a sampling period:

# echo 0 > /proc/timer_stats

The statistics can be retrieved by:

$ cat /proc/timer_stats

While sampling is enabled, each readout from /proc/timer_stats will see newly updated statistics. Once sampling is disabled, the sampled information is kept until a new sample period is started. This allows multiple readouts.

Sample output from /proc/timer_stats:

$ cat /proc/timer_stats
Timer Stats Version: v0.3
Sample period: 1.764 s
Collection: active
  255,     0 swapper/3        hrtimer_start_range_ns (tick_sched_timer)
   71,     0 swapper/1        hrtimer_start_range_ns (tick_sched_timer)
   58,     0 swapper/0        hrtimer_start_range_ns (tick_sched_timer)
    4,  1694 gnome-shell      mod_delayed_work_on (delayed_work_timer_fn)
   17,     7 rcu_sched        rcu_gp_kthread (process_timeout)
...
    1,  4911 kworker/u16:0    mod_delayed_work_on (delayed_work_timer_fn)
   1D,  2522 kworker/0:0      queue_delayed_work_on (delayed_work_timer_fn)
1029 total events, 583.333 events/sec

The output columns are:

[1]
a count of the number of events, optionally (since Linux 2.6.23) followed by the letter ‘D’ if this is a deferrable timer;

[2]
the PID of the process that initialized the timer;

[3]
the name of the process that initialized the timer;

[4]
the function where the timer was initialized; and (in parentheses) the callback function that is associated with the timer.

During the Linux 4.11 development cycle, this file was removed because of security concerns, as it exposes information across namespaces. Furthermore, it is possible to obtain the same information via in-kernel tracing facilities such as ftrace.

54 - Linux cli command proc_iomem

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_iomem and provides detailed information about the command proc_iomem, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_iomem.

NAME 🖥️ proc_iomem 🖥️

I/O memory map

DESCRIPTION

/proc/iomem
I/O memory map in Linux 2.4.

55 - Linux cli command shells

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command shells and provides detailed information about the command shells, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the shells.

NAME 🖥️ shells 🖥️

pathnames of valid login shells

DESCRIPTION

/etc/shells is a text file which contains the full pathnames of valid login shells. This file is consulted by chsh(1) and available to be queried by other programs.

Be aware that there are programs which consult this file to find out if a user is a normal user; for example, FTP daemons traditionally disallow access to users with shells not included in this file.

FILES

/etc/shells

EXAMPLES

/etc/shells may contain the following paths:

/bin/sh
/bin/bash
/bin/csh

56 - Linux cli command org.freedesktop.login1

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.freedesktop.login1 and provides detailed information about the command org.freedesktop.login1, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.freedesktop.login1.

NAME 🖥️ org.freedesktop.login1 🖥️

The D-Bus interface of systemd-logind

INTRODUCTION

systemd-logind.service(8) is a system service that keeps track of user logins and seats.

The daemon provides both a C library interface as well as a D-Bus interface. The library interface may be used to introspect and watch the state of user logins and seats. The bus interface provides the same functionality but in addition may also be used to make changes to the system state. For more information please consult sd-login(3).

THE MANAGER OBJECT

The service exposes the following interfaces on the Manager object on the bus:

node /org/freedesktop/login1 { interface org.freedesktop.login1.Manager { methods: GetSession(in s session_id, out o object_path); GetSessionByPID(in u pid, out o object_path); GetUser(in u uid, out o object_path); GetUserByPID(in u pid, out o object_path); GetSeat(in s seat_id, out o object_path); ListSessions(out a(susso) sessions); ListSessionsEx(out a(sussussbto) sessions); ListUsers(out a(uso) users); ListSeats(out a(so) seats); ListInhibitors(out a(ssssuu) inhibitors); @org.freedesktop.systemd1.Privileged(“true”) CreateSession(in u uid, in u pid, in s service, in s type, in s class, in s desktop, in s seat_id, in u vtnr, in s tty, in s display, in b remote, in s remote_user, in s remote_host, in a(sv) properties, out s session_id, out o object_path, out s runtime_path, out h fifo_fd, out u uid, out s seat_id, out u vtnr, out b existing); @org.freedesktop.systemd1.Privileged(“true”) CreateSessionWithPIDFD(in u uid, in h pidfd, in s service, in s type, in s class, in s desktop, in s seat_id, in u vtnr, in s tty, in s display, in b remote, in s remote_user, in s remote_host, in t flags, in a(sv) properties, out s session_id, out o object_path, out s runtime_path, out h fifo_fd, out u uid, out s seat_id, out u vtnr, out b existing); ReleaseSession(in s session_id); ActivateSession(in s session_id); ActivateSessionOnSeat(in s session_id, in s seat_id); LockSession(in s session_id); UnlockSession(in s session_id); LockSessions(); UnlockSessions(); KillSession(in s session_id, in s who, in i signal_number); KillUser(in u uid, in i signal_number); TerminateSession(in s session_id); TerminateUser(in u uid); TerminateSeat(in s seat_id); SetUserLinger(in u uid, in b enable, in b interactive); AttachDevice(in s seat_id, in s sysfs_path, in b interactive); FlushDevices(in b interactive); PowerOff(in b interactive); PowerOffWithFlags(in t flags); Reboot(in b interactive); RebootWithFlags(in t flags); Halt(in b interactive); HaltWithFlags(in t flags); Suspend(in b interactive); SuspendWithFlags(in t flags); Hibernate(in b interactive); HibernateWithFlags(in t flags); HybridSleep(in b interactive); HybridSleepWithFlags(in t flags); SuspendThenHibernate(in b interactive); SuspendThenHibernateWithFlags(in t flags); Sleep(in t flags); CanPowerOff(out s result); CanReboot(out s result); CanHalt(out s result); CanSuspend(out s result); CanHibernate(out s result); CanHybridSleep(out s result); CanSuspendThenHibernate(out s result); CanSleep(out s result); ScheduleShutdown(in s type, in t usec); CancelScheduledShutdown(out b cancelled); Inhibit(in s what, in s who, in s why, in s mode, out h pipe_fd); CanRebootParameter(out s result); SetRebootParameter(in s parameter); CanRebootToFirmwareSetup(out s result); SetRebootToFirmwareSetup(in b enable); CanRebootToBootLoaderMenu(out s result); SetRebootToBootLoaderMenu(in t timeout); CanRebootToBootLoaderEntry(out s result); SetRebootToBootLoaderEntry(in s boot_loader_entry); SetWallMessage(in s wall_message, in b enable); signals: SessionNew(s session_id, o object_path); SessionRemoved(s session_id, o object_path); UserNew(u uid, o object_path); UserRemoved(u uid, o object_path); SeatNew(s seat_id, o object_path); SeatRemoved(s seat_id, o object_path); PrepareForShutdown(b start); PrepareForShutdownWithMetadata(b start, a{sv} metadata); PrepareForSleep(b start); properties: @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) @org.freedesktop.systemd1.Privileged(“true”) readwrite b EnableWallMessages = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) @org.freedesktop.systemd1.Privileged(“true”) readwrite s WallMessage = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u NAutoVTs = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as KillOnlyUsers = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as KillExcludeUsers = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b KillUserProcesses = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s RebootParameter = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b RebootToFirmwareSetup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t RebootToBootLoaderMenu = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s RebootToBootLoaderEntry = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as BootLoaderEntries = […, …]; readonly b IdleHint = …; readonly t IdleSinceHint = …; readonly t IdleSinceHintMonotonic = …; readonly s BlockInhibited = …; readonly s DelayInhibited = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t InhibitDelayMaxUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t UserStopDelayUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as SleepOperation = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s HandlePowerKey = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s HandlePowerKeyLongPress = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s HandleRebootKey = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s HandleRebootKeyLongPress = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s HandleSuspendKey = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s HandleSuspendKeyLongPress = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s HandleHibernateKey = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s HandleHibernateKeyLongPress = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s HandleLidSwitch = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s HandleLidSwitchExternalPower = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s HandleLidSwitchDocked = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t HoldoffTimeoutUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s IdleAction = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t IdleActionUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b PreparingForShutdown = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b PreparingForSleep = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly (st) ScheduledShutdown = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b Docked = …; readonly b LidClosed = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b OnExternalPower = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RemoveIPC = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t RuntimeDirectorySize = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t RuntimeDirectoryInodesMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t InhibitorsMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t NCurrentInhibitors = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t SessionsMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t NCurrentSessions = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t StopIdleSessionUSec = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; };

Methods

GetSession() may be used to get the session object path for the session with the specified ID. Similarly, GetUser() and GetSeat() get the user and seat objects, respectively. GetSessionByPID() and GetUserByPID() get the session/user object the specified PID belongs to if there is any.

ListSessions() returns an array of all current sessions. The structures in the array consist of the following fields: session id, user id, user name, seat id, and session object path. If a session does not have a seat attached, the seat id field will be an empty string.

ListSessionsEx() returns an array of all current sessions with more metadata than ListSessions(). The structures in the array consist of the following fields: session id, user id, user name, seat id, leader pid, session class, tty name, idle hint, idle hint monotonic timestamp, and session object path. tty and seat id fields could be empty, if the session has no associated tty or session has no seat attached, respectively.

ListUsers() returns an array of all currently logged in users. The structures in the array consist of the following fields: user id, user name, user object path.

ListSeats() returns an array of all currently available seats. The structure in the array consists of the following fields: seat id, seat object path.

ListInhibitors() lists all currently active inhibitors. It returns an array of structures consisting of what, who, why, mode, uid (user ID), and pid (process ID).

CreateSession(), CreateSessionWithPIDFD(), and ReleaseSession() may be used to open or close login sessions. These calls should never be invoked directly by clients. Creating/closing sessions is exclusively the job of PAM and its pam_systemd(8) module.

ActivateSession() brings the session with the specified ID into the foreground. ActivateSessionOnSeat() does the same, but only if the seat id matches.

LockSession() asks the session with the specified ID to activate the screen lock. UnlockSession() asks the session with the specified ID to remove an active screen lock, if there is any. This is implemented by sending out the Lock() and Unlock() signals from the respective session object which session managers are supposed to listen on.

LockSessions() asks all sessions to activate their screen locks. This may be used to lock access to the entire machine in one action. Similarly, UnlockSessions() asks all sessions to deactivate their screen locks.

KillSession() may be used to send a Unix signal to one or all processes of a session. As arguments it takes the session id, either the string “leader” or “all” and a signal number. If “leader” is passed only the session “leader” is killed. If “all” is passed all processes of the session are killed.

KillUser() may be used to send a Unix signal to all processes of a user. As arguments it takes the user id and a signal number.

TerminateSession(), TerminateUser(), TerminateSeat() may be used to forcibly terminate one specific session, all processes of a user, and all sessions attached to a specific seat, respectively. The session, user, and seat are identified by their respective IDs.

SetUserLinger() enables or disables user lingering. If enabled, the runtime directory of a user is kept around and they may continue to run processes while logged out. If disabled, the runtime directory goes away as soon as they log out. SetUserLinger() expects three arguments: the UID, a boolean whether to enable/disable and a boolean controlling the polkit[1] authorization interactivity (see below). Note that the user linger state is persistently stored on disk.

AttachDevice() may be used to assign a specific device to a specific seat. The device is identified by its /sys/ path and must be eligible for seat assignments. AttachDevice() takes three arguments: the seat id, the sysfs path, and a boolean for controlling polkit interactivity (see below). Device assignments are persistently stored on disk. To create a new seat, simply specify a previously unused seat id. For more information about the seat assignment logic see sd-login(3).

FlushDevices() removes all explicit seat assignments for devices, resetting all assignments to the automatic defaults. The only argument it takes is the polkit interactivity boolean (see below).

PowerOff(), Reboot(), Halt(), Suspend(), and Hibernate() result in the system being powered off, rebooted, halted (shut down without turning off power), suspended (the system state is saved to RAM and the CPU is turned off), or hibernated (the system state is saved to disk and the machine is powered down). HybridSleep() results in the system entering a hybrid-sleep mode, i.e. the system is both hibernated and suspended. SuspendThenHibernate() results in the system being suspended, then later woken using an RTC timer and hibernated. The only argument is the polkit interactivity boolean interactive (see below). The main purpose of these calls is that they enforce polkit policy and hence allow powering off/rebooting/suspending/hibernating even by unprivileged users. They also enforce inhibition locks for non-privileged users. Sleep() automatically selects the most suitable sleep operation supported by the machine. The candidate sleep operations to check for support can be configured through SleepOperation= setting in logind.conf(5). UIs should expose these calls as the primary mechanism to poweroff/reboot/suspend/hibernate the machine. Methods PowerOffWithFlags(), RebootWithFlags(), HaltWithFlags(), SuspendWithFlags(), HibernateWithFlags(), HybridSleepWithFlags(), SuspendThenHibernateWithFlags(), and Sleep() take flags to allow for extendability, defined as follows:

#define SD_LOGIND_ROOT_CHECK_INHIBITORS (UINT64_C(1) « 0) #define SD_LOGIND_KEXEC_REBOOT (UINT64_C(1) « 1) #define SD_LOGIND_SOFT_REBOOT (UINT64_C(1) « 2) #define SD_LOGIND_SOFT_REBOOT_IF_NEXTROOT_SET_UP (UINT64_C(1) « 3)

When the flags is 0 then these methods behave just like the versions without flags. When SD_LOGIND_ROOT_CHECK_INHIBITORS (0x01) is set, active inhibitors are honoured for privileged users too. When SD_LOGIND_KEXEC_REBOOT (0x02) is set, then RebootWithFlags() performs a kexec reboot if kexec kernel is loaded. When SD_LOGIND_SOFT_REBOOT (0x04) is set, or SD_LOGIND_SOFT_REBOOT_IF_NEXTROOT_SET_UP (0x08) is set and a new root file system has been set up on “/run/nextroot/”, then RebootWithFlags() performs a userspace reboot only. SD_LOGIND_SOFT_REBOOT_IF_NEXTROOT_SET_UP and SD_LOGIND_KEXEC_REBOOT can be combined, with soft-reboot having precedence.

SetRebootParameter() sets a parameter for a subsequent reboot operation. See the description of reboot in systemctl(1) and reboot(2) for more information.

SetRebootToFirmwareSetup(), SetRebootToBootLoaderMenu(), and SetRebootToBootLoaderEntry() configure the action to be taken from the boot loader after a reboot: respectively entering firmware setup mode, the boot loader menu, or a specific boot loader entry. See systemctl(1) for the corresponding command line interface.

CanPowerOff(), CanReboot(), CanHalt(), CanSuspend(), CanHibernate(), CanHybridSleep(), CanSuspendThenHibernate(), CanSleep(), CanRebootParameter(), CanRebootToFirmwareSetup(), CanRebootToBootLoaderMenu(), and CanRebootToBootLoaderEntry() test whether the system supports the respective operation and whether the calling user is allowed to execute it. Returns one of “na”, “yes”, “no”, and “challenge”. If “na” is returned, the operation is not available because hardware, kernel, or drivers do not support it. If “yes” is returned, the operation is supported and the user may execute the operation without further authentication. If “no” is returned, the operation is available but the user is not allowed to execute the operation. If “challenge” is returned, the operation is available but only after authorization.

ScheduleShutdown() schedules a shutdown operation type at time usec in microseconds since the UNIX epoch. type can be one of “poweroff”, “dry-poweroff”, “reboot”, “dry-reboot”, “halt”, and “dry-halt”. (The “dry-” variants do not actually execute the shutdown action.) CancelScheduledShutdown() cancels a scheduled shutdown. The output parameter cancelled is true if a shutdown operation was scheduled.

SetWallMessage() sets the wall message (the message that will be sent out to all terminals and stored in a utmp(5) record) for a subsequent scheduled shutdown operation. The parameter wall_message specifies the shutdown reason (and may be empty) which will be included in the shutdown message. The parameter enable specifies whether to print a wall message on shutdown.

Inhibit() creates an inhibition lock. It takes four parameters: what, who, why, and mode. what is one or more of “shutdown”, “sleep”, “idle”, “handle-power-key”, “handle-suspend-key”, “handle-hibernate-key”, “handle-lid-switch”, separated by colons, for inhibiting poweroff/reboot, suspend/hibernate, the automatic idle logic, or hardware key handling. who should be a short human readable string identifying the application taking the lock. why should be a short human readable string identifying the reason why the lock is taken. Finally, mode is either “block” or “delay” which encodes whether the inhibit shall be consider mandatory or whether it should just delay the operation to a certain maximum time. The method returns a file descriptor. The lock is released the moment this file descriptor and all its duplicates are closed. For more information on the inhibition logic see Inhibitor Locks[2].

Signals

Whenever the inhibition state or idle hint changes, PropertyChanged signals are sent out to which clients can subscribe.

The SessionNew(), SessionRemoved(), UserNew(), UserRemoved(), SeatNew(), and SeatRemoved() signals are sent each time a session is created or removed, a user logs in or out, or a seat is added or removed. They each contain the ID of the object plus the object path.

The PrepareForShutdown(), PrepareForShutdownWithMetadata(), and PrepareForSleep() signals are sent right before (with the argument “true”) or after (with the argument “false”) the system goes down for reboot/poweroff and suspend/hibernate, respectively. This may be used by applications to save data on disk, release memory, or do other jobs that should be done shortly before shutdown/sleep, in conjunction with delay inhibitor locks. After completion of this work they should release their inhibition locks in order to not delay the operation any further. For more information see Inhibitor Locks[2]. The PrepareForShutdownWithMetadata() signal additionally sends a list of key/value pair metadata fields. Currently it sends a type string which defines the type of shutdown. The type can be one of “power-off”, “reboot”, “halt”, “kexec” or “soft-reboot”. This signal is sent first, followed by PrepareForShutdown() (for backward compatibility).

Properties

Most properties simply reflect the configuration, see logind.conf(5). This includes: NAutoVTs, KillOnlyUsers, KillExcludeUsers, KillUserProcesses, IdleAction, InhibitDelayMaxUSec, InhibitorsMax, UserStopDelayUSec, HandlePowerKey, HandleSuspendKey, HandleHibernateKey, HandleLidSwitch, HandleLidSwitchExternalPower, HandleLidSwitchDocked, IdleActionUSec, HoldoffTimeoutUSec, RemoveIPC, RuntimeDirectorySize, RuntimeDirectoryInodesMax, InhibitorsMax, and SessionsMax.

The IdleHint property reflects the idle hint state of the system. If the system is idle it might get into automatic suspend or shutdown depending on the configuration.

IdleSinceHint and IdleSinceHintMonotonic encode the timestamps of the last change of the idle hint boolean, in CLOCK_REALTIME and CLOCK_MONOTONIC timestamps, respectively, in microseconds since the epoch.

The BlockInhibited and DelayInhibited properties encode the currently active locks of the respective modes. They are colon separated lists of “shutdown”, “sleep”, and “idle” (see above).

NCurrentSessions and NCurrentInhibitors contain the number of currently registered sessions and inhibitors.

The BootLoaderEntries property contains a list of boot loader entries. This includes boot loader entries defined in configuration and any additional loader entries reported by the boot loader. See systemd-boot(7) for more information.

The PreparingForShutdown and PreparingForSleep boolean properties are true during the interval between the two PrepareForShutdown() and PrepareForSleep() signals respectively. Note that these properties do not send out PropertyChanged signals.

The RebootParameter property shows the value set with the SetRebootParameter() method described above.

ScheduledShutdown shows the value pair set with the ScheduleShutdown() method described above.

RebootToFirmwareSetup, RebootToBootLoaderMenu, and RebootToBootLoaderEntry are true when the resprective post-reboot operation was selected with SetRebootToFirmwareSetup(), SetRebootToBootLoaderMenu(), or SetRebootToBootLoaderEntry().

The WallMessage and EnableWallMessages properties reflect the shutdown reason and wall message enablement switch which can be set with the SetWallMessage() method described above.

Docked is true if the machine is connected to a dock. LidClosed is true when the lid (of a laptop) is closed. OnExternalPower is true when the machine is connected to an external power supply.

Security

A number of operations are protected via the polkit privilege system. SetUserLinger() requires the org.freedesktop.login1.set-user-linger privilege. AttachDevice() requires org.freedesktop.login1.attach-device and FlushDevices() requires org.freedesktop.login1.flush-devices. PowerOff(), Reboot(), Halt(), Suspend(), Hibernate() require org.freedesktop.login1.power-off, org.freedesktop.login1.power-off-multiple-sessions, org.freedesktop.login1.power-off-ignore-inhibit, org.freedesktop.login1.reboot, org.freedesktop.login1.reboot-multiple-sessions, org.freedesktop.login1.reboot-ignore-inhibit, org.freedesktop.login1.halt, org.freedesktop.login1.halt-multiple-sessions, org.freedesktop.login1.halt-ignore-inhibit, org.freedesktop.login1.suspend, org.freedesktop.login1.suspend-multiple-sessions, org.freedesktop.login1.suspend-ignore-inhibit, org.freedesktop.login1.hibernate, org.freedesktop.login1.hibernate-multiple-sessions, org.freedesktop.login1.hibernate-ignore-inhibit, respectively depending on whether there are other sessions around or active inhibits are present. HybridSleep() and SuspendThenHibernate() use the same privileges as Hibernate(). Sleep() uses the inhibits of the auto-selected sleep operation. SetRebootParameter() requires org.freedesktop.login1.set-reboot-parameter.

SetRebootToFirmwareSetup() requires org.freedesktop.login1.set-reboot-to-firmware-setup. SetRebootToBootLoaderMenu() requires org.freedesktop.login1.set-reboot-to-boot-loader-menu. SetRebootToBootLoaderEntry() requires org.freedesktop.login1.set-reboot-to-boot-loader-entry.

ScheduleShutdown() and CancelScheduledShutdown() require the same privileges (listed above) as the immediate poweroff/reboot/halt operations.

Inhibit() is protected via one of org.freedesktop.login1.inhibit-block-shutdown, org.freedesktop.login1.inhibit-delay-shutdown, org.freedesktop.login1.inhibit-block-sleep, org.freedesktop.login1.inhibit-delay-sleep, org.freedesktop.login1.inhibit-block-idle, org.freedesktop.login1.inhibit-handle-power-key, org.freedesktop.login1.inhibit-handle-suspend-key, org.freedesktop.login1.inhibit-handle-hibernate-key, org.freedesktop.login1.inhibit-handle-lid-switch depending on the lock type and mode taken.

The interactive boolean parameters can be used to control whether polkit should interactively ask the user for authentication credentials if required.

SEAT OBJECTS

node /org/freedesktop/login1/seat/seat0 { interface org.freedesktop.login1.Seat { methods: Terminate(); ActivateSession(in s session_id); SwitchTo(in u vtnr); SwitchToNext(); SwitchToPrevious(); properties: @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Id = …; readonly (so) ActiveSession = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b CanTTY = …; readonly b CanGraphical = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(so) Sessions = […]; readonly b IdleHint = …; readonly t IdleSinceHint = …; readonly t IdleSinceHintMonotonic = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; };

Methods

Terminate() and ActivateSession() work similarly to TerminateSeat() and ActivationSessionOnSeat() on the Manager object.

SwitchTo() switches to the session on the virtual terminal vtnr. SwitchToNext() and SwitchToPrevious() switch to, respectively, the next and previous sessions on the seat in the order of virtual terminals. If there is no active session, they switch to, respectively, the first and last session on the seat.

Signals

Whenever ActiveSession, Sessions, CanGraphical, CanTTY, or the idle state changes, PropertyChanged signals are sent out to which clients can subscribe.

Properties

The Id property encodes the ID of the seat.

ActiveSession encodes the currently active session if there is one. It is a structure consisting of the session id and the object path.

CanTTY encodes whether the session is suitable for text logins, and CanGraphical whether it is suitable for graphical sessions.

The Sessions property is an array of all current sessions of this seat, each encoded in a structure consisting of the ID and the object path.

The IdleHint, IdleSinceHint, and IdleSinceHintMonotonic properties encode the idle state, similarly to the ones exposed on the Manager object, but specific for this seat.

USER OBJECTS

node /org/freedesktop/login1/user/_1000 { interface org.freedesktop.login1.User { methods: Terminate(); Kill(in i signal_number); properties: @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u UID = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u GID = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Name = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t Timestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t TimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RuntimePath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Service = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Slice = …; readonly (so) Display = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s State = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(so) Sessions = […]; readonly b IdleHint = …; readonly t IdleSinceHint = …; readonly t IdleSinceHintMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b Linger = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; };

Methods

Terminate() and Kill() work similarly to the TerminateUser() and KillUser() methods on the manager object.

Signals

Whenever Sessions or the idle state changes, PropertyChanged signals are sent out to which clients can subscribe.

Properties

The UID and GID properties encode the Unix UID and primary GID of the user.

The Name property encodes the user name.

Timestamp and TimestampMonotonic encode the login time of the user in microseconds since the epoch, in the CLOCK_REALTIME and CLOCK_MONOTONIC clocks, respectively.

RuntimePath encodes the runtime path of the user, i.e. $XDG_RUNTIME_DIR. For details see the XDG Basedir Specification[3].

Service contains the unit name of the user systemd service of this user. Each logged in user is assigned a user service that runs a user systemd instance. This is usually an instance of [email protected].

Slice contains the unit name of the user systemd slice of this user. Each logged in user gets a private slice.

Display encodes which graphical session should be used as the primary UI display for the user. It is a structure encoding the session ID and the object path of the session to use.

State encodes the user state and is one of “offline”, “lingering”, “online”, “active”, or “closing”. See sd_uid_get_state(3) for more information about the states.

Sessions is an array of structures encoding all current sessions of the user. Each structure consists of the ID and object path.

The IdleHint, IdleSinceHint, and IdleSinceHintMonotonic properties encode the idle hint state of the user, similarly to the Managers properties, but specific for this user.

The Linger property shows whether lingering is enabled for this user.

SESSION OBJECTS

node /org/freedesktop/login1/session/1 { interface org.freedesktop.login1.Session { methods: Terminate(); Activate(); Lock(); Unlock(); SetIdleHint(in b idle); SetLockedHint(in b locked); Kill(in s who, in i signal_number); TakeControl(in b force); ReleaseControl(); SetType(in s type); SetClass(in s class); SetDisplay(in s display); SetTTY(in h tty_fd); TakeDevice(in u major, in u minor, out h fd, out b inactive); ReleaseDevice(in u major, in u minor); PauseDeviceComplete(in u major, in u minor); SetBrightness(in s subsystem, in s name, in u brightness); signals: PauseDevice(u major, u minor, s type); ResumeDevice(u major, u minor, h fd); Lock(); Unlock(); properties: @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Id = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (uo) User = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Name = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t Timestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t TimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u VTNr = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (so) Seat = …; readonly s TTY = …; readonly s Display = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b Remote = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RemoteHost = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RemoteUser = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Service = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Desktop = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Scope = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u Leader = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u Audit = …; readonly s Type = …; readonly s Class = …; readonly b Active = …; readonly s State = …; readonly b IdleHint = …; readonly t IdleSinceHint = …; readonly t IdleSinceHintMonotonic = …; readonly b LockedHint = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; };

Methods

Terminate(), Activate(), Lock(), Unlock(), and Kill() work similarly to the respective calls on the Manager object.

SetIdleHint() is called by the session object to update the idle state of the session whenever it changes.

TakeControl() allows a process to take exclusive managed device access-control for that session. Only one D-Bus connection can be a controller for a given session at any time. If the force argument is set (root only), an existing controller is kicked out and replaced. Otherwise, this method fails if there is already a controller. Note that this method is limited to D-Bus users with the effective UID set to the user of the session or root.

ReleaseControl() drops control of a given session. Closing the D-Bus connection implicitly releases control as well. See TakeControl() for more information. This method also releases all devices for which the controller requested ownership via TakeDevice().

SetType() allows the type of the session to be changed dynamically. It can only be called by sessions current controller. If TakeControl() has not been called, this method will fail. In addition, the session type will be reset to its original value once control is released, either by calling ReleaseControl() or closing the D-Bus connection. This should help prevent a session from entering an inconsistent state, for example if the controller crashes. The only argument type is the new session type.

SetClass() allows the caller to change the class of the session dynamically. It may only be called by sessions owening user. Currently, this call may be exclusively used to change the class from “user-incomplete” to “user”. The call is synchronous, and will return only once the users service manager has successfully been started, if necessary. The only argument type is the new session type.

SetDisplay() allows the display name of the graphical session to be changed. This is useful if the display server is started as part of the session. It can only be called by sessions current controller. If TakeControl() has not been called, this method will fail. The only argument display is the new display name.

SetTTY() allows the device name of the session to be changed. This is useful if the tty device is only known after authentication. It can only be called by sessions current controller. If TakeControl() has not been called, this method will fail. The only argument tty_fd is a file handle to the new tty device.

TakeDevice() allows a session controller to get a file descriptor for a specific device. Pass in the major and minor numbers of the character device and systemd-logind will return a file descriptor for the device. Only a limited set of device-types is currently supported (but may be extended). systemd-logind automatically mutes the file descriptor if the session is inactive and resumes it once the session is activated again. This guarantees that a session can only access session devices if the session is active. Note that this revoke/resume mechanism is asynchronous and may happen at any given time. This only works on devices that are attached to the seat of the given session. A process is not required to have direct access to the device node. systemd-logind only requires you to be the active session controller (see TakeControl()). Also note that any device can only be requested once. As long as you dont release it, further TakeDevice() calls will fail.

ReleaseDevice() releases a device again (see TakeDevice()). This is also implicitly done by ReleaseControl() or when closing the D-Bus connection.

PauseDeviceComplete() allows a session controller to synchronously pause a device after receiving a PauseDevice(“pause”) signal. Forced signals (or after an internal timeout) are automatically completed by systemd-logind asynchronously.

SetLockedHint() may be used to set the “locked hint” to locked, i.e. information whether the session is locked. This is intended to be used by the desktop environment to tell systemd-logind when the session is locked and unlocked.

SetBrightness() may be used to set the display brightness. This is intended to be used by the desktop environment and allows unprivileged programs to access hardware settings in a controlled way. The subsystem parameter specifies a kernel subsystem, either “backlight” or “leds”. The name parameter specifies a device name under the specified subsystem. The brightness parameter specifies the brightness. The range is defined by individual drivers, see /sys/class/subsystem/name/max_brightness.

Signals

The active session controller exclusively gets PauseDevice() and ResumeDevice() events for any device it requested via TakeDevice(). They notify the controller whenever a device is paused or resumed. A device is never resumed if its session is inactive. Also note that PauseDevice() signals are sent before the PropertyChanged signal for the Active state. The inverse is true for ResumeDevice(). A device may remain paused for unknown reasons even though the Session is active.

A PauseDevice() signal carries the major and minor numbers and a string describing the type as arguments. force means the device was already paused by systemd-logind and the signal is only an asynchronous notification. pause means systemd-logind grants you a limited amount of time to pause the device. You must respond to this via PauseDeviceComplete(). This synchronous pausing mechanism is used for backwards-compatibility to VTs and systemd-logind is free to not make use of it. It is also free to send a forced PauseDevice() if you dont respond in a timely manner (or for any other reason). gone means the device was unplugged from the system and you will no longer get any notifications about it. There is no need to call ReleaseDevice(). You may call TakeDevice() again if a new device is assigned the major+minor combination.

ResumeDevice() is sent whenever a session is active and a device is resumed. It carries the major/minor numbers as arguments and provides a new open file descriptor. You should switch to the new descriptor and close the old one. They are not guaranteed to have the same underlying open file descriptor in the kernel (except for a limited set of device types).

Whenever Active or the idle state changes, PropertyChanged signals are sent out to which clients can subscribe.

Lock()/Unlock() is sent when the session is asked to be screen-locked/unlocked. A session manager of the session should listen to this signal and act accordingly. This signal is sent out as a result of the Lock() and Unlock() methods, respectively.

Properties

Id encodes the session ID.

User encodes the user ID of the user this session belongs to. This is a structure consisting of the Unix UID and the object path.

Name encodes the user name.

Timestamp and TimestampMonotonic encode the microseconds since the epoch when the session was created, in CLOCK_REALTIME or CLOCK_MONOTONIC, respectively.

VTNr encodes the virtual terminal number of the session if there is any, 0 otherwise.

Seat encodes the seat this session belongs to if there is any. This is a structure consisting of the ID and the seat object path.

TTY encodes the kernel TTY path of the session if this is a text login. If not this is an empty string.

Display encodes the X11 display name if this is a graphical login. If not, this is an empty string.

Remote encodes whether the session is local or remote.

RemoteHost and RemoteUser encode the remote host and user if this is a remote session, or an empty string otherwise.

Service encodes the PAM service name that registered the session.

Desktop describes the desktop environment running in the session (if known).

Scope contains the systemd scope unit name of this session.

Leader encodes the PID of the process that registered the session.

Audit encodes the Kernel Audit session ID of the session if auditing is available.

Type encodes the session type. Its one of “unspecified” (for cron PAM sessions and suchlike), “tty” (for text logins) or “x11”/“mir”/“wayland” (for graphical logins).

Class encodes the session class. Its one of “user” (for normal user sessions), “greeter” (for display manager pseudo-sessions), or “lock-screen” (for display lock screens).

Active is a boolean that is true if the session is active, i.e. currently in the foreground. This field is semi-redundant due to State.

State encodes the session state and one of “online”, “active”, or “closing”. See sd_session_get_state(3) for more information about the states.

IdleHint, IdleSinceHint, and IdleSinceHintMonotonic encapsulate the idle hint state of this session, similarly to how the respective properties on the manager object do it for the whole system.

LockedHint shows the locked hint state of this session, as set by the SetLockedHint() method described above.

EXAMPLES

Example 1. Introspect the logind manager on the bus

$ gdbus introspect –system –dest org.freedesktop.login1
–object-path /org/freedesktop/login1

$ busctl introspect org.freedesktop.login1 /org/freedesktop/login1

Example 2. Introspect the default seat on the bus

$ gdbus introspect –system –dest org.freedesktop.login1
–object-path /org/freedesktop/login1/seat/seat0

$ busctl introspect org.freedesktop.login1 /org/freedesktop/login1/seat/seat0

Seat “seat0” is the default seat, so itll be present unless local configuration is made to reassign all devices to a different seat. The list of seats and users can be acquired with loginctl list-sessions.

Example 3. Introspect a single user on the bus

$ gdbus introspect –system –dest org.freedesktop.login1
–object-path /org/freedesktop/login1/user/_1000

$ busctl introspect org.freedesktop.login1 /org/freedesktop/login1/user/_1000

Example 4. Introspect org.freedesktop.login1.Session on the bus

$ gdbus introspect –system –dest org.freedesktop.login1
–object-path /org/freedesktop/login1/session/45

$ busctl introspect org.freedesktop.login1 /org/freedesktop/login1/session/45

VERSIONING

These D-Bus interfaces follow the usual interface versioning guidelines[4].

HISTORY

The Manager Object

HandlePowerKeyLongPress, HandleRebootKey, HandleRebootKeyLongPress, HandleSuspendKeyLongPress, and HandleHibernateKeyLongPress were added in version 251.

StopIdleSessionUSec was added in version 252.

PrepareForShutdownWithMetadata() and CreateSessionWithPIDFD() were added in version 255.

Sleep(), CanSleep(), SleepOperation, and ListSessionsEx() were added in version 256.

Session Objects

SetDisplay() was added in version 252.

SetTTY() was added in version 254.

SetClass() was added in version 256.

NOTES

polkit

https://www.freedesktop.org/software/polkit/docs/latest/

Inhibitor Locks

https://systemd.io/INHIBITOR_LOCKS

XDG Basedir Specification

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

the usual interface versioning guidelines

https://0pointer.de/blog/projects/versioning-dbus.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

57 - Linux cli command proc_timer_list

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_timer_list and provides detailed information about the command proc_timer_list, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_timer_list.

NAME 🖥️ proc_timer_list 🖥️

pending timers

DESCRIPTION

/proc/timer_list (since Linux 2.6.21)
This read-only file exposes a list of all currently pending (high-resolution) timers, all clock-event sources, and their parameters in a human-readable form.

58 - Linux cli command systemd.socket

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.socket and provides detailed information about the command systemd.socket, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.socket.

NAME 🖥️ systemd.socket 🖥️

Socket unit configuration

SYNOPSIS

socket.socket

DESCRIPTION

A unit configuration file whose name ends in “.socket” encodes information about an IPC or network socket or a file system FIFO controlled and supervised by systemd, for socket-based activation.

This man page lists the configuration options specific to this unit type. See systemd.unit(5) for the common options of all unit configuration files. The common configuration items are configured in the generic [Unit] and [Install] sections. The socket specific configuration options are configured in the [Socket] section.

Additional options are listed in systemd.exec(5), which define the execution environment the ExecStartPre=, ExecStartPost=, ExecStopPre= and ExecStopPost= commands are executed in, and in systemd.kill(5), which define the way the processes are terminated, and in systemd.resource-control(5), which configure resource control settings for the processes of the socket.

For each socket unit, a matching service unit must exist, describing the service to start on incoming traffic on the socket (see systemd.service(5) for more information about .service units). The name of the .service unit is by default the same as the name of the .socket unit, but can be altered with the Service= option described below. Depending on the setting of the Accept= option described below, this .service unit must either be named like the .socket unit, but with the suffix replaced, unless overridden with Service=; or it must be a template unit named the same way. Example: a socket file foo.socket needs a matching service foo.service if Accept=no is set. If Accept=yes is set, a service template [email protected] must exist from which services are instantiated for each incoming connection.

No implicit WantedBy= or RequiredBy= dependency from the socket to the service is added. This means that the service may be started without the socket, in which case it must be able to open sockets by itself. To prevent this, an explicit Requires= dependency may be added.

Socket units may be used to implement on-demand starting of services, as well as parallelized starting of services. See the blog stories linked at the end for an introduction.

Note that the daemon software configured for socket activation with socket units needs to be able to accept sockets from systemd, either via systemds native socket passing interface (see sd_listen_fds(3) for details about the precise protocol used and the order in which the file descriptors are passed) or via traditional inetd(8)-style socket passing (i.e. sockets passed in via standard input and output, using StandardInput=socket in the service file).

All network sockets allocated through .socket units are allocated in the hosts network namespace (see network_namespaces(7)). This does not mean however that the service activated by a configured socket unit has to be part of the hosts network namespace as well. It is supported and even good practice to run services in their own network namespace (for example through PrivateNetwork=, see systemd.exec(5)), receiving only the sockets configured through socket-activation from the hosts namespace. In such a set-up communication within the hosts network namespace is only permitted through the activation sockets passed in while all sockets allocated from the service code itself will be associated with the services own namespace, and thus possibly subject to a restrictive configuration.

AUTOMATIC DEPENDENCIES

Implicit Dependencies

The following dependencies are implicitly added:

·
Socket units automatically gain a Before= dependency on the service units they activate.

·
Socket units referring to file system paths (such as AF_UNIX sockets or FIFOs) implicitly gain Requires= and After= dependencies on all mount units necessary to access those paths.

·
Socket units using the BindToDevice= setting automatically gain a BindsTo= and After= dependency on the device unit encapsulating the specified network interface.

Additional implicit dependencies may be added as result of execution and resource control parameters as documented in systemd.exec(5) and systemd.resource-control(5).

Default Dependencies

The following dependencies are added unless DefaultDependencies=no is set:

·
Socket units automatically gain a Before= dependency on sockets.target.

·
Socket units automatically gain a pair of After= and Requires= dependency on sysinit.target, and a pair of Before= and Conflicts= dependencies on shutdown.target. These dependencies ensure that the socket unit is started before normal services at boot, and is stopped on shutdown. Only sockets involved with early boot or late system shutdown should disable DefaultDependencies= option.

OPTIONS

Socket unit files may include [Unit] and [Install] sections, which are described in systemd.unit(5).

Socket unit files must include a [Socket] section, which carries information about the socket or FIFO it supervises. A number of options that may be used in this section are shared with other unit types. These options are documented in systemd.exec(5), systemd.kill(5) and systemd.resource-control(5). The options specific to the [Socket] section of socket units are the following:

ListenStream=, ListenDatagram=, ListenSequentialPacket=

Specifies an address to listen on for a stream (SOCK_STREAM), datagram (SOCK_DGRAM), or sequential packet (SOCK_SEQPACKET) socket, respectively. The address can be written in various formats:
If the address starts with a slash ("/"), it is read as file system socket in the AF_UNIX socket family.
If the address starts with an at symbol ("@"), it is read as abstract namespace socket in the AF_UNIX family. The “@” is replaced with a NUL character before binding. For details, see unix(7).
If the address string is a single number, it is read as port number to listen on via IPv6. Depending on the value of BindIPv6Only= (see below) this might result in the service being available via both IPv6 and IPv4 (default) or just via IPv6.
If the address string is a string in the format “v.w.x.y:z”, it is interpreted as IPv4 address v.w.x.y and port z.
If the address string is a string in the format “[x]:y”, it is interpreted as IPv6 address x and port y. An optional interface scope (interface name or number) may be specified after a “%” symbol: “[x]:y%dev”. Interface scopes are only useful with link-local addresses, because the kernel ignores them in other cases. Note that if an address is specified as IPv6, it might still make the service available via IPv4 too, depending on the BindIPv6Only= setting (see below).
If the address string is a string in the format “vsock:x:y”, it is read as CID x on a port y address in the AF_VSOCK family. The CID is a unique 32-bit integer identifier in AF_VSOCK analogous to an IP address. Specifying the CID is optional, and may be set to the empty string. “vsock” may be replaced with “vsock-stream”, “vsock-dgram” or “vsock-seqpacket” to force usage of the corresponding socket type.
Note that SOCK_SEQPACKET (i.e. ListenSequentialPacket=) is only available for AF_UNIX sockets. SOCK_STREAM (i.e. ListenStream=) when used for IP sockets refers to TCP sockets, SOCK_DGRAM (i.e. ListenDatagram=) to UDP.
These options may be specified more than once, in which case incoming traffic on any of the sockets will trigger service activation, and all listed sockets will be passed to the service, regardless of whether there is incoming traffic on them or not. If the empty string is assigned to any of these options, the list of addresses to listen on is reset, all prior uses of any of these options will have no effect.
It is also possible to have more than one socket unit for the same service when using Service=, and the service will receive all the sockets configured in all the socket units. Sockets configured in one unit are passed in the order of configuration, but no ordering between socket units is specified.
If an IP address is used here, it is often desirable to listen on it before the interface it is configured on is up and running, and even regardless of whether it will be up and running at any point. To deal with this, it is recommended to set the FreeBind= option described below.

ListenFIFO=

Specifies a file system FIFO (see fifo(7) for details) to listen on. This expects an absolute file system path as argument. Behavior otherwise is very similar to the ListenDatagram= directive above.

ListenSpecial=

Specifies a special file in the file system to listen on. This expects an absolute file system path as argument. Behavior otherwise is very similar to the ListenFIFO= directive above. Use this to open character device nodes as well as special files in /proc/ and /sys/.

ListenNetlink=

Specifies a Netlink family to create a socket for to listen on. This expects a short string referring to the AF_NETLINK family name (such as audit or kobject-uevent) as argument, optionally suffixed by a whitespace followed by a multicast group integer. Behavior otherwise is very similar to the ListenDatagram= directive above.

ListenMessageQueue=

Specifies a POSIX message queue name to listen on (see mq_overview(7) for details). This expects a valid message queue name (i.e. beginning with “/”). Behavior otherwise is very similar to the ListenFIFO= directive above. On Linux message queue descriptors are actually file descriptors and can be inherited between processes.

ListenUSBFunction=

Specifies a USB FunctionFS[1] endpoints location to listen on, for implementation of USB gadget functions. This expects an absolute file system path of a FunctionFS mount point as the argument. Behavior otherwise is very similar to the ListenFIFO= directive above. Use this to open the FunctionFS endpoint ep0. When using this option, the activated service has to have the USBFunctionDescriptors= and USBFunctionStrings= options set.
Added in version 227.

SocketProtocol=

Takes one of udplite or sctp. The socket will use the UDP-Lite (IPPROTO_UDPLITE) or SCTP (IPPROTO_SCTP) protocol, respectively.
Added in version 229.

BindIPv6Only=

Takes one of default, both or ipv6-only. Controls the IPV6_V6ONLY socket option (see ipv6(7) for details). If both, IPv6 sockets bound will be accessible via both IPv4 and IPv6. If ipv6-only, they will be accessible via IPv6 only. If default (which is the default, surprise!), the system wide default setting is used, as controlled by /proc/sys/net/ipv6/bindv6only, which in turn defaults to the equivalent of both.

Backlog=

Takes an unsigned 32-bit integer argument. Specifies the number of connections to queue that have not been accepted yet. This setting matters only for stream and sequential packet sockets. See listen(2) for details. Defaults to 4294967295. Note that this value is silently capped by the “net.core.somaxconn” sysctl, which typically defaults to 4096, so typically the sysctl is the setting that actually matters.

BindToDevice=

Specifies a network interface name to bind this socket to. If set, traffic will only be accepted from the specified network interfaces. This controls the SO_BINDTODEVICE socket option (see socket(7) for details). If this option is used, an implicit dependency from this socket unit on the network interface device unit is created (see systemd.device(5)). Note that setting this parameter might result in additional dependencies to be added to the unit (see above).

SocketUser=, SocketGroup=

Takes a UNIX user/group name. When specified, all AF_UNIX sockets and FIFO nodes in the file system are owned by the specified user and group. If unset (the default), the nodes are owned by the root user/group (if run in system context) or the invoking user/group (if run in user context). If only a user is specified but no group, then the group is derived from the users default group.
Added in version 214.

SocketMode=

If listening on a file system socket or FIFO, this option specifies the file system access mode used when creating the file node. Takes an access mode in octal notation. Defaults to 0666.

DirectoryMode=

If listening on a file system socket or FIFO, the parent directories are automatically created if needed. This option specifies the file system access mode used when creating these directories. Takes an access mode in octal notation. Defaults to 0755.

Accept=

Takes a boolean argument. If yes, a service instance is spawned for each incoming connection and only the connection socket is passed to it. If no, all listening sockets themselves are passed to the started service unit, and only one service unit is spawned for all connections (also see above). This value is ignored for datagram sockets and FIFOs where a single service unit unconditionally handles all incoming traffic. Defaults to no. For performance reasons, it is recommended to write new daemons only in a way that is suitable for Accept=no. A daemon listening on an AF_UNIX socket may, but does not need to, call close(2) on the received socket before exiting. However, it must not unlink the socket from a file system. It should not invoke shutdown(2) on sockets it got with Accept=no, but it may do so for sockets it got with Accept=yes set. Setting Accept=yes is mostly useful to allow daemons designed for usage with inetd(8) to work unmodified with systemd socket activation.
Note that depending on this setting the services activated by units of this type are either regular services (in case of *Accept=*no) or instances of templated services (in case of *Accept=*yes). See the Description section above for a more detailed discussion of the naming rules of triggered services.
For IPv4 and IPv6 connections, the REMOTE_ADDR environment variable will contain the remote IP address, and REMOTE_PORT will contain the remote port. This is the same as the format used by CGI. For SOCK_RAW, the port is the IP protocol.
It is recommended to set CollectMode=inactive-or-failed for service instances activated via Accept=yes, to ensure that failed connection services are cleaned up and released from memory, and do not accumulate.

Writable=

Takes a boolean argument. May only be used in conjunction with ListenSpecial=. If true, the specified special file is opened in read-write mode, if false, in read-only mode. Defaults to false.
Added in version 227.

FlushPending=

Takes a boolean argument. May only be used when Accept=no. If yes, the sockets buffers are cleared after the triggered service exited. This causes any pending data to be flushed and any pending incoming connections to be rejected. If no, the sockets buffers wont be cleared, permitting the service to handle any pending connections after restart, which is the usually expected behaviour. Defaults to no.
Added in version 247.

MaxConnections=

The maximum number of connections to simultaneously run services instances for, when Accept=yes is set. If more concurrent connections are coming in, they will be refused until at least one existing connection is terminated. This setting has no effect on sockets configured with Accept=no or datagram sockets. Defaults to 64.

MaxConnectionsPerSource=

The maximum number of connections for a service per source IP address (in case of IPv4/IPv6), per source CID (in case of AF_VSOCK), or source UID (in case of AF_UNIX). This is very similar to the MaxConnections= directive above. Defaults to 0, i.e. disabled.
Added in version 232.

KeepAlive=

Takes a boolean argument. If true, the TCP/IP stack will send a keep alive message after 2h (depending on the configuration of /proc/sys/net/ipv4/tcp_keepalive_time) for all TCP streams accepted on this socket. This controls the SO_KEEPALIVE socket option (see socket(7) and the TCP Keepalive HOWTO[2] for details.) Defaults to false.

KeepAliveTimeSec=

Takes time (in seconds) as argument. The connection needs to remain idle before TCP starts sending keepalive probes. This controls the TCP_KEEPIDLE socket option (see socket(7) and the TCP Keepalive HOWTO[2] for details.) Default value is 7200 seconds (2 hours).
Added in version 216.

KeepAliveIntervalSec=

Takes time (in seconds) as argument between individual keepalive probes, if the socket option SO_KEEPALIVE has been set on this socket. This controls the TCP_KEEPINTVL socket option (see socket(7) and the TCP Keepalive HOWTO[2] for details.) Default value is 75 seconds.
Added in version 216.

KeepAliveProbes=

Takes an integer as argument. It is the number of unacknowledged probes to send before considering the connection dead and notifying the application layer. This controls the TCP_KEEPCNT socket option (see socket(7) and the TCP Keepalive HOWTO[2] for details.) Default value is 9.
Added in version 216.

NoDelay=

Takes a boolean argument. TCP Nagles algorithm works by combining a number of small outgoing messages, and sending them all at once. This controls the TCP_NODELAY socket option (see tcp(7)). Defaults to false.
Added in version 216.

Priority=

Takes an integer argument controlling the priority for all traffic sent from this socket. This controls the SO_PRIORITY socket option (see socket(7) for details.).

DeferAcceptSec=

Takes time (in seconds) as argument. If set, the listening process will be awakened only when data arrives on the socket, and not immediately when connection is established. When this option is set, the TCP_DEFER_ACCEPT socket option will be used (see tcp(7)), and the kernel will ignore initial ACK packets without any data. The argument specifies the approximate amount of time the kernel should wait for incoming data before falling back to the normal behavior of honoring empty ACK packets. This option is beneficial for protocols where the client sends the data first (e.g. HTTP, in contrast to SMTP), because the server process will not be woken up unnecessarily before it can take any action.
If the client also uses the TCP_DEFER_ACCEPT option, the latency of the initial connection may be reduced, because the kernel will send data in the final packet establishing the connection (the third packet in the “three-way handshake”).
Disabled by default.
Added in version 216.

ReceiveBuffer=, SendBuffer=

Takes an integer argument controlling the receive or send buffer sizes of this socket, respectively. This controls the SO_RCVBUF and SO_SNDBUF socket options (see socket(7) for details.). The usual suffixes K, M, G are supported and are understood to the base of 1024.

IPTOS=

Takes an integer argument controlling the IP Type-Of-Service field for packets generated from this socket. This controls the IP_TOS socket option (see ip(7) for details.). Either a numeric string or one of low-delay, throughput, reliability or low-cost may be specified.

IPTTL=

Takes an integer argument controlling the IPv4 Time-To-Live/IPv6 Hop-Count field for packets generated from this socket. This sets the IP_TTL/IPV6_UNICAST_HOPS socket options (see ip(7) and ipv6(7) for details.)

Mark=

Takes an integer value. Controls the firewall mark of packets generated by this socket. This can be used in the firewall logic to filter packets from this socket. This sets the SO_MARK socket option. See iptables(8) for details.

ReusePort=

Takes a boolean value. If true, allows multiple bind(2)s to this TCP or UDP port. This controls the SO_REUSEPORT socket option. See socket(7) for details.
Added in version 206.

SmackLabel=, SmackLabelIPIn=, SmackLabelIPOut=

Takes a string value. Controls the extended attributes “security.SMACK64”, “security.SMACK64IPIN” and “security.SMACK64IPOUT”, respectively, i.e. the security label of the FIFO, or the security label for the incoming or outgoing connections of the socket, respectively. See Smack[3] for details.
Added in version 196.

SELinuxContextFromNet=

Takes a boolean argument. When true, systemd will attempt to figure out the SELinux label used for the instantiated service from the information handed by the peer over the network. Note that only the security level is used from the information provided by the peer. Other parts of the resulting SELinux context originate from either the target binary that is effectively triggered by socket unit or from the value of the SELinuxContext= option. This configuration option applies only when activated service is passed in single socket file descriptor, i.e. service instances that have standard input connected to a socket or services triggered by exactly one socket unit. Also note that this option is useful only when MLS/MCS SELinux policy is deployed. Defaults to “false”.
Added in version 217.

PipeSize=

Takes a size in bytes. Controls the pipe buffer size of FIFOs configured in this socket unit. See fcntl(2) for details. The usual suffixes K, M, G are supported and are understood to the base of 1024.

MessageQueueMaxMessages=, MessageQueueMessageSize=

These two settings take integer values and control the mq_maxmsg field or the mq_msgsize field, respectively, when creating the message queue. Note that either none or both of these variables need to be set. See mq_setattr(3) for details.

FreeBind=

Takes a boolean value. Controls whether the socket can be bound to non-local IP addresses. This is useful to configure sockets listening on specific IP addresses before those IP addresses are successfully configured on a network interface. This sets the IP_FREEBIND/IPV6_FREEBIND socket option. For robustness reasons it is recommended to use this option whenever you bind a socket to a specific IP address. Defaults to false.

Transparent=

Takes a boolean value. Controls the IP_TRANSPARENT/IPV6_TRANSPARENT socket option. Defaults to false.

Broadcast=

Takes a boolean value. This controls the SO_BROADCAST socket option, which allows broadcast datagrams to be sent from this socket. Defaults to false.

PassCredentials=

Takes a boolean value. This controls the SO_PASSCRED socket option, which allows AF_UNIX sockets to receive the credentials of the sending process in an ancillary message. Defaults to false.

PassSecurity=

Takes a boolean value. This controls the SO_PASSSEC socket option, which allows AF_UNIX sockets to receive the security context of the sending process in an ancillary message. Defaults to false.

PassPacketInfo=

Takes a boolean value. This controls the IP_PKTINFO, IPV6_RECVPKTINFO, NETLINK_PKTINFO or PACKET_AUXDATA socket options, which enable reception of additional per-packet metadata as ancillary message, on AF_INET, AF_INET6, AF_UNIX and AF_PACKET sockets. Defaults to false.
Added in version 246.

Timestamping=

Takes one of “off”, “us” (alias: “usec”, “μs”) or “ns” (alias: “nsec”). This controls the SO_TIMESTAMP or SO_TIMESTAMPNS socket options, and enables whether ingress network traffic shall carry timestamping metadata. Defaults to off.
Added in version 247.

TCPCongestion=

Takes a string value. Controls the TCP congestion algorithm used by this socket. Should be one of “westwood”, “reno”, “cubic”, “lp” or any other available algorithm supported by the IP stack. This setting applies only to stream sockets.

ExecStartPre=, ExecStartPost=

Takes one or more command lines, which are executed before or after the listening sockets/FIFOs are created and bound, respectively. The first token of the command line must be an absolute filename, then followed by arguments for the process. Multiple command lines may be specified following the same scheme as used for ExecStartPre= of service unit files.

ExecStopPre=, ExecStopPost=

Additional commands that are executed before or after the listening sockets/FIFOs are closed and removed, respectively. Multiple command lines may be specified following the same scheme as used for ExecStartPre= of service unit files.

TimeoutSec=

Configures the time to wait for the commands specified in ExecStartPre=, ExecStartPost=, ExecStopPre= and ExecStopPost= to finish. If a command does not exit within the configured time, the socket will be considered failed and be shut down again. All commands still running will be terminated forcibly via SIGTERM, and after another delay of this time with SIGKILL. (See KillMode= in systemd.kill(5).) Takes a unit-less value in seconds, or a time span value such as “5min 20s”. Pass “0” to disable the timeout logic. Defaults to DefaultTimeoutStartSec= from the manager configuration file (see systemd-system.conf(5)).

Service=

Specifies the service unit name to activate on incoming traffic. This setting is only allowed for sockets with Accept=no. It defaults to the service that bears the same name as the socket (with the suffix replaced). In most cases, it should not be necessary to use this option. Note that setting this parameter might result in additional dependencies to be added to the unit (see above).

RemoveOnStop=

Takes a boolean argument. If enabled, any file nodes created by this socket unit are removed when it is stopped. This applies to AF_UNIX sockets in the file system, POSIX message queues, FIFOs, as well as any symlinks to them configured with Symlinks=. Normally, it should not be necessary to use this option, and is not recommended as services might continue to run after the socket unit has been terminated and it should still be possible to communicate with them via their file system node. Defaults to off.
Added in version 214.

Symlinks=

Takes a list of file system paths. The specified paths will be created as symlinks to the AF_UNIX socket path or FIFO path of this socket unit. If this setting is used, only one AF_UNIX socket in the file system or one FIFO may be configured for the socket unit. Use this option to manage one or more symlinked alias names for a socket, binding their lifecycle together. Note that if creation of a symlink fails this is not considered fatal for the socket unit, and the socket unit may still start. If an empty string is assigned, the list of paths is reset. Defaults to an empty list.
Added in version 214.

FileDescriptorName=

Assigns a name to all file descriptors this socket unit encapsulates. This is useful to help activated services identify specific file descriptors, if multiple fds are passed. Services may use the sd_listen_fds_with_names(3) call to acquire the names configured for the received file descriptors. Names may contain any ASCII character, but must exclude control characters and “:”, and must be at most 255 characters in length. If this setting is not used, the file descriptor name defaults to the name of the socket unit, including its .socket suffix.
Added in version 227.

TriggerLimitIntervalSec=, TriggerLimitBurst=

Configures a limit on how often this socket unit may be activated within a specific time interval. The TriggerLimitIntervalSec= setting may be used to configure the length of the time interval in the usual time units “us”, “ms”, “s”, “min”, “h”, … and defaults to 2s (See systemd.time(7) for details on the various time units understood). The TriggerLimitBurst= setting takes a positive integer value and specifies the number of permitted activations per time interval, and defaults to 200 for Accept=yes sockets (thus by default permitting 200 activations per 2s), and 20 otherwise (20 activations per 2s). Set either to 0 to disable any form of trigger rate limiting.
If the limit is hit, the socket unit is placed into a failure mode, and will not be connectible anymore until restarted. Note that this limit is enforced before the service activation is enqueued.
Compare with PollLimitIntervalSec=/PollLimitBurst= described below, which implements a temporary slowdown if a socket unit is flooded with incoming traffic, as opposed to the permanent failure state TriggerLimitIntervalSec=/TriggerLimitBurst= results in.
Added in version 230.

PollLimitIntervalSec=, PollLimitBurst=

Configures a limit on how often polling events on the file descriptors backing this socket unit will be considered. This pair of settings is similar to TriggerLimitIntervalSec=/TriggerLimitBurst= but instead of putting a (fatal) limit on the activation frequency puts a (transient) limit on the polling frequency. The expected parameter syntax and range are identical to that of the aforementioned options, and can be disabled the same way.
If the polling limit is hit polling is temporarily disabled on it until the specified time window passes. The polling limit hence slows down connection attempts if hit, but unlike the trigger limit wont cause permanent failures. Its the recommended mechanism to deal with DoS attempts through packet flooding.
The polling limit is enforced per file descriptor to listen on, as opposed to the trigger limit which is enforced for the entire socket unit. This distinction matters for socket units that listen on multiple file descriptors (i.e. have multiple ListenXYZ= stanzas).
These setting defaults to 150 (in case of Accept=yes) and 15 (otherwise) polling events per 2s. This is considerably lower than the default values for the trigger limit (see above) and means that the polling limit should typically ensure the trigger limit is never hit, unless one of them is reconfigured or disabled.
Added in version 255.

PassFileDescriptorsToExec=

Takes a boolean argument. Defaults to off. If enabled, file descriptors created by the socket unit are passed to ExecStartPost=, ExecStopPre=, and ExecStopPost= commands from the socket unit. The passed file descriptors can be accessed with sd_listen_fds(3) as if the commands were invoked from the associated service units. Note that ExecStartPre= command cannot access socket file descriptors.
Added in version 256.

Check systemd.unit(5), systemd.exec(5), and systemd.kill(5) for more settings.

NOTES

USB FunctionFS

https://docs.kernel.org/usb/functionfs.html

TCP Keepalive HOWTO

http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/

Smack

https://docs.kernel.org/admin-guide/LSM/Smack.html

Socket Activation

https://0pointer.de/blog/projects/socket-activation.html

Socket Activation, part II

https://0pointer.de/blog/projects/socket-activation2.html

Converting inetd Services

https://0pointer.de/blog/projects/inetd.html

Socket Activated Internet Services and OS Containers

https://0pointer.de/blog/projects/socket-activated-containers.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

59 - Linux cli command ppm

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ppm and provides detailed information about the command ppm, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ppm.

NAME 🖥️ ppm 🖥️

Netpbm color image format

DESCRIPTION

This program is part of Netpbm(1) .

The PPM format is a lowest common denominator color image file format.

It should be noted that this format is egregiously inefficient. It is highly redundant, while containing a lot of information that the human eye can’t even discern. Furthermore, the format allows very little information about the image besides basic color, which means you may have to couple a file in this format with other independent information to get any decent use out of it. However, it is very easy to write and analyze programs to process this format, and that is the point.

It should also be noted that files often conform to this format in every respect except the precise semantics of the sample values. These files are useful because of the way PPM is used as an intermediary format. They are informally called PPM files, but to be absolutely precise, you should indicate the variation from true PPM. For example, “PPM using the red, green, and blue colors that the scanner in question uses.”

The name “PPM” is an acronym derived from “Portable Pixel Map.” Images in this format (or a precursor of it) were once also called “portable pixmaps.”

THE FORMAT

The format definition is as follows. You can use the libnetpbm(1) C subroutine library to read and interpret the format conveniently and accurately.

A PPM file consists of a sequence of one or more PPM images. There are no data, delimiters, or padding before, after, or between images.

Each PPM image consists of the following:

A “magic number” for identifying the file type. A ppm image’s magic number is the two characters “P6”.
Whitespace (blanks, TABs, CRs, LFs).
A width, formatted as ASCII characters in decimal.
Whitespace.
A height, again in ASCII decimal.
Whitespace.
The maximum color value (Maxval), again in ASCII decimal. Must be less than 65536 and more than zero.
A single whitespace character (usually a newline).
A raster of Height rows, in order from top to bottom. Each row consists of Width pixels, in order from left to right. Each pixel is a triplet of red, green, and blue samples, in that order. Each sample is represented in pure binary by either 1 or 2 bytes. If the Maxval is less than 256, it is 1 byte. Otherwise, it is 2 bytes. The most significant byte is first.

A row of an image is horizontal. A column is vertical. The pixels in the image are square and contiguous.

In the raster, the sample values are “nonlinear.” They are proportional to the intensity of the ITU-R Recommendation BT.709 red, green, and blue in the pixel, adjusted by the BT.709 gamma transfer function. (That transfer function specifies a gamma number of 2.2 and has a linear section for small intensities). A value of Maxval for all three samples represents CIE D65 white and the most intense color in the color universe of which the image is part (the color universe is all the colors in all images to which this image might be compared).

BT.709’s range of channel values (16-240) is irrelevant to PPM.

ITU-R Recommendation BT.709 is a renaming of the former CCIR Recommendation 709. When CCIR was absorbed into its parent organization, the ITU, ca. 2000, the standard was renamed. This document once referred to the standard as CIE Rec. 709, but it isn’t clear now that CIE ever sponsored such a standard.

Note that another popular color space is the newer sRGB. A common variation from PPM is to substitute this color space for the one specified. You can use pnmgamma to convert between this variation and true PPM.

Note that a common variation from the PPM format is to have the sample values be “linear,” i.e. as specified above except without the gamma adjustment. pnmgamma takes such a PPM variant as input and produces a true PPM as output.

Strings starting with “#” may be comments, the same as with PBM(1) .

Note that you can use pamdepth to convert between a the format with 1 byte per sample and the one with 2 bytes per sample.

All characters referred to herein are encoded in ASCII. “newline” refers to the character known in ASCII as Line Feed or LF. A “white space” character is space, CR, LF, TAB, VT, or FF (I.e. what the ANSI standard C isspace() function calls white space).

Plain PPM

There is actually another version of the PPM format that is fairly rare: “plain” PPM format. The format above, which generally considered the normal one, is known as the “raw” PPM format. See pbm(1) for some commentary on how plain and raw formats relate to one another and how to use them.

The difference in the plain format is:

There is exactly one image in a file.
The magic number is P3 instead of P6.
Each sample in the raster is represented as an ASCII decimal number (of arbitrary size).
Each sample in the raster has white space before and after it. There must be at least one character of white space between any two samples, but there is no maximum. There is no particular separation of one pixel from another – just the required separation between the blue sample of one pixel from the red sample of the next pixel.
No line should be longer than 70 characters.

Here is an example of a small image in this format.

P3
# feep.ppm
4 4
15
 0  0  0    0  0  0    0  0  0   15  0 15
 0  0  0    0 15  7    0  0  0    0  0  0
 0  0  0    0  0  0    0 15  7    0  0  0
15  0 15    0  0  0    0  0  0    0  0  0

There is a newline character at the end of each of these lines.

Programs that read this format should be as lenient as possible, accepting anything that looks remotely like a PPM image.

INTERNET MEDIA TYPE

No Internet Media Type (aka MIME type, content type) for PPM has been registered with IANA, but the value image/x-portable-pixmap is conventional.

Note that the PNM Internet Media Type image/x-portable-anymap also applies.

FILE NAME

There are no requirements on the name of a PPM file, but the convention is to use the suffix “.ppm”. “pnm” is also conventional, for cases where distinguishing between the particular subformats of PNM is not convenient.

COMPATIBILITY

Before April 2000, a raw format PPM file could not have a maxval greater than 255. Hence, it could not have more than one byte per sample. Old programs may depend on this.

Before July 2000, there could be at most one image in a PPM file. As a result, most tools to process PPM files ignore (and don’t read) any data after the first image.

DOCUMENT SOURCE

This manual page was generated by the Netpbm tool ‘makeman’ from HTML source. The master documentation is at

http://netpbm.sourceforge.net/doc/ppm.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

60 - Linux cli command org.freedesktop.systemd1

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.freedesktop.systemd1 and provides detailed information about the command org.freedesktop.systemd1, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.freedesktop.systemd1.

NAME 🖥️ org.freedesktop.systemd1 🖥️

The D-Bus interface of systemd

INTRODUCTION

systemd(1) and its auxiliary daemons expose a number of APIs over D-Bus. This page only describes the various APIs exposed by the system and service manager itself. It does not cover the auxiliary daemons.

The service manager exposes a number of objects on the bus: one Manager object as a central entry point for clients along with individual objects for each unit and for each queued job. The unit objects implement a generic Unit interface as well as a type-specific interface. For example, service units implement both org.freedesktop.systemd1.Unit and org.freedesktop.system1.Service. The manager object can list unit and job objects or directly convert a unit name or job identifier to a bus path of the corresponding D-Bus object.

Properties exposing time values are usually encoded in microseconds (μs) on the bus, even if their corresponding settings in the unit files are in seconds.

PID 1 uses polkit[1] to allow access to privileged operations for unprivileged processes. Some operations (such as shutdown/reboot/suspend) are also available through the D-Bus API of logind, see org.freedesktop.login1(5).

THE MANAGER OBJECT

The main entry point object is available on the fixed /org/freedesktop/systemd1 object path:

node /org/freedesktop/systemd1 { interface org.freedesktop.systemd1.Manager { methods: GetUnit(in s name, out o unit); GetUnitByPID(in u pid, out o unit); GetUnitByInvocationID(in ay invocation_id, out o unit); GetUnitByControlGroup(in s cgroup, out o unit); GetUnitByPIDFD(in h pidfd, out o unit, out s unit_id, out ay invocation_id); LoadUnit(in s name, out o unit); StartUnit(in s name, in s mode, out o job); StartUnitWithFlags(in s name, in s mode, in t flags, out o job); StartUnitReplace(in s old_unit, in s new_unit, in s mode, out o job); StopUnit(in s name, in s mode, out o job); ReloadUnit(in s name, in s mode, out o job); RestartUnit(in s name, in s mode, out o job); TryRestartUnit(in s name, in s mode, out o job); ReloadOrRestartUnit(in s name, in s mode, out o job); ReloadOrTryRestartUnit(in s name, in s mode, out o job); EnqueueUnitJob(in s name, in s job_type, in s job_mode, out u job_id, out o job_path, out s unit_id, out o unit_path, out s job_type, out a(uosos) affected_jobs); KillUnit(in s name, in s whom, in i signal); QueueSignalUnit(in s name, in s whom, in i signal, in i value); CleanUnit(in s name, in as mask); FreezeUnit(in s name); ThawUnit(in s name); ResetFailedUnit(in s name); SetUnitProperties(in s name, in b runtime, in a(sv) properties); BindMountUnit(in s name, in s source, in s destination, in b read_only, in b mkdir); MountImageUnit(in s name, in s source, in s destination, in b read_only, in b mkdir, in a(ss) options); RefUnit(in s name); UnrefUnit(in s name); StartTransientUnit(in s name, in s mode, in a(sv) properties, in a(sa(sv)) aux, out o job); GetUnitProcesses(in s name, out a(sus) processes); AttachProcessesToUnit(in s unit_name, in s subcgroup, in au pids); AbandonScope(in s name); GetJob(in u id, out o job); GetJobAfter(in u id, out a(usssoo) jobs); GetJobBefore(in u id, out a(usssoo) jobs); CancelJob(in u id); ClearJobs(); ResetFailed(); SetShowStatus(in s mode); ListUnits(out a(ssssssouso) units); ListUnitsFiltered(in as states, out a(ssssssouso) units); ListUnitsByPatterns(in as states, in as patterns, out a(ssssssouso) units); ListUnitsByNames(in as names, out a(ssssssouso) units); ListJobs(out a(usssoo) jobs); Subscribe(); Unsubscribe(); Dump(out s output); DumpUnitsMatchingPatterns(in as patterns, out s output); DumpByFileDescriptor(out h fd); DumpUnitsMatchingPatternsByFileDescriptor(in as patterns, out h fd); Reload(); @org.freedesktop.DBus.Method.NoReply(“true”) Reexecute(); @org.freedesktop.systemd1.Privileged(“true”) Exit(); @org.freedesktop.systemd1.Privileged(“true”) Reboot(); @org.freedesktop.systemd1.Privileged(“true”) SoftReboot(in s new_root); @org.freedesktop.systemd1.Privileged(“true”) PowerOff(); @org.freedesktop.systemd1.Privileged(“true”) Halt(); @org.freedesktop.systemd1.Privileged(“true”) KExec(); @org.freedesktop.systemd1.Privileged(“true”) SwitchRoot(in s new_root, in s init); SetEnvironment(in as assignments); UnsetEnvironment(in as names); UnsetAndSetEnvironment(in as names, in as assignments); EnqueueMarkedJobs(out ao jobs); ListUnitFiles(out a(ss) unit_files); ListUnitFilesByPatterns(in as states, in as patterns, out a(ss) unit_files); GetUnitFileState(in s file, out s state); EnableUnitFiles(in as files, in b runtime, in b force, out b carries_install_info, out a(sss) changes); DisableUnitFiles(in as files, in b runtime, out a(sss) changes); EnableUnitFilesWithFlags(in as files, in t flags, out b carries_install_info, out a(sss) changes); DisableUnitFilesWithFlags(in as files, in t flags, out a(sss) changes); DisableUnitFilesWithFlagsAndInstallInfo(in as files, in t flags, out b carries_install_info, out a(sss) changes); ReenableUnitFiles(in as files, in b runtime, in b force, out b carries_install_info, out a(sss) changes); LinkUnitFiles(in as files, in b runtime, in b force, out a(sss) changes); PresetUnitFiles(in as files, in b runtime, in b force, out b carries_install_info, out a(sss) changes); PresetUnitFilesWithMode(in as files, in s mode, in b runtime, in b force, out b carries_install_info, out a(sss) changes); MaskUnitFiles(in as files, in b runtime, in b force, out a(sss) changes); UnmaskUnitFiles(in as files, in b runtime, out a(sss) changes); RevertUnitFiles(in as files, out a(sss) changes); SetDefaultTarget(in s name, in b force, out a(sss) changes); GetDefaultTarget(out s name); PresetAllUnitFiles(in s mode, in b runtime, in b force, out a(sss) changes); AddDependencyUnitFiles(in as files, in s target, in s type, in b runtime, in b force, out a(sss) changes); GetUnitFileLinks(in s name, in b runtime, out as links); SetExitCode(in y number); LookupDynamicUserByName(in s name, out u uid); LookupDynamicUserByUID(in u uid, out s name); GetDynamicUsers(out a(us) users); DumpUnitFileDescriptorStore(in s name, out a(suuutuusu) entries); StartAuxiliaryScope(in s name, in ah pidfds, in t flags, in a(sv) properties, out o job); signals: UnitNew(s id, o unit); UnitRemoved(s id, o unit); JobNew(u id, o job, s unit); JobRemoved(u id, o job, s unit, s result); StartupFinished(t firmware, t loader, t kernel, t initrd, t userspace, t total); UnitFilesChanged(); Reloading(b active); properties: @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Version = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Features = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Virtualization = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ConfidentialVirtualization = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Architecture = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Tainted = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t FirmwareTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t FirmwareTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LoaderTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LoaderTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t KernelTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t KernelTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t InitRDTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t InitRDTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t UserspaceTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t UserspaceTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t FinishTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t FinishTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t ShutdownStartTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t ShutdownStartTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t SecurityStartTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t SecurityStartTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t SecurityFinishTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t SecurityFinishTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t GeneratorsStartTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t GeneratorsStartTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t GeneratorsFinishTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t GeneratorsFinishTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t UnitsLoadStartTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t UnitsLoadStartTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t UnitsLoadFinishTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t UnitsLoadFinishTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t UnitsLoadTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t UnitsLoadTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t InitRDSecurityStartTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t InitRDSecurityStartTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t InitRDSecurityFinishTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t InitRDSecurityFinishTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t InitRDGeneratorsStartTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t InitRDGeneratorsStartTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t InitRDGeneratorsFinishTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t InitRDGeneratorsFinishTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t InitRDUnitsLoadStartTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t InitRDUnitsLoadStartTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t InitRDUnitsLoadFinishTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t InitRDUnitsLoadFinishTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) @org.freedesktop.systemd1.Privileged(“true”) readwrite s LogLevel = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) @org.freedesktop.systemd1.Privileged(“true”) readwrite s LogTarget = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly u NNames = …; readonly u NFailedUnits = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly u NJobs = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly u NInstalledJobs = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly u NFailedJobs = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly d Progress = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as Environment = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ConfirmSpawn = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b ShowStatus = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as UnitPath = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s DefaultStandardOutput = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s DefaultStandardError = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s WatchdogDevice = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t WatchdogLastPingTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t WatchdogLastPingTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) @org.freedesktop.systemd1.Privileged(“true”) readwrite t RuntimeWatchdogUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) @org.freedesktop.systemd1.Privileged(“true”) readwrite t RuntimeWatchdogPreUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) @org.freedesktop.systemd1.Privileged(“true”) readwrite s RuntimeWatchdogPreGovernor = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) @org.freedesktop.systemd1.Privileged(“true”) readwrite t RebootWatchdogUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) @org.freedesktop.systemd1.Privileged(“true”) readwrite t KExecWatchdogUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) @org.freedesktop.systemd1.Privileged(“true”) readwrite b ServiceWatchdogs = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ControlGroup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s SystemState = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly y ExitCode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultTimerAccuracyUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultTimeoutStartUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultTimeoutStopUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t DefaultTimeoutAbortUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultDeviceTimeoutUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultRestartUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultStartLimitIntervalUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u DefaultStartLimitBurst = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b DefaultCPUAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b DefaultBlockIOAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b DefaultIOAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b DefaultIPAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b DefaultMemoryAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b DefaultTasksAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitCPU = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitCPUSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitFSIZE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitFSIZESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitDATA = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitDATASoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitSTACK = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitSTACKSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitCORE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitCORESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitRSS = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitRSSSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitNOFILE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitNOFILESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitAS = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitASSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitNPROC = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitNPROCSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitMEMLOCK = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitMEMLOCKSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitLOCKS = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitLOCKSSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitSIGPENDING = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitSIGPENDINGSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitMSGQUEUE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitMSGQUEUESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitNICE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitNICESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitRTPRIO = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitRTPRIOSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitRTTIME = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DefaultLimitRTTIMESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t DefaultTasksMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t DefaultMemoryPressureThresholdUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s DefaultMemoryPressureWatch = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t TimerSlackNSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s DefaultOOMPolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i DefaultOOMScoreAdjust = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s CtrlAltDelBurstAction = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u SoftRebootsCount = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; };

Methods

Note that many of the methods exist twice: once on the Manager object and once on the respective unit objects. This is to optimize access times so that methods that belong to unit objects do not have to be called with a resolved unit path, but can be called with only the unit id, too.

GetUnit() may be used to get the unit object path for a unit name. It takes the unit name and returns the object path. If a unit has not been loaded yet by this name this method will fail.

GetUnitByPID() may be used to get the unit object path of the unit a process ID belongs to. It takes a UNIX PID and returns the object path. The PID must refer to an existing system process. GetUnitByPIDFD() may be used to query with a Linux PIDFD (see: pidfd_open(2)) instead of a PID, which is safer as UNIX PIDs can be recycled. The latter method returns the unit id and the invocation id together with the unit object path.

LoadUnit() is similar to GetUnit() but will load the unit from disk if possible.

StartUnit() enqueues a start job and possibly depending jobs. It takes the unit to activate and a mode string as arguments. The mode needs to be one of “replace”, “fail”, “isolate”, “ignore-dependencies”, or “ignore-requirements”. If “replace”, the method will start the unit and its dependencies, possibly replacing already queued jobs that conflict with it. If “fail”, the method will start the unit and its dependencies, but will fail if this would change an already queued job. If “isolate”, the method will start the unit in question and terminate all units that arent dependencies of it. If “ignore-dependencies”, it will start a unit but ignore all its dependencies. If “ignore-requirements”, it will start a unit but only ignore the requirement dependencies. It is not recommended to make use of the latter two options. On reply, if successful, this method returns the newly created job object which has been enqueued for asynchronous activation. Callers that want to track the outcome of the actual start operation need to monitor the result of this job. This can be achieved in a race-free manner by first subscribing to the JobRemoved() signal, then calling StartUnit() and using the returned job object to filter out unrelated JobRemoved() signals, until the desired one is received, which will then carry the result of the start operation.

StartUnitReplace() is similar to StartUnit() but replaces a job that is queued for one unit by a job for another unit.

StartUnitWithFlags() is similar to StartUnit() but allows the caller to pass an extra flags parameter, which does not support any flags for now, and is reserved for future extensions.

StopUnit() is similar to StartUnit() but stops the specified unit rather than starting it. Note that the “isolate” mode is invalid for this method.

ReloadUnit(), RestartUnit(), TryRestartUnit(), ReloadOrRestartUnit(), or ReloadOrTryRestartUnit() may be used to restart and/or reload a unit. These methods take similar arguments as StartUnit(). Reloading is done only if the unit is already running and fails otherwise. If a service is restarted that isnt running, it will be started unless the “Try” flavor is used in which case a service that isnt running is not affected by the restart. The “ReloadOrRestart” flavors attempt a reload if the unit supports it and use a restart otherwise.

EnqueueMarkedJobs() creates reload/restart jobs for units which have been appropriately marked, see Markers property above. This is equivalent to calling TryRestartUnit() or ReloadOrTryRestartUnit() for the marked units.

BindMountUnit() can be used to bind mount new files or directories into a running service mount namespace. If supported by the kernel, any prior mount on the selected target will be replaced by the new mount. If not supported, any prior mount will be over-mounted, but remain pinned and inaccessible.

MountImageUnit() can be used to mount new images into a running service mount namespace. If supported by the kernel, any prior mount on the selected target will be replaced by the new mount. If not supported, any prior mount will be over-mounted, but remain pinned and inaccessible.

KillUnit() may be used to kill (i.e. send a signal to) all processes of a unit. It takes the unit name, an enum who and a UNIX signal number to send. The who enum is one of “main”, “control” or “all”. If “main”, only the main process of the unit is killed. If “control”, only the control process of the unit is killed. If “all”, all processes are killed. A “control” process is for example a process that is configured via ExecStop= and is spawned in parallel to the main daemon process in order to shut it down.

QueueSignalUnit() is similar to KillUnit() but may be used to enqueue a POSIX Realtime Signal (i.e. SIGRTMIN+… and SIGRTMAX-…) to the selected process(es). Takes the same parameters as KillUnit() with one additional argument: an integer that is passed in the sival_int value accompanying the queued signal. See sigqueue(3) for details.

GetJob() returns the job object path for a specific job, identified by its id.

CancelJob() cancels a specific job identified by its numeric ID. This operation is also available in the Cancel() method of Job objects (see below) and exists primarily to reduce the necessary round trips to execute this operation. Note that this will not have any effect on jobs whose execution has already begun.

ClearJobs() flushes the job queue, removing all jobs that are still queued. Note that this does not have any effect on jobs whose execution has already begun. It only flushes jobs that are queued and have not yet begun execution.

ResetFailedUnit() resets the “failed” state of a specific unit.

ResetFailed() resets the “failed” state of all units.

ListUnits() returns an array of all currently loaded units. Note that units may be known by multiple names at the same time, and hence there might be more unit names loaded than actual units behind them. The array consists of structures with the following elements:

·
The primary unit name as string

·
The human readable description string

·
The load state (i.e. whether the unit file has been loaded successfully)

·
The active state (i.e. whether the unit is currently started or not)

·
The sub state (a more fine-grained version of the active state that is specific to the unit type, which the active state is not)

·
A unit that is being followed in its state by this unit, if there is any, otherwise the empty string.

·
The unit object path

·
If there is a job queued for the job unit, the numeric job id, 0 otherwise

·
The job type as string

·
The job object path

ListJobs() returns an array with all currently queued jobs. Returns an array consisting of structures with the following elements:

·
The numeric job id

·
The primary unit name for this job

·
The job type as string

·
The job state as string

·
The job object path

·
The unit object path

Subscribe() enables most bus signals to be sent out. Clients which are interested in signals need to call this method. Signals are only sent out if at least one client invoked this method. Unsubscribe() reverts the signal subscription that Subscribe() implements. It is not necessary to invoke Unsubscribe() as clients are tracked. Signals are no longer sent out as soon as all clients which previously asked for Subscribe() either closed their connection to the bus or invoked Unsubscribe().

Dump() returns a text dump of the internal service manager state. This is a privileged, low-level debugging interface only. The returned string is supposed to be readable exclusively by developers, and not programmatically. Theres no interface stability on the returned string guaranteed, and new fields may be added any time, and old fields removed. The general structure may be rearranged drastically between releases. This is exposed by systemd-analyze(1)s dump command. Similarly, DumpUnitsMatchingPatterns() returns the internal state of units whose names match the glob expressions specified in the patterns argument. The DumpByFileDescriptor()/DumpUnitsMatchingPatternsByFileDescriptor() methods are identical to Dump()/DumpUnitsMatchingPatterns(), but return data serialized into a file descriptor (the client should read the text data from it until hitting EOF). Given the size limits on D-Bus messages and the possibly large size of the returned strings, DumpByFileDescriptor()/DumpUnitsMatchingPatternsByFileDescriptor() are usually the preferred interface, since it ensures the data can be passed reliably from the service manager to the client. Note though that they cannot work when communicating with the service manager remotely, as file descriptors are strictly local to a system. All the Dump*() methods are rate limited for unprivileged users.

Reload() may be invoked to reload all unit files.

Reexecute() may be invoked to reexecute the main manager process. It will serialize its state, reexecute, and deserizalize the state again. This is useful for upgrades and is a more comprehensive version of Reload().

Exit() may be invoked to ask the manager to exit. This is not available for the system manager and is useful only for user session managers.

Reboot(), PowerOff(), Halt(), KExec() and SoftReboot() may be used to ask for immediate reboot, powering down, halt, kexec based reboot, or soft reboot of the system. Note that this does not shut down any services and immediately transitions into the later shutdown operation. These functions are normally only called as the last step of shutdown and should not be called directly. To shut down the machine, it is generally a better idea to invoke Reboot(), RebootWithFlags() or PowerOff() on the systemd-logind manager object; see org.freedesktop.login1(5) for more information. SoftReboot() accepts an argument indicating the path for the root file system to activate for the next boot cycle. If an empty string is specified the /run/nextroot/ path is used if it exists.

SwitchRoot() may be used to transition to a new root directory. This is intended to be used in the initrd, and also to transition from the host system into a shutdown initrd. The method takes two arguments: the new root directory (which needs to be specified) and an init binary path (which may be left empty, in which case it is automatically searched for). The state of the system manager will be serialized before the transition. After the transition, the manager binary on the main system is invoked and replaces the old PID 1. All state will then be deserialized.

SetEnvironment() may be used to alter the environment block that is passed to all spawned processes. It takes a string array of environment variable assignments. Any previously set environment variables will be overridden.

UnsetEnvironment() may be used to unset environment variables. It takes a string array of environment variable names. All variables specified will be unset (if they have been set previously) and no longer be passed to all spawned processes. This method has no effect for variables that were previously not set, but will not fail in that case.

UnsetAndSetEnvironment() is a combination of UnsetEnvironment() and SetEnvironment(). It takes two lists. The first list contains variables to unset, the second one contains assignments to set. If a variable is listed in both, the variable is set after this method returns, i.e. the set list overrides the unset list.

ListUnitFiles() returns an array of unit names and their enablement status. Note that ListUnit() returns a list of units currently loaded into memory, while ListUnitFiles() returns a list of unit files that were found on disk. Note that while most units are read directly from a unit file with the same name, some units are not backed by files and some files (templates) cannot directly be loaded as units but need to be instantiated instead.

GetUnitFileState() returns the current enablement status of a specific unit file.

EnableUnitFiles() may be used to enable one or more units in the system (by creating symlinks to them in /etc/ or /run/). It takes a list of unit files to enable (either just file names or full absolute paths if the unit files are residing outside the usual unit search paths) and two booleans: the first controls whether the unit shall be enabled for runtime only (true, /run/), or persistently (false, /etc/). The second one controls whether symlinks pointing to other units shall be replaced if necessary. This method returns one boolean and an array of the changes made. The boolean signals whether the unit files contained any enablement information (i.e. an [Install] section). The changes array consists of structures with three strings: the type of the change (one of “symlink” or “unlink”), the file name of the symlink and the destination of the symlink. Note that most of the following calls return a changes list in the same format.

Similarly, DisableUnitFiles() disables one or more units in the system, i.e. removes all symlinks to them in /etc/ and /run/.

The EnableUnitFilesWithFlags() and DisableUnitFilesWithFlags() take in options as flags instead of booleans to allow for extendability, defined as follows:

#define SD_SYSTEMD_UNIT_RUNTIME (UINT64_C(1) « 0) #define SD_SYSTEMD_UNIT_FORCE (UINT64_C(1) « 1) #define SD_SYSTEMD_UNIT_PORTABLE (UINT64_C(1) « 2)

SD_SYSTEMD_UNIT_RUNTIME will enable or disable the unit for runtime only, SD_SYSTEMD_UNIT_FORCE controls whether symlinks pointing to other units shall be replaced if necessary. SD_SYSTEMD_UNIT_PORTABLE will add or remove the symlinks in /etc/systemd/system.attached and /run/systemd/system.attached.

DisableUnitFilesWithFlagsAndInstallInfo() is similar to DisableUnitFilesWithFlags() and takes the same arguments, but returns a boolean to indicate whether the unit files contain any enablement information, like EnableUnitFiles(). The changes made are still returned in an array.

Similarly, ReenableUnitFiles() applies the changes to one or more units that would result from disabling and enabling the unit quickly one after the other in an atomic fashion. This is useful to apply updated [Install] information contained in unit files.

Similarly, LinkUnitFiles() links unit files (that are located outside of the usual unit search paths) into the unit search path.

Similarly, PresetUnitFiles() enables/disables one or more unit files according to the preset policy. See systemd.preset(7) for more information.

Similarly, MaskUnitFiles() masks unit files and UnmaskUnitFiles() unmasks them again.

SetDefaultTarget() changes the default.target link. See bootup(7) for more information.

GetDefaultTarget() retrieves the name of the unit to which default.target is aliased.

SetUnitProperties() may be used to modify certain unit properties at runtime. Not all properties may be changed at runtime, but many resource management settings (primarily those listed in systemd.resource-control(5)) may. The changes are applied instantly and stored on disk for future boots, unless runtime is true, in which case the settings only apply until the next reboot. name is the name of the unit to modify. properties are the settings to set, encoded as an array of property name and value pairs. Note that this is not a dictionary! Also note that when setting array properties with this method usually results in appending to the pre-configured array. To reset the configured arrays, set the property to an empty array first and then append to it.

StartTransientUnit() may be used to create and start a transient unit which will be released as soon as it is not running or referenced anymore or the system is rebooted. name is the unit name including its suffix and must be unique. mode is the same as in StartUnit(), properties contains properties of the unit, specified like in SetUnitProperties(). aux is currently unused and should be passed as an empty array. See the New Control Group Interface[2] for more information how to make use of this functionality for resource control purposes.

DumpUnitFileDescriptorStore() returns an array with information about the file descriptors currently in the file descriptor store of the specified unit. This call is equivalent to DumpFileDescriptorStore() on the org.freedesktop.systemd1.Service. For further details, see below.

StartAuxiliaryScope() creates a new scope unit from a service where calling process resides. Set of processes that will be migrated to newly created scope is passed in as an array of pidfds. This is useful for creating auxiliary scopes that should contain worker processes and their lifecycle shouldnt be bound to a lifecycle of the service, e.g. they should continue running after the restart of the service. Note that the main PID of the service can not be migrated to an auxiliary scope. Also, flags argument must be 0 and is reserved for future extensions.

CleanUnit() deletes the configuration, state, logs, cache and runtime data directories and clear out the file descriptors store for the unit, as specified in the mask parameters. The possible values are “configuration”, “state”, “logs”, “cache”, “runtime”, “fdstore”, and “all”.

Signals

Note that most signals are sent out only after Subscribe() has been invoked by at least one client. Make sure to invoke this method when subscribing to these signals!

UnitNew() and UnitRemoved() are sent out each time a new unit is loaded or unloaded. Note that this has little to do with whether a unit is available on disk or not, and simply reflects the units that are currently loaded into memory. The signals take two parameters: the primary unit name and the object path.

JobNew() and JobRemoved() are sent out each time a new job is queued or dequeued. Both signals take the numeric job ID, the bus path and the primary unit name for this job as arguments. JobRemoved() also includes a result string which is one of “done”, “canceled”, “timeout”, “failed”, “dependency”, or “skipped”. “done” indicates successful execution of a job. “canceled” indicates that a job has been canceled (via CancelJob() above) before it finished execution (this doesnt necessarily mean though that the job operation is actually cancelled too, see above). “timeout” indicates that the job timeout was reached. “failed” indicates that the job failed. “dependency” indicates that a job this job depended on failed and the job hence was removed as well. “skipped” indicates that a job was skipped because it didnt apply to the units current state.

StartupFinished() is sent out when startup finishes. It carries six microsecond timespan values, each indicating how much boot time has been spent in the firmware (if known), in the boot loader (if known), in the kernel initialization phase, in the initrd (if known), in userspace and in total. These values may also be calculated from the FirmwareTimestampMonotonic, LoaderTimestampMonotonic, InitRDTimestampMonotonic, UserspaceTimestampMonotonic, and FinishTimestampMonotonic properties (see below).

UnitFilesChanged() is sent out each time the list of enabled or masked unit files on disk have changed.

Reloading() is sent out immediately before a daemon reload is done (with the boolean parameter set to True) and after a daemon reload is completed (with the boolean parameter set to False). This may be used by UIs to optimize UI updates.

Properties

Most properties simply reflect the respective options in /etc/systemd/system.conf and the kernel command line.

The others:

Version encodes the version string of the running systemd instance. Note that the version string is purely informational. It should not be parsed and one may not assume the version to be formatted in any particular way. We take the liberty to change the versioning scheme at any time and it is not part of the public API.

Features encodes the features that have been enabled and disabled for this build. Enabled options are prefixed with “+”, disabled options with “-”.

Tainted encodes taint flags as a colon-separated list. When systemd detects it is running on a system with a certain problem, it will set an appropriate taint flag. Taints may be used to lower the chance of bogus bug reports. The following taints are currently known:

“unmerged-usr”

/bin, /sbin and /lib* are not symlinks to their counterparts under /usr/. For more information on this issue consult The Case for the /usr Merge[3].
Added in version 252.

“unmerged-bin”

/usr/sbin is not a symlink to /usr/bin/.
Added in version 256.

“var-run-bad”

/run/ does not exist or /var/run is not a symlink to /run/.
Added in version 252.

“cgroupsv1”

The system is using the deprecated cgroup v1 hierarchy.
Added in version 252.

“local-hwclock”

The local hardware clock (RTC) is configured to be in local time rather than UTC.
Added in version 252.

“support-ended”

The system is running past the end of support declared by the vendor. See the description of SUPPORT_END= in os-release(5).
Added in version 252.

“old-kernel”

The system is running a kernel version that is older than the minimum supported by this version of systemd.
Added in version 252.

“overflowuid-not-65534”, “overflowgid-not-65534”

The kernel overflow UID or GID have a value other than 65534.
Added in version 252.

“short-uid-range”, “short-gid-range”

The UID or GID range assigned to the running systemd instance covers less than 0…65534.
Added in version 252.

FirmwareTimestamp, FirmwareTimestampMonotonic, LoaderTimestamp, LoaderTimestampMonotonic, KernelTimestamp, KernelTimestampMonotonic, InitRDTimestamp, InitRDTimestampMonotonic, UserspaceTimestamp, UserspaceTimestampMonotonic, FinishTimestamp, FinishTimestampMonotonic, ShutdownStartTimestamp and ShutdownStartTimestampMonotonic encode CLOCK_REALTIME and CLOCK_MONOTONIC microsecond timestamps taken when the firmware first began execution, when the boot loader first began execution, when the kernel first began execution, when the initrd first began execution, when the main systemd instance began execution, when all queued startup jobs finished execution and finally, when a shutdown operation first began execution. These values are useful for determining boot-time performance. Note that as monotonic time begins with the kernel startup, the KernelTimestampMonotonic timestamp will always be 0 and FirmwareTimestampMonotonic and LoaderTimestampMonotonic are to be read as negative values. Also, not all fields are always available, depending on the used firmware, boot loader or initrd implementation. In these cases the respective pairs of timestamps are both 0, indicating that no data is available.

UnitsLoadTimestamp and UnitsLoadTimestampMonotonic encode CLOCK_REALTIME and CLOCK_MONOTONIC microseconds timestamps (as described above). The timestamps are taken every time when the manager starts loading unit files.

Similarly, the SecurityStartTimestamp, GeneratorsStartTimestamp and LoadUnitTimestamp (as well as their monotonic and stop counterparts) expose performance data for uploading the security policies to the kernel (such as the SELinux, IMA, or SMACK policies), for running the generator tools and for loading the unit files.

NNames encodes how many unit names are currently known. This only includes names of units that are currently loaded and can be more than the amount of actually loaded units since units may have more than one name.

NJobs encodes how many jobs are currently queued.

NInstalledJobs encodes how many jobs have ever been queued in total.

NFailedJobs encodes how many jobs have ever failed in total.

Progress encodes boot progress as a floating point value between 0.0 and 1.0. This value begins at 0.0 at early-boot and ends at 1.0 when boot is finished and is based on the number of executed and queued jobs. After startup, this field is always 1.0 indicating a finished boot.

Environment encodes the environment block passed to all executed services. It may be altered with bus calls such as SetEnvironment() (see above).

UnitPath encodes the currently active unit file search path. It is an array of file system paths encoded as strings.

SoftRebootsCount encodes how many soft-reboots were successfully completed since the last full boot. Starts at “0”.

Virtualization contains a short ID string describing the virtualization technology the system runs in. On bare-metal hardware this is the empty string. Otherwise, it contains an identifier such as “kvm”, “vmware” and so on. For a full list of IDs see systemd-detect-virt(1). Note that only the “innermost” virtualization technology is exported here. This detects both full-machine virtualizations (VMs) and shared-kernel virtualization (containers).

ConfidentialVirtualization contains a short ID string describing the confidential virtualization technology the system runs in. On bare-metal hardware this is the empty string. Otherwise, it contains an identifier such as “sev”, “sev-es”, “sev-snp”, “tdx” and so on. For a full list of IDs see systemd-detect-virt(1) .

.PP Architecture contains a short ID string describing the architecture the systemd instance is running on. This follows the same vocabulary as ConditionArchitectures=.

ControlGroup contains the root control group path of this system manager. Note that the root path is encoded as the empty string here (not as “/”!), so that it can be appended to /sys/fs/cgroup/systemd easily. This value will be set to the empty string for the host instance and some other string for container instances.

AccessSELinuxContext contains the SELinux context that is used to control access to the unit. Its read from the unit file when it is loaded and cached until the service manager is reloaded. This property contains an empty string if SELinux is not used or if no label could be read (for example because the unit is not backed by a file on disk).

SystemState contains the current state of the system manager. The possible values are:

“initializing”

The system is booting, and basic.target has not been reached yet.

“starting”

The system is booting, and basic.target has been reached.

“running”

The system has finished booting, and no units are in the failed state.

“degraded”

The system has finished booting, but some units are in the failed state.

“maintenance”

The system has finished booting, but it has been put in rescue or maintenance mode.

“stopping”

The system is shutting down.

Security

Read access is generally granted to all clients. Additionally, for unprivileged clients, some operations are allowed through the polkit privilege system. Operations which modify unit state (StartUnit(), StopUnit(), KillUnit(), QueueSignalUnit(), RestartUnit() and similar, SetProperty()) require org.freedesktop.systemd1.manage-units. Operations which modify unit file enablement state (EnableUnitFiles(), DisableUnitFiles(), EnableUnitFilesWithFlags(), DisableUnitFilesWithFlags(), ReenableUnitFiles(), LinkUnitFiles(), PresetUnitFiles(), MaskUnitFiles(), and similar) require org.freedesktop.systemd1.manage-unit-files. Operations which modify the exported environment (SetEnvironment(), UnsetEnvironment(), UnsetAndSetEnvironment()) require org.freedesktop.systemd1.set-environment. Reload() and Reexecute() require org.freedesktop.systemd1.reload-daemon. Operations which dump internal state require org.freedesktop.systemd1.bypass-dump-ratelimit to avoid rate limits.

UNIT OBJECTS

node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice { interface org.freedesktop.systemd1.Unit { methods: Start(in s mode, out o job); Stop(in s mode, out o job); Reload(in s mode, out o job); Restart(in s mode, out o job); TryRestart(in s mode, out o job); ReloadOrRestart(in s mode, out o job); ReloadOrTryRestart(in s mode, out o job); EnqueueJob(in s job_type, in s job_mode, out u job_id, out o job_path, out s unit_id, out o unit_path, out s job_type, out a(uosos) affected_jobs); Kill(in s whom, in i signal); QueueSignal(in s whom, in i signal, in i value); ResetFailed(); SetProperties(in b runtime, in a(sv) properties); Ref(); Unref(); Clean(in as mask); Freeze(); Thaw(); properties: @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Id = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as Names = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s Following = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as Requires = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as Requisite = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as Wants = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as BindsTo = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as PartOf = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as Upholds = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as RequiredBy = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as RequisiteOf = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as WantedBy = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as BoundBy = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as UpheldBy = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ConsistsOf = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as Conflicts = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ConflictedBy = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as Before = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as After = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as OnSuccess = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as OnSuccessOf = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as OnFailure = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as OnFailureOf = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as Triggers = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as TriggeredBy = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as PropagatesReloadTo = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ReloadPropagatedFrom = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as PropagatesStopTo = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as StopPropagatedFrom = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as JoinsNamespaceOf = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as SliceOf = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as RequiresMountsFor = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as WantsMountsFor = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as Documentation = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Description = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s AccessSELinuxContext = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s LoadState = …; readonly s ActiveState = …; readonly s FreezerState = …; readonly s SubState = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s FragmentPath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s SourcePath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as DropInPaths = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s UnitFileState = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s UnitFilePreset = …; readonly t StateChangeTimestamp = …; readonly t StateChangeTimestampMonotonic = …; readonly t InactiveExitTimestamp = …; readonly t InactiveExitTimestampMonotonic = …; readonly t ActiveEnterTimestamp = …; readonly t ActiveEnterTimestampMonotonic = …; readonly t ActiveExitTimestamp = …; readonly t ActiveExitTimestampMonotonic = …; readonly t InactiveEnterTimestamp = …; readonly t InactiveEnterTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b CanStart = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b CanStop = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b CanReload = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b CanIsolate = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as CanClean = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b CanFreeze = …; readonly (uo) Job = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b StopWhenUnneeded = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RefuseManualStart = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RefuseManualStop = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b AllowIsolate = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b DefaultDependencies = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SurviveFinalKillSignal = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s OnSuccessJobMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s OnFailureJobMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b IgnoreOnIsolate = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b NeedDaemonReload = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as Markers = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t JobTimeoutUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t JobRunningTimeoutUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s JobTimeoutAction = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s JobTimeoutRebootArgument = …; readonly b ConditionResult = …; readonly b AssertResult = …; readonly t ConditionTimestamp = …; readonly t ConditionTimestampMonotonic = …; readonly t AssertTimestamp = …; readonly t AssertTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sbbsi) Conditions = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sbbsi) Asserts = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (ss) LoadError = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b Transient = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b Perpetual = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t StartLimitIntervalUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u StartLimitBurst = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StartLimitAction = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s FailureAction = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i FailureActionExitStatus = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s SuccessAction = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i SuccessActionExitStatus = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RebootArgument = …; readonly ay InvocationID = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s CollectMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as Refs = […, …]; readonly a(ss) ActivationDetails = […]; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; };

Methods

Start(), Stop(), Reload(), Restart(), TryRestart(), ReloadOrRestart(), ReloadOrTryRestart(), Kill(), QueueSignal(), ResetFailed(), and SetProperties() implement the same operation as the respective methods on the Manager object (see above). However, these methods operate on the unit object and hence do not take a unit name parameter. Invoking the methods directly on the Manager object has the advantage of not requiring a GetUnit() call to get the unit object for a specific unit name. Calling the methods on the Manager object is hence a round trip optimization.

Properties

Id contains the primary name of the unit.

Names contains all names of the unit, including the primary name that is also exposed in Id.

Following either contains the empty string or contains the name of another unit that this unit follows in state. This is used for some device units which reflect the unit state machine of another unit, and which other unit this is might possibly change.

Requires, RequiresOverridable, Requisite, RequisiteOverridable, Wants, BindsTo, RequiredBy, RequiredByOverridable, WantedBy, BoundBy, Conflicts, ConflictedBy, Before, After, OnFailure, Triggers, TriggeredBy, PropagatesReloadTo, and RequiresMountsFor contain arrays which encode the dependencies and their inverse dependencies (where this applies) as configured in the unit file or determined automatically.

Description contains the human readable description string for the unit.

SourcePath contains the path to a configuration file this unit is automatically generated from in case it is not a native unit (in which case it contains the empty string). For example, all mount units generated from /etc/fstab have this field set to /etc/fstab.

Documentation contains a string array with URLs of documentation for this unit.

LoadState contains a state value that reflects whether the configuration file of this unit has been loaded. The following states are currently defined: “loaded”, “error”, and “masked”. “loaded” indicates that the configuration was successfully loaded. “error” indicates that the configuration failed to load. The LoadError field (see below) contains information about the cause of this failure. “masked” indicates that the unit is currently masked out (i.e. symlinked to /dev/null or empty). Note that the LoadState is fully orthogonal to the ActiveState (see below) as units without valid loaded configuration might be active (because configuration might have been reloaded at a time where a unit was already active).

ActiveState contains a state value that reflects whether the unit is currently active or not. The following states are currently defined: “active”, “reloading”, “inactive”, “failed”, “activating”, and “deactivating”. “active” indicates that unit is active (obviously…). “reloading” indicates that the unit is active and currently reloading its configuration. “inactive” indicates that it is inactive and the previous run was successful or no previous run has taken place yet. “failed” indicates that it is inactive and the previous run was not successful (more information about the reason for this is available on the unit type specific interfaces, for example for services in the Result property, see below). “activating” indicates that the unit has previously been inactive but is currently in the process of entering an active state. Conversely “deactivating” indicates that the unit is currently in the process of deactivation.

SubState encodes states of the same state machine that ActiveState covers, but knows more fine-grained states that are unit-type-specific. Where ActiveState only covers six high-level states, SubState covers possibly many more low-level unit-type-specific states that are mapped to the six high-level states. Note that multiple low-level states might map to the same high-level state, but not vice versa. Not all high-level states have low-level counterparts on all unit types. At this point the low-level states are not documented here, and are more likely to be extended later on than the common high-level states explained above.

FragmentPath contains the unit file path this unit was read from, if there is one (if not, it contains the empty string).

UnitFileState encodes the install state of the unit file of FragmentPath. It currently knows the following states: “enabled”, “enabled-runtime”, “linked”, “linked-runtime”, “masked”, “masked-runtime”, “static”, “disabled”, and “invalid”. “enabled” indicates that a unit file is permanently enabled. “enable-runtime” indicates the unit file is only temporarily enabled and will no longer be enabled after a reboot (that means, it is enabled via /run/ symlinks, rather than /etc/). “linked” indicates that a unit is linked into /etc/ permanently. “linked-runtime” indicates that a unit is linked into /run/ temporarily (until the next reboot). “masked” indicates that the unit file is masked permanently. “masked-runtime” indicates that it is masked in /run/ temporarily (until the next reboot). “static” indicates that the unit is statically enabled, i.e. always enabled and doesnt need to be enabled explicitly. “invalid” indicates that it could not be determined whether the unit file is enabled.

InactiveExitTimestamp, InactiveExitTimestampMonotonic, ActiveEnterTimestamp, ActiveEnterTimestampMonotonic, ActiveExitTimestamp, ActiveExitTimestampMonotonic, InactiveEnterTimestamp, and InactiveEnterTimestampMonotonic contain CLOCK_REALTIME and CLOCK_MONOTONIC 64-bit microsecond timestamps of the last time a unit left the inactive state, entered the active state, exited the active state, or entered an inactive state. These are the points in time where the unit transitioned “inactive”/“failed” → “activating”, “activating” → “active”, “active” → “deactivating”, and finally “deactivating” → “inactive”/“failed”. The fields are 0 in case such a transition has not yet been recorded on this boot.

CanStart, CanStop, and CanReload encode as booleans whether the unit supports the start, stop or reload operations. Even if a unit supports such an operation, the client might not necessary have the necessary privileges to execute them.

CanIsolate encodes as a boolean whether the unit may be started in isolation mode.

Job encodes the job ID and job object path of the job currently scheduled or executed for this unit, if there is any. If no job is scheduled or executed, the job id field will be 0.

StopWhenUnneeded, RefuseManualStart, RefuseManualStop, AllowIsolate, DefaultDependencies, OnFailureIsolate, IgnoreOnIsolate, IgnoreOnSnapshot map directly to the corresponding configuration booleans in the unit file.

NeedDaemonReload is a boolean that indicates whether the configuration file this unit is loaded from (i.e. FragmentPath or SourcePath) has changed since the configuration was read and hence whether a configuration reload is recommended.

Markers is an array of string flags that can be set using SetUnitProperties() to indicate that the service should be reloaded or restarted. Currently known values are “needs-restart” and “needs-reload”. Package scripts may use the first to mark units for later restart when a new version of the package is installed. Configuration management scripts may use the second to mark units for a later reload when the configuration is adjusted. Those flags are not set by the manager, except to unset as appropriate when the unit is stopped, restarted, or reloaded.

JobTimeoutUSec maps directly to the corresponding configuration setting in the unit file.

ConditionTimestamp and ConditionTimestampMonotonic contain the CLOCK_REALTIME/CLOCK_MONOTONIC microsecond timestamps of the last time the configured conditions of the unit have been checked or 0 if they have never been checked. Conditions are checked when a unit is requested to start.

ConditionResult contains the condition result of the last time the configured conditions of this unit were checked.

Conditions contains all configured conditions of the unit. For each condition, five fields are given: condition type (e.g. ConditionPathExists), whether the condition is a trigger condition, whether the condition is reversed, the right hand side of the condition (e.g. the path in case of ConditionPathExists), and the status. The status can be 0, in which case the condition hasnt been checked yet, a positive value, in which case the condition passed, or a negative value, in which case the condition is not met. Currently only 0, +1, and -1 are used, but additional values may be used in the future, retaining the meaning of zero/positive/negative values.

LoadError contains a pair of strings. If the unit failed to load (as encoded in LoadState, see above), then this will include a D-Bus error pair consisting of the error ID and an explanatory human readable string of what happened. If it loaded successfully, this will be a pair of empty strings.

Transient contains a boolean that indicates whether the unit was created as a transient unit (i.e. via StartTransientUnit() on the manager object).

ActivationDetails contains a list of string pairs, key and value, that describe the event that caused the unit to be activated, if any. The key describes the information (e.g.: trigger_unit, with value foo.service). This is only filled in if the unit was triggered by a Path or Timer unit, and it is only provided in a best effort fashion: it is not guaranteed to be set, and it is not guaranteed to be the only trigger. It is only guaranteed to be a valid trigger that caused the activation job to be enqueued and complete successfully. The key value pairs correspond (in lowercase) to the environment variables described in the “Environment Variables Set or Propagated by the Service Manager” section in systemd.exec(5). Note that new key value pair may be added at any time in future versions. Existing entries will not be removed.

Security

Similarly to methods on the Manager object, read-only access is allowed for everyone. All operations are allowed for clients with the CAP_SYS_ADMIN capability or when the org.freedesktop.systemd1.manage-units privilege is granted by polkit.

SERVICE UNIT OBJECTS

All service unit objects implement the org.freedesktop.systemd1.Service interface (described here) in addition to the generic org.freedesktop.systemd1.Unit interface (see above).

node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice { interface org.freedesktop.systemd1.Service { methods: BindMount(in s source, in s destination, in b read_only, in b mkdir); MountImage(in s source, in s destination, in b read_only, in b mkdir, in a(ss) options); DumpFileDescriptorStore(out a(suuutuusu) entries); GetProcesses(out a(sus) processes); AttachProcesses(in s subcgroup, in au pids); properties: @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Type = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ExitType = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Restart = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RestartMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s PIDFile = …; readonly s NotifyAccess = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t RestartUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u RestartSteps = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t RestartMaxDelayUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t RestartUSecNext = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t TimeoutStartUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t TimeoutStopUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t TimeoutAbortUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s TimeoutStartFailureMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s TimeoutStopFailureMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t RuntimeMaxUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t RuntimeRandomizedExtraUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t WatchdogUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t WatchdogTimestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t WatchdogTimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RootDirectoryStartOnly = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RemainAfterExit = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b GuessMainPID = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (aiai) RestartPreventExitStatus = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (aiai) RestartForceExitStatus = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (aiai) SuccessExitStatus = …; readonly u MainPID = …; readonly u ControlPID = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s BusName = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u FileDescriptorStoreMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly u NFileDescriptorStore = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s FileDescriptorStorePreserve = …; readonly s StatusText = …; readonly i StatusErrno = …; readonly s Result = …; readonly s ReloadResult = …; readonly s CleanResult = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s USBFunctionDescriptors = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s USBFunctionStrings = …; readonly u UID = …; readonly u GID = …; readonly u NRestarts = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s OOMPolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sst) OpenFile = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i ReloadSignal = …; readonly t ExecMainStartTimestamp = …; readonly t ExecMainStartTimestampMonotonic = …; readonly t ExecMainExitTimestamp = …; readonly t ExecMainExitTimestampMonotonic = …; readonly t ExecMainHandoffTimestamp = …; readonly t ExecMainHandoffTimestampMonotonic = …; readonly u ExecMainPID = …; readonly i ExecMainCode = …; readonly i ExecMainStatus = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasbttttuii) ExecCondition = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasasttttuii) ExecConditionEx = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasbttttuii) ExecStartPre = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasasttttuii) ExecStartPreEx = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasbttttuii) ExecStart = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasasttttuii) ExecStartEx = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasbttttuii) ExecStartPost = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasasttttuii) ExecStartPostEx = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasbttttuii) ExecReload = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasasttttuii) ExecReloadEx = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasbttttuii) ExecStop = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasasttttuii) ExecStopEx = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasbttttuii) ExecStopPost = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasasttttuii) ExecStopPostEx = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s Slice = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ControlGroup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t ControlGroupId = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryPeak = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemorySwapCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemorySwapPeak = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryZSwapCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryAvailable = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t EffectiveMemoryMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t EffectiveMemoryHigh = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUUsageNSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay EffectiveCPUs = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay EffectiveMemoryNodes = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t TasksCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t EffectiveTasksMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPIngressBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPIngressPackets = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPEgressBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPEgressPackets = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOReadBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOReadOperations = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOWriteBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOWriteOperations = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b Delegate = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as DelegateControllers = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s DelegateSubgroup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b CPUAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupCPUWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUShares = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupCPUShares = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUQuotaPerSecUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUQuotaPeriodUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay AllowedCPUs = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay StartupAllowedCPUs = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay AllowedMemoryNodes = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay StartupAllowedMemoryNodes = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b IOAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupIOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IODeviceWeight = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOReadBandwidthMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOWriteBandwidthMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOReadIOPSMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOWriteIOPSMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IODeviceLatencyTargetUSec = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b BlockIOAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t BlockIOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupBlockIOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) BlockIODeviceWeight = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) BlockIOReadBandwidth = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) BlockIOWriteBandwidth = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b MemoryAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t DefaultMemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t DefaultStartupMemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t DefaultMemoryMin = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryMin = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryHigh = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryHigh = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemorySwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemorySwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryZSwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryZSwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b MemoryZSwapWriteback = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryLimit = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s DevicePolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(ss) DeviceAllow = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b TasksAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t TasksMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b IPAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iayu) IPAddressAllow = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iayu) IPAddressDeny = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as IPIngressFilterPath = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as IPEgressFilterPath = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as DisableControllers = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ManagedOOMSwap = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ManagedOOMMemoryPressure = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly u ManagedOOMMemoryPressureLimit = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ManagedOOMPreference = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(ss) BPFProgram = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iiqq) SocketBindAllow = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iiqq) SocketBindDeny = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly (bas) RestrictNetworkInterfaces = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s MemoryPressureWatch = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryPressureThresholdUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iiss) NFTSet = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b CoredumpReceive = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as Environment = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sb) EnvironmentFiles = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as PassEnvironment = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as UnsetEnvironment = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u UMask = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitCPU = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitCPUSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitFSIZE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitFSIZESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitDATA = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitDATASoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitSTACK = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitSTACKSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitCORE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitCORESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRSS = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRSSSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNOFILE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNOFILESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitAS = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitASSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNPROC = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNPROCSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitMEMLOCK = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitMEMLOCKSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitLOCKS = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitLOCKSSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitSIGPENDING = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitSIGPENDINGSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitMSGQUEUE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitMSGQUEUESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNICE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNICESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRTPRIO = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRTPRIOSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRTTIME = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRTTIMESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s WorkingDirectory = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootDirectory = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootImage = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ss) RootImageOptions = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay RootHash = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootHashPath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay RootHashSignature = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootHashSignaturePath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootVerity = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RootEphemeral = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ExtensionDirectories = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sba(ss)) ExtensionImages = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ssba(ss)) MountImages = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i OOMScoreAdjust = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t CoredumpFilter = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i Nice = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i IOSchedulingClass = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i IOSchedulingPriority = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i CPUSchedulingPolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i CPUSchedulingPriority = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay CPUAffinity = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b CPUAffinityFromNUMA = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i NUMAPolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay NUMAMask = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t TimerSlackNSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b CPUSchedulingResetOnFork = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b NonBlocking = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardInput = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardInputFileDescriptorName = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay StandardInputData = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardOutput = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardOutputFileDescriptorName = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardError = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardErrorFileDescriptorName = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s TTYPath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b TTYReset = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b TTYVHangup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b TTYVTDisallocate = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly q TTYRows = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly q TTYColumns = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i SyslogPriority = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s SyslogIdentifier = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SyslogLevelPrefix = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i SyslogLevel = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i SyslogFacility = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i LogLevelMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LogRateLimitIntervalUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u LogRateLimitBurst = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly aay LogExtraFields = [[…], …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(bs) LogFilterPatterns = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s LogNamespace = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i SecureBits = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t CapabilityBoundingSet = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t AmbientCapabilities = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s User = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Group = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b DynamicUser = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SetLoginEnvironment = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RemoveIPC = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(say) SetCredential = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(say) SetCredentialEncrypted = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ss) LoadCredential = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ss) LoadCredentialEncrypted = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ImportCredential = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as SupplementaryGroups = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s PAMName = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ReadWritePaths = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ReadOnlyPaths = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as InaccessiblePaths = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ExecPaths = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as NoExecPaths = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ExecSearchPath = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t MountFlags = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateTmp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateDevices = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectClock = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectKernelTunables = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectKernelModules = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectKernelLogs = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectControlGroups = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateNetwork = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateUsers = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateMounts = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateIPC = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ProtectHome = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ProtectSystem = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SameProcessGroup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s UtmpIdentifier = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s UtmpMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bs) SELinuxContext = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bs) AppArmorProfile = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bs) SmackProcessLabel = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b IgnoreSIGPIPE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b NoNewPrivileges = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bas) SystemCallFilter = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as SystemCallArchitectures = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i SystemCallErrorNumber = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bas) SystemCallLog = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Personality = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b LockPersonality = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bas) RestrictAddressFamilies = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sst) RuntimeDirectorySymlink = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RuntimeDirectoryPreserve = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u RuntimeDirectoryMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as RuntimeDirectory = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sst) StateDirectorySymlink = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u StateDirectoryMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as StateDirectory = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sst) CacheDirectorySymlink = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u CacheDirectoryMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as CacheDirectory = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sst) LogsDirectorySymlink = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u LogsDirectoryMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as LogsDirectory = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u ConfigurationDirectoryMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ConfigurationDirectory = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t TimeoutCleanUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b MemoryDenyWriteExecute = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RestrictRealtime = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RestrictSUIDSGID = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t RestrictNamespaces = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bas) RestrictFileSystems = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ssbt) BindPaths = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ssbt) BindReadOnlyPaths = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ss) TemporaryFileSystem = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b MountAPIVFS = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s KeyringMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ProtectProc = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ProcSubset = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectHostname = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b MemoryKSM = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s NetworkNamespacePath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s IPCNamespacePath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootImagePolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s MountImagePolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ExtensionImagePolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s KillMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i KillSignal = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i RestartKillSignal = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i FinalKillSignal = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SendSIGKILL = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SendSIGHUP = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i WatchdogSignal = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; interface org.freedesktop.systemd1.Unit { … }; };

Methods

BindMount() and MountImage() implement the same operations as the respective methods on the Manager object (see above). However, these methods operate on the service object and hence do not take a unit name parameter. Invoking the methods directly on the Manager object has the advantage of not requiring a GetUnit() call to get the unit object for a specific unit name. Calling the methods on the Manager object is hence a round trip optimization.

DumpFileDescriptorStore() returns an array with information about the file descriptors currently in the file descriptor store of the service. Each entry consists of a file descriptor name (i.e. the FDNAME= field), the file descriptor inode type and access mode as integer (i.e. a mode_t value, flags such as S_IFREG, S_IRUSR, …), the major and minor numbers of the device number of the file system backing the inode of the file descriptor, the inode number, the major and minor numbers of the device number if this refers to a character or block device node, a file system path pointing to the inode, and the file descriptor flags (i.e. O_RDWR, O_RDONLY, …).

Properties

Most properties of the Service interface map directly to the corresponding settings in service unit files. For the sake of brevity, heres a list of all exceptions only:

TimeoutStartUSec, TimeoutStopUSec and TimeoutAbortUSec contain the start, stop and abort timeouts, in microseconds. Note the slight difference in naming when compared to the matching unit file settings (see systemd.service(7)): these bus properties strictly use microseconds (and thus are suffixed …USec) while the unit file settings default to a time unit of seconds (and thus are suffixed …Sec), unless a different unit is explicitly specified. This reflects that fact that internally the service manager deals in microsecond units only, and the bus properties are a relatively low-level (binary) concept exposing this. The unit file settings on the other hand are relatively high-level (string-based) concepts and thus support more user friendly time specifications which default to second time units but allow other units too, if specified.

WatchdogTimestamp and WatchdogTimestampMonotonic contain CLOCK_REALTIME/CLOCK_MONOTONIC microsecond timestamps of the last watchdog ping received from the service, or 0 if none was ever received.

ExecStartPre, ExecStart, ExecStartPost, ExecReload, ExecStop, and ExecStop are arrays of structures where each struct contains: the binary path to execute; an array with all arguments to pass to the executed command, starting with argument 0; a boolean whether it should be considered a failure if the process exits uncleanly; two pairs of CLOCK_REALTIME/CLOCK_MONOTONIC microsecond timestamps when the process began and finished running the last time, or 0 if it never ran or never finished running; the PID of the process, or 0 if it has not run yet; the exit code and status of the last run. This field hence maps more or less to the corresponding setting in the service unit file but is augmented with runtime data.

LimitCPU (and related properties) map more or less directly to the corresponding settings in the service unit files except that if they arent set, their value is 18446744073709551615 (i.e. -1).

Capabilities contains the configured capabilities, as formatted with cap_to_text(3).

SecureBits, CapabilityBoundingSet, MountFlags also correspond to the configured settings of the unit files, but instead of being formatted as strings, they are encoded as the actual binary flags they are.

ExecMainStartTimestamp, ExecMainStartTimestampMonotonic, ExecMainExitTimestamp, ExecMainExitTimestampMonotonic, ExecMainHandoffTimestamp, ExecMainHandoffTimestampMonotonic, ExecMainPID, ExecMainCode, ExecMainStatus contain information about the main process of the service as far as it is known. The ExecMainStartTimestamp timestamps record when the main process of the service is created. ExecMainExitTimestamp timestamps record when the main process exit has been detected by the service manager. ExecMainHandoffTimestamp timestamps records when the service binary is about to be executed by systemd-executor (this timestamp is recorded regardless if the immediately following execve() system call succeeds or fails). This is often the same runtime information that is also maintained for ExecStart=. However, it deviates for services with Type=forking as well as services that use MAINPID= sd_notify() messages as the main process of the service is not forked off by the service manager directly in that case. These fields either contain information of the last run of the process or of the current running process.

MainPID and ControlPID contain the main and control PID of the service. The main PID is the current main PID of the service and is 0 when the service currently has no main PID. The control PID is the PID of the current start/stop/reload process running and is 0 if no such process is currently running. That means that ExecMainPID and MainPID differ in the way that the latter immediately reflects whether a main process is currently running while the latter possible contains information collected from the last run even if the process is no longer around.

StatusText contains the status text passed to the service manager via a call to sd_notify(3). This may be used by services to inform the service manager about its internal state with a nice explanatory string.

Result encodes the execution result of the last run of the service. It is useful to determine the reason a service failed if it is in the “failed” state (see ActiveState above). The following values are currently known: “success” is set if the unit didnt fail. “resources” indicates that not enough resources were available to fork off and execute the service processes. “timeout” indicates that a timeout occurred while executing a service operation. “exit-code” indicates that a service process exited with an unclean exit code. “signal” indicates that a service process exited with an uncaught signal. “core-dump” indicates that a service process exited uncleanly and dumped core. “watchdog” indicates that a service did not send out watchdog ping messages often enough. “start-limit” indicates that a service has been started too frequently in a specific time frame (as configured in StartLimitInterval, StartLimitBurst).

ControlGroup indicates the control group path the processes of this service unit are placed in.

The following properties map 1:1 to corresponding settings in the unit file: RootDirectory RootImage RootImageOptions RootVerity RootHash RootHashSignature MountImages ExtensionImages ExtensionDirectories see systemd.exec(5) for their meaning.

MemoryAvailable takes into account units and parents “MemoryMax” or “MemoryHigh” or physically available RAM versus given levels memory consumption and takes minimum. Beware that other units below the tightest parent slice may consume the memory quicker and less than reported value would remain for own allocation. It works better in conjunction with MemoryAccounting=yes on involved units.

DelegateSubgroup contains the cgroup subgroup to place invoked unit processes in. As configured by the option of the same name in unit files. This is set to the empty string when it does not apply or no subgroup has been configured.

RuntimeDirectorySymlink, StateDirectorySymlink, CacheDirectorySymlink and LogsDirectorySymlink respectively implement the destination parameter of the unit files settings RuntimeDirectory, StateDirectory, CacheDirectory and LogsDirectory, which will create a symlink of the given name to the respective directory. The messages take an unused flags parameter, reserved for future backward-compatible changes.

SOCKET UNIT OBJECTS

node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2esocket { interface org.freedesktop.systemd1.Socket { methods: GetProcesses(out a(sus) processes); AttachProcesses(in s subcgroup, in au pids); properties: @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s BindIPv6Only = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u Backlog = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t TimeoutUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s BindToDevice = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s SocketUser = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s SocketGroup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u SocketMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u DirectoryMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b Accept = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b FlushPending = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b Writable = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b KeepAlive = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t KeepAliveTimeUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t KeepAliveIntervalUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u KeepAliveProbes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t DeferAcceptUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b NoDelay = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i Priority = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t ReceiveBuffer = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t SendBuffer = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i IPTOS = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i IPTTL = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t PipeSize = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b FreeBind = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b Transparent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b Broadcast = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PassCredentials = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PassFileDescriptorsToExec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PassSecurity = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PassPacketInfo = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Timestamping = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RemoveOnStop = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ss) Listen = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as Symlinks = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i Mark = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u MaxConnections = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u MaxConnectionsPerSource = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly x MessageQueueMaxMessages = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly x MessageQueueMessageSize = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s TCPCongestion = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ReusePort = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s SmackLabel = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s SmackLabelIPIn = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s SmackLabelIPOut = …; readonly u ControlPID = …; readonly s Result = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly u NConnections = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly u NAccepted = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly u NRefused = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s FileDescriptorName = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i SocketProtocol = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t TriggerLimitIntervalUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u TriggerLimitBurst = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t PollLimitIntervalUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u PollLimitBurst = …; readonly u UID = …; readonly u GID = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasbttttuii) ExecStartPre = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasbttttuii) ExecStartPost = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasbttttuii) ExecStopPre = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasbttttuii) ExecStopPost = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s Slice = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ControlGroup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t ControlGroupId = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryPeak = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemorySwapCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemorySwapPeak = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryZSwapCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryAvailable = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t EffectiveMemoryMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t EffectiveMemoryHigh = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUUsageNSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay EffectiveCPUs = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay EffectiveMemoryNodes = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t TasksCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t EffectiveTasksMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPIngressBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPIngressPackets = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPEgressBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPEgressPackets = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOReadBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOReadOperations = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOWriteBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOWriteOperations = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b Delegate = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as DelegateControllers = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s DelegateSubgroup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b CPUAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupCPUWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUShares = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupCPUShares = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUQuotaPerSecUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUQuotaPeriodUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay AllowedCPUs = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay StartupAllowedCPUs = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay AllowedMemoryNodes = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay StartupAllowedMemoryNodes = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b IOAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupIOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IODeviceWeight = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOReadBandwidthMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOWriteBandwidthMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOReadIOPSMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOWriteIOPSMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IODeviceLatencyTargetUSec = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b BlockIOAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t BlockIOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupBlockIOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) BlockIODeviceWeight = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) BlockIOReadBandwidth = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) BlockIOWriteBandwidth = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b MemoryAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t DefaultMemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t DefaultStartupMemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t DefaultMemoryMin = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryMin = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryHigh = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryHigh = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemorySwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemorySwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryZSwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryZSwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b MemoryZSwapWriteback = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryLimit = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s DevicePolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(ss) DeviceAllow = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b TasksAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t TasksMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b IPAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iayu) IPAddressAllow = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iayu) IPAddressDeny = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as IPIngressFilterPath = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as IPEgressFilterPath = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as DisableControllers = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ManagedOOMSwap = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ManagedOOMMemoryPressure = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly u ManagedOOMMemoryPressureLimit = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ManagedOOMPreference = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(ss) BPFProgram = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iiqq) SocketBindAllow = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iiqq) SocketBindDeny = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly (bas) RestrictNetworkInterfaces = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s MemoryPressureWatch = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryPressureThresholdUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iiss) NFTSet = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b CoredumpReceive = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as Environment = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sb) EnvironmentFiles = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as PassEnvironment = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as UnsetEnvironment = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u UMask = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitCPU = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitCPUSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitFSIZE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitFSIZESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitDATA = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitDATASoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitSTACK = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitSTACKSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitCORE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitCORESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRSS = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRSSSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNOFILE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNOFILESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitAS = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitASSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNPROC = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNPROCSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitMEMLOCK = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitMEMLOCKSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitLOCKS = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitLOCKSSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitSIGPENDING = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitSIGPENDINGSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitMSGQUEUE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitMSGQUEUESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNICE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNICESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRTPRIO = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRTPRIOSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRTTIME = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRTTIMESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s WorkingDirectory = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootDirectory = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootImage = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ss) RootImageOptions = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay RootHash = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootHashPath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay RootHashSignature = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootHashSignaturePath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootVerity = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RootEphemeral = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ExtensionDirectories = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sba(ss)) ExtensionImages = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ssba(ss)) MountImages = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i OOMScoreAdjust = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t CoredumpFilter = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i Nice = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i IOSchedulingClass = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i IOSchedulingPriority = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i CPUSchedulingPolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i CPUSchedulingPriority = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay CPUAffinity = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b CPUAffinityFromNUMA = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i NUMAPolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay NUMAMask = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t TimerSlackNSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b CPUSchedulingResetOnFork = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b NonBlocking = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardInput = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardInputFileDescriptorName = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay StandardInputData = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardOutput = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardOutputFileDescriptorName = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardError = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardErrorFileDescriptorName = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s TTYPath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b TTYReset = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b TTYVHangup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b TTYVTDisallocate = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly q TTYRows = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly q TTYColumns = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i SyslogPriority = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s SyslogIdentifier = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SyslogLevelPrefix = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i SyslogLevel = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i SyslogFacility = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i LogLevelMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LogRateLimitIntervalUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u LogRateLimitBurst = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly aay LogExtraFields = [[…], …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(bs) LogFilterPatterns = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s LogNamespace = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i SecureBits = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t CapabilityBoundingSet = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t AmbientCapabilities = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s User = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Group = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b DynamicUser = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SetLoginEnvironment = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RemoveIPC = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(say) SetCredential = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(say) SetCredentialEncrypted = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ss) LoadCredential = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ss) LoadCredentialEncrypted = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ImportCredential = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as SupplementaryGroups = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s PAMName = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ReadWritePaths = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ReadOnlyPaths = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as InaccessiblePaths = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ExecPaths = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as NoExecPaths = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ExecSearchPath = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t MountFlags = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateTmp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateDevices = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectClock = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectKernelTunables = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectKernelModules = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectKernelLogs = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectControlGroups = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateNetwork = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateUsers = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateMounts = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateIPC = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ProtectHome = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ProtectSystem = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SameProcessGroup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s UtmpIdentifier = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s UtmpMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bs) SELinuxContext = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bs) AppArmorProfile = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bs) SmackProcessLabel = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b IgnoreSIGPIPE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b NoNewPrivileges = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bas) SystemCallFilter = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as SystemCallArchitectures = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i SystemCallErrorNumber = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bas) SystemCallLog = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Personality = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b LockPersonality = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bas) RestrictAddressFamilies = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sst) RuntimeDirectorySymlink = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RuntimeDirectoryPreserve = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u RuntimeDirectoryMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as RuntimeDirectory = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sst) StateDirectorySymlink = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u StateDirectoryMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as StateDirectory = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sst) CacheDirectorySymlink = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u CacheDirectoryMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as CacheDirectory = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sst) LogsDirectorySymlink = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u LogsDirectoryMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as LogsDirectory = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u ConfigurationDirectoryMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ConfigurationDirectory = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t TimeoutCleanUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b MemoryDenyWriteExecute = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RestrictRealtime = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RestrictSUIDSGID = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t RestrictNamespaces = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bas) RestrictFileSystems = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ssbt) BindPaths = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ssbt) BindReadOnlyPaths = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ss) TemporaryFileSystem = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b MountAPIVFS = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s KeyringMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ProtectProc = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ProcSubset = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectHostname = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b MemoryKSM = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s NetworkNamespacePath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s IPCNamespacePath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootImagePolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s MountImagePolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ExtensionImagePolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s KillMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i KillSignal = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i RestartKillSignal = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i FinalKillSignal = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SendSIGKILL = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SendSIGHUP = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i WatchdogSignal = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; interface org.freedesktop.systemd1.Unit { … }; };

PollLimitIntervalUSec/PollLimitBurst properties configure the polling limit for the socket unit. Expects a time in µs, resp. an unsigned integer. If either is set to zero the limiting feature is turned off.

Properties

Most of the properties map directly to the corresponding settings in socket unit files. As socket units can include ExecStartPre (and similar) fields which contain information about processes to execute. They also share most of the fields related to the execution context that Service objects expose (see above).

In addition to these properties there are the following:

NAccepted contains the accumulated number of connections ever accepted on this socket. This only applies to sockets with Accept set to “yes”, i.e. those where systemd is responsible for accepted connections.

Similarly NConnections contains the number of currently open connections on this socket. It only applies only to socket units with Accept set to “yes”.

Result encodes the reason why a socket unit failed if it is in the “failed” state (see ActiveState above). The values “success”, “resources”, “timeout”, “exit-code”, “signal” and “core-dump” have the same meaning as they have for the corresponding field of service units (see above). In addition to that, the value “service-failed-permanent” indicates that the service of this socket failed continuously.

FlushPending specifies whether to flush the socket just before entering the listening state. This setting only applies to sockets with Accept= set to “no”.

TARGET UNIT OBJECTS

node /org/freedesktop/systemd1/unit/basic_2etarget { interface org.freedesktop.systemd1.Target { }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; interface org.freedesktop.systemd1.Unit { … }; };

Target units have neither type-specific methods nor properties.

DEVICE UNIT OBJECTS

All device unit objects implement the org.freedesktop.systemd1.Device interface (described here) in addition to the generic org.freedesktop.systemd1.Unit interface (see above).

node /org/freedesktop/systemd1/unit/dev_2dttyS0_2edevice { interface org.freedesktop.systemd1.Device { properties: readonly s SysFSPath = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; interface org.freedesktop.systemd1.Unit { … }; };

Properties

Device units only expose a single type-specific property:

SysFSPath contains the sysfs path of the kernel device this object corresponds to.

MOUNT UNIT OBJECTS

All mount unit objects implement the org.freedesktop.systemd1.Mount interface (described here) in addition to the generic org.freedesktop.systemd1.Unit interface (see above).

node /org/freedesktop/systemd1/unit/home_2emount { interface org.freedesktop.systemd1.Mount { methods: GetProcesses(out a(sus) processes); AttachProcesses(in s subcgroup, in au pids); properties: @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Where = …; readonly s What = …; readonly s Options = …; readonly s Type = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t TimeoutUSec = …; readonly u ControlPID = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u DirectoryMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SloppyOptions = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b LazyUnmount = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ForceUnmount = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ReadWriteOnly = …; readonly s Result = …; readonly u UID = …; readonly u GID = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasbttttuii) ExecMount = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasbttttuii) ExecUnmount = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasbttttuii) ExecRemount = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s Slice = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ControlGroup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t ControlGroupId = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryPeak = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemorySwapCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemorySwapPeak = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryZSwapCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryAvailable = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t EffectiveMemoryMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t EffectiveMemoryHigh = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUUsageNSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay EffectiveCPUs = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay EffectiveMemoryNodes = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t TasksCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t EffectiveTasksMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPIngressBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPIngressPackets = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPEgressBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPEgressPackets = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOReadBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOReadOperations = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOWriteBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOWriteOperations = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b Delegate = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as DelegateControllers = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s DelegateSubgroup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b CPUAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupCPUWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUShares = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupCPUShares = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUQuotaPerSecUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUQuotaPeriodUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay AllowedCPUs = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay StartupAllowedCPUs = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay AllowedMemoryNodes = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay StartupAllowedMemoryNodes = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b IOAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupIOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IODeviceWeight = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOReadBandwidthMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOWriteBandwidthMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOReadIOPSMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOWriteIOPSMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IODeviceLatencyTargetUSec = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b BlockIOAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t BlockIOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupBlockIOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) BlockIODeviceWeight = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) BlockIOReadBandwidth = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) BlockIOWriteBandwidth = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b MemoryAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t DefaultMemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t DefaultStartupMemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t DefaultMemoryMin = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryMin = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryHigh = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryHigh = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemorySwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemorySwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryZSwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryZSwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b MemoryZSwapWriteback = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryLimit = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s DevicePolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(ss) DeviceAllow = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b TasksAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t TasksMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b IPAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iayu) IPAddressAllow = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iayu) IPAddressDeny = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as IPIngressFilterPath = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as IPEgressFilterPath = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as DisableControllers = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ManagedOOMSwap = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ManagedOOMMemoryPressure = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly u ManagedOOMMemoryPressureLimit = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ManagedOOMPreference = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(ss) BPFProgram = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iiqq) SocketBindAllow = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iiqq) SocketBindDeny = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly (bas) RestrictNetworkInterfaces = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s MemoryPressureWatch = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryPressureThresholdUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iiss) NFTSet = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b CoredumpReceive = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as Environment = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sb) EnvironmentFiles = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as PassEnvironment = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as UnsetEnvironment = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u UMask = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitCPU = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitCPUSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitFSIZE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitFSIZESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitDATA = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitDATASoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitSTACK = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitSTACKSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitCORE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitCORESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRSS = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRSSSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNOFILE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNOFILESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitAS = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitASSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNPROC = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNPROCSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitMEMLOCK = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitMEMLOCKSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitLOCKS = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitLOCKSSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitSIGPENDING = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitSIGPENDINGSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitMSGQUEUE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitMSGQUEUESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNICE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNICESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRTPRIO = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRTPRIOSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRTTIME = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRTTIMESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s WorkingDirectory = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootDirectory = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootImage = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ss) RootImageOptions = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay RootHash = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootHashPath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay RootHashSignature = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootHashSignaturePath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootVerity = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RootEphemeral = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ExtensionDirectories = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sba(ss)) ExtensionImages = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ssba(ss)) MountImages = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i OOMScoreAdjust = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t CoredumpFilter = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i Nice = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i IOSchedulingClass = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i IOSchedulingPriority = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i CPUSchedulingPolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i CPUSchedulingPriority = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay CPUAffinity = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b CPUAffinityFromNUMA = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i NUMAPolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay NUMAMask = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t TimerSlackNSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b CPUSchedulingResetOnFork = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b NonBlocking = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardInput = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardInputFileDescriptorName = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay StandardInputData = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardOutput = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardOutputFileDescriptorName = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardError = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardErrorFileDescriptorName = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s TTYPath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b TTYReset = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b TTYVHangup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b TTYVTDisallocate = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly q TTYRows = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly q TTYColumns = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i SyslogPriority = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s SyslogIdentifier = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SyslogLevelPrefix = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i SyslogLevel = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i SyslogFacility = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i LogLevelMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LogRateLimitIntervalUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u LogRateLimitBurst = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly aay LogExtraFields = [[…], …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(bs) LogFilterPatterns = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s LogNamespace = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i SecureBits = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t CapabilityBoundingSet = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t AmbientCapabilities = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s User = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Group = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b DynamicUser = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SetLoginEnvironment = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RemoveIPC = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(say) SetCredential = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(say) SetCredentialEncrypted = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ss) LoadCredential = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ss) LoadCredentialEncrypted = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ImportCredential = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as SupplementaryGroups = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s PAMName = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ReadWritePaths = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ReadOnlyPaths = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as InaccessiblePaths = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ExecPaths = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as NoExecPaths = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ExecSearchPath = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t MountFlags = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateTmp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateDevices = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectClock = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectKernelTunables = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectKernelModules = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectKernelLogs = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectControlGroups = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateNetwork = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateUsers = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateMounts = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateIPC = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ProtectHome = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ProtectSystem = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SameProcessGroup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s UtmpIdentifier = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s UtmpMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bs) SELinuxContext = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bs) AppArmorProfile = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bs) SmackProcessLabel = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b IgnoreSIGPIPE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b NoNewPrivileges = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bas) SystemCallFilter = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as SystemCallArchitectures = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i SystemCallErrorNumber = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bas) SystemCallLog = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Personality = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b LockPersonality = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bas) RestrictAddressFamilies = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sst) RuntimeDirectorySymlink = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RuntimeDirectoryPreserve = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u RuntimeDirectoryMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as RuntimeDirectory = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sst) StateDirectorySymlink = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u StateDirectoryMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as StateDirectory = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sst) CacheDirectorySymlink = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u CacheDirectoryMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as CacheDirectory = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sst) LogsDirectorySymlink = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u LogsDirectoryMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as LogsDirectory = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u ConfigurationDirectoryMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ConfigurationDirectory = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t TimeoutCleanUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b MemoryDenyWriteExecute = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RestrictRealtime = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RestrictSUIDSGID = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t RestrictNamespaces = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bas) RestrictFileSystems = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ssbt) BindPaths = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ssbt) BindReadOnlyPaths = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ss) TemporaryFileSystem = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b MountAPIVFS = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s KeyringMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ProtectProc = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ProcSubset = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectHostname = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b MemoryKSM = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s NetworkNamespacePath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s IPCNamespacePath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootImagePolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s MountImagePolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ExtensionImagePolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s KillMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i KillSignal = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i RestartKillSignal = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i FinalKillSignal = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SendSIGKILL = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SendSIGHUP = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i WatchdogSignal = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; interface org.freedesktop.systemd1.Unit { … }; };

Properties

Most of the properties map directly to the corresponding settings in mount unit files. As mount units invoke the /usr/bin/mount command, their bus objects include implicit ExecMount (and similar) fields which contain information about processes to execute. They also share most of the fields related to the execution context that Service objects expose (see above). In addition to these properties there are the following:

ControlPID contains the PID of the currently running /usr/bin/mount or /usr/bin/umount command if there is one running, otherwise 0.

Result contains a value explaining why a mount unit failed if it failed. It can take the values “success”, “resources”, “timeout”, “exit-code”, “signal”, or “core-dump” which have the identical meaning as the corresponding values of the corresponding field of service unit objects (see above).

AUTOMOUNT UNIT OBJECTS

All automount unit objects implement the org.freedesktop.systemd1.Automount interface (described here) in addition to the generic org.freedesktop.systemd1.Unit interface (see above).

node /org/freedesktop/systemd1/unit/proc_2dsys_2dfs_2dbinfmt_5fmisc_2eautomount { interface org.freedesktop.systemd1.Automount { properties: @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Where = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ExtraOptions = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u DirectoryMode = …; readonly s Result = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t TimeoutIdleUSec = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; interface org.freedesktop.systemd1.Unit { … }; };

Properties

Most of the properties map directly to the corresponding settings in the automount unit files.

Result knows the values “success” and “resources” at this time. They have the same meanings as the corresponding values of the corresponding field of the Service object.

TIMER UNIT OBJECTS

All timer unit objects implement the org.freedesktop.systemd1.Timer interface (described here) in addition to the generic org.freedesktop.systemd1.Unit interface (see above).

node /org/freedesktop/systemd1/unit/systemd_2dtmpfiles_2dclean_2etimer { interface org.freedesktop.systemd1.Timer { properties: @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Unit = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(stt) TimersMonotonic = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sst) TimersCalendar = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b OnClockChange = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b OnTimezoneChange = …; readonly t NextElapseUSecRealtime = …; readonly t NextElapseUSecMonotonic = …; readonly t LastTriggerUSec = …; readonly t LastTriggerUSecMonotonic = …; readonly s Result = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t AccuracyUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t RandomizedDelayUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b FixedRandomDelay = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b Persistent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b WakeSystem = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RemainAfterElapse = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; interface org.freedesktop.systemd1.Unit { … }; };

Properties

Unit contains the name of the unit to activate when the timer elapses.

TimersMonotonic contains an array of structs that contain information about all monotonic timers of this timer unit. The structs contain a string identifying the timer base, which is one of “OnActiveUSec”, “OnBootUSec”, “OnStartupUSec”, “OnUnitActiveUSec”, or “OnUnitInactiveUSec” which correspond to the settings of the same names in the timer unit files; the microsecond offset from this timer base in monotonic time; the next elapsation point on the CLOCK_MONOTONIC clock, relative to its epoch.

TimersCalendar contains an array of structs that contain information about all realtime/calendar timers of this timer unit. The structs contain a string identifying the timer base, which may only be “OnCalendar” for now; the calendar specification string; the next elapsation point on the CLOCK_REALTIME clock, relative to its epoch.

NextElapseUSecRealtime contains the next elapsation point on the CLOCK_REALTIME clock in miscroseconds since the epoch, or 0 if this timer event does not include at least one calendar event.

Similarly, NextElapseUSecMonotonic contains the next elapsation point on the CLOCK_MONOTONIC clock in microseconds since the epoch, or 0 if this timer event does not include at least one monotonic event.

Result knows the values “success” and “resources” with the same meanings as the matching values of the corresponding property of the service interface.

SWAP UNIT OBJECTS

All swap unit objects implement the org.freedesktop.systemd1.Swap interface (described here) in addition to the generic org.freedesktop.systemd1.Unit interface (see above).

node /org/freedesktop/systemd1/unit/dev_2dsda3_2eswap { interface org.freedesktop.systemd1.Swap { methods: GetProcesses(out a(sus) processes); AttachProcesses(in s subcgroup, in au pids); properties: readonly s What = …; readonly i Priority = …; readonly s Options = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t TimeoutUSec = …; readonly u ControlPID = …; readonly s Result = …; readonly u UID = …; readonly u GID = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasbttttuii) ExecActivate = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“invalidates”) readonly a(sasbttttuii) ExecDeactivate = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s Slice = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ControlGroup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t ControlGroupId = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryPeak = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemorySwapCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemorySwapPeak = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryZSwapCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryAvailable = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t EffectiveMemoryMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t EffectiveMemoryHigh = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUUsageNSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay EffectiveCPUs = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay EffectiveMemoryNodes = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t TasksCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t EffectiveTasksMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPIngressBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPIngressPackets = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPEgressBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPEgressPackets = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOReadBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOReadOperations = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOWriteBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOWriteOperations = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b Delegate = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as DelegateControllers = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s DelegateSubgroup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b CPUAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupCPUWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUShares = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupCPUShares = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUQuotaPerSecUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUQuotaPeriodUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay AllowedCPUs = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay StartupAllowedCPUs = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay AllowedMemoryNodes = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay StartupAllowedMemoryNodes = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b IOAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupIOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IODeviceWeight = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOReadBandwidthMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOWriteBandwidthMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOReadIOPSMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOWriteIOPSMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IODeviceLatencyTargetUSec = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b BlockIOAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t BlockIOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupBlockIOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) BlockIODeviceWeight = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) BlockIOReadBandwidth = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) BlockIOWriteBandwidth = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b MemoryAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t DefaultMemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t DefaultStartupMemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t DefaultMemoryMin = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryMin = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryHigh = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryHigh = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemorySwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemorySwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryZSwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryZSwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b MemoryZSwapWriteback = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryLimit = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s DevicePolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(ss) DeviceAllow = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b TasksAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t TasksMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b IPAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iayu) IPAddressAllow = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iayu) IPAddressDeny = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as IPIngressFilterPath = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as IPEgressFilterPath = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as DisableControllers = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ManagedOOMSwap = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ManagedOOMMemoryPressure = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly u ManagedOOMMemoryPressureLimit = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ManagedOOMPreference = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(ss) BPFProgram = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iiqq) SocketBindAllow = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iiqq) SocketBindDeny = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly (bas) RestrictNetworkInterfaces = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s MemoryPressureWatch = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryPressureThresholdUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iiss) NFTSet = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b CoredumpReceive = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as Environment = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sb) EnvironmentFiles = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as PassEnvironment = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as UnsetEnvironment = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u UMask = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitCPU = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitCPUSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitFSIZE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitFSIZESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitDATA = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitDATASoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitSTACK = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitSTACKSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitCORE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitCORESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRSS = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRSSSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNOFILE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNOFILESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitAS = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitASSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNPROC = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNPROCSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitMEMLOCK = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitMEMLOCKSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitLOCKS = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitLOCKSSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitSIGPENDING = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitSIGPENDINGSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitMSGQUEUE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitMSGQUEUESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNICE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitNICESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRTPRIO = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRTPRIOSoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRTTIME = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LimitRTTIMESoft = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s WorkingDirectory = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootDirectory = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootImage = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ss) RootImageOptions = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay RootHash = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootHashPath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay RootHashSignature = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootHashSignaturePath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootVerity = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RootEphemeral = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ExtensionDirectories = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sba(ss)) ExtensionImages = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ssba(ss)) MountImages = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i OOMScoreAdjust = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t CoredumpFilter = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i Nice = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i IOSchedulingClass = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i IOSchedulingPriority = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i CPUSchedulingPolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i CPUSchedulingPriority = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay CPUAffinity = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b CPUAffinityFromNUMA = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i NUMAPolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay NUMAMask = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t TimerSlackNSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b CPUSchedulingResetOnFork = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b NonBlocking = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardInput = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardInputFileDescriptorName = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay StandardInputData = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardOutput = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardOutputFileDescriptorName = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardError = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s StandardErrorFileDescriptorName = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s TTYPath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b TTYReset = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b TTYVHangup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b TTYVTDisallocate = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly q TTYRows = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly q TTYColumns = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i SyslogPriority = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s SyslogIdentifier = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SyslogLevelPrefix = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i SyslogLevel = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i SyslogFacility = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i LogLevelMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t LogRateLimitIntervalUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u LogRateLimitBurst = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly aay LogExtraFields = [[…], …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(bs) LogFilterPatterns = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s LogNamespace = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i SecureBits = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t CapabilityBoundingSet = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t AmbientCapabilities = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s User = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Group = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b DynamicUser = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SetLoginEnvironment = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RemoveIPC = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(say) SetCredential = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(say) SetCredentialEncrypted = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ss) LoadCredential = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ss) LoadCredentialEncrypted = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ImportCredential = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as SupplementaryGroups = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s PAMName = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ReadWritePaths = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ReadOnlyPaths = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as InaccessiblePaths = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ExecPaths = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as NoExecPaths = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ExecSearchPath = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t MountFlags = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateTmp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateDevices = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectClock = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectKernelTunables = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectKernelModules = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectKernelLogs = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectControlGroups = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateNetwork = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateUsers = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateMounts = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b PrivateIPC = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ProtectHome = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ProtectSystem = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SameProcessGroup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s UtmpIdentifier = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s UtmpMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bs) SELinuxContext = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bs) AppArmorProfile = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bs) SmackProcessLabel = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b IgnoreSIGPIPE = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b NoNewPrivileges = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bas) SystemCallFilter = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as SystemCallArchitectures = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i SystemCallErrorNumber = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bas) SystemCallLog = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Personality = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b LockPersonality = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bas) RestrictAddressFamilies = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sst) RuntimeDirectorySymlink = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RuntimeDirectoryPreserve = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u RuntimeDirectoryMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as RuntimeDirectory = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sst) StateDirectorySymlink = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u StateDirectoryMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as StateDirectory = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sst) CacheDirectorySymlink = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u CacheDirectoryMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as CacheDirectory = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(sst) LogsDirectorySymlink = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u LogsDirectoryMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as LogsDirectory = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u ConfigurationDirectoryMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as ConfigurationDirectory = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t TimeoutCleanUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b MemoryDenyWriteExecute = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RestrictRealtime = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b RestrictSUIDSGID = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t RestrictNamespaces = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (bas) RestrictFileSystems = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ssbt) BindPaths = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ssbt) BindReadOnlyPaths = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ss) TemporaryFileSystem = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b MountAPIVFS = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s KeyringMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ProtectProc = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ProcSubset = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b ProtectHostname = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b MemoryKSM = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s NetworkNamespacePath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s IPCNamespacePath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootImagePolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s MountImagePolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s ExtensionImagePolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s KillMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i KillSignal = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i RestartKillSignal = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i FinalKillSignal = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SendSIGKILL = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SendSIGHUP = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i WatchdogSignal = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; interface org.freedesktop.systemd1.Unit { … }; };

Properties

Most of the properties map directly to the corresponding settings in swap unit files. As mount units invoke the swapon(8) command, their bus objects include implicit ExecActivate (and similar) fields which contain information about processes to execute. They also share most of the fields related to the execution context that Service objects expose (see above). In addition to these properties there are the following:

ControlPID contains the PID of the currently running swapon(8) or swapoff(8) command if there is one running, otherwise 0.

Result contains a value explaining why a mount unit failed if it failed. It can take the values “success”, “resources”, “timeout”, “exit-code”, “signal”, or “core-dump” which have the identical meanings as the corresponding values of the corresponding field of service unit objects (see above).

PATH UNIT OBJECTS

node /org/freedesktop/systemd1/unit/cups_2epath { interface org.freedesktop.systemd1.Path { properties: @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Unit = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ss) Paths = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b MakeDirectory = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u DirectoryMode = …; readonly s Result = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t TriggerLimitIntervalUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u TriggerLimitBurst = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; interface org.freedesktop.systemd1.Unit { … }; };

Properties

Most properties correspond directly with the matching settings in path unit files.

The others:

Paths contains an array of structs. Each struct contains the condition to watch, which can be one of “PathExists”, “PathExistsGlob”, “PathChanged”, “PathModified”, or “DirectoryNotEmpty” which correspond directly to the matching settings in the path unit files; and the path to watch, possibly including glob expressions.

Result contains a result value which can be “success” or “resources” which have the same meaning as the corresponding field of the Service interface.

SLICE UNIT OBJECTS

All slice unit objects implement the org.freedesktop.systemd1.Slice interface (described here) in addition to the generic org.freedesktop.systemd1.Unit interface (see above).

node /org/freedesktop/systemd1/unit/system_2eslice { interface org.freedesktop.systemd1.Slice { methods: GetProcesses(out a(sus) processes); AttachProcesses(in s subcgroup, in au pids); properties: @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s Slice = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ControlGroup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t ControlGroupId = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryPeak = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemorySwapCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemorySwapPeak = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryZSwapCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryAvailable = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t EffectiveMemoryMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t EffectiveMemoryHigh = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUUsageNSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay EffectiveCPUs = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay EffectiveMemoryNodes = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t TasksCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t EffectiveTasksMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPIngressBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPIngressPackets = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPEgressBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPEgressPackets = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOReadBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOReadOperations = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOWriteBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOWriteOperations = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b Delegate = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as DelegateControllers = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s DelegateSubgroup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b CPUAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupCPUWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUShares = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupCPUShares = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUQuotaPerSecUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUQuotaPeriodUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay AllowedCPUs = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay StartupAllowedCPUs = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay AllowedMemoryNodes = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay StartupAllowedMemoryNodes = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b IOAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupIOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IODeviceWeight = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOReadBandwidthMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOWriteBandwidthMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOReadIOPSMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOWriteIOPSMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IODeviceLatencyTargetUSec = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b BlockIOAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t BlockIOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupBlockIOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) BlockIODeviceWeight = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) BlockIOReadBandwidth = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) BlockIOWriteBandwidth = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b MemoryAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t DefaultMemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t DefaultStartupMemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t DefaultMemoryMin = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryMin = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryHigh = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryHigh = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemorySwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemorySwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryZSwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryZSwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b MemoryZSwapWriteback = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryLimit = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s DevicePolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(ss) DeviceAllow = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b TasksAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t TasksMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b IPAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iayu) IPAddressAllow = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iayu) IPAddressDeny = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as IPIngressFilterPath = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as IPEgressFilterPath = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as DisableControllers = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ManagedOOMSwap = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ManagedOOMMemoryPressure = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly u ManagedOOMMemoryPressureLimit = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ManagedOOMPreference = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(ss) BPFProgram = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iiqq) SocketBindAllow = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iiqq) SocketBindDeny = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly (bas) RestrictNetworkInterfaces = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s MemoryPressureWatch = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryPressureThresholdUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iiss) NFTSet = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b CoredumpReceive = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; interface org.freedesktop.systemd1.Unit { … }; };

Properties

Most properties correspond directly with the matching settings in slice unit files.

SCOPE UNIT OBJECTS

All scope unit objects implement the org.freedesktop.systemd1.Scope interface (described here) in addition to the generic org.freedesktop.systemd1.Unit interface (see above).

node /org/freedesktop/systemd1/unit/session_2d1_2escope { interface org.freedesktop.systemd1.Scope { methods: Abandon(); GetProcesses(out a(sus) processes); AttachProcesses(in s subcgroup, in au pids); signals: RequestStop(); properties: readonly s Controller = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t TimeoutStopUSec = …; readonly s Result = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t RuntimeMaxUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t RuntimeRandomizedExtraUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s OOMPolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s Slice = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ControlGroup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t ControlGroupId = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryPeak = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemorySwapCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemorySwapPeak = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryZSwapCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryAvailable = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t EffectiveMemoryMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t EffectiveMemoryHigh = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUUsageNSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay EffectiveCPUs = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay EffectiveMemoryNodes = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t TasksCurrent = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t EffectiveTasksMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPIngressBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPIngressPackets = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPEgressBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IPEgressPackets = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOReadBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOReadOperations = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOWriteBytes = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOWriteOperations = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b Delegate = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as DelegateControllers = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s DelegateSubgroup = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b CPUAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupCPUWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUShares = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupCPUShares = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUQuotaPerSecUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t CPUQuotaPeriodUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay AllowedCPUs = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay StartupAllowedCPUs = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay AllowedMemoryNodes = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly ay StartupAllowedMemoryNodes = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b IOAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t IOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupIOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IODeviceWeight = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOReadBandwidthMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOWriteBandwidthMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOReadIOPSMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IOWriteIOPSMax = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) IODeviceLatencyTargetUSec = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b BlockIOAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t BlockIOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupBlockIOWeight = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) BlockIODeviceWeight = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) BlockIOReadBandwidth = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(st) BlockIOWriteBandwidth = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b MemoryAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t DefaultMemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t DefaultStartupMemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t DefaultMemoryMin = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryMin = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryLow = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryHigh = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryHigh = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemorySwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemorySwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryZSwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t StartupMemoryZSwapMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b MemoryZSwapWriteback = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryLimit = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s DevicePolicy = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(ss) DeviceAllow = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b TasksAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t TasksMax = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b IPAccounting = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iayu) IPAddressAllow = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iayu) IPAddressDeny = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as IPIngressFilterPath = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as IPEgressFilterPath = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly as DisableControllers = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ManagedOOMSwap = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ManagedOOMMemoryPressure = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly u ManagedOOMMemoryPressureLimit = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s ManagedOOMPreference = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(ss) BPFProgram = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iiqq) SocketBindAllow = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iiqq) SocketBindDeny = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly (bas) RestrictNetworkInterfaces = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s MemoryPressureWatch = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t MemoryPressureThresholdUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly a(iiss) NFTSet = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b CoredumpReceive = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s KillMode = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i KillSignal = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i RestartKillSignal = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i FinalKillSignal = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SendSIGKILL = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly b SendSIGHUP = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly i WatchdogSignal = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; interface org.freedesktop.systemd1.Unit { … }; };

Methods

Abandon() may be used to place a scope unit in the “abandoned” state. This may be used to inform the system manager that the manager that created the scope lost interest in the scope (for example, because it is terminating), without wanting to shut down the scope entirely.

Signals

RequestStop() is sent to the peer that is configured in the Controller property when systemd is requested to terminate the scope unit. A program registering a scope can use this to cleanly shut down the processes it added to the scope instead of letting systemd do it with the usual SIGTERM logic.

Properties

All properties correspond directly with the matching properties of service units.

Controller contains the bus name (unique or well-known) that is notified when the scope unit is to be shut down via a RequestStop() signal (see below). This is set when the scope is created. If not set, the scopes processes will terminated with SIGTERM directly.

JOB OBJECTS

Job objects encapsulate scheduled or running jobs. Each unit can have none or one jobs in the execution queue. Each job is attached to exactly one unit.

node /org/freedesktop/systemd1/job/666 { interface org.freedesktop.systemd1.Job { methods: Cancel(); GetAfter(out a(usssoo) jobs); GetBefore(out a(usssoo) jobs); properties: @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u Id = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly (so) Unit = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s JobType = …; readonly s State = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly a(ss) ActivationDetails = […]; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; };

Methods

Cancel() cancels the job. Note that this will remove a job from the queue if it is not yet executed but generally will not cause a job that is already in the process of being executed to be aborted. This operation may also be requested via the CancelJob() method of the Manager object (see above), which is sometimes useful to reduce roundtrips.

Properties

Id is the numeric Id of the job. During the runtime of a systemd instance each numeric ID is only assigned once.

Unit refers to the unit this job belongs to. It is a structure consisting of the name of the unit and a bus path to the units object.

JobType refers to the jobs type and is one of “start”, “verify-active”, “stop”, “reload”, “restart”, “try-restart”, or “reload-or-start”. Note that later versions might define additional values.

State refers to the jobs state and is one of “waiting” and “running”. The former indicates that a job is currently queued but has not begun to execute yet. The latter indicates that a job is currently being executed.

ActivationDetails has the same content as the property of the same name under the org.freedesktop.systemd1.Unit interface.

EXAMPLES

Example 1. Introspect org.freedesktop.systemd1.Manager on the bus

$ gdbus introspect –system
–dest org.freedesktop.systemd1
–object-path /org/freedesktop/systemd1

Example 2. Introspect a unit on the bus

$ busctl introspect org.freedesktop.systemd1
$(busctl call org.freedesktop.systemd1
/org/freedesktop/systemd1
org.freedesktop.systemd1.Manager
GetUnit s systemd-resolved.service | cut -d" -f2)

Example 3. Introspect org.freedesktop.systemd1.Job on the bus

$ gdbus introspect –system –dest org.freedesktop.systemd1
–object-path /org/freedesktop/systemd1/job/1292

VERSIONING

These D-Bus interfaces follow the usual interface versioning guidelines[4].

HISTORY

The Manager Object

RuntimeWatchdogPreUSec and RuntimeWatchdogPreGovernor were added in version 251.

WatchdogDevice, WatchdogLastPingTimestamp, WatchdogLastPingTimestampMonotonic, DefaultDeviceTimeoutUSec, DumpUnitsMatchingPatterns(), and DumpUnitsMatchingPatternsByFileDescriptor() were added in version 252.

GetUnitByPIDFD() and DisableUnitFilesWithFlagsAndInstallInfo() were added in version 253.

ConfidentialVirtualization, DefaultIOAccounting, DefaultIPAccounting, DefaultMemoryPressureThresholdUSec, DefaultMemoryPressureWatch, QueueSignalUnit(), SoftReboot(), and DumpUnitFileDescriptorStore() were added in version 254.

StartAuxiliaryScope(), ShutdownStartTimestamp, ShutdownStartTimestampMonotonic and SoftRebootsCount were added in version 256.

Unit Objects

Upholds and UpheldBy were added in version 251.

AccessSELinuxContext and ActivationDetails were added in version 252.

QueueSignal() was added in version 254.

SurviveFinalKillSignal was added in version 255.

WantsMountsFor was added in version 256.

Service Unit Objects

ControlGroupId and ExtensionDirectories were added in version 251.

OpenFile, ReloadSignal, MemoryZSwapMax, and LogFilterPatterns were added in version 253.

RestartMode, RestartSteps, RestartMaxDelayUSec, RestartUSecNext, FileDescriptorStorePreserve, DumpFileDescriptorStore(), DelegateSubgroup, DefaultStartupMemoryLow, StartupMemoryLow, StartupMemoryHigh, StartupMemoryMax, StartupMemorySwapMax, StartupMemoryZSwapMax, MemoryPressureWatch, MemoryPressureThresholdUSec, RootEphemeral, ImportCredential, MemoryKSM, RootImagePolicy, MountImagePolicy, and ExtensionImagePolicy were added in version 254.

NFTSet, SetLoginEnvironment, CoredumpReceive, MemoryPeak, MemorySwapCurrent, MemorySwapPeak, and MemoryZSwapCurrent were added in version 255.

EffectiveMemoryHigh, EffectiveMemoryMax, EffectiveTasksMax, MemoryZSwapWriteback, ExecMainHandoffTimestampMonotonic, and ExecMainHandoffTimestamp were added in version 256.

Socket Unit Objects

ControlGroupId and ExtensionDirectories were added in version 251.

MemoryZSwapMax and LogFilterPatterns were added in version 253.

DelegateSubgroup, DefaultStartupMemoryLow, StartupMemoryLow, StartupMemoryHigh, StartupMemoryMax, StartupMemorySwapMax, StartupMemoryZSwapMax, MemoryPressureWatch, MemoryPressureThresholdUSec, RootEphemeral, ImportCredential, MemoryKSM, RootImagePolicy, MountImagePolicy, and ExtensionImagePolicy were added in version 254.

PollLimitIntervalUSec, PollLimitBurst, NFTSet, SetLoginEnvironment, CoredumpReceive, MemoryPeak, MemorySwapCurrent, MemorySwapPeak, and MemoryZSwapCurrent were added in version 255.

EffectiveMemoryHigh, EffectiveMemoryMax, EffectiveTasksMax, MemoryZSwapWriteback, and PassFileDescriptorsToExec were added in version 256.

Mount Unit Objects

ControlGroupId and ExtensionDirectories were added in version 251.

MemoryZSwapMax and LogFilterPatterns were added in version 253.

NFTSet, SetLoginEnvironment, CoredumpReceive, MemoryPeak, MemorySwapCurrent, MemorySwapPeak, and MemoryZSwapCurrent were added in version 255.

EffectiveMemoryHigh, EffectiveMemoryMax, EffectiveTasksMax, and MemoryZSwapWriteback were added in version 256.

Swap Unit Objects

ControlGroupId and ExtensionDirectories were added in version 251.

MemoryZSwapMax and LogFilterPatterns were added in version 253.

NFTSet, SetLoginEnvironment, CoredumpReceive, MemoryPeak, MemorySwapCurrent, MemorySwapPeak, and MemoryZSwapCurrent were added in version 255.

EffectiveMemoryHigh, EffectiveMemoryMax, EffectiveTasksMax, and MemoryZSwapWriteback were added in version 256.

Slice Unit Objects

ControlGroupId was added in version 251.

MemoryZSwapMax was added in version 253.

NFTSet, CoredumpReceive, MemoryPeak, MemorySwapCurrent, MemorySwapPeak, and MemoryZSwapCurrent were added in version 255.

EffectiveMemoryHigh, EffectiveMemoryMax, EffectiveTasksMax, and MemoryZSwapWriteback were added in version 256.

Scope Unit Objects

ControlGroupId was added in version 251.

OOMPolicy and MemoryZSwapMax were added in version 253.

NFTSet, CoredumpReceive, MemoryPeak, MemorySwapCurrent, MemorySwapPeak, and MemoryZSwapCurrent were added in version 255.

EffectiveMemoryHigh, EffectiveMemoryMax, EffectiveTasksMax, and MemoryZSwapWriteback were added in version 256.

Job Objects

ActivationDetails was added in version 252.

NOTES

polkit

https://www.freedesktop.org/software/polkit/docs/latest/

New Control Group Interface

https://systemd.io/CONTROL_GROUP_INTERFACE

The Case for the /usr Merge

https://systemd.io/THE_CASE_FOR_THE_USR_MERGE

the usual interface versioning guidelines

https://0pointer.de/blog/projects/versioning-dbus.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

61 - Linux cli command libnftables-json

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command libnftables-json and provides detailed information about the command libnftables-json, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the libnftables-json.

NAME 🖥️ libnftables-json 🖥️

json - Supported JSON schema by libnftables

SYNOPSIS

{ “nftables”: [ OBJECTS ] }

OBJECTS := LIST_OBJECTS | CMD_OBJECTS

LIST_OBJECTS := LIST_OBJECT [ , LIST_OBJECTS ]

CMD_OBJECTS := CMD_OBJECT [ , CMD_OBJECTS ]

CMD_OBJECT := { CMD**:** LIST_OBJECT } | METAINFO_OBJECT

DESCRIPTION

libnftables supports JSON formatted input and output. This is implemented as an alternative frontend to the standard CLI syntax parser, therefore basic behaviour is identical and, for (almost) any operation available in standard syntax, there should be an equivalent one in JSON.

JSON input may be provided in a single string as parameter to nft_run_cmd_from_buffer() or in a file identified by the filename parameter of the nft_run_cmd_from_filename() function.

JSON output has to be enabled via the nft_ctx_output_set_json() function, turning library standard output into JSON format. Error output remains unaffected.

GLOBAL STRUCTURE

In general, any JSON input or output is enclosed in an object with a single property named nftables. Its value is an array containing commands (for input) or ruleset elements (for output).

A command is an object with a single property whose name identifies the command. Its value is a ruleset element - basically identical to output elements, apart from certain properties which may be interpreted differently or are required when output generally omits them.

METAINFO OBJECT

In output, the first object in an nftables array is a special one containing library information. Its content is as follows:

{ “metainfo”: { “version”: STRING, “release_name”: STRING, “json_schema_version”: NUMBER }}

The values of version and release_name properties are equal to the package version and release name as printed by nft -v. The value of the json_schema_version property is an integer indicating the schema version.

If supplied in library input, the parser will verify the json_schema_version value to not exceed the internally hardcoded one (to make sure the given schema is fully understood). In future, a lower number than the internal one may activate compatibility mode to parse outdated and incompatible JSON input.

COMMAND OBJECTS

The structure accepts an arbitrary amount of commands which are interpreted in order of appearance. For instance, the following standard syntax input:

flush ruleset add table inet mytable add chain inet mytable mychain add rule inet mytable mychain tcp dport 22 accept

translates into JSON as such:

{ “nftables”: [ { “flush”: { “ruleset”: null }}, { “add”: { “table”: { “family”: “inet”, “name”: “mytable” }}}, { “add”: { “chain”: { “family”: “inet”, “table”: “mytable”, “name”: “mychain” }}}, { “add”: { “rule”: { “family”: “inet”, “table”: “mytable”, “chain”: “mychain”, “expr”: [ { “match”: { “op”: “==”, “left”: { “payload”: { “protocol”: “tcp”, “field”: “dport” }}, “right”: 22 }}, { “accept”: null } ] }}} ]}

ADD

{ “add”: ADD_OBJECT }

ADD_OBJECT := TABLE | CHAIN | RULE | SET | MAP | ELEMENT |
                FLOWTABLE | COUNTER | QUOTA | CT_HELPER | LIMIT |
                CT_TIMEOUT | CT_EXPECTATION

Add a new ruleset element to the kernel.

REPLACE

{ “replace”: RULE }

Replace a rule. In RULE, the handle property is mandatory and identifies the rule to be replaced.

CREATE

{ “create”: ADD_OBJECT }

Identical to add command, but returns an error if the object already exists.

INSERT

{ “insert”: RULE }

This command is identical to add for rules, but instead of appending the rule to the chain by default, it inserts at first position. If a handle or index property is given, the rule is inserted before the rule identified by those properties.

DELETE

{ “delete”: ADD_OBJECT }

Delete an object from the ruleset. Only the minimal number of properties required to uniquely identify an object is generally needed in ADD_OBJECT. For most ruleset elements, this is family and table plus either handle or name (except rules since they don’t have a name).

LIST

{ “list”: LIST_OBJECT }

LIST_OBJECT := TABLE | TABLES | CHAIN | CHAINS | SET | SETS |
                 MAP | MAPS | COUNTER | COUNTERS | QUOTA | QUOTAS |
                 CT_HELPER | CT_HELPERS | LIMIT | LIMITS | RULESET |
                 METER | METERS | FLOWTABLE | FLOWTABLES |
                 CT_TIMEOUT | CT_EXPECTATION

List ruleset elements. The plural forms are used to list all objects of that kind, optionally filtered by family and for some, also table.

RESET

{ “reset”: RESET_OBJECT }

RESET_OBJECT := COUNTER | COUNTERS | QUOTA | QUOTAS | RULE | RULES | SET | MAP | ELEMENT

Reset state in suitable objects, i.e. zero their internal counter.

FLUSH

{ “flush”: FLUSH_OBJECT }
FLUSH_OBJECT := TABLE | CHAIN | SET | MAP | METER | RULESET

Empty contents in given object, e.g. remove all chains from given table or remove all elements from given set.

RENAME

{ “rename”: CHAIN }

Rename a chain. The new name is expected in a dedicated property named newname.

RULESET ELEMENTS

TABLE

{ “table”: { “family”: STRING, “name”: STRING, “handle”: NUMBER, “flags”: TABLE_FLAGS }}
TABLE_FLAGS := TABLE_FLAG | [ TABLE_FLAG_LIST ]
TABLE_FLAG_LIST := TABLE_FLAG [, TABLE_FLAG_LIST ]
TABLE_FLAG := "dormant" | "owner" | "persist"

This object describes a table.

family

The table’s family, e.g. “ip” or “ip6”.

name

The table’s name.

handle

The table’s handle. In input, it is used only in delete command as alternative to name.

flags

The table’s flags.

CHAIN

{ “chain”: { “family”: STRING, “table”: STRING, “name”: STRING, “newname”: STRING, “handle”: NUMBER, “type”: STRING, “hook”: STRING, “prio”: NUMBER, “dev”: STRING, “policy”: STRING }}

This object describes a chain.

family

The table’s family.

table

The table’s name.

name

The chain’s name.

handle

The chain’s handle. In input, it is used only in delete command as alternative to name.

newname

A new name for the chain, only relevant in the rename command.

The following properties are required for base chains:

type

The chain’s type.

hook

The chain’s hook.

prio

The chain’s priority.

dev

The chain’s bound interface (if in the netdev family).

policy

The chain’s policy.

RULE

{ “rule”: { “family”: STRING, “table”: STRING, “chain”: STRING, “expr”: [ STATEMENTS ], “handle”: NUMBER, “index”: NUMBER, “comment”: STRING }}
STATEMENTS := STATEMENT [, STATEMENTS ]

This object describes a rule. Basic building blocks of rules are statements. Each rule consists of at least one.

family

The table’s family.

table

The table’s name.

chain

The chain’s name.

expr

An array of statements this rule consists of. In input, it is used in add/insert/replace commands only.

handle

The rule’s handle. In delete/replace commands, it serves as an identifier of the rule to delete/replace. In add/insert commands, it serves as an identifier of an existing rule to append/prepend the rule to.

index

The rule’s position for add/insert commands. It is used as an alternative to handle then.

comment

Optional rule comment.

SET / MAP

{ “set”: { “family”: STRING, “table”: STRING, “name”: STRING, “handle”: NUMBER, “type”: SET_TYPE, “policy”: SET_POLICY, “flags”: [ SET_FLAG_LIST ], “elem”: SET_ELEMENTS, “timeout”: NUMBER, “gc-interval”: NUMBER, “size”: NUMBER, “auto-merge”: BOOLEAN }}
{ "map": {
        "family": STRING,
        "table": STRING,
        "name": STRING,
        "handle": NUMBER,
        "type": SET_TYPE,
        "map": STRING,
        "policy": SET_POLICY,
        "flags": [ SET_FLAG_LIST ],
        "elem": SET_ELEMENTS,
        "timeout": NUMBER,
        "gc-interval": NUMBER,
        "size": NUMBER,
        "auto-merge": BOOLEAN
}}

SET_TYPE := STRING | [ SET_TYPE_LIST ]
SET_TYPE_LIST := STRING [, SET_TYPE_LIST ]
SET_POLICY := "performance" | "memory"
SET_FLAG_LIST := SET_FLAG [, SET_FLAG_LIST ]
SET_FLAG := "constant" | "interval" | "timeout"
SET_ELEMENTS := EXPRESSION | [ EXPRESSION_LIST ]
EXPRESSION_LIST := EXPRESSION [, EXPRESSION_LIST ]

These objects describe a named set or map. Maps are a special form of sets in that they translate a unique key to a value.

family

The table’s family.

table

The table’s name.

name

The set’s name.

handle

The set’s handle. For input, it is used in the delete command only.

type

The set’s datatype, see below.

map

Type of values this set maps to (i.e. this set is a map).

policy

The set’s policy.

flags

The set’s flags.

elem

Initial set element(s), see below.

timeout

Element timeout in seconds.

gc-interval

Garbage collector interval in seconds.

size

Maximum number of elements supported.

auto-merge

Automatic merging of adjacent/overlapping set elements in interval sets.

TYPE

The set type might be a string, such as “ipv4_addr” or an array consisting of strings (for concatenated types).

ELEM

A single set element might be given as string, integer or boolean value for simple cases. If additional properties are required, a formal elem object may be used.
Multiple elements may be given in an array.

ELEMENT

{ “element”: { “family”: STRING, “table”: STRING, “name”: STRING, “elem”: SET_ELEM }}
SET_ELEM := EXPRESSION | [ EXPRESSION_LIST ]
EXPRESSION_LIST := EXPRESSION [, EXPRESSION ]

Manipulate element(s) in a named set.

family

The table’s family.

table

The table’s name.

name

The set’s name.

elem

See elem property of set object.

FLOWTABLE

{ “flowtable”: { “family”: STRING, “table”: STRING, “name”: STRING, “handle”: NUMBER, “hook”: STRING, “prio”: NUMBER, “dev”: FT_INTERFACE }}
FT_INTERFACE := STRING | [ FT_INTERFACE_LIST ]
FT_INTERFACE_LIST := STRING [, STRING ]

This object represents a named flowtable.

family

The table’s family.

table

The table’s name.

name

The flow table’s name.

handle

The flow table’s handle. In input, it is used by the delete command only.

hook

The flow table’s hook.

prio

The flow table’s priority.

dev

The flow table’s interface(s).

COUNTER

{ “counter”: { “family”: STRING, “table”: STRING, “name”: STRING, “handle”: NUMBER, “packets”: NUMBER, “bytes”: NUMBER }}

This object represents a named counter.

family

The table’s family.

table

The table’s name.

name

The counter’s name.

handle

The counter’s handle. In input, it is used by the delete command only.

packets

Packet counter value.

bytes

Byte counter value.

QUOTA

{ “quota”: { “family”: STRING, “table”: STRING, “name”: STRING, “handle”: NUMBER, “bytes”: NUMBER, “used”: NUMBER, “inv”: BOOLEAN }}

This object represents a named quota.

family

The table’s family.

table

The table’s name.

name

The quota’s name.

handle

The quota’s handle. In input, it is used by the delete command only.

bytes

Quota threshold.

used

Quota used so far.

inv

If true, match if the quota has been exceeded.

CT HELPER

{ “ct helper”: { “family”: STRING, “table”: STRING, “name”: STRING, “handle”: … , “type”: STRING, “protocol”: CTH_PROTO, “l3proto”: STRING }}
CTH_PROTO := "tcp" | "udp"

This object represents a named conntrack helper.

family

The table’s family.

table

The table’s name.

name

The ct helper’s name.

handle

The ct helper’s handle. In input, it is used by the delete command only.

type

The ct helper type name, e.g. “ftp” or “tftp”.

protocol

The ct helper’s layer 4 protocol.

l3proto

The ct helper’s layer 3 protocol, e.g. “ip” or “ip6”.

LIMIT

{ “limit”: { “family”: STRING, “table”: STRING, “name”: STRING, “handle”: NUMBER, “rate”: NUMBER, “per”: STRING, “burst”: NUMBER, “unit”: LIMIT_UNIT, “inv”: BOOLEAN }}
LIMIT_UNIT := "packets" | "bytes"

This object represents a named limit.

family

The table’s family.

table

The table’s name.

name

The limit’s name.

handle

The limit’s handle. In input, it is used by the delete command only.

rate

The limit’s rate value.

per

Time unit to apply the limit to, e.g. “week”, “day”, “hour”, etc. If omitted, defaults to “second”.

burst

The limit’s burst value. If omitted, defaults to 0.

unit

Unit of rate and burst values. If omitted, defaults to “packets”.

inv

If true, match if limit was exceeded. If omitted, defaults to false.

CT TIMEOUT

{ “ct timeout”: { “family”: STRING, “table”: STRING, “name”: STRING, “handle”: NUMBER, “protocol”: CTH_PROTO, “state”: STRING, “value: NUMBER, “l3proto”: STRING }}
CTH_PROTO := "tcp" | "udp" | "dccp" | "sctp" | "gre" | "icmpv6" | "icmp" | "generic"

This object represents a named conntrack timeout policy.

family

The table’s family.

table

The table’s name.

name

The ct timeout object’s name.

handle

The ct timeout object’s handle. In input, it is used by delete command only.

protocol

The ct timeout object’s layer 4 protocol.

state

The connection state name, e.g. “established”, “syn_sent”, “close” or “close_wait”, for which the timeout value has to be updated.

value

The updated timeout value for the specified connection state.

l3proto

The ct timeout object’s layer 3 protocol, e.g. “ip” or “ip6”.

CT EXPECTATION

{ “ct expectation”: { “family”: STRING, “table”: STRING, “name”: STRING, “handle”: NUMBER, “l3proto”: STRING “protocol”:* CTH_PROTO, “dport”: NUMBER, “timeout: NUMBER, “size: NUMBER, *}}
CTH_PROTO := "tcp" | "udp" | "dccp" | "sctp" | "gre" | "icmpv6" | "icmp" | "generic"

This object represents a named conntrack expectation.

family

The table’s family.

table

The table’s name.

name

The ct expectation object’s name.

handle

The ct expectation object’s handle. In input, it is used by delete command only.

l3proto

The ct expectation object’s layer 3 protocol, e.g. “ip” or “ip6”.

protocol

The ct expectation object’s layer 4 protocol.

dport

The destination port of the expected connection.

timeout

The time in millisecond that this expectation will live.

size

The maximum count of expectations to be living in the same time.

STATEMENTS

Statements are the building blocks for rules. Each rule consists of at least one.

VERDICT

{ “accept”: null } { “drop”: null } { “continue”: null } { “return”: null } { “jump”: { “target”: * STRING *}} { “goto”: { “target”: * STRING *}}

A verdict either terminates packet traversal through the current chain or delegates to a different one.

jump and goto statements expect a target chain name.

MATCH

{ “match”: { “left”: EXPRESSION, “right”: EXPRESSION, “op”: STRING }}

This matches the expression on left hand side (typically a packet header or packet meta info) with the expression on right hand side (typically a constant value). If the statement evaluates to true, the next statement in this rule is considered. If not, processing continues with the next rule in the same chain.

left

Left hand side of this match.

right

Right hand side of this match.

Operator indicating the type of comparison.

OPERATORS

== Equal
!= Not equal
< Less than
> Greater than
⇐ Less than or equal to
>= Greater than or equal to
in Perform a lookup, i.e. test if bits on RHS are contained in LHS value
Unlike with the standard API, the operator is mandatory here. In the standard API, a missing operator may be resolved in two ways, depending on the type of expression on the RHS:
·
If the RHS is a bitmask or a list of bitmasks, the expression resolves into a binary operation with the inequality operator, like this: LHS & RHS != 0.
·
In any other case, the equality operator is simply inserted.
For the non-trivial first case, the JSON API supports the in operator.

COUNTER

{ “counter”: { “packets”: NUMBER, “bytes”: NUMBER }}
{ "counter": STRING }

This object represents a byte/packet counter. In input, no properties are required. If given, they act as initial values for the counter.

The first form creates an anonymous counter which lives in the rule it appears in. The second form specifies a reference to a named counter object.

packets

Packets counted.

bytes

Bytes counted.

MANGLE

{ “mangle”: { “key”: EXPRESSION, “value”: EXPRESSION }}

This changes the packet data or meta info.

key

The packet data to be changed, given as an exthdr, payload, meta, ct or ct helper expression.

value

Value to change data to.

QUOTA

{ “quota”: { “val”: NUMBER, “val_unit”: STRING, “used”: NUMBER, “used_unit”: STRING, “inv”: BOOLEAN }}
{ "quota": STRING }

The first form creates an anonymous quota which lives in the rule it appears in. The second form specifies a reference to a named quota object.

val

Quota value.

val_unit

Unit of val, e.g. “kbytes” or “mbytes”. If omitted, defaults to “bytes”.

used

Quota used so far. Optional on input. If given, serves as initial value.

used_unit

Unit of used. Defaults to “bytes”.

inv

If true, will match if quota was exceeded. Defaults to false.

LIMIT

{ “limit”: { “rate”: NUMBER, “rate_unit”: STRING, “per”: STRING, “burst”: NUMBER, “burst_unit”: STRING, “inv”: BOOLEAN }}
{ "limit": STRING }

The first form creates an anonymous limit which lives in the rule it appears in. The second form specifies a reference to a named limit object.

rate

Rate value to limit to.

rate_unit

Unit of rate, e.g. “packets” or “mbytes”. Defaults to “packets”.

per

Denominator of rate, e.g. “week” or “minutes”.

burst

Burst value. Defaults to 0.

burst_unit

Unit of burst, ignored if rate_unit is “packets”. Defaults to “bytes”.

inv

If true, matches if the limit was exceeded. Defaults to false.

FWD

{ “fwd”: { “dev”: EXPRESSION, “family”: FWD_FAMILY, “addr”: EXPRESSION }}
FWD_FAMILY := "ip" | "ip6"

Forward a packet to a different destination.

dev

Interface to forward the packet on.

family

Family of addr.

addr

IP(v6) address to forward the packet to.

Both family and addr are optional, but if at least one is given, both must be present.

NOTRACK

{ “notrack”: null }

Disable connection tracking for the packet.

DUP

{ “dup”: { “addr”: EXPRESSION, “dev”: EXPRESSION }}

Duplicate a packet to a different destination.

addr

Address to duplicate packet to.

dev

Interface to duplicate packet on. May be omitted to not specify an interface explicitly.

NETWORK ADDRESS TRANSLATION

{ “snat”: { “addr”: EXPRESSION, “family”: STRING, “port”: EXPRESSION, “flags”: FLAGS }}

{ "dnat": {
        "addr": EXPRESSION,
        "family": STRING,
        "port": EXPRESSION,
        "flags": FLAGS
}}

{ "masquerade": {
        "port": EXPRESSION,
        "flags": FLAGS
}}

{ "redirect": {
        "port": EXPRESSION,
        "flags": FLAGS
}}

FLAGS := FLAG | [ FLAG_LIST ]
FLAG_LIST := FLAG [, FLAG_LIST ]
FLAG := "random" | "fully-random" | "persistent"

Perform Network Address Translation.

addr

Address to translate to.

family

Family of addr, either ip or ip6. Required in inet table family.

port

Port to translate to.

flags

Flag(s).

All properties are optional and default to none.

REJECT

{ “reject”: { “type”: STRING, “expr”: EXPRESSION }}

Reject the packet and send the given error reply.

type

Type of reject, either “tcp reset”, “icmpx”, “icmp” or “icmpv6”.

expr

ICMP code to reject with.

All properties are optional.

SET

{ “set”: { “op”: STRING, “elem”: EXPRESSION, “set”: STRING }}

Dynamically add/update elements to a set.

Operator on set, either “add” or “update”.

elem

Set element to add or update.

set

Set reference.

LOG

{ “log”: { “prefix”: STRING, “group”: NUMBER, “snaplen”: NUMBER, “queue-threshold”: NUMBER, “level”: LEVEL, “flags”: FLAGS }}
LEVEL := "emerg" | "alert" | "crit" | "err" | "warn" | "notice" |
           "info" | "debug" | "audit"

FLAGS := FLAG | [ FLAG_LIST ]
FLAG_LIST := FLAG [, FLAG_LIST ]
FLAG := "tcp sequence" | "tcp options" | "ip options" | "skuid" |
          "ether" | "all"

Log the packet.

prefix

Prefix for log entries.

group

Log group.

snaplen

Snaplen for logging.

queue-threshold

Queue threshold.

level

Log level. Defaults to “warn”.

flags

Log flags.

All properties are optional.

CT HELPER

{ “ct helper”: EXPRESSION }

Enable the specified conntrack helper for this packet.

ct helper

CT helper reference.

METER

{ “meter”: { “name”: STRING, “key”: EXPRESSION, “stmt”: STATEMENT }}

Apply a given statement using a meter.

name

Meter name.

key

Meter key.

stmt

Meter statement.

QUEUE

{ “queue”: { “num”: EXPRESSION, “flags”: FLAGS }}
FLAGS := FLAG | [ FLAG_LIST ]
FLAG_LIST := FLAG [, FLAG_LIST ]
FLAG := "bypass" | "fanout"

Queue the packet to userspace.

num

Queue number.

flags

Queue flags.

VERDICT MAP

{ “vmap”: { “key”: EXPRESSION, “data”: EXPRESSION }}

Apply a verdict conditionally.

key

Map key.

data

Mapping expression consisting of value/verdict pairs.

CT COUNT

{ “ct count”: { “val”: NUMBER, “inv”: BOOLEAN }}

Limit the number of connections using conntrack.

val

Connection count threshold.

inv

If true, match if val was exceeded. If omitted, defaults to false.

CT TIMEOUT

{ “ct timeout”: EXPRESSION }

Assign connection tracking timeout policy.

ct timeout

CT timeout reference.

CT EXPECTATION

{ “ct expectation”: EXPRESSION }

Assign connection tracking expectation.

ct expectation

CT expectation reference.

XT

{ “xt”: { “type”: TYPENAME, “name”: STRING }}
TYPENAME := match | target | watcher

This represents an xt statement from xtables compat interface. It is a fallback if translation is not available or not complete.

Seeing this means the ruleset (or parts of it) were created by iptables-nft and one should use that to manage it.

BEWARE: nftables won’t restore these statements.

EXPRESSIONS

Expressions are the building blocks of (most) statements. In their most basic form, they are just immediate values represented as a JSON string, integer or boolean type.

IMMEDIATES

STRING NUMBER BOOLEAN

Immediate expressions are typically used for constant values. For strings, there are two special cases:

@STRING

The remaining part is taken as set name to create a set reference.

*****

Construct a wildcard expression.

LISTS

ARRAY

List expressions are constructed by plain arrays containing of an arbitrary number of expressions.

CONCAT

{ “concat”: CONCAT }

CONCAT := [ EXPRESSION_LIST ]
EXPRESSION_LIST := EXPRESSION [, EXPRESSION_LIST ]

Concatenate several expressions.

SET

{ “set”: SET }

SET := EXPRESSION | [ EXPRESSION_LIST ]

This object constructs an anonymous set. For mappings, an array of arrays with exactly two elements is expected.

MAP

{ “map”: { “key”: EXPRESSION, “data”: EXPRESSION }}

Map a key to a value.

key

Map key.

data

Mapping expression consisting of value/target pairs.

PREFIX

{ “prefix”: { “addr”: EXPRESSION, “len”: NUMBER }}

Construct an IPv4 or IPv6 prefix consisting of address part in addr and prefix length in len.

RANGE

{ “range”: [ EXPRESSION , EXPRESSION ] }

Construct a range of values. The first array item denotes the lower boundary, the second one the upper boundary.

PAYLOAD

{ “payload”: { “base”: BASE, “offset”: NUMBER, “len”: NUMBER }}
{ "payload": {
        "protocol": STRING,
        "field": STRING
}}

BASE := "ll" | "nh" | "th"

Construct a payload expression, i.e. a reference to a certain part of packet data. The first form creates a raw payload expression to point at a random number (len) of bytes at a certain offset (offset) from a given reference point (base). The following base values are accepted:

“ll”

The offset is relative to Link Layer header start offset.

“nh”

The offset is relative to Network Layer header start offset.

“th”

The offset is relative to Transport Layer header start offset.

The second form allows one to reference a field by name (field) in a named packet header (protocol).

EXTHDR

{ “exthdr”: { “name”: STRING, “field”: STRING, “offset”: NUMBER }}

Create a reference to a field (field) in an IPv6 extension header (name). offset is used only for rt0 protocol.

If the field property is not given, the expression is to be used as a header existence check in a match statement with a boolean on the right hand side.

TCP OPTION

{ “tcp option”: { “name”: STRING, “field”: STRING }}

Create a reference to a field (field) of a TCP option header (name).

If the field property is not given, the expression is to be used as a TCP option existence check in a match statement with a boolean on the right hand side.

SCTP CHUNK

{ “sctp chunk”: { “name”: STRING, “field”: STRING }}

Create a reference to a field (field) of an SCTP chunk (name).

If the field property is not given, the expression is to be used as an SCTP chunk existence check in a match statement with a boolean on the right hand side.

DCCP OPTION

{ “dccp option”: { “type”: NUMBER* }}

Create a reference to a DCCP option (type).

The expression is to be used as a DCCP option existence check in a match statement with a boolean on the right hand side.

RT

{ “rt”: { “key”: RT_KEY, “family”: RT_FAMILY }}
RT_KEY := "classid" | "nexthop" | "mtu"
RT_FAMILY := "ip" | "ip6"

Create a reference to packet routing data.

The family property is optional and defaults to unspecified.

CT

{ “ct”: { “key”: STRING, “family”: CT_FAMILY, “dir”: CT_DIRECTION }}
CT_FAMILY := "ip" | "ip6"
CT_DIRECTION := "original" | "reply"

Create a reference to packet conntrack data.

Some CT keys do not support a direction. In this case, dir must not be given.

NUMGEN

{ “numgen”: { “mode”: NG_MODE, “mod”: NUMBER, “offset”: NUMBER }}
NG_MODE := "inc" | "random"

Create a number generator.

The offset property is optional and defaults to 0.

HASH

{ “jhash”: { “mod”: NUMBER, “offset”: NUMBER, “expr”: EXPRESSION, “seed”: NUMBER }}
{ "symhash": {
        "mod": NUMBER,
        "offset": NUMBER
}}

Hash packet data.

The offset and seed properties are optional and default to 0.

FIB

{ “fib”: { “result”: FIB_RESULT, “flags”: FIB_FLAGS }}

FIB_RESULT := "oif" | "oifname" | "type"

FIB_FLAGS := FIB_FLAG | [ FIB_FLAG_LIST ]
FIB_FLAG_LIST := FIB_FLAG [, FIB_FLAG_LIST ]
FIB_FLAG := "saddr" | "daddr" | "mark" | "iif" | "oif"

Perform kernel Forwarding Information Base lookups.

BINARY OPERATION

{ “|”: [ EXPRESSION, EXPRESSIONS ] } { “^”: [ EXPRESSION, EXPRESSIONS ] } { “&”: [ EXPRESSION, EXPRESSIONS ] } { “«”: [ EXPRESSION, EXPRESSIONS ] } { “»”: [ EXPRESSION, EXPRESSIONS ] } EXPRESSIONS := EXPRESSION | EXPRESSION, EXPRESSIONS

All binary operations expect an array of at least two expressions, of which the first element denotes the left hand side and the second one the right hand side. Extra elements are accepted in the given array and appended to the term accordingly.

VERDICT

{ “accept”: null } { “drop”: null } { “continue”: null } { “return”: null } { “jump”: { “target”: STRING }} { “goto”: { “target”: STRING }}

Same as the verdict statement, but for use in verdict maps.

jump and goto verdicts expect a target chain name.

ELEM

{ “elem”: { “val”: EXPRESSION, “timeout”: NUMBER, “expires”: NUMBER, “comment”: STRING }}

Explicitly set element object, in case timeout, expires or comment are desired. Otherwise, it may be replaced by the value of val.

SOCKET

{ “socket”: { “key”: SOCKET_KEY }}
SOCKET_KEY := "transparent"

Construct a reference to packet’s socket.

OSF

{ “osf”: { “key”: OSF_KEY, “ttl”: OSF_TTL }}
OSF_KEY := "name"
OSF_TTL := "loose" | "skip"

Perform OS fingerprinting. This expression is typically used in the LHS of a match statement.

key

Which part of the fingerprint info to match against. At this point, only the OS name is supported.

ttl

Define how the packet’s TTL value is to be matched. This property is optional. If omitted, the TTL value has to match exactly. A value of loose accepts TTL values less than the fingerprint one. A value of skip omits TTL value comparison entirely.

AUTHOR

Phil Sutter <[email protected]>

Author.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

62 - Linux cli command proc_pid_task

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_task and provides detailed information about the command proc_pid_task, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_task.

NAME 🖥️ proc_pid_task 🖥️

self/ - thread information

DESCRIPTION

In a multithreaded process, the contents of the /proc/pid/task directory are not available if the main thread has already terminated (typically by calling pthread_exit(3)).

63 - Linux cli command proc_kmsg

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_kmsg and provides detailed information about the command proc_kmsg, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_kmsg.

NAME 🖥️ proc_kmsg 🖥️

kernel messages

DESCRIPTION

/proc/kmsg
This file can be used instead of the syslog(2) system call to read kernel messages. A process must have superuser privileges to read this file, and only one process should read this file. This file should not be read if a syslog process is running which uses the syslog(2) system call facility to log kernel messages.

Information in this file is retrieved with the dmesg(1) program.

64 - Linux cli command pnm

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command pnm and provides detailed information about the command pnm, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the pnm.

NAME 🖥️ pnm 🖥️

Netpbm superformat

DESCRIPTION

The PNM format is just an abstraction of the PBM, PGM, and PPM formats. I.e. the name “PNM” refers collectively to PBM, PGM, and PPM.

The name “PNM” is an acronym derived from “Portable Any Map.” This derivation makes more sense if you consider it in the context of the other Netpbm format names: PBM, PGM, and PPM.

The more general term “Netpbm format” refers to the PNM formats plus PAM.

PNM is principally used with Netpbm(1) .

Note that besides being names of formats, PBM, PGM, PPM, and PNM are also classes of programs. A PNM program can take PBM, PGM, or PPM input. That’s nothing special – a PPM program can too. But a PNM program can often produce multiple output formats as well, and a PNM program can see the difference between PBM, PGM, and PPM input and respond to each differently whereas a PPM program sees everything as if it were PPM. This is discussed more in “the description of the netpbm programs” (1) .

“pnm” also appears in the names of the most general Netpbm library routines(1) , some of which aren’t even related to the PNM format.

INTERNET MEDIA TYPE

No Internet Media Type (aka MIME type, content type) for PNM has been registered with the IANA, but the value image/x-portable-anymap is conventional.

Note that there are also conventional Internet Media Types for each of the PNM subformats. The recommended practice is to use those in preference to the PNM code when it is convenient to do so.

FILE NAME

There are no requirements on the name of a PNM file, but the convention is to use the suffix “pbm”, “pgm”, or “ppm”, depending on the particular subformat, or “pnm” if it is not convenient to distinguish the subformats.

DOCUMENT SOURCE

This manual page was generated by the Netpbm tool ‘makeman’ from HTML source. The master documentation is at

http://netpbm.sourceforge.net/doc/pnm.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

65 - Linux cli command gitignore

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitignore and provides detailed information about the command gitignore, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitignore.

NAME 🖥️ gitignore 🖥️

Specifies intentionally untracked files to ignore

SYNOPSIS

$XDG_CONFIG_HOME/git/ignore, $GIT_DIR/info/exclude, .gitignore

DESCRIPTION

A gitignore file specifies intentionally untracked files that Git should ignore. Files already tracked by Git are not affected; see the NOTES below for details.

Each line in a gitignore file specifies a pattern. When deciding whether to ignore a path, Git normally checks gitignore patterns from multiple sources, with the following order of precedence, from highest to lowest (within one level of precedence, the last matching pattern decides the outcome):

·
Patterns read from the command line for those commands that support them.

·
Patterns read from a .gitignore file in the same directory as the path, or in any parent directory (up to the top-level of the working tree), with patterns in the higher level files being overridden by those in lower level files down to the directory containing the file. These patterns match relative to the location of the .gitignore file. A project normally includes such .gitignore files in its repository, containing patterns for files generated as part of the project build.

·
Patterns read from $GIT_DIR/info/exclude.

·
Patterns read from the file specified by the configuration variable core.excludesFile.

Which file to place a pattern in depends on how the pattern is meant to be used.

·
Patterns which should be version-controlled and distributed to other repositories via clone (i.e., files that all developers will want to ignore) should go into a .gitignore file.

·
Patterns which are specific to a particular repository but which do not need to be shared with other related repositories (e.g., auxiliary files that live inside the repository but are specific to one user’s workflow) should go into the $GIT_DIR/info/exclude file.

·
Patterns which a user wants Git to ignore in all situations (e.g., backup or temporary files generated by the user’s editor of choice) generally go into a file specified by core.excludesFile in the user’s ~/.gitconfig. Its default value is $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/ignore is used instead.

The underlying Git plumbing tools, such as git ls-files and git read-tree, read gitignore patterns specified by command-line options, or from files specified by command-line options. Higher-level Git tools, such as git status and git add, use patterns from the sources specified above.

PATTERN FORMAT

·
A blank line matches no files, so it can serve as a separator for readability.

·
A line starting with # serves as a comment. Put a backslash ("****") in front of the first hash for patterns that begin with a hash.

·
Trailing spaces are ignored unless they are quoted with backslash ("****").

·
An optional prefix “!” which negates the pattern; any matching file excluded by a previous pattern will become included again. It is not possible to re-include a file if a parent directory of that file is excluded. Git doesn’t list excluded directories for performance reasons, so any patterns on contained files have no effect, no matter where they are defined. Put a backslash ("**") in front of the first “!” for patterns that begin with a literal “!”, for example, “\important!.txt**”.

·
The slash “/” is used as the directory separator. Separators may occur at the beginning, middle or end of the .gitignore search pattern.

·
If there is a separator at the beginning or middle (or both) of the pattern, then the pattern is relative to the directory level of the particular .gitignore file itself. Otherwise the pattern may also match at any level below the .gitignore level.

·
If there is a separator at the end of the pattern then the pattern will only match directories, otherwise the pattern can match both files and directories.

·
For example, a pattern doc/frotz/ matches doc/frotz directory, but not a/doc/frotz directory; however frotz/ matches frotz and a/frotz that is a directory (all paths are relative from the .gitignore file).

·
An asterisk “*” matches anything except a slash. The character “?” matches any one character except “/”. The range notation, e.g. [a-zA-Z], can be used to match one of the characters in a range. See fnmatch(3) and the FNM_PATHNAME flag for a more detailed description.

Two consecutive asterisks ("**") in patterns matched against full pathname may have special meaning:

·
A leading “**” followed by a slash means match in all directories. For example, “**/foo” matches file or directory “foo” anywhere, the same as pattern “foo”. “**/foo/bar” matches file or directory “bar” anywhere that is directly under directory “foo”.

·
A trailing “/**” matches everything inside. For example, “abc/**” matches all files inside directory “abc”, relative to the location of the .gitignore file, with infinite depth.

·
A slash followed by two consecutive asterisks then a slash matches zero or more directories. For example, “a/**/b” matches “a/b”, “a/x/b”, “a/x/y/b” and so on.

·
Other consecutive asterisks are considered regular asterisks and will match according to the previous rules.

CONFIGURATION

The optional configuration variable core.excludesFile indicates a path to a file containing patterns of file names to exclude, similar to $GIT_DIR/info/exclude. Patterns in the exclude file are used in addition to those in $GIT_DIR/info/exclude.

NOTES

The purpose of gitignore files is to ensure that certain files not tracked by Git remain untracked.

To stop tracking a file that is currently tracked, use git rm –cached to remove the file from the index. The filename can then be added to the .gitignore file to stop the file from being reintroduced in later commits.

Git does not follow symbolic links when accessing a .gitignore file in the working tree. This keeps behavior consistent when the file is accessed from the index or a tree versus from the filesystem.

EXAMPLES

·
The pattern hello.* matches any file or directory whose name begins with hello.. If one wants to restrict this only to the directory and not in its subdirectories, one can prepend the pattern with a slash, i.e. /hello.*; the pattern now matches hello.txt, hello.c but not a/hello.java.

·
The pattern foo/ will match a directory foo and paths underneath it, but will not match a regular file or a symbolic link foo (this is consistent with the way how pathspec works in general in Git)

·
The pattern doc/frotz and /doc/frotz have the same effect in any .gitignore file. In other words, a leading slash is not relevant if there is already a middle slash in the pattern.

·
The pattern foo/*, matches foo/test.json (a regular file), foo/bar (a directory), but it does not match foo/bar/hello.c (a regular file), as the asterisk in the pattern does not match bar/hello.c which has a slash in it.

$ git status
    [...]
    # Untracked files:
    [...]
    #       Documentation/foo.html
    #       Documentation/gitignore.html
    #       file.o
    #       lib.a
    #       src/internal.o
    [...]
    $ cat .git/info/exclude
    # ignore objects and archives, anywhere in the tree.
    *.[oa]
    $ cat Documentation/.gitignore
    # ignore generated html files,
    *.html
    # except foo.html which is maintained by hand
    !foo.html
    $ git status
    [...]
    # Untracked files:
    [...]
    #       Documentation/foo.html
    [...]

Another example:

$ cat .gitignore
    vmlinux*
    $ ls arch/foo/kernel/vm*
    arch/foo/kernel/vmlinux.lds.S
    $ echo !/vmlinux* >arch/foo/kernel/.gitignore

The second .gitignore prevents Git from ignoring arch/foo/kernel/vmlinux.lds.S.

Example to exclude everything except a specific directory foo/bar (note the /* - without the slash, the wildcard would also exclude everything within foo/bar):

$ cat .gitignore
    # exclude everything except directory foo/bar
    /*
    !/foo
    /foo/*
    !/foo/bar

GIT

Part of the git(1) suite

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

66 - Linux cli command exim4_exim_key

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command exim4_exim_key and provides detailed information about the command exim4_exim_key, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the exim4_exim_key.

NAME 🖥️ exim4_exim_key 🖥️

config_files - Files in use by the Debian exim4 packages

SYNOPSIS

DESCRIPTION

This manual page describes the files that are in use by the Debian exim4 packages and which are not part of an exim installation done from source.

/etc/aliases

You should at least set up an alias for postmaster in the /etc/aliases file.

/etc/email-addresses

is used to rewrite the email addresses of users. This is particularly useful for users who use their ISP’s domain for email.

The file should contain lines of the form

user: [email protected]
otheruser: [email protected]

/etc/exim4/local_host_blacklist

In the blacklist, the trick is to read a line break as “or” if it follows a positive item, and as “and” if it follows a negative item.

For example, a /etc/exim4/local_host_blacklist

192.168.10.0/24
!172.16.10.128/26
172.16.10.0/24
10.0.0.0/8

Exim just evaluates left to right (or up-down in the file listing context), so you don’t get the same kind of operator binding as in a programming language.

/etc/exim4/host_local_deny_exceptions

/etc/exim4/local_sender_blacklist

In the blacklist, the trick is to read a line break as “or” if it follows a positive item, and as “and” if it follows a negative item.

For example, a /etc/exim4/local_sender_blacklist

domain1.example
[email protected]
domain2.example
domain3.example

Exim just evaluates left to right (or up-down in the file listing context), so you don’t get the same kind of operator binding as in a programming language.

/etc/exim4/sender_local_deny_exceptions

/etc/exim4/local_sender_callout

/etc/exim4/local_rcpt_callout

/etc/exim4/local_domain_dnsbl_whitelist

/etc/exim4/hubbed_hosts

The file should contain key-value pairs of domain pattern and route data of the form

domain: host-list options
dict.ref.example: mail-1.ref.example:mail-2.ref.example
foo.example: internal.mail.example.com
bar.example: 192.168.183.3

which will cause mail for foo.example to be sent to the host internal.mail.example (IP address derived from A record only), and mail to bar.example to be sent to 192.168.183.3.

See spec.txt chapter 20.3 through 20.7 for a more detailed explanation of host list format and available options.

/etc/exim4/passwd

contains account and password data for SMTP authentication when the local exim is SMTP server and clients authenticate to the local exim.

The file should contain lines of the form

username:crypted-password:clear-password

clear-password is only necessary if you want to offer CRAM-MD5 authentication. If you don’t plan on doing so, the third column can be omitted completely.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim 640.

/etc/exim4/passwd.client

contains account and password data for SMTP authentication when exim is authenticating as a client to some remote server.

The file should contain lines of the form

target.mail.server.example:login-user-name:password

This goes inevitably wrong if the host name of the mail server is a CNAME (a DNS alias), or the reverse lookup does not fit the forward one.

password is your SMTP password in clear text. If you do not know about your SMTP password, you can try using your POP3 password as a first guess.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim 640.

/etc/exim4/exim.crt

/etc/exim4/exim.key

/etc/mailname

The “mail name” of the system. See Debian policy Chapter Customized programs and exim4-base’s README.Debian for further details.

BUGS

Plenty. Please report them through the Debian BTS

This manual page needs a major re-work. If somebody knows better groff than us and has more experience in writing manual pages, any patches would be greatly appreciated.

NOTES

Unresolvable items in host lists

Adding or keeping items in the abovementioned host lists which are not resolvable by DNS has severe consequences.

notresolvable.example.com:rejectme.example.com

Starting the list with the special pattern +ignore_unknown as a safeguard against this behavior is strongly recommended if hostnames are used in hostlists.

AUTHOR

Marc Haber <[email protected]> with help from Ross Boylan.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

67 - Linux cli command proc_interrupts

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_interrupts and provides detailed information about the command proc_interrupts, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_interrupts.

NAME 🖥️ proc_interrupts 🖥️

number of interrupts

DESCRIPTION

/proc/interrupts
This is used to record the number of interrupts per CPU per IO device. Since Linux 2.6.24, for the i386 and x86-64 architectures, at least, this also includes interrupts internal to the system (that is, not associated with a device as such), such as NMI (nonmaskable interrupt), LOC (local timer interrupt), and for SMP systems, TLB (TLB flush interrupt), RES (rescheduling interrupt), CAL (remote function call interrupt), and possibly others. Very easy to read formatting, done in ASCII.

68 - Linux cli command org.bluez.AgentManager

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.AgentManager and provides detailed information about the command org.bluez.AgentManager, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.AgentManager.

NAME 🖥️ org.bluez.AgentManager 🖥️

BlueZ D-Bus AgentManager API documentation

INTERFACE

Service
org.bluez
Interface
org.bluez.AgentManager1
Object path
/org/bluez

Methods

void RegisterAgent(object agent, string capability)

Registers pairing agent.
The object path defines the path of the agent that will be called when user input is needed and must implement org.bluez.Agent(5) interface.
Every application can register its own agent and for all actions triggered by that application its agent is used.
It is not required by an application to register an agent. If an application does chooses to not register an agent, the default agent is used. This is on most cases a good idea. Only application like a pairing wizard should register their own agent.
An application can only register one agent. Multiple agents per application is not supported.
Possible capability values:
""
Fallback to “KeyboardDisplay”.
“DisplayOnly”
“DisplayYesNo”
“KeyboardOnly”
“NoInputNoOutput”
“KeyboardDisplay”
Possible errors:
org.bluez.Error.InvalidArguments
org.bluez.Error.AlreadyExists

void UnregisterAgent(object agent)

Unregisters an agent that has been previously registered using RegisterAgent. The object path parameter must match the same value that has been used on registration.
Possible errors:
org.bluez.Error.DoesNotExist

void RequestDefaultAgent(object agent)

Requests to make the application agent the default agent. The application is required to register an agent.
Special permission might be required to become the default agent.
Possible errors:
org.bluez.Error.DoesNotExist

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

69 - Linux cli command gitprotocol-http

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitprotocol-http and provides detailed information about the command gitprotocol-http, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitprotocol-http.

NAME 🖥️ gitprotocol-http 🖥️

http - Git HTTP-based protocols

SYNOPSIS

<over-the-wire-protocol>

DESCRIPTION

Git supports two HTTP based transfer protocols. A “dumb” protocol which requires only a standard HTTP server on the server end of the connection, and a “smart” protocol which requires a Git aware CGI (or server module). This document describes both protocols.

As a design feature smart clients can automatically upgrade “dumb” protocol URLs to smart URLs. This permits all users to have the same published URL, and the peers automatically select the most efficient transport available to them.

URL FORMAT

URLs for Git repositories accessed by HTTP use the standard HTTP URL syntax documented by RFC 1738, so they are of the form:

http://:/?

Within this documentation the placeholder $GIT_URL will stand for the http:// repository URL entered by the end-user.

Servers SHOULD handle all requests to locations matching $GIT_URL, as both the “smart” and “dumb” HTTP protocols used by Git operate by appending additional path components onto the end of the user supplied $GIT_URL string.

An example of a dumb client requesting a loose object:

$GIT_URL: http://example.com:8080/git/repo.git URL request: http://example.com:8080/git/repo.git/objects/d0/49f6c27a2244e12041955e262a404c7faba355

An example of a smart request to a catch-all gateway:

$GIT_URL: http://example.com/daemon.cgi?svc=git&q= URL request: http://example.com/daemon.cgi?svc=git&q=/info/refs&service=git-receive-pack

An example of a request to a submodule:

$GIT_URL: http://example.com/git/repo.git/path/submodule.git URL request: http://example.com/git/repo.git/path/submodule.git/info/refs

Clients MUST strip a trailing /, if present, from the user supplied $GIT_URL string to prevent empty path tokens (//) from appearing in any URL sent to a server. Compatible clients MUST expand $GIT_URL/info/refs as foo/info/refs and not foo//info/refs.

AUTHENTICATION

Standard HTTP authentication is used if authentication is required to access a repository, and MAY be configured and enforced by the HTTP server software.

Because Git repositories are accessed by standard path components server administrators MAY use directory based permissions within their HTTP server to control repository access.

Clients SHOULD support Basic authentication as described by RFC 2617. Servers SHOULD support Basic authentication by relying upon the HTTP server placed in front of the Git server software.

Servers SHOULD NOT require HTTP cookies for the purposes of authentication or access control.

Clients and servers MAY support other common forms of HTTP based authentication, such as Digest authentication.

SSL

Clients and servers SHOULD support SSL, particularly to protect passwords when relying on Basic HTTP authentication.

SESSION STATE

The Git over HTTP protocol (much like HTTP itself) is stateless from the perspective of the HTTP server side. All state MUST be retained and managed by the client process. This permits simple round-robin load-balancing on the server side, without needing to worry about state management.

Clients MUST NOT require state management on the server side in order to function correctly.

Servers MUST NOT require HTTP cookies in order to function correctly. Clients MAY store and forward HTTP cookies during request processing as described by RFC 2616 (HTTP/1.1). Servers SHOULD ignore any cookies sent by a client.

GENERAL REQUEST PROCESSING

Except where noted, all standard HTTP behavior SHOULD be assumed by both client and server. This includes (but is not necessarily limited to):

If there is no repository at $GIT_URL, or the resource pointed to by a location matching $GIT_URL does not exist, the server MUST NOT respond with 200 OK response. A server SHOULD respond with 404 Not Found, 410 Gone, or any other suitable HTTP status code which does not imply the resource exists as requested.

If there is a repository at $GIT_URL, but access is not currently permitted, the server MUST respond with the 403 Forbidden HTTP status code.

Servers SHOULD support both HTTP 1.0 and HTTP 1.1. Servers SHOULD support chunked encoding for both request and response bodies.

Clients SHOULD support both HTTP 1.0 and HTTP 1.1. Clients SHOULD support chunked encoding for both request and response bodies.

Servers MAY return ETag and/or Last-Modified headers.

Clients MAY revalidate cached entities by including If-Modified-Since and/or If-None-Match request headers.

Servers MAY return 304 Not Modified if the relevant headers appear in the request and the entity has not changed. Clients MUST treat 304 Not Modified identical to 200 OK by reusing the cached entity.

Clients MAY reuse a cached entity without revalidation if the Cache-Control and/or Expires header permits caching. Clients and servers MUST follow RFC 2616 for cache controls.

DISCOVERING REFERENCES

All HTTP clients MUST begin either a fetch or a push exchange by discovering the references available on the remote repository.

Dumb Clients

HTTP clients that only support the “dumb” protocol MUST discover references by making a request for the special info/refs file of the repository.

Dumb HTTP clients MUST make a GET request to $GIT_URL/info/refs, without any search/query parameters.

C: GET $GIT_URL/info/refs HTTP/1.0

S: 200 OK S: S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0 S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}

The Content-Type of the returned info/refs entity SHOULD be text/plain; charset=utf-8, but MAY be any content type. Clients MUST NOT attempt to validate the returned Content-Type. Dumb servers MUST NOT return a return type starting with application/x-git-.

Cache-Control headers MAY be returned to disable caching of the returned entity.

When examining the response clients SHOULD only examine the HTTP status code. Valid responses are 200 OK, or 304 Not Modified.

The returned content is a UNIX formatted text file describing each ref and its known value. The file SHOULD be sorted by name according to the C locale ordering. The file SHOULD NOT include the default ref named HEAD.

info_refs = *( ref_record ) ref_record = any_ref / peeled_ref

any_ref = obj-id HTAB refname LF peeled_ref = obj-id HTAB refname LF obj-id HTAB refname “^{}” LF

Smart Clients

HTTP clients that support the “smart” protocol (or both the “smart” and “dumb” protocols) MUST discover references by making a parameterized request for the info/refs file of the repository.

The request MUST contain exactly one query parameter, service=$servicename, where $servicename MUST be the service name the client wishes to contact to complete the operation. The request MUST NOT contain additional query parameters.

C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0

dumb server reply:

S: 200 OK S: S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0 S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}

smart server reply:

S: 200 OK S: Content-Type: application/x-git-upload-pack-advertisement S: Cache-Control: no-cache S: S: 001e# service=git-upload-pack

S: 0000
S: 004895dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maintmulti_ack

S: 003fd049f6c27a2244e12041955e262a404c7faba355 refs/heads/master

S: 003c2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0

S: 003fa3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}

S: 0000

The client may send Extra Parameters (see gitprotocol-pack(5)) as a colon-separated string in the Git-Protocol HTTP header.

Uses the –http-backend-info-refs option to git-upload-pack(1).

Dumb Server Response

Dumb servers MUST respond with the dumb server reply format.
See the prior section under dumb clients for a more detailed description of the dumb server response.

Smart Server Response

If the server does not recognize the requested service name, or the requested service name has been disabled by the server administrator, the server MUST respond with the 403 Forbidden HTTP status code.
Otherwise, smart servers MUST respond with the smart server reply format for the requested service name.
Cache-Control headers SHOULD be used to disable caching of the returned entity.
The Content-Type MUST be application/x-$servicename-advertisement. Clients SHOULD fall back to the dumb protocol if another content type is returned. When falling back to the dumb protocol clients SHOULD NOT make an additional request to $GIT_URL/info/refs, but instead SHOULD use the response already in hand. Clients MUST NOT continue if they do not support the dumb protocol.
Clients MUST validate the status code is either 200 OK or 304 Not Modified.
Clients MUST validate the first five bytes of the response entity matches the regex ^[0-9a-f]{4}#. If this test fails, clients MUST NOT continue.
Clients MUST parse the entire response as a sequence of pkt-line records.
Clients MUST verify the first pkt-line is # service=$servicename. Servers MUST set $servicename to be the request parameter value. Servers SHOULD include an LF at the end of this line. Clients MUST ignore an LF at the end of the line.
Servers MUST terminate the response with the magic 0000 end pkt-line marker.
The returned response is a pkt-line stream describing each ref and its known value. The stream SHOULD be sorted by name according to the C locale ordering. The stream SHOULD include the default ref named HEAD as the first ref. The stream MUST include capability declarations behind a NUL on the first ref.
The returned response contains “version 1” if “version=1” was sent as an Extra Parameter.
smart_reply = PKT-LINE("# service=$servicename" LF) “0000” *1(“version 1”) ref_list “0000” ref_list = empty_list / non_empty_list
empty_list = PKT-LINE(zero-id SP “capabilities^{}” NUL cap-list LF)
non_empty_list = PKT-LINE(obj-id SP name NUL cap_list LF) *ref_record
cap-list = capability (SP capability) capability = 1(LC_ALPHA / DIGIT / “-” / “_”) LC_ALPHA = %x61-7A
ref_record = any_ref / peeled_ref any_ref = PKT-LINE(obj-id SP name LF) peeled_ref = PKT-LINE(obj-id SP name LF) PKT-LINE(obj-id SP name “^{}” LF

SMART SERVICE GIT-UPLOAD-PACK

This service reads from the repository pointed to by $GIT_URL.

Clients MUST first perform ref discovery with $GIT_URL/info/refs?service=git-upload-pack.

C: POST $GIT_URL/git-upload-pack HTTP/1.0 C: Content-Type: application/x-git-upload-pack-request C: C: 0032want 0a53e9ddeaddad63ad106860237bbf53411d11a7

C: 0032have 441b40d833fdfa93eb2908e52742248faf0ee993

C: 0000

S: 200 OK S: Content-Type: application/x-git-upload-pack-result S: Cache-Control: no-cache S: S: ….ACK %s, continue S: ….NAK

Clients MUST NOT reuse or revalidate a cached response. Servers MUST include sufficient Cache-Control headers to prevent caching of the response.

Servers SHOULD support all capabilities defined here.

Clients MUST send at least one “want” command in the request body. Clients MUST NOT reference an id in a “want” command which did not appear in the response obtained through ref discovery unless the server advertises capability allow-tip-sha1-in-want or allow-reachable-sha1-in-want.

compute_request = want_list have_list request_end request_end = “0000” / “done”

want_list = PKT-LINE(want SP cap_list LF) *(want_pkt) want_pkt = PKT-LINE(want LF) want = “want” SP id cap_list = capability *(SP capability)

have_list = *PKT-LINE(“have” SP id LF)

TODO: Document this further.

The Negotiation Algorithm

The computation to select the minimal pack proceeds as follows (C = client, S = server):

init step:

C: Use ref discovery to obtain the advertised refs.

C: Place any object seen into set advertised.

C: Build an empty set, common, to hold the objects that are later determined to be on both ends.

C: Build a set, want, of the objects from advertised that the client wants to fetch, based on what it saw during ref discovery.

C: Start a queue, c_pending, ordered by commit time (popping newest first). Add all client refs. When a commit is popped from the queue its parents SHOULD be automatically inserted back. Commits MUST only enter the queue once.

one compute step:

C: Send one $GIT_URL/git-upload-pack request:

C: 0032want <want #1>…………………………. C: 0032want <want #2>…………………………. …. C: 0032have <common #1>……………………….. C: 0032have <common #2>……………………….. …. C: 0032have <have #1>…………………………. C: 0032have <have #2>…………………………. …. C: 0000

The stream is organized into “commands”, with each command appearing by itself in a pkt-line. Within a command line, the text leading up to the first space is the command name, and the remainder of the line to the first LF is the value. Command lines are terminated with an LF as the last byte of the pkt-line value.

Commands MUST appear in the following order, if they appear at all in the request stream:

·
“want”

·
“have”

The stream is terminated by a pkt-line flush (0000).

A single “want” or “have” command MUST have one hex formatted object name as its value. Multiple object names MUST be sent by sending multiple commands. Object names MUST be given using the object format negotiated through the object-format capability (default SHA-1).

The have list is created by popping the first 32 commits from c_pending. Fewer can be supplied if c_pending empties.

If the client has sent 256 “have” commits and has not yet received one of those back from s_common, or the client has emptied c_pending it SHOULD include a “done” command to let the server know it won’t proceed:

C: 0009done

S: Parse the git-upload-pack request:

Verify all objects in want are directly reachable from refs.

The server MAY walk backwards through history or through the reflog to permit slightly stale requests.

If no “want” objects are received, send an error: TODO: Define error if no “want” lines are requested.

If any “want” object is not reachable, send an error: TODO: Define error if an invalid “want” is requested.

Create an empty list, s_common.

If “have” was sent:

Loop through the objects in the order supplied by the client.

For each object, if the server has the object reachable from a ref, add it to s_common. If a commit is added to s_common, do not add any ancestors, even if they also appear in have.

S: Send the git-upload-pack response:

If the server has found a closed set of objects to pack or the request ends with “done”, it replies with the pack. TODO: Document the pack based response

S: PACK…

The returned stream is the side-band-64k protocol supported by the git-upload-pack service, and the pack is embedded into stream 1. Progress messages from the server side MAY appear in stream 2.

Here a “closed set of objects” is defined to have at least one path from every “want” to at least one “common” object.

If the server needs more information, it replies with a status continue response: TODO: Document the non-pack response

C: Parse the upload-pack response: TODO: Document parsing response

Do another compute step.

SMART SERVICE GIT-RECEIVE-PACK

This service reads from the repository pointed to by $GIT_URL.

Clients MUST first perform ref discovery with $GIT_URL/info/refs?service=git-receive-pack.

C: POST $GIT_URL/git-receive-pack HTTP/1.0 C: Content-Type: application/x-git-receive-pack-request C: C: ….0a53e9ddeaddad63ad106860237bbf53411d11a7 441b40d833fdfa93eb2908e52742248faf0ee993 refs/heads/maint� report-status C: 0000 C: PACK….

S: 200 OK S: Content-Type: application/x-git-receive-pack-result S: Cache-Control: no-cache S: S: ….

Clients MUST NOT reuse or revalidate a cached response. Servers MUST include sufficient Cache-Control headers to prevent caching of the response.

Servers SHOULD support all capabilities defined here.

Clients MUST send at least one command in the request body. Within the command portion of the request body clients SHOULD send the id obtained through ref discovery as old_id.

update_request = command_list “PACK”

command_list = PKT-LINE(command NUL cap_list LF) *(command_pkt) command_pkt = PKT-LINE(command LF) cap_list = *(SP capability) SP

command = create / delete / update create = zero-id SP new_id SP name delete = old_id SP zero-id SP name update = old_id SP new_id SP name

TODO: Document this further.

REFERENCES

RFC 1738: Uniform Resource Locators (URL)[1] RFC 2616: Hypertext Transfer Protocol — HTTP/1.1[2]

GIT

Part of the git(1) suite

NOTES

RFC 1738: Uniform Resource Locators (URL)

http://www.ietf.org/rfc/rfc1738.txt

RFC 2616: Hypertext Transfer Protocol — HTTP/1.1

http://www.ietf.org/rfc/rfc2616.txt

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

70 - Linux cli command proc_tid_children

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_tid_children and provides detailed information about the command proc_tid_children, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_tid_children.

NAME 🖥️ proc_tid_children 🖥️

child tasks

DESCRIPTION

/proc/tid/children (since Linux 3.5)
A space-separated list of child tasks of this task. Each child task is represented by its TID.

This option is intended for use by the checkpoint-restore (CRIU) system, and reliably provides a list of children only if all of the child processes are stopped or frozen. It does not work properly if children of the target task exit while the file is being read! Exiting children may cause non-exiting children to be omitted from the list. This makes this interface even more unreliable than classic PID-based approaches if the inspected task and its children aren’t frozen, and most code should probably not use this interface.

Until Linux 4.2, the presence of this file was governed by the CONFIG_CHECKPOINT_RESTORE kernel configuration option. Since Linux 4.2, it is governed by the CONFIG_PROC_CHILDREN option.

71 - Linux cli command org.freedesktop.hostname1

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.freedesktop.hostname1 and provides detailed information about the command org.freedesktop.hostname1, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.freedesktop.hostname1.

NAME 🖥️ org.freedesktop.hostname1 🖥️

The D-Bus interface of systemd-hostnamed

INTRODUCTION

systemd-hostnamed.service(8) is a system service that can be used to control the hostname and related machine metadata from user programs. This page describes the hostname semantics and the D-Bus interface.

THE D-BUS API

The service exposes the following interfaces on the bus:

node /org/freedesktop/hostname1 { interface org.freedesktop.hostname1 { methods: SetHostname(in s hostname, in b interactive); SetStaticHostname(in s hostname, in b interactive); SetPrettyHostname(in s hostname, in b interactive); SetIconName(in s icon, in b interactive); SetChassis(in s chassis, in b interactive); SetDeployment(in s deployment, in b interactive); SetLocation(in s location, in b interactive); GetProductUUID(in b interactive, out ay uuid); GetHardwareSerial(out s serial); Describe(out s json); properties: readonly s Hostname = …; readonly s StaticHostname = …; readonly s PrettyHostname = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s DefaultHostname = …; readonly s HostnameSource = …; readonly s IconName = …; readonly s Chassis = …; readonly s Deployment = …; readonly s Location = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s KernelName = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s KernelRelease = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s KernelVersion = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s OperatingSystemPrettyName = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s OperatingSystemCPEName = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t OperatingSystemSupportEnd = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s HomeURL = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s HardwareVendor = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s HardwareModel = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s FirmwareVersion = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s FirmwareVendor = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t FirmwareDate = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay MachineID = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay BootID = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u VSockCID = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; };

Whenever the hostname or other metadata is changed via the daemon, PropertyChanged signals are sent out to subscribed clients. Changing a hostname using this interface is authenticated via polkit[1].

SEMANTICS

The StaticHostname property exposes the “static” hostname configured in /etc/hostname. It is not always in sync with the current hostname as returned by the gethostname(3) system call. If no static hostname is configured this property will be the empty string.

When systemd(1) or systemd-hostnamed.service(8) set the hostname, this static hostname has the highest priority.

The Hostname property exposes the actual hostname configured in the kernel via sethostname(2). It can be different from the static hostname. This property is never empty.

The PrettyHostname property exposes the pretty hostname which is a free-form UTF-8 hostname for presentation to the user. User interfaces should ensure that the pretty hostname and the static hostname stay in sync. E.g. when the former is “Lennart’s Computer” the latter should be “lennarts-computer”. If no pretty hostname is set this setting will be the empty string. Applications should then find a suitable fallback, such as the dynamic hostname.

The DefaultHostname property exposes the default hostname (configured through os-release(5), or a fallback set at compilation time).

The HostnameSource property exposes the origin of the currently configured hostname. One of “static” (set from /etc/hostname), “transient” (a non-permanent hostname from an external source), “default” (the value from os-release or the compiled-in fallback).

The IconName property exposes the icon name following the XDG icon naming spec. If not set, information such as the chassis type (see below) is used to find a suitable fallback icon name (i.e. “computer-laptop” vs. “computer-desktop” is picked based on the chassis information). If no such data is available, the empty string is returned. In that case an application should fall back to a replacement icon, for example “computer”. If this property is set to the empty string, the automatic fallback name selection is enabled again.

The Chassis property exposes a chassis type, one of the currently defined chassis types: “desktop”, “laptop”, “server”, “tablet”, “handset”, as well as the special chassis types “vm” and “container” for virtualized systems. Note that in most cases the chassis type will be determined automatically from DMI/SMBIOS/ACPI firmware information. Writing to this setting is hence useful only to override misdetected chassis types, or to configure the chassis type if it could not be auto-detected. Set this property to the empty string to reenable the automatic detection of the chassis type from firmware information.

Note that systemd-hostnamed starts only on request and terminates after a short idle period. This effectively means that PropertyChanged messages are not sent out for changes made directly on the files (as in: administrator edits the files with vi). This is the intended behavior: manual configuration changes should require manual reloading.

The transient (dynamic) hostname exposed by the Hostname property maps directly to the kernel hostname. This hostname should be assumed to be highly dynamic, and hence should be watched directly, without depending on PropertyChanged messages from systemd-hostnamed. To accomplish this, open /proc/sys/kernel/hostname and poll(3) for SIGHUP which is triggered by the kernel every time the hostname changes. Again: this is special for the transient (dynamic) hostname, and does not apply to the configured (fixed) hostname.

Applications may read the hostname data directly if hostname change notifications are not necessary. Use gethostname(2), /etc/hostname (possibly with per-distribution fallbacks), and machine-info(3) for that. For more information on these files and syscalls see the respective man pages.

KernelName, KernelRelease, and KernelVersion expose the kernel name (e.g. “Linux”), release (e.g. “5.0.0-11”), and version (i.e. the build number, e.g. “#11”) as reported by uname(2). OperatingSystemPrettyName, OperatingSystemCPEName, and HomeURL expose the PRETTY_NAME=, CPE_NAME= and HOME_URL= fields from os-release(5). The purpose of those properties is to allow remote clients to access this information over D-Bus. Local clients can access the information directly.

MachineID expose the 128bit machine ID, see machine-id(5) for details.

BootID expose the 128bit boot ID, as per /proc/sys/kernel/random/boot_id.

VSockCID exposes the systems local AF_VSOCK CID (Context Identifier, i.e. address) for the system, if one is available in the virtual machine environment. Set to UINT32_MAX otherwise. See vsock(7) for details.

OperatingSystemSupportEnd exposes when the OS vendor support ends, if this information is known. Its an unsigned 64bit value, in µs since the UNIX epoch, UTC. If this information is not known carries the value 2^64-1, i.e. UINT64_MAX.

HardwareVendor and HardwareModel expose information about the vendor of the hardware of the system. If no such information can be determined these properties are set to empty strings.

FirmwareVersion and FirmwareVendor expose information about the systems firmware, i.e. a version string and a vendor name. If no such information can be determined these properties are set to empty strings.

FirmwareDate exposes the firmware build date, if that information is known. Its an unsigned 64bit value, in µs since the UNIX epoch, UTC. If not known UNIT64_MAX.

Methods

SetHostname() sets the transient (dynamic) hostname, which is used if no static hostname is set. This value must be an internet-style hostname, 7-bit lowercase ASCII, no special chars/spaces. An empty string will unset the transient hostname.

SetStaticHostname() sets the static hostname which is exposed by the StaticHostname property. When called with an empty argument, the static configuration in /etc/hostname is removed. Since the static hostname has the highest priority, calling this function usually affects also the Hostname property and the effective hostname configured in the kernel.

SetPrettyHostname() sets the pretty hostname which is exposed by the PrettyHostname property.

SetIconName(), SetChassis(), SetDeployment(), and SetLocation() set the properties IconName (the name of the icon representing for the machine), Chassis (the machine form factor), Deployment (the system deployment environment), and Location (physical system location), respectively.

PrettyHostname, IconName, Chassis, Deployment, and Location are stored in /etc/machine-info. See machine-info(5) for the semantics of those settings.

GetProductUUID() returns the “product UUID” as exposed by the kernel based on DMI information in /sys/class/dmi/id/product_uuid. Reading the file directly requires root privileges, and this method allows access to unprivileged clients through the polkit framework.

GetHardwareSerial() returns the “hardware serial” as exposed by the kernel based on DMI information. Reading the file directly requires root privileges, and this method allows access to unprivileged clients through the polkit framework.

Describe() returns a JSON representation of all properties in one.

Security

The interactive boolean parameters can be used to control whether polkit should interactively ask the user for authentication credentials if required.

The polkit action for SetHostname() is org.freedesktop.hostname1.set-hostname. For SetStaticHostname() and SetPrettyHostname() it is org.freedesktop.hostname1.set-static-hostname. For SetIconName(), SetChassis(), SetDeployment() and SetLocation() it is org.freedesktop.hostname1.set-machine-info.

RECOMMENDATIONS

Here are three examples that show how the pretty hostname and the icon name should be used:

·
When registering DNS-SD services: use the pretty hostname in the service name, and pass the icon name in the TXT data, if there is an icon name. Browsing clients can then show the server icon on each service. This is especially useful for WebDAV applications or UPnP media sharing.

·
Set the bluetooth name to the pretty hostname.

·
When your file browser has a “Computer” icon, replace the name with the pretty hostname if set, and the icon with the icon name, if it is set.

To properly handle name lookups with changing local hostnames without having to edit /etc/hosts, we recommend using systemd-hostnamed in combination with nss-myhostname(3).

Here are some recommendations to follow when generating a static (internet) hostname from a pretty name:

·
Generate a single DNS label only, not an FQDN. That means no dots allowed. Strip them, or replace them with “-”.

·
Its probably safer to not use any non-ASCII chars, even if DNS allows this in some way these days. In fact, restrict your charset to “a-zA-Z0-9” and “-”. Strip other chars, or try to replace them in some smart way with chars from this set, for example “ä” → “ae”, and use “-” as the replacement for all punctuation characters and whitespace.

·
Try to avoid creating repeated “-”, as well as “-” as the first or last char.

·
Limit the hostname to 63 chars, which is the length of a DNS label.

·
If after stripping special chars the empty string is the result, you can pass this as-is to systemd-hostnamed in which case it will automatically use a suitable fallback.

·
Uppercase characters should be replaced with their lowercase equivalents.

Note that while systemd-hostnamed applies some checks to the hostname you pass they are much looser than the recommendations above. For example, systemd-hostnamed will also accept “_” in the hostname, but we recommend not using this to avoid clashes with DNS-SD service types. Also systemd-hostnamed allows longer hostnames, but because of the DNS label limitations, we recommend not making use of this.

Here are a couple of example conversions:

·
“Lennarts PC” → “lennarts-pc”

·
“Müllers Computer” → “muellers-computer”

·
“Voran!” → “voran”

·
“Es war einmal ein Männlein” → “es-war-einmal-ein-maennlein”

·
“Jawoll. Ist doch wahr!” → “jawoll-ist-doch-wahr”

·
“レナート” → “localhost”

·
“…zack!!! zack!…” → “zack-zack”

Of course, an already valid internet hostname label you enter and pass through this conversion should stay unmodified, so that users have direct control of it, if they want — by simply ignoring the fact that the pretty hostname is pretty and just edit it as if it was the normal internet name.

VERSIONING

These D-Bus interfaces follow the usual interface versioning guidelines[2].

EXAMPLES

Example 1. Introspect org.freedesktop.hostname1 on the bus

$ gdbus introspect –system
–dest org.freedesktop.hostname1
–object-path /org/freedesktop/hostname1

HISTORY

The D-Bus API

FirmwareVersion and GetHardwareSerial() were added in version 251.

OperatingSystemSupportEnd, FirmwareVendor, and FirmwareDate were added in version 253.

MachineID, BootID and VSockCID were added in version 256.

NOTES

polkit

https://www.freedesktop.org/software/polkit/docs/latest/

the usual interface versioning guidelines

https://0pointer.de/blog/projects/versioning-dbus.html

Feature page about xdg-hostname

https://fedoraproject.org/wiki/Features/BetterHostname

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

72 - Linux cli command org.bluez.obex.Client

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.obex.Client and provides detailed information about the command org.bluez.obex.Client, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.obex.Client.

NAME 🖥️ org.bluez.obex.Client 🖥️

BlueZ D-Bus OBEX Client API documentation

INTERFACE

Service
org.bluez.obex
Interface
org.bluez.obex.Client1
Object path
/org/bluez/obex

Methods

object CreateSession(string destination, dict args)

Connects to the destination address and then proceed to create an OBEX session object which implements org.bluez.obex.Session(5) interface.
The last parameter is a dictionary to hold optional or type-specific parameters.
Possible args values:
string Target
Type of session to be created.
Possible values:
“ftp”
“map”
“opp”
“pbap”
“sync”
string Source
Local address to be used.
byte Channel
Channel to be used.
Possible errors:
org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Error.Failed

void RemoveSession(object session)

Disconnects and removes session previously created by CreateSession() aborting any pending transfers.
Possible errors:
org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Error.NotAuthorized

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

73 - Linux cli command exim4_hubbed_hosts

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command exim4_hubbed_hosts and provides detailed information about the command exim4_hubbed_hosts, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the exim4_hubbed_hosts.

NAME 🖥️ exim4_hubbed_hosts 🖥️

config_files - Files in use by the Debian exim4 packages

SYNOPSIS

DESCRIPTION

This manual page describes the files that are in use by the Debian exim4 packages and which are not part of an exim installation done from source.

/etc/aliases

You should at least set up an alias for postmaster in the /etc/aliases file.

/etc/email-addresses

is used to rewrite the email addresses of users. This is particularly useful for users who use their ISP’s domain for email.

The file should contain lines of the form

user: [email protected]
otheruser: [email protected]

/etc/exim4/local_host_blacklist

In the blacklist, the trick is to read a line break as “or” if it follows a positive item, and as “and” if it follows a negative item.

For example, a /etc/exim4/local_host_blacklist

192.168.10.0/24
!172.16.10.128/26
172.16.10.0/24
10.0.0.0/8

Exim just evaluates left to right (or up-down in the file listing context), so you don’t get the same kind of operator binding as in a programming language.

/etc/exim4/host_local_deny_exceptions

/etc/exim4/local_sender_blacklist

In the blacklist, the trick is to read a line break as “or” if it follows a positive item, and as “and” if it follows a negative item.

For example, a /etc/exim4/local_sender_blacklist

domain1.example
[email protected]
domain2.example
domain3.example

Exim just evaluates left to right (or up-down in the file listing context), so you don’t get the same kind of operator binding as in a programming language.

/etc/exim4/sender_local_deny_exceptions

/etc/exim4/local_sender_callout

/etc/exim4/local_rcpt_callout

/etc/exim4/local_domain_dnsbl_whitelist

/etc/exim4/hubbed_hosts

The file should contain key-value pairs of domain pattern and route data of the form

domain: host-list options
dict.ref.example: mail-1.ref.example:mail-2.ref.example
foo.example: internal.mail.example.com
bar.example: 192.168.183.3

which will cause mail for foo.example to be sent to the host internal.mail.example (IP address derived from A record only), and mail to bar.example to be sent to 192.168.183.3.

See spec.txt chapter 20.3 through 20.7 for a more detailed explanation of host list format and available options.

/etc/exim4/passwd

contains account and password data for SMTP authentication when the local exim is SMTP server and clients authenticate to the local exim.

The file should contain lines of the form

username:crypted-password:clear-password

clear-password is only necessary if you want to offer CRAM-MD5 authentication. If you don’t plan on doing so, the third column can be omitted completely.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim 640.

/etc/exim4/passwd.client

contains account and password data for SMTP authentication when exim is authenticating as a client to some remote server.

The file should contain lines of the form

target.mail.server.example:login-user-name:password

This goes inevitably wrong if the host name of the mail server is a CNAME (a DNS alias), or the reverse lookup does not fit the forward one.

password is your SMTP password in clear text. If you do not know about your SMTP password, you can try using your POP3 password as a first guess.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim 640.

/etc/exim4/exim.crt

/etc/exim4/exim.key

/etc/mailname

The “mail name” of the system. See Debian policy Chapter Customized programs and exim4-base’s README.Debian for further details.

BUGS

Plenty. Please report them through the Debian BTS

This manual page needs a major re-work. If somebody knows better groff than us and has more experience in writing manual pages, any patches would be greatly appreciated.

NOTES

Unresolvable items in host lists

Adding or keeping items in the abovementioned host lists which are not resolvable by DNS has severe consequences.

notresolvable.example.com:rejectme.example.com

Starting the list with the special pattern +ignore_unknown as a safeguard against this behavior is strongly recommended if hostnames are used in hostlists.

AUTHOR

Marc Haber <[email protected]> with help from Ross Boylan.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

74 - Linux cli command proc_sys_user

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_sys_user and provides detailed information about the command proc_sys_user, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_sys_user.

NAME 🖥️ proc_sys_user 🖥️

limits on the number of namespaces of various types

DESCRIPTION

/proc/sys/user/ (since Linux 4.9)
See namespaces(7).

75 - Linux cli command proc_fs

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_fs and provides detailed information about the command proc_fs, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_fs.

NAME 🖥️ proc_fs 🖥️

mounted filesystems

DESCRIPTION

/proc/fs/
Contains subdirectories that in turn contain files with information about (certain) mounted filesystems.

76 - Linux cli command proc_cgroups

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_cgroups and provides detailed information about the command proc_cgroups, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_cgroups.

NAME 🖥️ proc_cgroups 🖥️

control groups

DESCRIPTION

/proc/cgroups (since Linux 2.6.24)
See cgroups(7).

77 - Linux cli command papersize

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command papersize and provides detailed information about the command papersize, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the papersize.

NAME 🖥️ papersize 🖥️

specify preferred paper size

SYNOPSYS

/etc/papersize

DESCRIPTION

The papersize file is used to specify the preferred paper size to use by available commands and programs generating documents.

The format of this file is extremely simple: whitespace and anything starting with `#’ is ignored, and the name of the paper is the first string found; the case in the name of the paper does not import (see CAVEATS section however).

PAPER NAMES

The following names are commonly understood by programs: a3, a4, a5, b5, letter, legal, executive, note and 11x17.

Additional paper names that one may encounter are: a0, a1, a2, a6, a7, a8, a9, a10, b0, b1, b2, b3, b4, tabloid, statement, note, halfletter, halfexecutive, folio, quarto, ledger, archA, archB, archC, archD, archE, flsa, flse, csheet, dsheet, esheet and 10x14.

The value of the papersize file can be overridden by looking in order at the PAPERSIZE environment variable, then at the contents of the file specified by the PAPERCONF environment variable. If the papersize file does not exist, programs using the paper library default to using letter as a fall-back value

CAVEATS

This manual page documents the format of the papersize file that is read by the libpaper library. Some programs that read this file do not yet use the library and may have trouble ignoring whitespace and comments in the file; they may also require that the paper names use a specific capitalization.

DOCUMENTATION

Yves Arrouye <[email protected]>

78 - Linux cli command org.bluez.obex.Session

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.obex.Session and provides detailed information about the command org.bluez.obex.Session, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.obex.Session.

NAME 🖥️ org.bluez.obex.Session 🖥️

BlueZ D-Bus OBEX Client API documentation

INTERFACE

Service
org.bluez.obex
Interface
org.bluez.obex.Session1
Object path
/org/bluez/obex/server/session{#} or /org/bluez/obex/client/session{#}

Methods

string GetCapabilities()

Get remote device capabilities.
Possible errors:
org.bluez.obex.Error.NotSupported
org.bluez.obex.Error.Failed

Properties

string Source [readonly]

Bluetooth adapter address

string Destination [readonly]

Bluetooth device address

byte Channel [readonly]

Bluetooth channel

string Target [readonly]

Target UUID

string Root [readonly]

Root path

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

79 - Linux cli command proc_pid_fdinfo

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_fdinfo and provides detailed information about the command proc_pid_fdinfo, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_fdinfo.

NAME 🖥️ proc_pid_fdinfo 🖥️

information about file descriptors

DESCRIPTION

/proc/pid/fdinfo/ (since Linux 2.6.22)
This is a subdirectory containing one entry for each file which the process has open, named by its file descriptor. The files in this directory are readable only by the owner of the process. The contents of each file can be read to obtain information about the corresponding file descriptor. The content depends on the type of file referred to by the corresponding file descriptor.

For regular files and directories, we see something like:

$ cat /proc/12015/fdinfo/4
pos:    1000
flags:  01002002
mnt_id: 21

The fields are as follows:

pos
This is a decimal number showing the file offset.

flags
This is an octal number that displays the file access mode and file status flags (see open(2)). If the close-on-exec file descriptor flag is set, then flags will also include the value O_CLOEXEC.

Before Linux 3.1, this field incorrectly displayed the setting of O_CLOEXEC at the time the file was opened, rather than the current setting of the close-on-exec flag.

mnt_id This field, present since Linux 3.15, is the ID of the mount containing this file. See the description of /proc/pid/mountinfo.

For eventfd file descriptors (see eventfd(2)), we see (since Linux 3.8) the following fields:

pos:	0
flags:	02
mnt_id:	10
eventfd-count:               40

eventfd-count is the current value of the eventfd counter, in hexadecimal.

For epoll file descriptors (see epoll(7)), we see (since Linux 3.8) the following fields:

pos:	0
flags:	02
mnt_id:	10
tfd:        9 events:       19 data: 74253d2500000009
tfd:        7 events:       19 data: 74253d2500000007

Each of the lines beginning tfd describes one of the file descriptors being monitored via the epoll file descriptor (see epoll_ctl(2) for some details). The tfd field is the number of the file descriptor. The events field is a hexadecimal mask of the events being monitored for this file descriptor. The data field is the data value associated with this file descriptor.

For signalfd file descriptors (see signalfd(2)), we see (since Linux 3.8) the following fields:

pos:	0
flags:	02
mnt_id:	10
sigmask:	0000000000000006

sigmask is the hexadecimal mask of signals that are accepted via this signalfd file descriptor. (In this example, bits 2 and 3 are set, corresponding to the signals SIGINT and SIGQUIT; see signal(7).)

For inotify file descriptors (see inotify(7)), we see (since Linux 3.8) the following fields:

pos:	0
flags:	00
mnt_id:	11
inotify wd:2 ino:7ef82a sdev:800001 mask:800afff ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:2af87e00220ffd73
inotify wd:1 ino:192627 sdev:800001 mask:800afff ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:27261900802dfd73

Each of the lines beginning with “inotify” displays information about one file or directory that is being monitored. The fields in this line are as follows:

wd
A watch descriptor number (in decimal).

ino
The inode number of the target file (in hexadecimal).

sdev
The ID of the device where the target file resides (in hexadecimal).

mask
The mask of events being monitored for the target file (in hexadecimal).

If the kernel was built with exportfs support, the path to the target file is exposed as a file handle, via three hexadecimal fields: fhandle-bytes, fhandle-type, and f_handle.

For fanotify file descriptors (see fanotify(7)), we see (since Linux 3.8) the following fields:

pos:	0
flags:	02
mnt_id:	11
fanotify flags:0 event-flags:88002
fanotify ino:19264f sdev:800001 mflags:0 mask:1 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:4f261900a82dfd73

The fourth line displays information defined when the fanotify group was created via fanotify_init(2):

flags
The flags argument given to fanotify_init(2) (expressed in hexadecimal).

event-flags
The event_f_flags argument given to fanotify_init(2) (expressed in hexadecimal).

Each additional line shown in the file contains information about one of the marks in the fanotify group. Most of these fields are as for inotify, except:

mflags
The flags associated with the mark (expressed in hexadecimal).

mask
The events mask for this mark (expressed in hexadecimal).

ignored_mask
The mask of events that are ignored for this mark (expressed in hexadecimal).

For details on these fields, see fanotify_mark(2).

For timerfd file descriptors (see timerfd(2)), we see (since Linux 3.17) the following fields:

pos:    0
flags:  02004002
mnt_id: 13
clockid: 0
ticks: 0
settime flags: 03
it_value: (7695568592, 640020877)
it_interval: (0, 0)

clockid
This is the numeric value of the clock ID (corresponding to one of the CLOCK_* constants defined via <time.h>) that is used to mark the progress of the timer (in this example, 0 is CLOCK_REALTIME).

ticks
This is the number of timer expirations that have occurred, (i.e., the value that read(2) on it would return).

settime flags
This field lists the flags with which the timerfd was last armed (see timerfd_settime(2)), in octal (in this example, both TFD_TIMER_ABSTIME and TFD_TIMER_CANCEL_ON_SET are set).

it_value
This field contains the amount of time until the timer will next expire, expressed in seconds and nanoseconds. This is always expressed as a relative value, regardless of whether the timer was created using the TFD_TIMER_ABSTIME flag.

it_interval
This field contains the interval of the timer, in seconds and nanoseconds. (The it_value and it_interval fields contain the values that timerfd_gettime(2) on this file descriptor would return.)

80 - Linux cli command libsasl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command libsasl and provides detailed information about the command libsasl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the libsasl.

NAME 🖥️ libsasl 🖥️

authentication library

SYNOPSIS

Cyrus SASL library handling communication between an application and the Cyrus SASL authentication framework.

Description

This document describes generic configuration options for the Cyrus SASL authentication library libsasl.

The library handles communication between an application and the Cyrus SASL authentication framework. Both exchange information before libsasl can start offering authentication services for the application.

The application, among other data, sends the service_name. The service name is the services name as specified by IANA. SMTP servers, for example, send smtp as service_name. This information is handed over by libsasl e.g. when Kerberos or PAM authentication takes place.

Configuration options in general are read either from a file or passed by the application using libsasl during library initialization.

File-Based configuration

When an application (server) starts, it initializes the libsasl library. The application passes app_name (application name) to the SASL library. Its value is used to construct the name of the application specific SASL configuration file. The Cyrus SASL sample-server, for example, sends sample as app_name. Using this value the SASL library will search the configuration directories for a file named sample.conf and read configuration options from it.

Note
Consult the applications manual to determine what app_name it sends to the Cyrus SASL library.

Application-Based Configuration

Configuration options for libsasl are written down together with application specific options in the applications configuration file. The application reads them and passes them over to libsasl when it loads the library.

Note
An example for application-based configuration is the Cyrus IMAP server imapd. SASL configuration is written to imapd.conf and passed to the SASL library when the imapd server starts.

Configuration Syntax

The general format of Cyrus SASL configuration file is as follows:

Configuration options
Configuration options are written each on a single physical line. Parameter and value must be separated by a colon and a single whitespace:

parameter: value

Important

There must be no trailing whitespace after the value or Cyrus SASL will fail to apply the value appropriately!

Comments, Empty lines and whitespace-only lines
Empty lines and whitespace-only lines are ignored, as are lines whose first non-whitespace character is a ‘#’.

Options

There are generic options and options specific to the password verification service or auxiliary property plugin chosen by the administrator. Such specific options are documented in manuals listed in libsasl(5).

The following configuration parameters are generic configuration options:

authdaemond_path (default: /dev/null)
Path to Courier MTA authdaemond’s unix socket. Only applicable when pwcheck_method is set to authdaemond.

auto_transition: (default: no)
Automatically transition users to other mechanisms when they do a successful plaintext authentication and if an auxprop plugin is used.

Important

This option does not apply to the ldapdb(5) plugin. It is a read-only plugin.

no
Do not transition users to other mechanisms.

noplain
Transition users to other mechanisms, but write non-plaintext secrets only.

yes
Transition users to other mechanisms.

Note

The only mechanisms (as currently implemented) which don’t use plaintext secrets are OTP and SRP.

auxprop_plugin: (default: empty)
A whitespace-separated list of one or more auxiliary plugins used if the pwcheck_method parameter specifies auxprop as an option. Plugins will be queried in list order. If no plugin is specified, all available plugins will be queried.

ldapdb
Specify ldapdb to use the Cyrus SASL ldapdb(5) plugin.

sasldb
Specify sasldb to use the Cyrus SASL sasldb(5) plugin.

sql
Specify sql to use the Cyrus SASL sql(5) plugin.

log_level: (default: 1)
Specifies a numeric log level. Available log levels are:

0
Don’t log anything

1
Log unusual errors

2
Log all authentication failures

3
Log non-fatal warnings

4
More verbose than 3

5
More verbose than 4

6
Traces of internal protocols

7
Traces of internal protocols, including passwords

Important

Cyrus SASL sends log messages to the application that runs it. The application decides if it forwards such messages to the sysklogd(8) service, to which facility they are sent and which priority is given to the message.

mech_list: (default: empty)
The optional mech_list parameter specifies a whitespace-separated list of one or more mechanisms allowed for authentication.

pwcheck_method: (default: auxprop)
A whitespace-separated list of one or more mechanisms. Cyrus SASL provides the following mechanisms:

authdaemond
Configures Cyrus SASL to contact the Courier MTA authdaemond(8) password verification service for password verification.

alwaystrue
Lets the pwcheck succeed always.

auxprop
Cyrus SASL will use its own plugin infrastructure to verify passwords. The auxprop_plugin parameter controls which plugins will be used.

pwcheck
Verify passwords using the Cyrus SASL pwcheck(8) password verification service. The pwcheck daemon is considered deprecated and should not be used anymore. Use the saslauthd password verification service instead.

saslauthd
Verify passwords using the Cyrus SASL saslauthd(8) password verification service.

saslauthd_path: (default: empty)
Path to saslauthd(8) run directory (including the /mux named pipe)

Author

This manual was written for the Debian distribution because the original program does not have a manual page. Parts of the documentation have been taken from the Cyrus SASL’s options.html.

Patrick Ben Koetter [email protected]

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

81 - Linux cli command gitformat-index

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitformat-index and provides detailed information about the command gitformat-index, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitformat-index.

NAME 🖥️ gitformat-index 🖥️

index - Git index format

SYNOPSIS

$GIT_DIR/index

DESCRIPTION

Git index format

THE GIT INDEX FILE HAS THE FOLLOWING FORMAT

All binary numbers are in network byte order. In a repository using the traditional SHA-1, checksums and object IDs (object names) mentioned below are all computed using SHA-1. Similarly, in SHA-256 repositories, these values are computed using SHA-256. Version 2 is described here unless stated otherwise.

·
A 12-byte header consisting of
4-byte signature: The signature is { D, I, R, C } (stands for “dircache”)
4-byte version number: The current supported versions are 2, 3 and 4.
32-bit number of index entries.

·
A number of sorted index entries (see below).

·
Extensions
Extensions are identified by signature. Optional extensions can be ignored if Git does not understand them.
4-byte extension signature. If the first byte is A..Z the extension is optional and can be ignored.
32-bit size of the extension
Extension data

·
Hash checksum over the content of the index file before this checksum.

INDEX ENTRY

Index entries are sorted in ascending order on the name field, interpreted as a string of unsigned bytes (i.e. memcmp() order, no localization, no special casing of directory separator /). Entries with the same name are sorted by their stage field.

An index entry typically represents a file. However, if sparse-checkout is enabled in cone mode (core.sparseCheckoutCone is enabled) and the extensions.sparseIndex extension is enabled, then the index may contain entries for directories outside of the sparse-checkout definition. These entries have mode 040000, include the SKIP_WORKTREE bit, and the path ends in a directory separator.

32-bit ctime seconds, the last time a files metadata changed this is stat(2) data

32-bit ctime nanosecond fractions this is stat(2) data

32-bit mtime seconds, the last time a files data changed this is stat(2) data

32-bit mtime nanosecond fractions this is stat(2) data

32-bit dev this is stat(2) data

32-bit ino this is stat(2) data

32-bit mode, split into (high to low bits)

16-bit unused, must be zero

4-bit object type valid values in binary are 1000 (regular file), 1010 (symbolic link) and 1110 (gitlink)

3-bit unused, must be zero

9-bit unix permission. Only 0755 and 0644 are valid for regular files. Symbolic links and gitlinks have value 0 in this field.

32-bit uid this is stat(2) data

32-bit gid this is stat(2) data

32-bit file size This is the on-disk size from stat(2), truncated to 32-bit.

Object name for the represented object

A 16-bit flags field split into (high to low bits)

1-bit assume-valid flag

1-bit extended flag (must be zero in version 2)

2-bit stage (during merge)

12-bit name length if the length is less than 0xFFF; otherwise 0xFFF is stored in this field.

(Version 3 or later) A 16-bit field, only applicable if the “extended flag” above is 1, split into (high to low bits).

1-bit reserved for future

1-bit skip-worktree flag (used by sparse checkout)

1-bit intent-to-add flag (used by “git add -N”)

13-bit unused, must be zero

Entry path name (variable length) relative to top level directory (without leading slash). / is used as path separator. The special path components “.”, “..” and “.git” (without quotes) are disallowed. Trailing slash is also disallowed.

The exact encoding is undefined, but the . and / characters are encoded in 7-bit ASCII and the encoding cannot contain a NUL byte (iow, this is a UNIX pathname).

(Version 4) In version 4, the entry path name is prefix-compressed relative to the path name for the previous entry (the very first entry is encoded as if the path name for the previous entry is an empty string). At the beginning of an entry, an integer N in the variable width encoding (the same encoding as the offset is encoded for OFS_DELTA pack entries; see linkgit:gitformat-pack[5]) is stored, followed by a NUL-terminated string S. Removing N bytes from the end of the path name for the previous entry, and replacing it with the string S yields the path name for this entry.

1-8 nul bytes as necessary to pad the entry to a multiple of eight bytes while keeping the name NUL-terminated.

(Version 4) In version 4, the padding after the pathname does not exist.

Interpretation of index entries in split index mode is completely different. See below for details.

EXTENSIONS

Cache tree

Since the index does not record entries for directories, the cache entries cannot describe tree objects that already exist in the object database for regions of the index that are unchanged from an existing commit. The cache tree extension stores a recursive tree structure that describes the trees that already exist and completely match sections of the cache entries. This speeds up tree object generation from the index for a new commit by only computing the trees that are “new” to that commit. It also assists when comparing the index to another tree, such as HEAD^{tree}, since sections of the index can be skipped when a tree comparison demonstrates equality.

The recursive tree structure uses nodes that store a number of cache entries, a list of subnodes, and an object ID (OID). The OID references the existing tree for that node, if it is known to exist. The subnodes correspond to subdirectories that themselves have cache tree nodes. The number of cache entries corresponds to the number of cache entries in the index that describe paths within that trees directory.

The extension tracks the full directory structure in the cache tree extension, but this is generally smaller than the full cache entry list.

When a path is updated in index, Git invalidates all nodes of the recursive cache tree corresponding to the parent directories of that path. We store these tree nodes as being “invalid” by using “-1” as the number of cache entries. Invalid nodes still store a span of index entries, allowing Git to focus its efforts when reconstructing a full cache tree.

The signature for this extension is { T, R, E, E }.

A series of entries fill the entire extension; each of which consists of:

·
NUL-terminated path component (relative to its parent directory);

·
ASCII decimal number of entries in the index that is covered by the tree this entry represents (entry_count);

·
A space (ASCII 32);

·
ASCII decimal number that represents the number of subtrees this tree has;

·
A newline (ASCII 10); and

·
Object name for the object that would result from writing this span of index as a tree.
An entry can be in an invalidated state and is represented by having a negative number in the entry_count field. In this case, there is no object name and the next entry starts immediately after the newline. When writing an invalid entry, -1 should always be used as entry_count.
The entries are written out in the top-down, depth-first order. The first entry represents the root level of the repository, followed by the first subtree–lets call this A–of the root level (with its name relative to the root level), followed by the first subtree of A (with its name relative to A), and so on. The specified number of subtrees indicates when the current level of the recursive stack is complete.

Resolve undo

A conflict is represented in the index as a set of higher stage entries. When a conflict is resolved (e.g. with “git add path”), these higher stage entries will be removed and a stage-0 entry with proper resolution is added.

When these higher stage entries are removed, they are saved in the resolve undo extension, so that conflicts can be recreated (e.g. with “git checkout -m”), in case users want to redo a conflict resolution from scratch.

The signature for this extension is { R, E, U, C }.

A series of entries fill the entire extension; each of which consists of:

·
NUL-terminated pathname the entry describes (relative to the root of the repository, i.e. full pathname);

·
Three NUL-terminated ASCII octal numbers, entry mode of entries in stage 1 to 3 (a missing stage is represented by “0” in this field); and

·
At most three object names of the entry in stages from 1 to 3 (nothing is written for a missing stage).

Split index

In split index mode, the majority of index entries could be stored in a separate file. This extension records the changes to be made on top of that to produce the final index.

The signature for this extension is { l, i, n, k }.

The extension consists of:

·
Hash of the shared index file. The shared index file path is $GIT_DIR/sharedindex.<hash>. If all bits are zero, the index does not require a shared index file.

·
An ewah-encoded delete bitmap, each bit represents an entry in the shared index. If a bit is set, its corresponding entry in the shared index will be removed from the final index. Note, because a delete operation changes index entry positions, but we do need original positions in replace phase, it’s best to just mark entries for removal, then do a mass deletion after replacement.

·
An ewah-encoded replace bitmap, each bit represents an entry in the shared index. If a bit is set, its corresponding entry in the shared index will be replaced with an entry in this index file. All replaced entries are stored in sorted order in this index. The first “1” bit in the replace bitmap corresponds to the first index entry, the second “1” bit to the second entry and so on. Replaced entries may have empty path names to save space.
The remaining index entries after replaced ones will be added to the final index. These added entries are also sorted by entry name then stage.

UNTRACKED CACHE

Untracked cache saves the untracked file list and necessary data to verify the cache. The signature for this extension is { U, N, T, R }.

The extension starts with

·
A sequence of NUL-terminated strings, preceded by the size of the sequence in variable width encoding. Each string describes the environment where the cache can be used.

·
Stat data of $GIT_DIR/info/exclude. See “Index entry” section from ctime field until “file size”.

·
Stat data of core.excludesFile

·
32-bit dir_flags (see struct dir_struct)

·
Hash of $GIT_DIR/info/exclude. A null hash means the file does not exist.

·
Hash of core.excludesFile. A null hash means the file does not exist.

·
NUL-terminated string of per-dir exclude file name. This usually is “.gitignore”.

·
The number of following directory blocks, variable width encoding. If this number is zero, the extension ends here with a following NUL.

·
A number of directory blocks in depth-first-search order, each consists of

·
The number of untracked entries, variable width encoding.

·
The number of sub-directory blocks, variable width encoding.

·
The directory name terminated by NUL.

·
A number of untracked file/dir names terminated by NUL.

The remaining data of each directory block is grouped by type:

·
An ewah bitmap, the n-th bit marks whether the n-th directory has valid untracked cache entries.

·
An ewah bitmap, the n-th bit records “check-only” bit of read_directory_recursive() for the n-th directory.

·
An ewah bitmap, the n-th bit indicates whether hash and stat data is valid for the n-th directory and exists in the next data.

·
An array of stat data. The n-th data corresponds with the n-th “one” bit in the previous ewah bitmap.

·
An array of hashes. The n-th hash corresponds with the n-th “one” bit in the previous ewah bitmap.

·
One NUL.

FILE SYSTEM MONITOR CACHE

The file system monitor cache tracks files for which the core.fsmonitor hook has told us about changes. The signature for this extension is { F, S, M, N }.

The extension starts with

·
32-bit version number: the current supported versions are 1 and 2.

·
(Version 1) 64-bit time: the extension data reflects all changes through the given time which is stored as the nanoseconds elapsed since midnight, January 1, 1970.

·
(Version 2) A null terminated string: an opaque token defined by the file system monitor application. The extension data reflects all changes relative to that token.

·
32-bit bitmap size: the size of the CE_FSMONITOR_VALID bitmap.

·
An ewah bitmap, the n-th bit indicates whether the n-th index entry is not CE_FSMONITOR_VALID.

END OF INDEX ENTRY

The End of Index Entry (EOIE) is used to locate the end of the variable length index entries and the beginning of the extensions. Code can take advantage of this to quickly locate the index extensions without having to parse through all of the index entries.

Because it must be able to be loaded before the variable length cache entries and other index extensions, this extension must be written last. The signature for this extension is { E, O, I, E }.

The extension consists of:

·
32-bit offset to the end of the index entries

·
Hash over the extension types and their sizes (but not their contents). E.g. if we have “TREE” extension that is N-bytes long, “REUC” extension that is M-bytes long, followed by “EOIE”, then the hash would be:
Hash(“TREE” + + “REUC” + )

INDEX ENTRY OFFSET TABLE

The Index Entry Offset Table (IEOT) is used to help address the CPU cost of loading the index by enabling multi-threading the process of converting cache entries from the on-disk format to the in-memory format. The signature for this extension is { I, E, O, T }.

The extension consists of:

·
32-bit version (currently 1)

·
A number of index offset entries each consisting of:

·
32-bit offset from the beginning of the file to the first cache entry in this block of entries.

·
32-bit count of cache entries in this block

SPARSE DIRECTORY ENTRIES

When using sparse-checkout in cone mode, some entire directories within the index can be summarized by pointing to a tree object instead of the entire expanded list of paths within that tree. An index containing such entries is a “sparse index”. Index format versions 4 and less were not implemented with such entries in mind. Thus, for these versions, an index containing sparse directory entries will include this extension with signature { s, d, i, r }. Like the split-index extension, tools should avoid interacting with a sparse index unless they understand this extension.

GIT

Part of the git(1) suite

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

82 - Linux cli command mke2fs.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command mke2fs.conf and provides detailed information about the command mke2fs.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the mke2fs.conf.

NAME 🖥️ mke2fs.conf 🖥️

Configuration file for mke2fs

DESCRIPTION

mke2fs.conf is the configuration file for mke2fs(8). It controls the default parameters used by mke2fs(8) when it is creating ext2, ext3, or ext4 file systems.

The mke2fs.conf file uses an INI-style format. Stanzas, or top-level sections, are delimited by square braces: [ ]. Within each section, each line defines a relation, which assigns tags to values, or to a subsection, which contains further relations or subsections. An example of the INI-style format used by this configuration file follows below:

[section1]
tag1 = value_a
tag1 = value_b
tag2 = value_c

[section 2]
tag3 = {
subtag1 = subtag_value_a
subtag1 = subtag_value_b
subtag2 = subtag_value_c
}
tag1 = value_d
tag2 = value_e
}

Comments are delimited by a semicolon (’;’) or a hash (’#’) character at the beginning of the comment, and are terminated by the end of line character.

Tags and values must be quoted using double quotes if they contain spaces. Within a quoted string, the standard backslash interpretations apply: " " (for the newline character), " " (for the tab character), “” (for the backspace character), and “" (for the backslash character).

Some relations expect a boolean value. The parser is quite liberal on recognizing ``yes’’, ‘`y’’, ``true’’, ``t’’, ``1’’, ``on’’, etc. as a boolean true value, and ``no’’, ``n’’, ``false’’, ``nil’’, ``0’’, ``off’’ as a boolean false value.

The following stanzas are used in the mke2fs.conf file. They will be described in more detail in future sections of this document.

[options]
Contains relations which influence how mke2fs behaves.

[defaults]
Contains relations which define the default parameters used by mke2fs(8). In general, these defaults may be overridden by a definition in the fs_types stanza, or by a command-line option provided by the user.

[fs_types]
Contains relations which define defaults that should be used for specific file system and usage types. The file system type and usage type can be specified explicitly using the -tand**-T** options to mke2fs(8), respectively.

[devices]
Contains relations which define defaults for specific devices.

THE [options] STANZA

The following relations are defined in the [options] stanza.

proceed_delay
If this relation is set to a positive integer, then mke2fs will wait proceed_delay seconds after asking the user for permission to proceed and then continue, even if the user has not answered the question. Defaults to 0, which means to wait until the user answers the question one way or another.

sync_kludge
If this relation is set to a positive integer, then while writing the inode table, mke2fs will request the operating system flush out pending writes to initialize the inode table every sync_kludge block groups. This is needed to work around buggy kernels that don’t handle writeback throttling correctly.

THE [defaults] STANZA

The following relations are defined in the [defaults] stanza.

creator_os
This relation specifies the “creator operating system” for the file system unless it is overridden on the command line. The default value is the OS for which the mke2fs executable was compiled.

fs_type
This relation specifies the default file system type if the user does not specify it via the -t option, or if mke2fs is not started using a program name of the form **mkfs.**fs-type. If both the user and the mke2fs.conf file do not specify a default file system type, mke2fs will use a default file system type of ext3 if a journal was requested via a command-line option, or ext2 if not.

undo_dir
This relation specifies the directory where the undo file should be stored. It can be overridden via the E2FSPROGS_UNDO_DIR environment variable. If the directory location is set to the value none, mke2fs will not create an undo file.

In addition, any tags that can be specified in a per-file system tags subsection as defined below (e.g., blocksize, hash_alg, inode_ratio, inode_size, reserved_ratio, etc.) can also be specified in the defaults stanza to specify the default value to be used if the user does not specify one on the command line, and the file system-type specific section of the configuration file does not specify a default value.

THE [fs_types] STANZA

Each tag in the [fs_types] stanza names a file system type or usage type which can be specified via the -t or -T options to mke2fs(8), respectively.

The mke2fs program constructs a list of fs_types by concatenating the file system type (i.e., ext2, ext3, etc.) with the usage type list. For most configuration options, mke2fs will look for a subsection in the [fs_types] stanza corresponding with each entry in the constructed list, with later entries overriding earlier file system or usage types. For example, consider the following mke2fs.conf fragment:

[defaults]
base_features = sparse_super,filetype,resize_inode,dir_index
blocksize = 4096
inode_size = 256
inode_ratio = 16384

[fs_types]
ext3 = {
features = has_journal
}
ext4 = {
features = extents,flex_bg
inode_size = 256
}
small = {
blocksize = 1024
inode_ratio = 4096
}
floppy = {
features = ^resize_inode
blocksize = 1024
inode_size = 128
}

If mke2fs started with a program name of mke2fs.ext4, then the file system type of ext4 will be used. If the file system is smaller than 3 megabytes, and no usage type is specified, then mke2fs will use a default usage type of floppy. This results in an fs_types list of “ext4, floppy”. Both the ext4 subsection and the floppy subsection define an inode_size relation, but since the later entries in the fs_types list supersede earlier ones, the configuration parameter for fs_types.floppy.inode_size will be used, so the file system will have an inode size of 128.

The exception to this resolution is the features tag, which specifies a set of changes to the features used by the file system, and which is cumulative. So in the above example, first the configuration relation defaults.base_features would enable an initial feature set with the sparse_super, filetype, resize_inode, and dir_index features enabled. Then configuration relation fs_types.ext4.features would enable the extents and flex_bg features, and finally the configuration relation fs_types.floppy.features would remove the resize_inode feature, resulting in a file system feature set consisting of the sparse_super, filetype, dir_index, extents_and flex_bg features.

For each file system type, the following tags may be used in that fs_type’s subsection. These tags may also be used in the default section:

base_features
This relation specifies the features which are initially enabled for this file system type. Only one base_features will be used, so if there are multiple entries in the fs_types list whose subsections define the base_features relation, only the last will be used by mke2fs(8).

enable_periodic_fsck
This boolean relation specifies whether periodic file system checks should be enforced at boot time. If set to true, checks will be forced every 180 days, or after a random number of mounts. These values may be changed later via the -i and -c command-line options to tune2fs(8).

errors
Change the behavior of the kernel code when errors are detected. In all cases, a file system error will cause e2fsck(8) to check the file system on the next boot. errors can be one of the following:

continue
Continue normal execution.

remount-ro
Remount file system read-only.

panic
Cause a kernel panic.

features
This relation specifies a comma-separated list of features edit requests which modify the feature set used by the newly constructed file system. The syntax is the same as the -O command-line option to mke2fs(8); that is, a feature can be prefixed by a caret (’^’) symbol to disable a named feature. Each feature relation specified in the fs_types list will be applied in the order found in the fs_types list.

force_undo
This boolean relation, if set to a value of true, forces mke2fs to always try to create an undo file, even if the undo file might be huge and it might extend the time to create the file system image because the inode table isn’t being initialized lazily.

default_features
This relation specifies set of features which should be enabled or disabled after applying the features listed in the base_features and features relations. It may be overridden by the -O command-line option to mke2fs(8).

auto_64-bit_support
This relation is a boolean which specifies whether mke2fs(8) should automatically add the 64bit feature if the number of blocks for the file system requires this feature to be enabled. The resize_inode feature is also automatically disabled since it doesn’t support 64-bit block numbers.

default_mntopts
This relation specifies the set of mount options which should be enabled by default. These may be changed at a later time with the -o command-line option to tune2fs(8).

blocksize
This relation specifies the default blocksize if the user does not specify a blocksize on the command line.

lazy_itable_init
This boolean relation specifies whether the inode table should be lazily initialized. It only has meaning if the uninit_bg feature is enabled. If lazy_itable_init is true and the uninit_bg feature is enabled, the inode table will not be fully initialized by mke2fs(8). This speeds up file system initialization noticeably, but it requires the kernel to finish initializing the file system in the background when the file system is first mounted.

lazy_journal_init
This boolean relation specifies whether the journal inode should be lazily initialized. It only has meaning if the has_journal feature is enabled. If lazy_journal_init is true, the journal inode will not be fully zeroed out by mke2fs. This speeds up file system initialization noticeably, but carries some small risk if the system crashes before the journal has been overwritten entirely one time.

journal_location
This relation specifies the location of the journal.

num_backup_sb
This relation indicates whether file systems with the sparse_super2 feature enabled should be created with 0, 1, or 2 backup superblocks.

packed_meta_blocks
This boolean relation specifies whether the allocation bitmaps, inode table, and journal should be located at the beginning of the file system.

inode_ratio
This relation specifies the default inode ratio if the user does not specify one on the command line.

inode_size
This relation specifies the default inode size if the user does not specify one on the command line.

reserved_ratio
This relation specifies the default percentage of file system blocks reserved for the super-user, if the user does not specify one on the command line.

hash_alg
This relation specifies the default hash algorithm used for the new file systems with hashed b-tree directories. Valid algorithms accepted are: legacy, half_md4, and tea.

flex_bg_size
This relation specifies the number of block groups that will be packed together to create one large virtual block group on an ext4 file system. This improves meta-data locality and performance on meta-data heavy workloads. The number of groups must be a power of 2 and may only be specified if the flex_bg file system feature is enabled.

options
This relation specifies additional extended options which should be treated by mke2fs(8) as if they were prepended to the argument of the -E option. This can be used to configure the default extended options used by mke2fs(8) on a per-file system type basis.

discard
This boolean relation specifies whether the mke2fs(8) should attempt to discard device prior to file system creation.

cluster_size
This relation specifies the default cluster size if the bigalloc file system feature is enabled. It can be overridden via the -C command line option to mke2fs(8)

make_hugefiles
This boolean relation enables the creation of pre-allocated files as part of formatting the file system. The extent tree blocks for these pre-allocated files will be placed near the beginning of the file system, so that if all of the other metadata blocks are also configured to be placed near the beginning of the file system (by disabling the backup superblocks, using the packed_meta_blocks option, etc.), the data blocks of the pre-allocated files will be contiguous.

hugefiles_dir
This relation specifies the directory where huge files are created, relative to the file system root.

hugefiles_uid
This relation controls the user ownership for all of the files and directories created by the make_hugefiles feature.

hugefiles_gid
This relation controls the group ownership for all of the files and directories created by the make_hugefiles feature.

hugefiles_umask
This relation specifies the umask used when creating the files and directories by the make_hugefiles feature.

num_hugefiles
This relation specifies the number of huge files to be created. If this relation is not specified, or is set to zero, and the hugefiles_size relation is non-zero, then make_hugefiles will create as many huge files as can fit to fill the entire file system.

hugefiles_slack
This relation specifies how much space should be reserved for other files.

hugefiles_size
This relation specifies the size of the huge files. If this relation is not specified, the default is to fill the entire file system.

hugefiles_align
This relation specifies the alignment for the start block of the huge files. It also forces the size of huge files to be a multiple of the requested alignment. If this relation is not specified, no alignment requirement will be imposed on the huge files.

hugefiles_align_disk
This relations specifies whether the alignment should be relative to the beginning of the hard drive (assuming that the starting offset of the partition is available to mke2fs). The default value is false, which will cause hugefile alignment to be relative to the beginning of the file system.

hugefiles_name
This relation specifies the base file name for the huge files.

hugefiles_digits
This relation specifies the (zero-padded) width of the field for the huge file number.

warn_y2038_dates
This boolean relation specifies whether mke2fs will issue a warning when creating a file system with 128 byte inodes (and so therefore will not support dates after January 19th, 2038). The default value is true, except for file systems created for the GNU Hurd since it only supports 128-byte inodes.

zero_hugefiles
This boolean relation specifies whether or not zero blocks will be written to the hugefiles while mke2fs(8) is creating them. By default, zero blocks will be written to the huge files to avoid stale data from being made available to potentially untrusted user programs, unless the device supports a discard/trim operation which will take care of zeroing the device blocks. By setting zero_hugefiles to false, this step will always be skipped, which can be useful if it is known that the disk has been previously erased, or if the user programs that will have access to the huge files are trusted to not reveal stale data.

encoding
This relation defines the file name encoding to be used if the casefold feature is enabled. Currently the only valid encoding is utf8-12.1 or utf8, which requests the most recent Unicode version; since 12.1 is the only available Unicode version, utf8 and utf8-12.1 have the same result. encoding_flags This relation defines encoding-specific flags. For utf8 encodings, the only available flag is strict, which will cause attempts to create file names containing invalid Unicode characters to be rejected by the kernel. Strict mode is not enabled by default.

THE [devices] STANZA

Each tag in the [devices] stanza names device name so that per-device defaults can be specified.

fs_type
This relation specifies the default parameter for the -t option, if this option isn’t specified on the command line.

usage_types
This relation specifies the default parameter for the -T option, if this option isn’t specified on the command line.

FILES

/etc/mke2fs.conf
The configuration file for mke2fs(8).

83 - Linux cli command tzfile

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command tzfile and provides detailed information about the command tzfile, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the tzfile.

NAME 🖥️ tzfile 🖥️

timezone information

DESCRIPTION

The timezone information files used by tzset(3) are typically found under a directory with a name like /usr/share/zoneinfo. These files use the format described in Internet RFC 8536. Each file is a sequence of 8-bit bytes. In a file, a binary integer is represented by a sequence of one or more bytes in network order (bigendian, or high-order byte first), with all bits significant, a signed binary integer is represented using two’s complement, and a boolean is represented by a one-byte binary integer that is either 0 (false) or 1 (true). The format begins with a 44-byte header containing the following fields:

The magic four-byte ASCII sequence “TZif” identifies the file as a timezone information file.
A byte identifying the version of the file’s format (as of 2021, either an ASCII NUL, “2”, “3”, or “4”).
Fifteen bytes containing zeros reserved for future use.
Six four-byte integer values, in the following order:
tzh_ttisutcnt
The number of UT/local indicators stored in the file. (UT is Universal Time.)
tzh_ttisstdcnt
The number of standard/wall indicators stored in the file.
tzh_leapcnt
The number of leap seconds for which data entries are stored in the file.
tzh_timecnt
The number of transition times for which data entries are stored in the file.
tzh_typecnt
The number of local time types for which data entries are stored in the file (must not be zero).
tzh_charcnt
The number of bytes of time zone abbreviation strings stored in the file.

The above header is followed by the following fields, whose lengths depend on the contents of the header:

tzh_timecnt four-byte signed integer values sorted in ascending order. These values are written in network byte order. Each is used as a transition time (as returned by time(2)) at which the rules for computing local time change.
tzh_timecnt one-byte unsigned integer values; each one but the last tells which of the different types of local time types described in the file is associated with the time period starting with the same-indexed transition time and continuing up to but not including the next transition time. (The last time type is present only for consistency checking with the POSIX.1-2017-style TZ string described below.) These values serve as indices into the next field.
tzh_typecnt ttinfo entries, each defined as follows:
struct ttinfo {
	int32_t	tt_utoff;
	unsigned char	tt_isdst;
	unsigned char	tt_desigidx;
};
Each structure is written as a four-byte signed integer value for tt_utoff, in network byte order, followed by a one-byte boolean for tt_isdst and a one-byte value for tt_desigidx. In each structure, tt_utoff gives the number of seconds to be added to UT, tt_isdst tells whether tm_isdst should be set by localtime(3) and tt_desigidx serves as an index into the array of time zone abbreviation bytes that follow the ttinfo entries in the file; if the designated string is “00”, the ttinfo entry is a placeholder indicating that local time is unspecified. The tt_utoff value is never equal to -2**31, to let 32-bit clients negate it without overflow. Also, in realistic applications tt_utoff is in the range [-89999, 93599] (i.e., more than -25 hours and less than 26 hours); this allows easy support by implementations that already support the POSIX-required range [-24:59:59, 25:59:59].
tzh_charcnt bytes that represent time zone designations, which are null-terminated byte strings, each indexed by the tt_desigidx values mentioned above. The byte strings can overlap if one is a suffix of the other. The encoding of these strings is not specified.
tzh_leapcnt pairs of four-byte values, written in network byte order; the first value of each pair gives the nonnegative time (as returned by time(2)) at which a leap second occurs or at which the leap second table expires; the second is a signed integer specifying the correction, which is the total number of leap seconds to be applied during the time period starting at the given time. The pairs of values are sorted in strictly ascending order by time. Each pair denotes one leap second, either positive or negative, except that if the last pair has the same correction as the previous one, the last pair denotes the leap second table’s expiration time. Each leap second is at the end of a UTC calendar month. The first leap second has a nonnegative occurrence time, and is a positive leap second if and only if its correction is positive; the correction for each leap second after the first differs from the previous leap second by either 1 for a positive leap second, or -1 for a negative leap second. If the leap second table is empty, the leap-second correction is zero for all timestamps; otherwise, for timestamps before the first occurrence time, the leap-second correction is zero if the first pair’s correction is 1 or -1, and is unspecified otherwise (which can happen only in files truncated at the start).
tzh_ttisstdcnt standard/wall indicators, each stored as a one-byte boolean; they tell whether the transition times associated with local time types were specified as standard time or local (wall clock) time.
tzh_ttisutcnt UT/local indicators, each stored as a one-byte boolean; they tell whether the transition times associated with local time types were specified as UT or local time. If a UT/local indicator is set, the corresponding standard/wall indicator must also be set.

The standard/wall and UT/local indicators were designed for transforming a TZif file’s transition times into transitions appropriate for another time zone specified via a POSIX.1-2017-style TZ string that lacks rules. For example, when TZ=“EET2EEST” and there is no TZif file “EET2EEST”, the idea was to adapt the transition times from a TZif file with the well-known name “posixrules” that is present only for this purpose and is a copy of the file “Europe/Brussels”, a file with a different UT offset. POSIX does not specify this obsolete transformational behavior, the default rules are installation-dependent, and no implementation is known to support this feature for timestamps past 2037, so users desiring (say) Greek time should instead specify TZ=“Europe/Athens” for better historical coverage, falling back on TZ=“EET2EEST,M3.5.0/3,M10.5.0/4” if POSIX conformance is required and older timestamps need not be handled accurately.

The localtime(3) function normally uses the first ttinfo structure in the file if either tzh_timecnt is zero or the time argument is less than the first transition time recorded in the file.

NOTES

This manual page documents <tzfile.h> in the glibc source archive, see timezone/tzfile.h.

It seems that timezone uses tzfile internally, but glibc refuses to expose it to userspace. This is most likely because the standardised functions are more useful and portable, and actually documented by glibc. It may only be in glibc just to support the non-glibc-maintained timezone data (which is maintained by some other entity).

Version 2 format

For version-2-format timezone files, the above header and data are followed by a second header and data, identical in format except that eight bytes are used for each transition time or leap second time. (Leap second counts remain four bytes.) After the second header and data comes a newline-enclosed string in the style of the contents of a POSIX.1-2017 TZ environment variable, for use in handling instants after the last transition time stored in the file or for all instants if the file has no transitions. The TZ string is empty (i.e., nothing between the newlines) if there is no POSIX.1-2017-style representation for such instants. If nonempty, the TZ string must agree with the local time type after the last transition time if present in the eight-byte data; for example, given the string “WET0WEST,M3.5.0/1,M10.5.0” then if a last transition time is in July, the transition’s local time type must specify a daylight-saving time abbreviated “WEST” that is one hour east of UT. Also, if there is at least one transition, time type 0 is associated with the time period from the indefinite past up to but not including the earliest transition time.

Version 3 format

For version-3-format timezone files, the TZ string may use two minor extensions to the POSIX.1-2017 TZ format, as described in newtzset(3). First, the hours part of its transition times may be signed and range from -167 through 167 instead of the POSIX-required unsigned values from 0 through 24. Second, DST is in effect all year if it starts January 1 at 00:00 and ends December 31 at 24:00 plus the difference between daylight saving and standard time.

Version 4 format

For version-4-format TZif files, the first leap second record can have a correction that is neither +1 nor -1, to represent truncation of the TZif file at the start. Also, if two or more leap second transitions are present and the last entry’s correction equals the previous one, the last entry denotes the expiration of the leap second table instead of a leap second; timestamps after this expiration are unreliable in that future releases will likely add leap second entries after the expiration, and the added leap seconds will change how post-expiration timestamps are treated.

Interoperability considerations

Future changes to the format may append more data.

Version 1 files are considered a legacy format and should not be generated, as they do not support transition times after the year 2038. Readers that understand only Version 1 must ignore any data that extends beyond the calculated end of the version 1 data block.

Other than version 1, writers should generate the lowest version number needed by a file’s data. For example, a writer should generate a version 4 file only if its leap second table either expires or is truncated at the start. Likewise, a writer not generating a version 4 file should generate a version 3 file only if TZ string extensions are necessary to accurately model transition times.

The sequence of time changes defined by the version 1 header and data block should be a contiguous sub-sequence of the time changes defined by the version 2+ header and data block, and by the footer. This guideline helps obsolescent version 1 readers agree with current readers about timestamps within the contiguous sub-sequence. It also lets writers not supporting obsolescent readers use a tzh_timecnt of zero in the version 1 data block to save space.

When a TZif file contains a leap second table expiration time, TZif readers should either refuse to process post-expiration timestamps, or process them as if the expiration time did not exist (possibly with an error indication).

Time zone designations should consist of at least three (3) and no more than six (6) ASCII characters from the set of alphanumerics, “”, and “+”. This is for compatibility with POSIX requirements for time zone abbreviations.

When reading a version 2 or higher file, readers should ignore the version 1 header and data block except for the purpose of skipping over them.

Readers should calculate the total lengths of the headers and data blocks and check that they all fit within the actual file size, as part of a validity check for the file.

When a positive leap second occurs, readers should append an extra second to the local minute containing the second just before the leap second. If this occurs when the UTC offset is not a multiple of 60 seconds, the leap second occurs earlier than the last second of the local minute and the minute’s remaining local seconds are numbered through 60 instead of the usual 59; the UTC offset is unaffected.

Common interoperability issues

This section documents common problems in reading or writing TZif files. Most of these are problems in generating TZif files for use by older readers. The goals of this section are:

to help TZif writers output files that avoid common pitfalls in older or buggy TZif readers,
to help TZif readers avoid common pitfalls when reading files generated by future TZif writers, and
to help any future specification authors see what sort of problems arise when the TZif format is changed.

When new versions of the TZif format have been defined, a design goal has been that a reader can successfully use a TZif file even if the file is of a later TZif version than what the reader was designed for. When complete compatibility was not achieved, an attempt was made to limit glitches to rarely used timestamps and allow simple partial workarounds in writers designed to generate new-version data useful even for older-version readers. This section attempts to document these compatibility issues and workarounds, as well as to document other common bugs in readers.

Interoperability problems with TZif include the following:

Some readers examine only version 1 data. As a partial workaround, a writer can output as much version 1 data as possible. However, a reader should ignore version 1 data, and should use version 2+ data even if the reader’s native timestamps have only 32 bits.
Some readers designed for version 2 might mishandle timestamps after a version 3 or higher file’s last transition, because they cannot parse extensions to POSIX.1-2017 in the TZ-like string. As a partial workaround, a writer can output more transitions than necessary, so that only far-future timestamps are mishandled by version 2 readers.
Some readers designed for version 2 do not support permanent daylight saving time with transitions after 24:00 – e.g., a TZ string “EST5EDT,0/0,J365/25” denoting permanent Eastern Daylight Time (-04). As a workaround, a writer can substitute standard time for two time zones east, e.g., “XXX3EDT4,0/0,J365/23” for a time zone with a never-used standard time (XXX, -03) and negative daylight saving time (EDT, -04) all year. Alternatively, as a partial workaround a writer can substitute standard time for the next time zone east – e.g., “AST4” for permanent Atlantic Standard Time (-04).
Some readers designed for version 2 or 3, and that require strict conformance to RFC 8536, reject version 4 files whose leap second tables are truncated at the start or that end in expiration times.
Some readers ignore the footer, and instead predict future timestamps from the time type of the last transition. As a partial workaround, a writer can output more transitions than necessary.
Some readers do not use time type 0 for timestamps before the first transition, in that they infer a time type using a heuristic that does not always select time type 0. As a partial workaround, a writer can output a dummy (no-op) first transition at an early time.
Some readers mishandle timestamps before the first transition that has a timestamp not less than -2**31. Readers that support only 32-bit timestamps are likely to be more prone to this problem, for example, when they process 64-bit transitions only some of which are representable in 32 bits. As a partial workaround, a writer can output a dummy transition at timestamp -2**31.
Some readers mishandle a transition if its timestamp has the minimum possible signed 64-bit value. Timestamps less than -2**59 are not recommended.
Some readers mishandle TZ strings that contain “<” or “>”. As a partial workaround, a writer can avoid using “<” or “>” for time zone abbreviations containing only alphabetic characters.
Many readers mishandle time zone abbreviations that contain non-ASCII characters. These characters are not recommended.
Some readers may mishandle time zone abbreviations that contain fewer than 3 or more than 6 characters, or that contain ASCII characters other than alphanumerics, “”, and “+”. These abbreviations are not recommended.
Some readers mishandle TZif files that specify daylight-saving time UT offsets that are less than the UT offsets for the corresponding standard time. These readers do not support locations like Ireland, which uses the equivalent of the TZ string “IST1GMT0,M10.5.0,M3.5.0/1”, observing standard time (IST, +01) in summer and daylight saving time (GMT, +00) in winter. As a partial workaround, a writer can output data for the equivalent of the TZ string “GMT0IST,M3.5.0/1,M10.5.0”, thus swapping standard and daylight saving time. Although this workaround misidentifies which part of the year uses daylight saving time, it records UT offsets and time zone abbreviations correctly.
Some readers generate ambiguous timestamps for positive leap seconds that occur when the UTC offset is not a multiple of 60 seconds. For example, in a timezone with UTC offset +01:23:45 and with a positive leap second 78796801 (1972-06-30 23:59:60 UTC), some readers will map both 78796800 and 78796801 to 01:23:45 local time the next day instead of mapping the latter to 01:23:46, and they will map 78796815 to 01:23:59 instead of to 01:23:60. This has not yet been a practical problem, since no civil authority has observed such UTC offsets since leap seconds were introduced in 1972.

Some interoperability problems are reader bugs that are listed here mostly as warnings to developers of readers.

Some readers do not support negative timestamps. Developers of distributed applications should keep this in mind if they need to deal with pre-1970 data.
Some readers mishandle timestamps before the first transition that has a nonnegative timestamp. Readers that do not support negative timestamps are likely to be more prone to this problem.
Some readers mishandle time zone abbreviations like “08” that contain “+”, “”, or digits.
Some readers mishandle UT offsets that are out of the traditional range of -12 through +12 hours, and so do not support locations like Kiritimati that are outside this range.
Some readers mishandle UT offsets in the range [-3599, -1] seconds from UT, because they integer-divide the offset by 3600 to get 0 and then display the hour part as “+00”.
Some readers mishandle UT offsets that are not a multiple of one hour, or of 15 minutes, or of 1 minute.

84 - Linux cli command extendedopacity

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command extendedopacity and provides detailed information about the command extendedopacity, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the extendedopacity.

Created: 17 April 2003

NAME 🖥️ extendedopacity 🖥️

theory of netpbm interpolation and extrapolation

DESCRIPTION

This page is a copy of http://www.sgi.com/misc/grafica/interp/ on April 17, 2003, with some slight formatting changes, included in the Netpbm documentation for convenience. Since at least June 11, 2005, the source page has been missing.

Image Processing By Interpolation and Extrapolation

Paul Haeberli and Douglas Voorhies

Introduction

Interpolation and extrapolation between two images offers a general, unifying approach to many common point and area image processing operations. Brightness, contrast, saturation, tint, and sharpness can all be controlled with one formula, separately or simultaneously. In several cases, there are also performance benefits.

Linear interpolation is often used to blend two images. Blend fractions (alpha) and (1 - alpha) are used in a weighted average of each component of each pixel:

      out = (1 - alpha)*in0 + alpha*in1

Typically alpha is a number in the range 0.0 to 1.0. This is commonly used to linearly interpolate two images. What is less often considered is that alpha may range beyond the interval 0.0 to 1.0. Values above one subtract a portion of in0 while scaling in1. Values below 0.0 have the opposite effect.

Extrapolation is particularly useful if a degenerate version of the image is used as the image to get “away from.” Extrapolating away from a black-and-white image increases saturation. Extrapolating away from a blurred image increases sharpness. The interpolation/extrapolation formula offers one-parameter control, making display of a series of images, each differing in brightness, contrast, sharpness, color, or saturation, particularly easy to compute, and inviting hardware acceleration.

In the following examples, a single alpha value is used per image. However other processing is possible, for example where alpha is a function of X and Y, or where a brush footprint controls alpha near the cursor.

Changing Brightness

To control image brightness, we use pure black as the degenerate (zero alpha) image. Interpolation darkens the image, and extrapolation brightens it. In both cases, brighter pixels are affected more.

brightness

Changing Contrast

Contrast can be controlled using a constant gray image with the average image luminance. Interpolation reduces contrast and extrapolation boosts it. Negative alpha generates inverted images with varying contrast. In all cases, the average image luminance is constant.

contrast

If middle gray or the average pixel color is used instead, contrast is again altered, but with middle gray or the average color left unaffected. Shades and colors far away from the chosen value are most affected.

Changing Saturation

To alter saturation, pixel components must move towards or away from the pixel’s luminance value. By using a black-and-white image as the degenerate version, saturation can be decreased using interpolation, and increased using extrapolation. This avoids computationally more expensive conversions to and from HSV space. Repeated update in an interactive application is especially fast, since the luminance of each pixel need not be recomputed. Negative alpha preserves luminance but inverts the hue of the input image.

saturation

Sharpening an Image

Any convolution, such as sharpening or blurring, can be adjusted by this approach. If a blurred image is used as the degenerate image, interpolation attenuates high frequencies to varying degrees, and extrapolation boosts them, sharpening the image by unsharp masking. Varying alpha acts as a kernel scale factor, so a series of convolutions differing only in scale can be done easily, independent of the size of the kernel. Since blurring, unlike sharpening, is often a separable operation, sharpening by extrapolation may be far more efficient for large kernels.

sharpening

Note that global contrast control, local contrast control, and sharpening form a continuum. Global contrast pushes pixel components towards or away from the average image luminance. Local contrast is similar, but uses local area luminance. Unsharp masking is the extreme case, using only the color of nearby pixels.

Combined Processing

An unusual property of this interpolation/extrapolation approach is that all of these image parameters may be altered simultaneously. Here sharpness, tint, and saturation are all altered.

combined

Conclusion

Image applications frequently need to produce multiple degrees of manipulation interactively. Image applications frequently need to interactively manipulate an image by continuously changing a single parameter. The best hardware mechanisms employ a single “inner loop” to achieve a wide variety of effects. Interpolation and extrapolation of images can be a unifying approach, providing a single function that can do many common image processing operations.

Since a degenerate image is sometimes easier to calculate, extrapolation may offer a more efficient method to achieve effects such as sharpening or saturation. Blending is a linear operation, and so it must be performed in linear, not gamma-warped space. Component range must also be monitored, since clamping, especially of the degenerate image, causes inaccuracy.

These image manipulation techniques can be used in paint programs to easily implement brushes that saturate, sharpen, lighten, darken, or modify contrast and color. The only major change needed is to work with alpha values outside the range 0.0 to 1.0.

It is surprising and unfortunate how many graphics software packages needlessly limit interpolant values to the range 0.0 to 1.0. Application developers should allow users to extrapolate parameters when practical.

References

For a slightly extended version of this article, see: P. Haeberli and D. Voorhies. Image Processing by Linear Interpolation and Extrapolation. IRIS Universe Magazine No. 28, Silicon Graphics, Aug, 1994.

DOCUMENT SOURCE

This manual page was generated by the Netpbm tool ‘makeman’ from HTML source. The master documentation is at

http://netpbm.sourceforge.net/doc/extendedopacity.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

85 - Linux cli command org.bluez.obex.Message

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.obex.Message and provides detailed information about the command org.bluez.obex.Message, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.obex.Message.

NAME 🖥️ org.bluez.obex.Message 🖥️

BlueZ D-Bus OBEX Message API documentation

INTERFACE

Service
org.bluez.obex
Interface
org.bluez.obex.Message1
Object path
[Session object path]/message{#}

Methods

object, dict Get(string targetfile, boolean attachment)

Download message and store it in the target file.
If an empty target file is given, a temporary file will be automatically generated.
The returned path represents the newly created transfer, which should be used to find out if the content has been successfully transferred or if the operation fails.
The properties of this transfer are also returned along with the object path, to avoid a call to GetProperties, see org.bluez.obex.Transfer(5) for the possible list of properties.
Possible errors:
org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Error.Failed

Properties

string Folder [readonly]

Folder which the message belongs to

string Subject [readonly]

Message subject

string Timestamp [readonly]

Message timestamp

string Sender [readonly]

Message sender name

string SenderAddress [readonly]

Message sender address

string ReplyTo [readonly]

Message Reply-To address

string Recipient [readonly]

Message recipient name

string RecipientAddress [readonly]

Message recipient address

string Type [readonly]

Message type
Possible values:
“email”
“sms-gsm”
“sms-cdma”
“mms”

uint64 Size [readonly]

Message size in bytes

string Status [readonly]

Message reception status
Possible values:
“complete”
“fractioned”
“notification”

boolean Priority [readonly]

Message priority flag

boolean Read [read/write]

Message read flag

boolean Deleted [writeonly]

Message deleted flag

boolean Sent [readonly]

Message sent flag

boolean Protected [readonly]

Message protected flag

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

86 - Linux cli command fips_configssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command fips_configssl and provides detailed information about the command fips_configssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the fips_configssl.

NAME 🖥️ fips_configssl 🖥️

OpenSSL FIPS configuration

DESCRIPTION

A separate configuration file, using the OpenSSL config (5) syntax, is used to hold information about the FIPS module. This includes a digest of the shared library file, and status about the self-testing. This data is used automatically by the module itself for two purposes:

- Run the startup FIPS self-test known answer tests (KATS).
This is normally done once, at installation time, but may also be set up to run each time the module is used.

- Verify the module’s checksum.
This is done each time the module is used.

This file is generated by the openssl-fipsinstall (1) program, and used internally by the FIPS module during its initialization.

The following options are supported. They should all appear in a section whose name is identified by the fips option in the providers section, as described in “Provider Configuration Module” in config (5).

activate
If present, the module is activated. The value assigned to this name is not significant.

install-version
A version number for the fips install process. Should be 1.

conditional-errors
The FIPS module normally enters an internal error mode if any self test fails. Once this error mode is active, no services or cryptographic algorithms are accessible from this point on. Continuous tests are a subset of the self tests (e.g., a key pair test during key generation, or the CRNG output test). Setting this value to 0 allows the error mode to not be triggered if any continuous test fails. The default value of 1 will trigger the error mode. Regardless of the value, the operation (e.g., key generation) that called the continuous test will return an error code if its continuous test fails. The operation may then be retried if the error mode has not been triggered.

security-checks
This indicates if run-time checks related to enforcement of security parameters such as minimum security strength of keys and approved curve names are used. A value of ‘1’ will perform the checks, otherwise if the value is ‘0’ the checks are not performed and FIPS compliance must be done by procedures documented in the relevant Security Policy.

module-mac
The calculated MAC of the FIPS provider file.

install-status
An indicator that the self-tests were successfully run. This should only be written after the module has successfully passed its self tests during installation. If this field is not present, then the self tests will run when the module loads.

install-mac
A MAC of the value of the install-status option, to prevent accidental changes to that value. It is written-to at the same time as install-status is updated.

For example:

[fips_sect] activate = 1 install-version = 1 conditional-errors = 1 security-checks = 1 module-mac = 41:D0:FA:C2:5D:41:75:CD:7D:C3:90:55:6F:A4:DC install-mac = FE:10:13:5A:D3:B4:C7:82:1B:1E:17:4C:AC:84:0C install-status = INSTALL_SELF_TEST_KATS_RUN

NOTES

When using the FIPS provider, it is recommended that the config_diagnostics option is enabled to prevent accidental use of non-FIPS validated algorithms via broken or mistaken configuration. See config (5).

HISTORY

This functionality was added in OpenSSL 3.0.

COPYRIGHT

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

87 - Linux cli command proc_dma

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_dma and provides detailed information about the command proc_dma, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_dma.

NAME 🖥️ proc_dma 🖥️

ISA DMA channels

DESCRIPTION

/proc/dma
This is a list of the registered ISA DMA (direct memory access) channels in use.

88 - Linux cli command sshd_config

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command sshd_config and provides detailed information about the command sshd_config, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the sshd_config.

reads configuration data from

(or the file specified with

on the command line). The file contains keyword-argument pairs, one per line. Unless noted otherwise, for each keyword, the first obtained value will be used. Lines starting with

and empty lines are interpreted as comments. Arguments may optionally be enclosed in double quotes

in order to represent arguments containing spaces.

Note that the Debian

package sets several options as standard in

which are not the default in

files are included at the start of the configuration file, so options set there will override those in

The possible keywords and their meanings are as follows (note that keywords are case-insensitive and arguments are case-sensitive):

Specifies what environment variables sent by the client will be copied into the session’s

See

and

for how to configure the client. The

environment variable is always accepted whenever the client requests a pseudo-terminal as it is required by the protocol. Variables are specified by name, which may contain the wildcard characters

and

Multiple environment variables may be separated by whitespace or spread across multiple

directives. Be warned that some environment variables could be used to bypass restricted user environments. For this reason, care should be taken in the use of this directive. The default is not to accept any environment variables.

Specifies which address family should be used by

Valid arguments are

(the default),

(use IPv4 only), or

(use IPv6 only).

Specifies whether

forwarding is permitted. The default is

Note that disabling agent forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders.

This keyword can be followed by a list of group name patterns, separated by spaces. If specified, login is allowed only for users whose primary group or supplementary group list matches one of the patterns. Only group names are valid; a numerical group ID is not recognized. By default, login is allowed for all groups. The allow/deny groups directives are processed in the following order:

See PATTERNS in

for more information on patterns. This keyword may appear multiple times in

with each instance appending to the list.

Specifies whether StreamLocal (Unix-domain socket) forwarding is permitted. The available options are

(the default) or

to allow StreamLocal forwarding,

to prevent all StreamLocal forwarding,

to allow local (from the perspective of

forwarding only or

to allow remote forwarding only. Note that disabling StreamLocal forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders.

Specifies whether TCP forwarding is permitted. The available options are

(the default) or

to allow TCP forwarding,

to prevent all TCP forwarding,

to allow local (from the perspective of

forwarding only or

to allow remote forwarding only. Note that disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders.

This keyword can be followed by a list of user name patterns, separated by spaces. If specified, login is allowed only for user names that match one of the patterns. Only user names are valid; a numerical user ID is not recognized. By default, login is allowed for all users. If the pattern takes the form USER@HOST then USER and HOST are separately checked, restricting logins to particular users from particular hosts. HOST criteria may additionally contain addresses to match in CIDR address/masklen format. The allow/deny users directives are processed in the following order:

See PATTERNS in

for more information on patterns. This keyword may appear multiple times in

with each instance appending to the list.

Specifies the authentication methods that must be successfully completed for a user to be granted access. This option must be followed by one or more lists of comma-separated authentication method names, or by the single string

to indicate the default behaviour of accepting any single authentication method. If the default is overridden, then successful authentication requires completion of every method in at least one of these lists.

For example,

would require the user to complete public key authentication, followed by either password or keyboard interactive authentication. Only methods that are next in one or more lists are offered at each stage, so for this example it would not be possible to attempt password or keyboard-interactive authentication before public key.

For keyboard interactive authentication it is also possible to restrict authentication to a specific device by appending a colon followed by the device identifier

depending on the server configuration. For example,

would restrict keyboard interactive authentication to the

device.

If the publickey method is listed more than once,

verifies that keys that have been used successfully are not reused for subsequent authentications. For example,

requires successful authentication using two different public keys.

Note that each authentication method listed should also be explicitly enabled in the configuration.

The available authentication methods are:

(used for access to password-less accounts when

is enabled),

and

Specifies a program to be used to look up the user’s public keys. The program must be owned by root, not writable by group or others and specified by an absolute path. Arguments to

accept the tokens described in the

section. If no arguments are specified then the username of the target user is used.

The program should produce on standard output zero or more lines of authorized_keys output (see

is tried after the usual

files and will not be executed if a matching key is found there. By default, no

is run.

Specifies the user under whose account the

is run. It is recommended to use a dedicated user that has no other role on the host than running authorized keys commands. If

is specified but

is not, then

will refuse to start.

Specifies the file that contains the public keys used for user authentication. The format is described in the AUTHORIZED_KEYS FILE FORMAT section of

Arguments to

accept the tokens described in the

section. After expansion,

is taken to be an absolute path or one relative to the user’s home directory. Multiple files may be listed, separated by whitespace. Alternately this option may be set to

to skip checking for user keys in files. The default is

Specifies a program to be used to generate the list of allowed certificate principals as per

The program must be owned by root, not writable by group or others and specified by an absolute path. Arguments to

accept the tokens described in the

section. If no arguments are specified then the username of the target user is used.

The program should produce on standard output zero or more lines of

output. If either

is specified, then certificates offered by the client for authentication must contain a principal that is listed. By default, no

is run.

Specifies the user under whose account the

is run. It is recommended to use a dedicated user that has no other role on the host than running authorized principals commands. If

is specified but

is not, then

will refuse to start.

Specifies a file that lists principal names that are accepted for certificate authentication. When using certificates signed by a key listed in

this file lists names, one of which must appear in the certificate for it to be accepted for authentication. Names are listed one per line preceded by key options (as described in

Empty lines and comments starting with

are ignored.

Arguments to

accept the tokens described in the

section. After expansion,

is taken to be an absolute path or one relative to the user’s home directory. The default is

i.e. not to use a principals file – in this case, the username of the user must appear in a certificate’s principals list for it to be accepted.

Note that

is only used when authentication proceeds using a CA listed in

and is not consulted for certification authorities trusted via

though the

key option offers a similar facility (see

for details).

The contents of the specified file are sent to the remote user before authentication is allowed. If the argument is

then no banner is displayed. By default, no banner is displayed.

Specifies which algorithms are allowed for signing of certificates by certificate authorities (CAs). The default is:

ssh-ed25519,ecdsa-sha2-nistp256, ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, [email protected], [email protected], rsa-sha2-512,rsa-sha2-256

If the specified list begins with a

character, then the specified algorithms will be appended to the default set instead of replacing them. If the specified list begins with a

character, then the specified algorithms (including wildcards) will be removed from the default set instead of replacing them.

Certificates signed using other algorithms will not be accepted for public key or host-based authentication.

Specifies whether and how quickly

should close inactive channels. Timeouts are specified as one or more

pairs separated by whitespace, where the

must be the special keyword

or a channel type name from the list below, optionally containing wildcard characters.

The timeout value

is specified in seconds or may use any of the units documented in the

section. For example,

would cause interactive sessions to terminate after five minutes of inactivity. Specifying a zero value disables the inactivity timeout.

The special timeout

applies to all active channels, taken together. Traffic on any active channel will reset the timeout, but when the timeout expires then all open channels will be closed. Note that this global timeout is not matched by wildcards and must be specified explicitly.

The available channel type names include:

Open connections to

Open TCP or Unix socket (respectively) connections that have been established from a

local forwarding, i.e.

Open TCP or Unix socket (respectively) connections that have been established to a

listening on behalf of a

remote forwarding, i.e.

The interactive main session, including shell session, command execution,

etc.

Open

connections.

Open X11 forwarding sessions.

Note that in all the above cases, terminating an inactive session does not guarantee to remove all resources associated with the session, e.g. shell processes or X11 clients relating to the session may continue to execute.

Moreover, terminating an inactive channel or session does not necessarily close the SSH connection, nor does it prevent a client from requesting another channel of the same type. In particular, expiring an inactive forwarding session does not prevent another identical forwarding from being subsequently created.

The default is not to expire channels of any type for inactivity.

Specifies the pathname of a directory to

to after authentication. At session startup

checks that all components of the pathname are root-owned directories which are not writable by group or others. After the chroot,

changes the working directory to the user’s home directory. Arguments to

accept the tokens described in the

section.

The

must contain the necessary files and directories to support the user’s session. For an interactive session this requires at least a shell, typically

and basic

nodes such as

and

devices. For file transfer sessions using SFTP no additional configuration of the environment is necessary if the in-process sftp-server is used, though sessions which use logging may require

inside the chroot directory on some operating systems (see

for details).

For safety, it is very important that the directory hierarchy be prevented from modification by other processes on the system (especially those outside the jail). Misconfiguration can lead to unsafe environments which

cannot detect.

The default is

indicating not to

Specifies the ciphers allowed. Multiple ciphers must be comma-separated. If the specified list begins with a

character, then the specified ciphers will be appended to the default set instead of replacing them. If the specified list begins with a

character, then the specified ciphers (including wildcards) will be removed from the default set instead of replacing them. If the specified list begins with a

character, then the specified ciphers will be placed at the head of the default set.

The supported ciphers are:

3des-cbc

aes128-cbc

aes192-cbc

aes256-cbc

aes128-ctr

aes192-ctr

aes256-ctr

[email protected]

The default is:

[email protected], aes128-ctr,aes192-ctr,aes256-ctr, [email protected],[email protected]

The list of available ciphers may also be obtained using

Sets the number of client alive messages which may be sent without

receiving any messages back from the client. If this threshold is reached while client alive messages are being sent, sshd will disconnect the client, terminating the session. It is important to note that the use of client alive messages is very different from

The client alive messages are sent through the encrypted channel and therefore will not be spoofable. The TCP keepalive option enabled by

is spoofable. The client alive mechanism is valuable when the client or server depend on knowing when a connection has become unresponsive.

The default value is 3. If

is set to 15, and

is left at the default, unresponsive SSH clients will be disconnected after approximately 45 seconds. Setting a zero

disables connection termination.

Sets a timeout interval in seconds after which if no data has been received from the client,

will send a message through the encrypted channel to request a response from the client. The default is 0, indicating that these messages will not be sent to the client.

Specifies whether compression is enabled after the user has authenticated successfully. The argument must be

(a legacy synonym for

The default is

Specifies whether the distribution-specified extra version suffix is included during initial protocol handshake. The default is

This keyword can be followed by a list of group name patterns, separated by spaces. Login is disallowed for users whose primary group or supplementary group list matches one of the patterns. Only group names are valid; a numerical group ID is not recognized. By default, login is allowed for all groups. The allow/deny groups directives are processed in the following order:

See PATTERNS in

for more information on patterns. This keyword may appear multiple times in

with each instance appending to the list.

This keyword can be followed by a list of user name patterns, separated by spaces. Login is disallowed for user names that match one of the patterns. Only user names are valid; a numerical user ID is not recognized. By default, login is allowed for all users. If the pattern takes the form USER@HOST then USER and HOST are separately checked, restricting logins to particular users from particular hosts. HOST criteria may additionally contain addresses to match in CIDR address/masklen format. The allow/deny users directives are processed in the following order:

See PATTERNS in

for more information on patterns. This keyword may appear multiple times in

with each instance appending to the list.

Disables all forwarding features, including X11,

TCP and StreamLocal. This option overrides all other forwarding-related options and may simplify restricted configurations.

Writes a temporary file containing a list of authentication methods and public credentials (e.g. keys) used to authenticate the user. The location of the file is exposed to the user session through the

environment variable. The default is

Specifies the hash algorithm used when logging key fingerprints. Valid options are:

and

The default is

Forces the execution of the command specified by

ignoring any command supplied by the client and

if present. The command is invoked by using the user’s login shell with the -c option. This applies to shell, command, or subsystem execution. It is most useful inside a

block. The command originally supplied by the client is available in the

environment variable. Specifying a command of

will force the use of an in-process SFTP server that requires no support files when used with

The default is

Specifies whether remote hosts are allowed to connect to ports forwarded for the client. By default,

binds remote port forwardings to the loopback address. This prevents other remote hosts from connecting to forwarded ports.

can be used to specify that sshd should allow remote port forwardings to bind to non-loopback addresses, thus allowing other hosts to connect. The argument may be

to force remote port forwardings to be available to the local host only,

to force remote port forwardings to bind to the wildcard address, or

to allow the client to select the address to which the forwarding is bound. The default is

Specifies whether user authentication based on GSSAPI is allowed. The default is

Specifies whether to automatically destroy the user’s credentials cache on logout. The default is

Specifies whether key exchange based on GSSAPI is allowed. GSSAPI key exchange doesn’t rely on ssh keys to verify host identity. The default is

Determines whether to be strict about the identity of the GSSAPI acceptor a client authenticates against. If set to

then the client must authenticate against the host service on the current hostname. If set to

then the client may authenticate against any service key stored in the machine’s default store. This facility is provided to assist with operation on multi homed machines. The default is

Controls whether the user’s GSSAPI credentials should be updated following a successful connection rekeying. This option can be used to accepted renewed or updated credentials from a compatible client. The default is

For this to work

needs to be enabled in the server and also used by the client.

The list of key exchange algorithms that are accepted by GSSAPI key exchange. Possible values are

gss-gex-sha1-, gss-group1-sha1-, gss-group14-sha1-, gss-group14-sha256-, gss-group16-sha512-, gss-nistp256-sha256-, gss-curve25519-sha256-

The default is

This option only applies to connections using GSSAPI.

Specifies the signature algorithms that will be accepted for hostbased authentication as a list of comma-separated patterns. Alternately if the specified list begins with a

character, then the specified signature algorithms will be appended to the default set instead of replacing them. If the specified list begins with a

character, then the specified signature algorithms (including wildcards) will be removed from the default set instead of replacing them. If the specified list begins with a

character, then the specified signature algorithms will be placed at the head of the default set. The default for this option is:

[email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], ssh-ed25519, ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, [email protected], [email protected], rsa-sha2-512,rsa-sha2-256

The list of available signature algorithms may also be obtained using

This was formerly named HostbasedAcceptedKeyTypes.

Specifies whether rhosts or /etc/hosts.equiv authentication together with successful public key client host authentication is allowed (host-based authentication). The default is

Specifies whether or not the server will attempt to perform a reverse name lookup when matching the name in the

and

files during

A setting of

means that

uses the name supplied by the client rather than attempting to resolve the name from the TCP connection itself. The default is

Specifies a file containing a public host certificate. The certificate’s public key must match a private host key already specified by

The default behaviour of

is not to load any certificates.

Specifies a file containing a private host key used by SSH. The defaults are

and

Note that

will refuse to use a file if it is group/world-accessible and that the

option restricts which of the keys are actually used by

It is possible to have multiple host key files. It is also possible to specify public host key files instead. In this case operations on the private key will be delegated to an

Identifies the UNIX-domain socket used to communicate with an agent that has access to the private host keys. If the string

is specified, the location of the socket will be read from the

environment variable.

Specifies the host key signature algorithms that the server offers. The default for this option is:

The list of available signature algorithms may also be obtained using

Specifies whether to ignore per-user

and

files during

The system-wide

and

are still used regardless of this setting.

Accepted values are

(the default) to ignore all per-user files,

to allow the use of

but to ignore

to allow both

and

Specifies whether

should ignore the user’s

during

and use only the system-wide known hosts file

The default is

Include the specified configuration file(s). Multiple pathnames may be specified and each pathname may contain

wildcards that will be expanded and processed in lexical order. Files without absolute paths are assumed to be in

directive may appear inside a

block to perform conditional inclusion.

Specifies the IPv4 type-of-service or DSCP class for the connection. Accepted values are

a numeric value, or

to use the operating system default. This option may take one or two arguments, separated by whitespace. If one argument is specified, it is used as the packet class unconditionally. If two values are specified, the first is automatically selected for interactive sessions and the second for non-interactive sessions. The default is

for interactive sessions and

for non-interactive sessions.

Specifies whether to allow keyboard-interactive authentication. The default is

The argument to this keyword must be

is a deprecated alias for this.

Specifies whether the password provided by the user for

will be validated through the Kerberos KDC. To use this option, the server needs a Kerberos servtab which allows the verification of the KDC’s identity. The default is

If AFS is active and the user has a Kerberos 5 TGT, attempt to acquire an AFS token before accessing the user’s home directory. The default is

If password authentication through Kerberos fails then the password will be validated via any additional local mechanism such as

The default is

Specifies whether to automatically destroy the user’s ticket cache file on logout. The default is

Specifies the available KEX (Key Exchange) algorithms. Multiple algorithms must be comma-separated. Alternately if the specified list begins with a

character, then the specified algorithms will be appended to the default set instead of replacing them. If the specified list begins with a

character, then the specified algorithms (including wildcards) will be removed from the default set instead of replacing them. If the specified list begins with a

character, then the specified algorithms will be placed at the head of the default set. The supported algorithms are:

curve25519-sha256

[email protected]

diffie-hellman-group1-sha1

diffie-hellman-group14-sha1

diffie-hellman-group14-sha256

diffie-hellman-group16-sha512

diffie-hellman-group18-sha512

diffie-hellman-group-exchange-sha1

diffie-hellman-group-exchange-sha256

ecdh-sha2-nistp256

ecdh-sha2-nistp384

ecdh-sha2-nistp521

[email protected]

The default is:

[email protected], curve25519-sha256,[email protected], ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521, diffie-hellman-group-exchange-sha256, diffie-hellman-group16-sha512,diffie-hellman-group18-sha512, diffie-hellman-group14-sha256

The list of available key exchange algorithms may also be obtained using

Specifies the local addresses

should listen on. The following forms may be used:

is not specified, sshd will listen on the address and all

options specified. The default is to listen on all local addresses. Multiple

options are permitted.

The server disconnects after this time if the user has not successfully logged in. If the value is 0, there is no time limit. The default is 120 seconds.

Gives the verbosity level that is used when logging messages from

The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. The default is INFO. DEBUG and DEBUG1 are equivalent. DEBUG2 and DEBUG3 each specify higher levels of debugging output. Logging with a DEBUG level violates the privacy of users and is not recommended.

Specify one or more overrides to

An override consists of a pattern lists that matches the source file, function and line number to force detailed logging for. For example, an override pattern of:

kex.c:*:1000,*:kex_exchange_identification():*,packet.c:*

would enable detailed logging for line 1000 of

everything in the

function, and all code in the

file. This option is intended for debugging and no overrides are enabled by default.

Specifies the available MAC (message authentication code) algorithms. The MAC algorithm is used for data integrity protection. Multiple algorithms must be comma-separated. If the specified list begins with a

character, then the specified algorithms will be appended to the default set instead of replacing them. If the specified list begins with a

character, then the specified algorithms (including wildcards) will be removed from the default set instead of replacing them. If the specified list begins with a

character, then the specified algorithms will be placed at the head of the default set.

The algorithms that contain

calculate the MAC after encryption (encrypt-then-mac). These are considered safer and their use recommended. The supported MACs are:

hmac-md5

hmac-md5-96

hmac-sha1

hmac-sha1-96

hmac-sha2-256

hmac-sha2-512

[email protected]

The default is:

[email protected],[email protected], [email protected],[email protected], [email protected], [email protected],[email protected], hmac-sha2-256,hmac-sha2-512,hmac-sha1

The list of available MAC algorithms may also be obtained using

Introduces a conditional block. If all of the criteria on the

line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another

line or the end of the file. If a keyword appears in multiple

blocks that are satisfied, only the first instance of the keyword is applied.

The arguments to

are one or more criteria-pattern pairs or the single token

which matches all criteria. The available criteria are

and

The match patterns may consist of single entries or comma-separated lists and may use the wildcard and negation operators described in the

section of

The patterns in an

criteria may additionally contain addresses to match in CIDR address/masklen format, such as 192.0.2.0/24 or 2001:db8::/32. Note that the mask length provided must be consistent with the address - it is an error to specify a mask length that is too long for the address or one with bits set in this host portion of the address. For example, 192.0.2.0/33 and 192.0.2.0/8, respectively.

Only a subset of keywords may be used on the lines following a

keyword. Available keywords are

and

Specifies the maximum number of authentication attempts permitted per connection. Once the number of failures reaches half this value, additional failures are logged. The default is 6.

Specifies the maximum number of open shell, login or subsystem (e.g. sftp) sessions permitted per network connection. Multiple sessions may be established by clients that support connection multiplexing. Setting

to 1 will effectively disable session multiplexing, whereas setting it to 0 will prevent all shell, login and subsystem sessions while still permitting forwarding. The default is 10.

Specifies the maximum number of concurrent unauthenticated connections to the SSH daemon. Additional connections will be dropped until authentication succeeds or the

expires for a connection. The default is 10:30:100.

Alternatively, random early drop can be enabled by specifying the three colon separated values start:rate:full (e.g. “10:30:60”).

will refuse connection attempts with a probability of rate/100 (30%) if there are currently start (10) unauthenticated connections. The probability increases linearly and all connection attempts are refused if the number of unauthenticated connections reaches full (60).

Specifies the

file that contains the Diffie-Hellman groups used for the

and

key exchange methods. The default is

Specifies whether password authentication is allowed. The default is

When password authentication is allowed, it specifies whether the server allows login to accounts with empty password strings. The default is

Specifies the addresses/ports on which a remote TCP port forwarding may listen. The listen specification must be one of the following forms:

Multiple permissions may be specified by separating them with whitespace. An argument of

can be used to remove all restrictions and permit any listen requests. An argument of

can be used to prohibit all listen requests. The host name may contain wildcards as described in the PATTERNS section in

The wildcard

can also be used in place of a port number to allow all ports. By default all port forwarding listen requests are permitted. Note that the

option may further restrict which addresses may be listened on. Note also that

will request a listen host of

if no listen host was specifically requested, and this name is treated differently to explicit localhost addresses of

and

Specifies the destinations to which TCP port forwarding is permitted. The forwarding specification must be one of the following forms:

Multiple forwards may be specified by separating them with whitespace. An argument of

can be used to remove all restrictions and permit any forwarding requests. An argument of

can be used to prohibit all forwarding requests. The wildcard

can be used for host or port to allow all hosts or ports respectively. Otherwise, no pattern matching or address lookups are performed on supplied names. By default all port forwarding requests are permitted.

Specifies whether root can log in using

The argument must be

The default is

If this option is set to

(or its deprecated alias,

password and keyboard-interactive authentication are disabled for root.

If this option is set to

root login with public key authentication will be allowed, but only if the

option has been specified (which may be useful for taking remote backups even if root login is normally not allowed). All other authentication methods are disabled for root.

If this option is set to

root is not allowed to log in.

Specifies whether

allocation is permitted. The default is

Specifies whether

device forwarding is allowed. The argument must be

(layer 3),

(layer 2), or

Specifying

permits both

and

The default is

Independent of this setting, the permissions of the selected

device must allow access to the user.

Specifies whether

and

options in

are processed by

Valid options are

or a pattern-list specifying which environment variable names to accept (for example

The default is

Enabling environment processing may enable users to bypass access restrictions in some configurations using mechanisms such as

Specifies whether any

file is executed. The default is

Specifies the number of unauthenticated connections allowed from a given source address, or

if there is no limit. This limit is applied in addition to

whichever is lower. The default is

Specifies the number of bits of source address that are grouped together for the purposes of applying PerSourceMaxStartups limits. Values for IPv4 and optionally IPv6 may be specified, separated by a colon. The default is

which means each address is considered individually.

Specifies the file that contains the process ID of the SSH daemon, or

to not write one. The default is

Specifies the port number that

listens on. The default is 22. Multiple options of this type are permitted. See also

Specifies whether

should print the date and time of the last user login when a user logs in interactively. The default is

Specifies whether

should print

when a user logs in interactively. (On some systems it is also printed by the shell,

or equivalent.) The default is

Specifies the signature algorithms that will be accepted for public key authentication as a list of comma-separated patterns. Alternately if the specified list begins with a

character, then the specified algorithms will be appended to the default set instead of replacing them. If the specified list begins with a

character, then the specified algorithms (including wildcards) will be removed from the default set instead of replacing them. If the specified list begins with a

character, then the specified algorithms will be placed at the head of the default set. The default for this option is:

The list of available signature algorithms may also be obtained using

Sets one or more public key authentication options. The supported keywords are:

(the default; indicating no additional options are enabled),

and

The

option causes public key authentication using a FIDO authenticator algorithm (i.e.

to always require the signature to attest that a physically present user explicitly confirmed the authentication (usually by touching the authenticator). By default,

requires user presence unless overridden with an authorized_keys option. The

flag disables this override.

The

option requires a FIDO key signature attest that the user was verified, e.g. via a PIN.

Neither the

options have any effect for other, non-FIDO, public key types.

Specifies whether public key authentication is allowed. The default is

Specifies the maximum amount of data that may be transmitted or received before the session key is renegotiated, optionally followed by a maximum amount of time that may pass before the session key is renegotiated. The first argument is specified in bytes and may have a suffix of

to indicate Kilobytes, Megabytes, or Gigabytes, respectively. The default is between

and

depending on the cipher. The optional second value is specified in seconds and may use any of the units documented in the

section. The default value for

which means that rekeying is performed after the cipher’s default amount of data has been sent or received and no time based rekeying is done.

Specifies the minimum RSA key size (in bits) that

will accept. User and host-based authentication keys smaller than this limit will be refused. The default is

bits. Note that this limit may only be raised from the default.

Specifies revoked public keys file, or

to not use one. Keys listed in this file will be refused for public key authentication. Note that if this file is not readable, then public key authentication will be refused for all users. Keys may be specified as a text file, listing one public key per line, or as an OpenSSH Key Revocation List (KRL) as generated by

For more information on KRLs, see the KEY REVOCATION LISTS section in

Specifies a path to a library that will be used when loading FIDO authenticator-hosted keys, overriding the default of using the built-in USB HID support.

Specifies one or more environment variables to set in child sessions started by

The environment value may be quoted (e.g. if it contains whitespace characters). Environment variables set by

override the default environment and any variables specified by the user via

Sets the octal file creation mode mask

used when creating a Unix-domain socket file for local or remote port forwarding. This option is only used for port forwarding to a Unix-domain socket file.

The default value is 0177, which creates a Unix-domain socket file that is readable and writable only by the owner. Note that not all operating systems honor the file mode on Unix-domain socket files.

Specifies whether to remove an existing Unix-domain socket file for local or remote port forwarding before creating a new one. If the socket file already exists and

is not enabled,

will be unable to forward the port to the Unix-domain socket file. This option is only used for port forwarding to a Unix-domain socket file.

The argument must be

The default is

Specifies whether

should check file modes and ownership of the user’s files and home directory before accepting login. This is normally desirable because novices sometimes accidentally leave their directory or files world-writable. The default is

Note that this does not apply to

whose permissions and ownership are checked unconditionally.

Configures an external subsystem (e.g. file transfer daemon). Arguments should be a subsystem name and a command (with optional arguments) to execute upon subsystem request.

The command

implements the SFTP file transfer subsystem.

Alternately the name

implements an in-process SFTP server. This may simplify configurations using

to force a different filesystem root on clients. It accepts the same command line arguments as

and even though it is in-process, settings such as

do not apply to it and must be set explicitly via command line arguments.

By default no subsystems are defined.

Gives the facility code that is used when logging messages from

The possible values are: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. The default is AUTH.

Specifies whether the system should send TCP keepalive messages to the other side. If they are sent, death of the connection or crash of one of the machines will be properly noticed. However, this means that connections will die if the route is down temporarily, and some people find it annoying. On the other hand, if TCP keepalives are not sent, sessions may hang indefinitely on the server, leaving

users and consuming server resources.

The default is

(to send TCP keepalive messages), and the server will notice if the network goes down or the client host crashes. This avoids infinitely hanging sessions.

To disable TCP keepalive messages, the value should be set to

This option was formerly called

Specifies a file containing public keys of certificate authorities that are trusted to sign user certificates for authentication, or

to not use one. Keys are listed one per line; empty lines and comments starting with

are allowed. If a certificate is presented for authentication and has its signing CA key listed in this file, then it may be used for authentication for any user listed in the certificate’s principals list. Note that certificates that lack a list of principals will not be permitted for authentication using

For more details on certificates, see the CERTIFICATES section in

Specifies whether and how quickly

should close client connections with no open channels. Open channels include active shell, command execution or subsystem sessions, connected network, socket, agent or X11 forwardings. Forwarding listeners, such as those from the

flag, are not considered as open channels and do not prevent the timeout. The timeout value is specified in seconds or may use any of the units documented in the

section.

Note that this timeout starts when the client connection completes user authentication but before the client has an opportunity to open any channels. Caution should be used when using short timeout values, as they may not provide sufficient time for the client to request and open its channels before terminating the connection.

The default

is to never expire connections for having no open channels. This option may be useful in conjunction with

Specifies whether

should look up the remote host name, and to check that the resolved host name for the remote IP address maps back to the very same IP address.

If this option is set to

(the default) then only addresses and not host names may be used in

and

directives.

Enables the Pluggable Authentication Module interface. If set to

this will enable PAM authentication using

and

in addition to PAM account and session module processing for all authentication types.

Because PAM keyboard-interactive authentication usually serves an equivalent role to password authentication, you should disable either

is enabled, you will not be able to run

as a non-root user. The default is

Optionally specifies additional text to append to the SSH protocol banner sent by the server upon connection. The default is

Specifies the first display number available for

X11 forwarding. This prevents sshd from interfering with real X11 servers. The default is 10.

Specifies whether X11 forwarding is permitted. The argument must be

The default is

When X11 forwarding is enabled, there may be additional exposure to the server and to client displays if the

proxy display is configured to listen on the wildcard address (see

though this is not the default. Additionally, the authentication spoofing and authentication data verification and substitution occur on the client side. The security risk of using X11 forwarding is that the client’s X11 display server may be exposed to attack when the SSH client requests forwarding (see the warnings for

A system administrator may have a stance in which they want to protect clients that may expose themselves to attack by unwittingly requesting X11 forwarding, which can warrant a

setting.

Note that disabling X11 forwarding does not prevent users from forwarding X11 traffic, as users can always install their own forwarders.

Specifies whether

should bind the X11 forwarding server to the loopback address or to the wildcard address. By default, sshd binds the forwarding server to the loopback address and sets the hostname part of the

environment variable to

This prevents remote hosts from connecting to the proxy display. However, some older X11 clients may not function with this configuration.

may be set to

to specify that the forwarding server should be bound to the wildcard address. The argument must be

The default is

Specifies the full pathname of the

program, or

to not use one. The default is

command-line arguments and configuration file options that specify time may be expressed using a sequence of the form:

where

is a positive integer value and

is one of the following:

seconds

minutes

hours

days

weeks

Each member of the sequence is added together to calculate the total time value.

Time format examples:

600 seconds (10 minutes)

10 minutes

1 hour 30 minutes (90 minutes)

Arguments to some keywords can make use of tokens, which are expanded at runtime:

A literal

Identifies the connection endpoints, containing four space-separated values: client address, client port number, server address, and server port number.

The fingerprint of the CA key.

The fingerprint of the key or certificate.

The home directory of the user.

The key ID in the certificate.

The base64-encoded CA key.

The base64-encoded key or certificate for authentication.

The serial number of the certificate.

The type of the CA key.

The key or certificate type.

The numeric user ID of the target user.

The username.

accepts the tokens %%, %C, %D, %f, %h, %k, %t, %U, and %u.

accepts the tokens %%, %h, %U, and %u.

accepts the tokens %%, %C, %D, %F, %f, %h, %i, %K, %k, %s, %T, %t, %U, and %u.

accepts the tokens %%, %h, %U, and %u.

Contains configuration data for

This file should be writable by root only, but it is recommended (though not necessary) that it be world-readable.

OpenSSH is a derivative of the original and free ssh 1.2.12 release by

and

removed many bugs, re-added newer features and created OpenSSH.

contributed the support for SSH protocol versions 1.5 and 2.0.

and

contributed support for privilege separation.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

89 - Linux cli command adjtime_config

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command adjtime_config and provides detailed information about the command adjtime_config, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the adjtime_config.

NAME 🖥️ adjtime_config 🖥️

information about hardware clock setting and drift factor

SYNOPSIS

/etc/adjtime

DESCRIPTION

The file /etc/adjtime contains descriptive information about the hardware mode clock setting and clock drift factor. The file is read and write by hwclock(8); and read by programs like rtcwake to get RTC time mode.

The file is usually located in /etc, but tools like hwclock(8) or rtcwake(8) can use alternative location by command line options if write access to /etc is unwanted. The default clock mode is “UTC” if the file is missing.

The Hardware Clock is usually not very accurate. However, much of its inaccuracy is completely predictable - it gains or loses the same amount of time every day. This is called systematic drift. The util hwclock(8) keeps the file /etc/adjtime, that keeps some historical information. For more details see “The Adjust Function” and “The Adjtime File” sections from hwclock(8) man page.

The adjtime file is formatted in ASCII.

First line

Three numbers, separated by blanks:

drift factor

the systematic drift rate in seconds per day (floating point decimal)

last adjust time

the resulting number of seconds since 1969 UTC of most recent adjustment or calibration (decimal integer)

adjustment status

zero (for compatibility with clock(8)) as a floating point decimal

Second line

last calibration time

The resulting number of seconds since 1969 UTC of most recent calibration. Zero if there has been no calibration yet or it is known that any previous calibration is moot (for example, because the Hardware Clock has been found, since that calibration, not to contain a valid time). This is a decimal integer.

Third line

clock mode

Supported values are UTC or LOCAL. Tells whether the Hardware Clock is set to Coordinated Universal Time or local time. You can always override this value with options on the hwclock(8) command line.

FILES

/etc/adjtime

REPORTING BUGS

For bug reports, use the issue tracker at <https://github.com/util-linux/util-linux/issues>.

AVAILABILITY

adjtime_config is part of the util-linux package which can be downloaded from Linux Kernel Archive <https://www.kernel.org/pub/linux/utils/util-linux/>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

90 - Linux cli command sysfs

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command sysfs and provides detailed information about the command sysfs, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the sysfs.

NAME 🖥️ sysfs 🖥️

a filesystem for exporting kernel objects

DESCRIPTION

The sysfs filesystem is a pseudo-filesystem which provides an interface to kernel data structures. (More precisely, the files and directories in sysfs provide a view of the kobject structures defined internally within the kernel.) The files under sysfs provide information about devices, kernel modules, filesystems, and other kernel components.

The sysfs filesystem is commonly mounted at /sys. Typically, it is mounted automatically by the system, but it can also be mounted manually using a command such as:

mount -t sysfs sysfs /sys

Many of the files in the sysfs filesystem are read-only, but some files are writable, allowing kernel variables to be changed. To avoid redundancy, symbolic links are heavily used to connect entries across the filesystem tree.

Files and directories

The following list describes some of the files and directories under the /sys hierarchy.

/sys/block
This subdirectory contains one symbolic link for each block device that has been discovered on the system. The symbolic links point to corresponding directories under /sys/devices.

/sys/bus
This directory contains one subdirectory for each of the bus types in the kernel. Inside each of these directories are two subdirectories:

devices
This subdirectory contains symbolic links to entries in /sys/devices that correspond to the devices discovered on this bus.

drivers
This subdirectory contains one subdirectory for each device driver that is loaded on this bus.

/sys/class
This subdirectory contains a single layer of further subdirectories for each of the device classes that have been registered on the system (e.g., terminals, network devices, block devices, graphics devices, sound devices, and so on). Inside each of these subdirectories are symbolic links for each of the devices in this class. These symbolic links refer to entries in the /sys/devices directory.

/sys/class/net
Each of the entries in this directory is a symbolic link representing one of the real or virtual networking devices that are visible in the network namespace of the process that is accessing the directory. Each of these symbolic links refers to entries in the /sys/devices directory.

/sys/dev
This directory contains two subdirectories block/ and char/, corresponding, respectively, to the block and character devices on the system. Inside each of these subdirectories are symbolic links with names of the form major-ID:minor-ID, where the ID values correspond to the major and minor ID of a specific device. Each symbolic link points to the sysfs directory for a device. The symbolic links inside /sys/dev thus provide an easy way to look up the sysfs interface using the device IDs returned by a call to stat(2) (or similar).

The following shell session shows an example from /sys/dev:

$ stat -c "%t %T" /dev/null
1 3
$ readlink /sys/dev/char/1\:3
../../devices/virtual/mem/null
$ ls -Fd /sys/devices/virtual/mem/null
/sys/devices/virtual/mem/null/
$ ls -d1 /sys/devices/virtual/mem/null/*
/sys/devices/virtual/mem/null/dev
/sys/devices/virtual/mem/null/power/
/sys/devices/virtual/mem/null/subsystem@
/sys/devices/virtual/mem/null/uevent

/sys/devices
This is a directory that contains a filesystem representation of the kernel device tree, which is a hierarchy of device structures within the kernel.

/sys/firmware
This subdirectory contains interfaces for viewing and manipulating firmware-specific objects and attributes.

/sys/fs
This directory contains subdirectories for some filesystems. A filesystem will have a subdirectory here only if it chose to explicitly create the subdirectory.

/sys/fs/cgroup
This directory conventionally is used as a mount point for a tmpfs(5) filesystem containing mount points for cgroups(7) filesystems.

/sys/fs/smackfs
The directory contains configuration files for the SMACK LSM. See the kernel source file Documentation/admin-guide/LSM/Smack.rst.

/sys/hypervisor
[To be documented]

/sys/kernel
This subdirectory contains various files and subdirectories that provide information about the running kernel.

/sys/kernel/cgroup/
For information about the files in this directory, see cgroups(7).

/sys/kernel/debug/tracing
Mount point for the tracefs filesystem used by the kernel’s ftrace facility. (For information on ftrace, see the kernel source file Documentation/trace/ftrace.txt.)

/sys/kernel/mm
This subdirectory contains various files and subdirectories that provide information about the kernel’s memory management subsystem.

/sys/kernel/mm/hugepages
This subdirectory contains one subdirectory for each of the huge page sizes that the system supports. The subdirectory name indicates the huge page size (e.g., hugepages-2048kB). Within each of these subdirectories is a set of files that can be used to view and (in some cases) change settings associated with that huge page size. For further information, see the kernel source file Documentation/admin-guide/mm/hugetlbpage.rst.

/sys/module
This subdirectory contains one subdirectory for each module that is loaded into the kernel. The name of each directory is the name of the module. In each of the subdirectories, there may be following files:

coresize
[to be documented]

initsize
[to be documented]

initstate
[to be documented]

refcnt
[to be documented]

srcversion
[to be documented]

taint
[to be documented]

uevent
[to be documented]

version
[to be documented]

In each of the subdirectories, there may be following subdirectories:

drivers
[To be documented]

holders
[To be documented]

notes
[To be documented]

parameters
This directory contains one file for each module parameter, with each file containing the value of the corresponding parameter. Some of these files are writable, allowing the

sections
This subdirectories contains files with information about module sections. This information is mainly used for debugging.

[To be documented]

/sys/power
[To be documented]

STANDARDS

Linux.

HISTORY

Linux 2.6.0.

NOTES

This manual page is incomplete, possibly inaccurate, and is the kind of thing that needs to be updated very often.

91 - Linux cli command proc_cpuinfo

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_cpuinfo and provides detailed information about the command proc_cpuinfo, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_cpuinfo.

NAME 🖥️ proc_cpuinfo 🖥️

CPU and system architecture information

DESCRIPTION

/proc/cpuinfo
This is a collection of CPU and system architecture dependent items, for each supported architecture a different list. Two common entries are processor which gives CPU number and bogomips; a system constant that is calculated during kernel initialization. SMP machines have information for each CPU. The lscpu(1) command gathers its information from this file.

92 - Linux cli command whois.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command whois.conf and provides detailed information about the command whois.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the whois.conf.

NAME 🖥️ whois.conf 🖥️

alternative WHOIS servers list for whois client

SYNOPSIS

/etc/whois.conf

DESCRIPTION

This file contains a list of WHOIS servers which can augment or override the built-in list of the client.

It’s a plain text file in ASCII encoding. Each line consists of two fields: a pattern to match WHOIS object identifier and a corresponding WHOIS server domain name.

Fields are separated by non-empty sequence of space or a tabular characters. A line starting with a hash character is a free comment and it’s not considered.

The pattern is case-insensitive extended regular expression if whois client has been compiled with POSIX regular expressions support. Otherwise, simple case-insensitive suffix comparison against WHOIS object identifier is used.

Internationalized domain names (IDN) must be specified in ascii-compatible encoding (ACE) format.

EXAMPLE

\nz$ nz.whois-servers.net
# Hangul Korean TLD
\xn–3e0b707e$ whois.kr
# Private ASNs
^as645(1[2-9]|2[0-9]|3[0-4])$ whois.example.net

FILES

/etc/whois.conf

AUTHOR

This manual page was written by Petr Písař <[email protected]> and is licensed under the terms of the GNU General Public License, version 2 or higher.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

93 - Linux cli command apt_preferences

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command apt_preferences and provides detailed information about the command apt_preferences, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the apt_preferences.

NAME 🖥️ apt_preferences 🖥️

Preference control file for APT

DESCRIPTION

The APT preferences file /etc/apt/preferences and the fragment files in the /etc/apt/preferences.d/ folder can be used to control which versions of packages will be selected for installation.

Several versions of a package may be available for installation when the sources.list(5) file contains references to more than one distribution (for example, stable and testing). APT assigns a priority to each version that is available. Subject to dependency constraints, apt-get selects the version with the highest priority for installation. The APT preferences override the priorities that APT assigns to package versions by default, thus giving the user control over which one is selected for installation.

Several instances of the same version of a package may be available when the sources.list(5) file contains references to more than one source. In this case apt-get downloads the instance listed earliest in the sources.list(5) file. The APT preferences do not affect the choice of instance, only the choice of version.

Preferences are a strong power in the hands of a system administrator but they can become also their biggest nightmare if used without care! APT will not question the preferences, so wrong settings can lead to uninstallable packages or wrong decisions while upgrading packages. Even more problems will arise if multiple distribution releases are mixed without a good understanding of the following paragraphs. Packages included in a specific release arent tested in (and therefore dont always work as expected in) older or newer releases, or together with other packages from different releases. You have been warned.

Note that the files in the /etc/apt/preferences.d directory are parsed in alphanumeric ascending order and need to obey the following naming convention: The files have either no or “pref” as filename extension and only contain alphanumeric, hyphen (-), underscore (_) and period (.) characters. Otherwise APT will print a notice that it has ignored a file, unless that file matches a pattern in the Dir::Ignore-Files-Silently configuration list - in which case it will be silently ignored.

APTs Default Priority Assignments

If there is no preferences file or if there is no entry in the file that applies to a particular version then the priority assigned to that version is the priority of the distribution to which that version belongs. It is possible to single out a distribution, “the target release”, which receives a higher priority than other distributions do by default. The target release can be set on the apt-get command line or in the APT configuration file /etc/apt/apt.conf. Note that this has precedence over any general priority you set in the /etc/apt/preferences file described later, but not over specifically pinned packages. For example,

apt-get install -t testing some-package

APT::Default-Release “stable”;

If the target release has been specified then APT uses the following algorithm to set the priorities of the versions of a package. Assign:

priority 1

to the versions coming from archives which in their Release files are marked as “NotAutomatic: yes” but not as “ButAutomaticUpgrades: yes” like the Debian experimental archive, as well as versions that are not phased on this systems.

priority 100

to the version that is already installed (if any) and to the versions coming from archives which in their Release files are marked as “NotAutomatic: yes” and “ButAutomaticUpgrades: yes” like the Debian backports archive since squeeze-backports.

priority 500

to the versions that do not belong to the target release.

priority 990

to the versions that belong to the target release.

The highest of those priorities whose description matches the version is assigned to the version.

If the target release has not been specified then APT simply assigns priority 100 to all installed package versions and priority 500 to all uninstalled package versions, except versions coming from archives which in their Release files are marked as “NotAutomatic: yes” - these versions get the priority 1 or priority 100 if it is additionally marked as “ButAutomaticUpgrades: yes”.

APT then applies the following rules, listed in order of precedence, to determine which version of a package to install.

·
Never downgrade unless the priority of an available version exceeds 1000. (“Downgrading” is installing a less recent version of a package in place of a more recent version. Note that none of APTs default priorities exceeds 1000; such high priorities can only be set in the preferences file. Note also that downgrading a package can be risky.)

·
Install the highest priority version.

·
If two or more versions have the same priority, install the most recent one (that is, the one with the higher version number).

·
If two or more versions have the same priority and version number but either the packages differ in some of their metadata or the –reinstall option is given, install the uninstalled one.

In a typical situation, the installed version of a package (priority 100) is not as recent as one of the versions available from the sources listed in the sources.list(5) file (priority 500 or 990). Then the package will be upgraded when apt-get install some-package or apt-get upgrade is executed.

More rarely, the installed version of a package is more recent than any of the other available versions. The package will not be downgraded when apt-get install some-package or apt-get upgrade is executed.

Sometimes the installed version of a package is more recent than the version belonging to the target release, but not as recent as a version belonging to some other distribution. Such a package will indeed be upgraded when apt-get install some-package or apt-get upgrade is executed, because at least one of the available versions has a higher priority than the installed version.

Phased Updates

APT understands a field called Phased-Update-Percentage which can be used to control the rollout of a new version. It is an integer between 0 and 100.

A systems eligibility to a phased update is determined by seeding random number generator with the package source name, the version number, and /etc/machine-id, and then calculating an integer in the range [0, 100]. If this integer is larger than the Phased-Update-Percentage, the version is pinned to 1, and thus held back. Otherwise, normal policy rules apply.

In case you have multiple systems that you want to receive the same set of updates, you can set APT::Machine-ID to a UUID such that they all phase the same, or set APT::Get::Never-Include-Phased-Updates or APT::Get::Always-Include-Phased-Updates to true such that APT will never/always consider phased updates.

The Effect of APT Preferences

The APT preferences file allows the system administrator to control the assignment of priorities. The file consists of one or more multi-line records separated by blank lines. Records can have one of two forms, a specific form and a general form.

·
The specific form assigns a priority (a “Pin-Priority”) to one or more specified packages with a specified version or version range. For example, the following record assigns a high priority to all versions of the perl package whose version number begins with “5.32”. Multiple packages can be separated by spaces.
Package: perl Pin: version 5.32* Pin-Priority: 1001

·
The general form assigns a priority to all of the package versions in a given distribution (that is, to all the versions of packages that are listed in a certain Release file) or to all of the package versions coming from a particular Internet site, as identified by the sites fully qualified domain name.
This general-form entry in the APT preferences file applies only to groups of packages. For example, the following record assigns a high priority to all package versions available from the local site.
Package: * Pin: origin "" Pin-Priority: 999
A note of caution: the keyword used here is “origin” which can be used to match a hostname. The following record will assign a high priority to all versions available from the server identified by the hostname “ftp.de.debian.org”
Package: * Pin: origin “ftp.de.debian.org” Pin-Priority: 999
This should not be confused with the Origin of a distribution as specified in a Release file. What follows the “Origin:” tag in a Release file is not an Internet address but an author or vendor name, such as “Debian” or “Ximian”.
The following record assigns a low priority to all package versions belonging to any distribution whose Archive name is “unstable”.
Package: * Pin: release a=unstable Pin-Priority: 50
The following record assigns a high priority to all package versions belonging to any distribution whose Codename is “trixie”.
Package: * Pin: release n=trixie Pin-Priority: 900
The following record assigns a high priority to all package versions belonging to any release whose Archive name is “stable” and whose release Version number is “12”.
Package: * Pin: release a=stable, v=12 Pin-Priority: 500

The effect of the comma operator is similar to an “and” in logic: All conditions must be satisfied for the pin to match. There is one exception: For any type of condition (such as two “a” conditions), only the last such condition is checked.

Matching packages in the Package field

The Package field specifies the package that a pinning priority is applied to. The field can either contain a binary package name, a source package name (prefixed with “src:”), a glob(7) expression or a regular expression (surrounded by slashes). Multiple package names, glob(7) expressions and regular expressions can be listed separated by whitespace in which case the record will match any of the matched packages.

By default, only packages of the native architecture are matched. To match binary packages of any architecture, add the :any suffix to the package name. You can also limit matching to a specific architecture by appending the architecture name to the package name, separated by a colon character.

For example, the following example uses a glob expression and a regular expression to assign the priority 500 to all packages from experimental where the name starts with gnome (as a glob(7)-like expression) or contains the word kde (as a POSIX extended regular expression surrounded by slashes).

Package: gnome* /kde/ Pin: release a=experimental Pin-Priority: 500

The rule for those expressions is that they can occur anywhere where a string can occur. Thus, the following pin assigns the priority 990 to all packages from a release starting with lunar.

Package: * Pin: release n=lunar* Pin-Priority: 990

If a regular expression occurs in a Package field, the behavior is the same as if this regular expression were replaced with a list of all package names it matches. It is undecided whether this will change in the future; thus you should always list wild-card pins first, so later specific pins override it. The pattern “*” in a Package field is not considered a glob(7) expression in itself.

To pin all binaries produced by the apt source package of this APTs version to 990, you can do:

Package: src:apt Pin: version 2.9.5 Pin-Priority: 990

Source package pinning can be combined with regular expressions and glob patterns, and can also take a binary architecture.

For example, lets pin all binaries for all architectures produced by any source package containing apt in its name to 990:

Package: src:apt:any Pin: version * Pin-Priority: 990

The :any suffix makes sure to select binary packages from any architecture. Without that suffix, apt implicitly assumes the :native suffix which would only select packages from the native architecture.

How APT Interprets Priorities

Priorities (P) assigned in the APT preferences file must be positive or negative integers. They are interpreted as follows (roughly speaking):

P >= 1000

causes a version to be installed even if this constitutes a downgrade of the package

990 <= P < 1000

causes a version to be installed even if it does not come from the target release, unless the installed version is more recent

500 <= P < 990

causes a version to be installed unless there is a version available belonging to the target release or the installed version is more recent

100 <= P < 500

causes a version to be installed unless there is a version available belonging to some other distribution or the installed version is more recent

0 < P < 100

causes a version to be installed only if there is no installed version of the package

P < 0

prevents the version from being installed

P = 0

has undefined behaviour, do not use it.

The first specific-form record matching an available package version determines the priority of the package version. Failing that, the priority of the package is defined as the maximum of all priorities defined by generic-form records matching the version. Records defined using patterns in the Pin field other than “*” are treated like specific-form records.

For example, suppose the APT preferences file contains the three records presented earlier:

Package: perl Pin: version 5.32* Pin-Priority: 1001
Package: *
Pin: origin ""
Pin-Priority: 999

Package: *
Pin: release unstable
Pin-Priority: 50

Then:

·
The most recent available version of the perl package will be installed, so long as that versions version number begins with “5.32”. If any 5.32* version of perl is available and the installed version is 5.36*, then perl will be downgraded.

·
A version of any package other than perl that is available from the local system has priority over other versions, even versions belonging to the target release.

·
A version of a package whose origin is not the local system but some other site listed in sources.list(5) and which belongs to an unstable distribution is only installed if it is selected for installation and no version of the package is already installed.

Determination of Package Version and Distribution Properties

The locations listed in the sources.list(5) file should provide Packages and Release files to describe the packages available at that location.

The Packages file is normally found in the directory …/dists/dist-name/component/arch: for example, …/dists/stable/main/binary-i386/Packages. It consists of a series of multi-line records, one for each package available in that directory. Only two lines in each record are relevant for setting APT priorities:

the Package: line

gives the package name

the Version: line

gives the version number for the named package

The Release file is normally found in the directory …/dists/dist-name: for example, …/dists/stable/Release, or …/dists/bookworm/Release. It consists of a single multi-line record which applies to all of the packages in the directory tree below its parent. Unlike the Packages file, nearly all of the lines in a Release file are relevant for setting APT priorities:

the Archive: or Suite: line

names the archive to which all the packages in the directory tree belong. For example, the line “Archive: stable” or “Suite: stable” specifies that all of the packages in the directory tree below the parent of the Release file are in a stable archive. Specifying this value in the APT preferences file would require the line:
Pin: release a=stable

the Codename: line

names the codename to which all the packages in the directory tree belong. For example, the line “Codename: trixie” specifies that all of the packages in the directory tree below the parent of the Release file belong to a version named trixie. Specifying this value in the APT preferences file would require the line:
Pin: release n=trixie

the Version: line

names the release version. For example, the packages in the tree might belong to Debian release version 12. Note that there is normally no version number for the testing and unstable distributions because they have not been released yet. Specifying this in the APT preferences file would require one of the following lines.
Pin: release v=12 Pin: release a=stable, v=12 Pin: release 12

the Component: line

names the licensing component associated with the packages in the directory tree of the Release file. For example, the line “Component: main” specifies that all the packages in the directory tree are from the main component, which entails that they are licensed under terms listed in the Debian Free Software Guidelines. Specifying this component in the APT preferences file would require the line:
Pin: release c=main

the Origin: line

names the originator of the packages in the directory tree of the Release file. Most commonly, this is Debian. Specifying this origin in the APT preferences file would require the line:
Pin: release o=Debian

the Label: line

names the label of the packages in the directory tree of the Release file. Most commonly, this is Debian. Specifying this label in the APT preferences file would require the line:
Pin: release l=Debian

All of the Packages and Release files retrieved from locations listed in the sources.list(5) file are stored in the directory /var/lib/apt/lists, or in the file named by the variable Dir::State::Lists in the apt.conf file. For example, the file debian.lcs.mit.edu_debian_dists_unstable_contrib_binary-i386_Release contains the Release file retrieved from the site debian.lcs.mit.edu for binary-i386 architecture files from the contrib component of the unstable distribution.

Optional Lines in an APT Preferences Record

Each record in the APT preferences file can optionally begin with one or more lines beginning with the word Explanation:. This provides a place for comments.

EXAMPLES

Tracking Stable

The following APT preferences file will cause APT to assign a priority higher than the default (500) to all package versions belonging to a stable distribution and a prohibitively low priority to package versions belonging to other Debian distributions.

Explanation: Uninstall or do not install any Debian-originated Explanation: package versions other than those in the stable distro Package: * Pin: release a=stable Pin-Priority: 900
Package: *
Pin: release o=Debian
Pin-Priority: -10

With a suitable sources.list(5) file and the above preferences file, any of the following commands will cause APT to upgrade to the latest stable version(s).

apt-get install package-name apt-get upgrade apt-get dist-upgrade

The following command will cause APT to upgrade the specified package to the latest version from the testing distribution; the package will not be upgraded again unless this command is given again.

apt-get install package/testing

Tracking Testing or Unstable

The following APT preferences file will cause APT to assign a high priority to package versions from the testing distribution, a lower priority to package versions from the unstable distribution, and a prohibitively low priority to package versions from other Debian distributions.

Package: * Pin: release a=testing Pin-Priority: 900
Package: *
Pin: release a=unstable
Pin-Priority: 800

Package: *
Pin: release o=Debian
Pin-Priority: -10

With a suitable sources.list(5) file and the above preferences file, any of the following commands will cause APT to upgrade to the latest testing version(s).

apt-get install package-name apt-get upgrade apt-get dist-upgrade

The following command will cause APT to upgrade the specified package to the latest version from the unstable distribution. Thereafter, apt-get upgrade will upgrade the package to the most recent testing version if that is more recent than the installed version, otherwise, to the most recent unstable version if that is more recent than the installed version.

apt-get install package/unstable

Tracking the evolution of a codename release

The following APT preferences file will cause APT to assign a priority higher than the default (500) to all package versions belonging to a specified codename of a distribution and a prohibitively low priority to package versions belonging to other Debian distributions, codenames and archives. Note that with this APT preference APT will follow the migration of a release from the archive testing to stable and later oldstable. If you want to follow for example the progress in testing notwithstanding the codename changes you should use the example configurations above.

Explanation: Uninstall or do not install any Debian-originated package versions Explanation: other than those in the distribution codenamed with trixie or sid Package: * Pin: release n=trixie Pin-Priority: 900
Explanation: Debian unstable is always codenamed with sid
Package: *
Pin: release n=sid
Pin-Priority: 800

Package: *
Pin: release o=Debian
Pin-Priority: -10

With a suitable sources.list(5) file and the above preferences file, any of the following commands will cause APT to upgrade to the latest version(s) in the release codenamed with trixie.

apt-get install package-name apt-get upgrade apt-get dist-upgrade

The following command will cause APT to upgrade the specified package to the latest version from the sid distribution. Thereafter, apt-get upgrade will upgrade the package to the most recent trixie version if that is more recent than the installed version, otherwise, to the most recent sid version if that is more recent than the installed version.

apt-get install package/sid

FILES

/etc/apt/preferences

Version preferences file. This is where you would specify “pinning”, i.e. a preference to get certain packages from a separate source or from a different version of a distribution. Configuration Item: Dir::Etc::Preferences.

/etc/apt/preferences.d/

File fragments for the version preferences. Configuration Item: Dir::Etc::PreferencesParts.

BUGS

APT bug page[1]. If you wish to report a bug in APT, please see /usr/share/doc/debian/bug-reporting.txt or the reportbug(1) command.

AUTHOR

APT team

NOTES

APT bug page

https://bugs.debian.org/src:apt

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

94 - Linux cli command org.bluez.DeviceSet

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.DeviceSet and provides detailed information about the command org.bluez.DeviceSet, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.DeviceSet.

NAME 🖥️ org.bluez.DeviceSet 🖥️

BlueZ D-Bus DeviceSet API documentation

INTERFACE

Service
org.bluez
Interface
org.bluez.DeviceSet1
Object path
[variable prefix]/{hci0,hci1,…}/set_{sirk}

Methods

void Connect() [experimental]

Connects all devices members of the set, each member is connected in sequence as they were added/loaded following the same proceedure as described in Device1.Connect.
Possible errors:
org.bluez.Error.NotReady
org.bluez.Error.Failed
org.bluez.Error.InProgress
org.bluez.Error.AlreadyConnected

void Disconnect() [experimental]

Disconnects all devices members of the set, each member is disconnected in sequence as they were connected following the same proceedure as described in Device1.Disconnect.
Possible errors:
org.bluez.Error.NotConnected

Properties

object Adapter [readonly, experimental]

The object path of the adapter the set belongs to.

bool AutoConnect [read-write, experimental]

Indicates if the devices members of the set shall be automatically connected once any of its members is connected.

array(object) Devices [ready-only, experimental]

List of devices objects that are members of the set.

byte Size [read-only, experimental]

Set members size.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

95 - Linux cli command proc_tty

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_tty and provides detailed information about the command proc_tty, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_tty.

NAME 🖥️ proc_tty 🖥️

tty

DESCRIPTION

/proc/tty/
Subdirectory containing the pseudo-files and subdirectories for tty drivers and line disciplines.

96 - Linux cli command ext3

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ext3 and provides detailed information about the command ext3, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ext3.

NAME 🖥️ ext3 🖥️

the second extended file system
ext3 - the third extended file system
ext4 - the fourth extended file system

DESCRIPTION

The second, third, and fourth extended file systems, or ext2, ext3, and ext4 as they are commonly known, are Linux file systems that have historically been the default file system for many Linux distributions. They are general purpose file systems that have been designed for extensibility and backwards compatibility. In particular, file systems previously intended for use with the ext2 and ext3 file systems can be mounted using the ext4 file system driver, and indeed in many modern Linux distributions, the ext4 file system driver has been configured to handle mount requests for ext2 and ext3 file systems.

FILE SYSTEM FEATURES

A file system formatted for ext2, ext3, or ext4 can have some collection of the following file system feature flags enabled. Some of these features are not supported by all implementations of the ext2, ext3, and ext4 file system drivers, depending on Linux kernel version in use. On other operating systems, such as the GNU/HURD or FreeBSD, only a very restrictive set of file system features may be supported in their implementations of ext2.

64bit

Enables the file system to be larger than 2^32 blocks. This feature is set automatically, as needed, but it can be useful to specify this feature explicitly if the file system might need to be resized larger than 2^32 blocks, even if it was smaller than that threshold when it was originally created. Note that some older kernels and older versions of e2fsprogs will not support file systems with this ext4 feature enabled.

bigalloc

This ext4 feature enables clustered block allocation, so that the unit of allocation is a power of two number of blocks. That is, each bit in the what had traditionally been known as the block allocation bitmap now indicates whether a cluster is in use or not, where a cluster is by default composed of 16 blocks. This feature can decrease the time spent on doing block allocation and brings smaller fragmentation, especially for large files. The size can be specified using the mke2fs -C option.

Warning: The bigalloc feature is still under development, and may not be fully supported with your kernel or may have various bugs. Please see the web page http://ext4.wiki.kernel.org/index.php/Bigalloc for details. May clash with delayed allocation (see nodelalloc mount option).

This feature requires that the extent feature be enabled.

casefold

This ext4 feature provides file system level character encoding support for directories with the casefold (+F) flag enabled. This feature is name-preserving on the disk, but it allows applications to lookup for a file in the file system using an encoding equivalent version of the file name.

dir_index

Use hashed b-trees to speed up name lookups in large directories. This feature is supported by ext3 and ext4 file systems, and is ignored by ext2 file systems.

dir_nlink

Normally, ext4 allows an inode to have no more than 65,000 hard links. This applies to regular files as well as directories, which means that there can be no more than 64,998 subdirectories in a directory (because each of the ‘.’ and ‘..’ entries, as well as the directory entry for the directory in its parent directory counts as a hard link). This feature lifts this limit by causing ext4 to use a link count of 1 to indicate that the number of hard links to a directory is not known when the link count might exceed the maximum count limit.

ea_inode

Normally, a file’s extended attributes and associated metadata must fit within the inode or the inode’s associated extended attribute block. This feature allows the value of each extended attribute to be placed in the data blocks of a separate inode if necessary, increasing the limit on the size and number of extended attributes per file.

encrypt

Enables support for file-system level encryption of data blocks and file names. The inode metadata (timestamps, file size, user/group ownership, etc.) is not encrypted.

This feature is most useful on file systems with multiple users, or where not all files should be encrypted. In many use cases, especially on single-user systems, encryption at the block device layer using dm-crypt may provide much better security.

ext_attr

This feature enables the use of extended attributes. This feature is supported by ext2, ext3, and ext4.

extent

This ext4 feature allows the mapping of logical block numbers for a particular inode to physical blocks on the storage device to be stored using an extent tree, which is a more efficient data structure than the traditional indirect block scheme used by the ext2 and ext3 file systems. The use of the extent tree decreases metadata block overhead, improves file system performance, and decreases the needed to run e2fsck(8) on the file system. (Note: both extent and extents are accepted as valid names for this feature for historical/backwards compatibility reasons.)

extra_isize

This ext4 feature reserves a specific amount of space in each inode for extended metadata such as nanosecond timestamps and file creation time, even if the current kernel does not currently need to reserve this much space. Without this feature, the kernel will reserve the amount of space for features it currently needs, and the rest may be consumed by extended attributes.

For this feature to be useful the inode size must be 256 bytes in size or larger.

filetype

This feature enables the storage of file type information in directory entries. This feature is supported by ext2, ext3, and ext4.

flex_bg

This ext4 feature allows the per-block group metadata (allocation bitmaps and inode tables) to be placed anywhere on the storage media. In addition, mke2fs will place the per-block group metadata together starting at the first block group of each “flex_bg group”. The size of the flex_bg group can be specified using the -G option.

has_journal

Create a journal to ensure file system consistency even across unclean shutdowns. Setting the file system feature is equivalent to using the -j option with mke2fs or tune2fs. This feature is supported by ext3 and ext4, and ignored by the ext2 file system driver.

huge_file

This ext4 feature allows files to be larger than 2 terabytes in size.

inline_data
Allow data to be stored in the inode and extended attribute area.

journal_dev

This feature is enabled on the superblock found on an external journal device. The block size for the external journal must be the same as the file system which uses it.

The external journal device can be used by a file system by specifying the -J device=<external-device> option to mke2fs(8) or tune2fs(8).

large_dir

This feature increases the limit on the number of files per directory by raising the maximum size of directories and, for hashed b-tree directories (see dir_index), the maximum height of the hashed b-tree used to store the directory entries.

large_file

This feature flag is set automatically by modern kernels when a file larger than 2 gigabytes is created. Very old kernels could not handle large files, so this feature flag was used to prohibit those kernels from mounting file systems that they could not understand.

metadata_csum

This ext4 feature enables metadata checksumming. This feature stores checksums for all of the file system metadata (superblock, group descriptor blocks, inode and block bitmaps, directories, and extent tree blocks). The checksum algorithm used for the metadata blocks is different than the one used for group descriptors with the uninit_bg feature. These two features are incompatible and metadata_csum will be used preferentially instead of uninit_bg.

metadata_csum_seed

This feature allows the file system to store the metadata checksum seed in the superblock, which allows the administrator to change the UUID of a file system using the metadata_csum feature while it is mounted.

meta_bg

This ext4 feature allows file systems to be resized on-line without explicitly needing to reserve space for growth in the size of the block group descriptors. This scheme is also used to resize file systems which are larger than 2^32 blocks. It is not recommended that this feature be set when a file system is created, since this alternate method of storing the block group descriptors will slow down the time needed to mount the file system, and newer kernels can automatically set this feature as necessary when doing an online resize and no more reserved space is available in the resize inode.

mmp

This ext4 feature provides multiple mount protection (MMP). MMP helps to protect the file system from being multiply mounted and is useful in shared storage environments.

project

This ext4 feature provides project quota support. With this feature, the project ID of inode will be managed when the file system is mounted.

quota

Create quota inodes (inode #3 for userquota and inode #4 for group quota) and set them in the superblock. With this feature, the quotas will be enabled automatically when the file system is mounted.

Causes the quota files (i.e., user.quota and group.quota which existed in the older quota design) to be hidden inodes.

resize_inode

This file system feature indicates that space has been reserved so that the block group descriptor table can be extended while resizing a mounted file system. The online resize operation is carried out by the kernel, triggered by resize2fs(8). By default mke2fs will attempt to reserve enough space so that the file system may grow to 1024 times its initial size. This can be changed using the resize extended option.

This feature requires that the sparse_super or sparse_super2 feature be enabled.

sparse_super

This file system feature is set on all modern ext2, ext3, and ext4 file systems. It indicates that backup copies of the superblock and block group descriptors are present only in a few block groups, not all of them.

sparse_super2

This feature indicates that there will only be at most two backup superblocks and block group descriptors. The block groups used to store the backup superblock(s) and blockgroup descriptor(s) are stored in the superblock, but typically, one will be located at the beginning of block group #1, and one in the last block group in the file system. This feature is essentially a more extreme version of sparse_super and is designed to allow a much larger percentage of the disk to have contiguous blocks available for data files.

stable_inodes

Marks the file system’s inode numbers and UUID as stable. resize2fs(8) will not allow shrinking a file system with this feature, nor will tune2fs(8) allow changing its UUID. This feature allows the use of specialized encryption settings that make use of the inode numbers and UUID. Note that the encrypt feature still needs to be enabled separately. stable_inodes is a “compat” feature, so old kernels will allow it.

uninit_bg

This ext4 file system feature indicates that the block group descriptors will be protected using checksums, making it safe for mke2fs(8) to create a file system without initializing all of the block groups. The kernel will keep a high watermark of unused inodes, and initialize inode tables and blocks lazily. This feature speeds up the time to check the file system using e2fsck(8), and it also speeds up the time required for mke2fs(8) to create the file system.

verity

Enables support for verity protected files. Verity files are readonly, and their data is transparently verified against a Merkle tree hidden past the end of the file. Using the Merkle tree’s root hash, a verity file can be efficiently authenticated, independent of the file’s size.

This feature is most useful for authenticating important read-only files on read-write file systems. If the file system itself is read-only, then using dm-verity to authenticate the entire block device may provide much better security.

MOUNT OPTIONS

This section describes mount options which are specific to ext2, ext3, and ext4. Other generic mount options may be used as well; see mount(8) for details.

Mount options for ext2

The `ext2’ file system is the standard Linux file system. Since Linux 2.5.46, for most mount options the default is determined by the file system superblock. Set them with tune2fs(8).

acl|noacl
Support POSIX Access Control Lists (or not). See the acl(5) manual page.

bsddf|minixdf
Set the behavior for the statfs system call. The minixdf behavior is to return in the f_blocks field the total number of blocks of the file system, while the bsddf behavior (which is the default) is to subtract the overhead blocks used by the ext2 file system and not available for file storage. Thus

% mount /k -o minixdf; df /k; umount /k

File System	1024-blocks	Used	Available	Capacity	Mounted on
/dev/sda6	2630655	86954	2412169	3%	/k

% mount /k -o bsddf; df /k; umount /k

File System	1024-blocks	Used	Available	Capacity	Mounted on
/dev/sda6	2543714	13	2412169	0%	/k

(Note that this example shows that one can add command line options to the options given in /etc/fstab.)

check=none or nocheck
No checking is done at mount time. This is the default. This is fast. It is wise to invoke e2fsck(8) every now and then, e.g. at boot time. The non-default behavior is unsupported (check=normal and check=strict options have been removed). Note that these mount options don’t have to be supported if ext4 kernel driver is used for ext2 and ext3 file systems.

debug
Print debugging info upon each (re)mount.

errors={continue|remount-ro|panic}
Define the behavior when an error is encountered. (Either ignore errors and just mark the file system erroneous and continue, or remount the file system read-only, or panic and halt the system.) The default is set in the file system superblock, and can be changed using tune2fs(8).

grpid|bsdgroups and nogrpid|sysvgroups
These options define what group id a newly created file gets. When grpid is set, it takes the group id of the directory in which it is created; otherwise (the default) it takes the fsgid of the current process, unless the directory has the setgid bit set, in which case it takes the gid from the parent directory, and also gets the setgid bit set if it is a directory itself.

grpquota|noquota|quota|usrquota
The usrquota (same as quota) mount option enables user quota support on the file system. grpquota enables group quotas support. You need the quota utilities to actually enable and manage the quota system.

nouid32
Disables 32-bit UIDs and GIDs. This is for interoperability with older kernels which only store and expect 16-bit values.

oldalloc or orlov
Use old allocator or Orlov allocator for new inodes. Orlov is default.

**resgid=**n and **resuid=**n
The ext2 file system reserves a certain percentage of the available space (by default 5%, see mke2fs(8) and tune2fs(8)). These options determine who can use the reserved blocks. (Roughly: whoever has the specified uid, or belongs to the specified group.)

**sb=**n
Instead of using the normal superblock, use an alternative superblock specified by n. This option is normally used when the primary superblock has been corrupted. The location of backup superblocks is dependent on the file system’s blocksize, the number of blocks per group, and features such as sparse_super.

Additional backup superblocks can be determined by using the mke2fs program using the -n option to print out where the superblocks exist, supposing mke2fs is supplied with arguments that are consistent with the file system’s layout (e.g. blocksize, blocks per group, sparse_super, etc.).

The block number here uses 1 k units. Thus, if you want to use logical block 32768 on a file system with 4 k blocks, use “sb=131072”.

user_xattr|nouser_xattr
Support “user.” extended attributes (or not).

Mount options for ext3

The ext3 file system is a version of the ext2 file system which has been enhanced with journaling. It supports the same options as ext2 as well as the following additions:

journal_dev=devnum/journal_path=path
When the external journal device’s major/minor numbers have changed, these options allow the user to specify the new journal location. The journal device is identified either through its new major/minor numbers encoded in devnum, or via a path to the device.

norecovery/noload
Don’t load the journal on mounting. Note that if the file system was not unmounted cleanly, skipping the journal replay will lead to the file system containing inconsistencies that can lead to any number of problems.

data={journal|ordered|writeback}
Specifies the journaling mode for file data. Metadata is always journaled. To use modes other than ordered on the root file system, pass the mode to the kernel as boot parameter, e.g. rootflags=data=journal.

journal
All data is committed into the journal prior to being written into the main file system.

ordered
This is the default mode. All data is forced directly out to the main file system prior to its metadata being committed to the journal.

writeback
Data ordering is not preserved – data may be written into the main file system after its metadata has been committed to the journal. This is rumoured to be the highest-throughput option. It guarantees internal file system integrity, however it can allow old data to appear in files after a crash and journal recovery.

data_err=ignore
Just print an error message if an error occurs in a file data buffer in ordered mode.

data_err=abort
Abort the journal if an error occurs in a file data buffer in ordered mode.

barrier=0 / barrier=1"
This disables / enables the use of write barriers in the jbd code. barrier=0 disables, barrier=1 enables (default). This also requires an IO stack which can support barriers, and if jbd gets an error on a barrier write, it will disable barriers again with a warning. Write barriers enforce proper on-disk ordering of journal commits, making volatile disk write caches safe to use, at some performance penalty. If your disks are battery-backed in one way or another, disabling barriers may safely improve performance.

**commit=**nrsec
Start a journal commit every nrsec seconds. The default value is 5 seconds. Zero means default.

user_xattr
Enable Extended User Attributes. See the attr(5) manual page.

jqfmt={vfsold|vfsv0|vfsv1}
Apart from the old quota system (as in ext2, jqfmt=vfsold aka version 1 quota) ext3 also supports journaled quotas (version 2 quota). jqfmt=vfsv0 or jqfmt=vfsv1 enables journaled quotas. Journaled quotas have the advantage that even after a crash no quota check is required. When the quota file system feature is enabled, journaled quotas are used automatically, and this mount option is ignored.

usrjquota=aquota.user|grpjquota=aquota.group
For journaled quotas (jqfmt=vfsv0 or jqfmt=vfsv1), the mount options usrjquota=aquota.user and grpjquota=aquota.group are required to tell the quota system which quota database files to use. When the quota file system feature is enabled, journaled quotas are used automatically, and this mount option is ignored.

Mount options for ext4

The ext4 file system is an advanced level of the ext3 file system which incorporates scalability and reliability enhancements for supporting large file system.

The options journal_dev, journal_path, norecovery, noload, data, commit, orlov, oldalloc, [no]user_xattr, [no]acl, bsddf, minixdf, debug, errors, data_err, grpid, bsdgroups, nogrpid, sysvgroups, resgid, resuid, sb, quota, noquota, nouid32, grpquota, usrquota, usrjquota, grpjquota, and jqfmt are backwardly compatible with ext3 or ext2.

journal_checksum | nojournal_checksum
The journal_checksum option enables checksumming of the journal transactions. This will allow the recovery code in e2fsck and the kernel to detect corruption in the kernel. It is a compatible change and will be ignored by older kernels.

journal_async_commit
Commit block can be written to disk without waiting for descriptor blocks. If enabled older kernels cannot mount the device. This will enable ‘journal_checksum’ internally.

barrier=0 / barrier=1 / barrier / nobarrier
These mount options have the same effect as in ext3. The mount options “barrier” and “nobarrier” are added for consistency with other ext4 mount options.

The ext4 file system enables write barriers by default.

**inode_readahead_blks=**n
This tuning parameter controls the maximum number of inode table blocks that ext4’s inode table readahead algorithm will pre-read into the buffer cache. The value must be a power of 2. The default value is 32 blocks.

**stripe=**n
Number of file system blocks that mballoc will try to use for allocation size and alignment. For RAID5/6 systems this should be the number of data disks * RAID chunk size in file system blocks.

delalloc
Deferring block allocation until write-out time.

nodelalloc
Disable delayed allocation. Blocks are allocated when data is copied from user to page cache.

**max_batch_time=**usec
Maximum amount of time ext4 should wait for additional file system operations to be batch together with a synchronous write operation. Since a synchronous write operation is going to force a commit and then a wait for the I/O complete, it doesn’t cost much, and can be a huge throughput win, we wait for a small amount of time to see if any other transactions can piggyback on the synchronous write. The algorithm used is designed to automatically tune for the speed of the disk, by measuring the amount of time (on average) that it takes to finish committing a transaction. Call this time the “commit time”. If the time that the transaction has been running is less than the commit time, ext4 will try sleeping for the commit time to see if other operations will join the transaction. The commit time is capped by the max_batch_time, which defaults to 15000 µs (15 ms). This optimization can be turned off entirely by setting max_batch_time to 0.

**min_batch_time=**usec
This parameter sets the commit time (as described above) to be at least min_batch_time. It defaults to zero microseconds. Increasing this parameter may improve the throughput of multi-threaded, synchronous workloads on very fast disks, at the cost of increasing latency.

**journal_ioprio=**prio
The I/O priority (from 0 to 7, where 0 is the highest priority) which should be used for I/O operations submitted by kjournald2 during a commit operation. This defaults to 3, which is a slightly higher priority than the default I/O priority.

abort
Simulate the effects of calling ext4_abort() for debugging purposes. This is normally used while remounting a file system which is already mounted.

auto_da_alloc|noauto_da_alloc
Many broken applications don’t use fsync() when replacing existing files via patterns such as

fd = open(“foo.new”)/write(fd,…)/close(fd)/ rename(“foo.new”, “foo”)

or worse yet

fd = open(“foo”, O_TRUNC)/write(fd,…)/close(fd).

If auto_da_alloc is enabled, ext4 will detect the replace-via-rename and replace-via-truncate patterns and force that any delayed allocation blocks are allocated such that at the next journal commit, in the default data=ordered mode, the data blocks of the new file are forced to disk before the rename() operation is committed. This provides roughly the same level of guarantees as ext3, and avoids the “zero-length” problem that can happen when a system crashes before the delayed allocation blocks are forced to disk.

noinit_itable
Do not initialize any uninitialized inode table blocks in the background. This feature may be used by installation CD’s so that the install process can complete as quickly as possible; the inode table initialization process would then be deferred until the next time the file system is mounted.

init_itable=n
The lazy itable init code will wait n times the number of milliseconds it took to zero out the previous block group’s inode table. This minimizes the impact on system performance while the file system’s inode table is being initialized.

discard/nodiscard
Controls whether ext4 should issue discard/TRIM commands to the underlying block device when blocks are freed. This is useful for SSD devices and sparse/thinly-provisioned LUNs, but it is off by default until sufficient testing has been done.

block_validity/noblock_validity
This option enables/disables the in-kernel facility for tracking file system metadata blocks within internal data structures. This allows multi- block allocator and other routines to quickly locate extents which might overlap with file system metadata blocks. This option is intended for debugging purposes and since it negatively affects the performance, it is off by default.

dioread_lock/dioread_nolock
Controls whether or not ext4 should use the DIO read locking. If the dioread_nolock option is specified ext4 will allocate uninitialized extent before buffer write and convert the extent to initialized after IO completes. This approach allows ext4 code to avoid using inode mutex, which improves scalability on high speed storages. However this does not work with data journaling and dioread_nolock option will be ignored with kernel warning. Note that dioread_nolock code path is only used for extent-based files. Because of the restrictions this options comprises it is off by default (e.g. dioread_lock).

max_dir_size_kb=n
This limits the size of the directories so that any attempt to expand them beyond the specified limit in kilobytes will cause an ENOSPC error. This is useful in memory-constrained environments, where a very large directory can cause severe performance problems or even provoke the Out Of Memory killer. (For example, if there is only 512 MB memory available, a 176 MB directory may seriously cramp the system’s style.)

i_version
Enable 64-bit inode version support. This option is off by default.

nombcache
This option disables use of mbcache for extended attribute deduplication. On systems where extended attributes are rarely or never shared between files, use of mbcache for deduplication adds unnecessary computational overhead.

prjquota
The prjquota mount option enables project quota support on the file system. You need the quota utilities to actually enable and manage the quota system. This mount option requires the project file system feature.

FILE ATTRIBUTES

The ext2, ext3, and ext4 file systems support setting the following file attributes on Linux systems using the chattr(1) utility:

a - append only

A - no atime updates

d - no dump

D - synchronous directory updates

i - immutable

S - synchronous updates

u - undeletable

In addition, the ext3 and ext4 file systems support the following flag:

j - data journaling

Finally, the ext4 file system also supports the following flag:

e - extents format

For descriptions of these attribute flags, please refer to the chattr(1) man page.

KERNEL SUPPORT

This section lists the file system driver (e.g., ext2, ext3, ext4) and upstream kernel version where a particular file system feature was supported. Note that in some cases the feature was present in earlier kernel versions, but there were known, serious bugs. In other cases the feature may still be considered in an experimental state. Finally, note that some distributions may have backported features into older kernels; in particular the kernel versions in certain “enterprise distributions” can be extremely misleading.

filetype
ext2, 2.2.0

sparse_super
ext2, 2.2.0

large_file
ext2, 2.2.0

has_journal
ext3, 2.4.15

ext_attr
ext2/ext3, 2.6.0

dir_index
ext3, 2.6.0

resize_inode
ext3, 2.6.10 (online resizing)

64bit
ext4, 2.6.28

dir_nlink
ext4, 2.6.28

extent
ext4, 2.6.28

extra_isize
ext4, 2.6.28

flex_bg
ext4, 2.6.28

huge_file
ext4, 2.6.28

meta_bg
ext4, 2.6.28

uninit_bg
ext4, 2.6.28

mmp
ext4, 3.0

bigalloc
ext4, 3.2

quota
ext4, 3.6

inline_data
ext4, 3.8

sparse_super2
ext4, 3.16

metadata_csum
ext4, 3.18

encrypt
ext4, 4.1

metadata_csum_seed
ext4, 4.4

project
ext4, 4.5

ea_inode
ext4, 4.13

large_dir
ext4, 4.13

casefold
ext4, 5.2

verity
ext4, 5.4

stable_inodes
ext4, 5.5

97 - Linux cli command deb-substvars

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command deb-substvars and provides detailed information about the command deb-substvars, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the deb-substvars.

NAME 🖥️ deb-substvars 🖥️

substvars - Debian source substitution variables

SYNOPSIS

debian/substvars, debian/binary-package.substvars, variables

DESCRIPTION

Before dpkg-source, dpkg-gencontrol and dpkg-genchanges write their control information (to the source control file .dsc for dpkg-source and to standard output for dpkg-gencontrol and dpkg-genchanges) they perform some variable substitutions on the output file.

Variable Syntax

A variable substitution has the form ${variable-name}. Variable names consist of alphanumerics (a-zA-Z0-9), hyphens (-) and colons (:) and start with an alphanumeric, and are case-sensitive, even though they might refer to other entities which are case-preserving. Variable substitutions are performed repeatedly until none are left; the full text of the field after the substitution is rescanned to look for more substitutions.

File Syntax

Substitution variables can be specified in a file. These files consist of lines of the form name**=value or name?=**value. The = operator assigns a normal substitution variable, while the ?= operator (since dpkg 1.21.8) assigns an optional substitution variable which will emit no warnings even if unused. Trailing whitespace on each line, blank lines, and lines starting with a # symbol (comments) are ignored.

Substitution

Variables can be set using the -V common option. They can be also specified in the file debian/substvars (or whatever other file is specified using the -T common option).

After all the substitutions have been done each occurrence of the string ${} (which is not an actual substitution variable) is replaced with a $ sign. This can be used as an escape sequence such as ${}{VARIABLE} which will end up as ${VARIABLE} on the output.

If a variable is referred to but not defined it generates a warning and an empty value is assumed.

While variable substitution is done on all control fields, some of those fields are used and needed during the build when the substitution did not yet occur. That’s why you can’t use variables in the Package, Source and Architecture fields.

Variable substitution happens on the content of the fields after they have been parsed, thus if you want a variable to expand over multiple lines you do not have to include a space after the newline. This is done implicitly when the field is output. For example, if the variable ${Description} is set to “foo is bar.${Newline}foo is great.” and if you have the following field:

Description: foo application ${Description} . More text.

It will result in:

Description: foo application foo is bar. foo is great. . More text.

Built-in Variable

Additionally, the following standard variables are always available:

Arch
The current host architecture (i.e. the architecture the package is being built for, the equivalent of DEB_HOST_ARCH).

vendor:Name
The current vendor name (since dpkg 1.20.0). This value comes from the Vendor field for the current vendor’s origin file, as dpkg-vendor (1) would retrieve it.

vendor:Id
The current vendor ID (since dpkg 1.20.0). This is just the lowercase variant of vendor:Name.

source:Version
The source package version (since dpkg 1.13.19).

source:Upstream-Version
The upstream source package version, including the Debian version epoch if any (since dpkg 1.13.19).

binary:Version
The binary package version (which may differ from source:Version in a binNMU for example; since dpkg 1.13.19).

Source-Version
The source package version (from the changelog file). This variable is now obsolete and emits an error when used as its meaning is different from its function, please use the source:Version or binary:Version as appropriate.

source:Synopsis
The source package synopsis, extracted from the source stanza Description field, if it exists (since dpkg 1.19.0).

source:Extended-Description
The source package extended description, extracted from the source stanza Description field, if it exists (since dpkg 1.19.0).

Installed-Size
The approximate total size of the package’s installed files. This value is copied into the corresponding control file field; setting it will modify the value of that field. If this variable is not set dpkg-gencontrol will compute the default value by accumulating the size of each regular file and symlink rounded to 1 KiB used units, and a baseline of 1 KiB for any other filesystem object type. With hardlinks only being counted once as a regular file. Note: Take into account that this can only ever be an approximation, as the actual size used on the installed system will depend greatly on the filesystem used and its parameters, which might end up using either more or less space than the specified in this field.

Extra-Size
Additional disk space used when the package is installed. If this variable is set its value is added to that of the Installed-Size variable (whether set explicitly or using the default value) before it is copied into the Installed-Size control file field.

S:field-name
The value of the source stanza field field-name (which must be given in the canonical capitalization; since dpkg 1.18.11). Setting these variables has no effect other than on places where they are expanded explicitly. These variables are only available when generating binary control files.

F:field-name
The value of the output field field-name (which must be given in the canonical capitalization). Setting these variables has no effect other than on places where they are expanded explicitly.

Format
The .changes file format version generated by this version of the source packaging scripts. If you set this variable the contents of the Format field in the .changes file will change too.

Newline, Space, Tab
These variables each hold the corresponding character.

shlibs:dependencyfield
Variable settings with names of this form are generated by dpkg-shlibdeps.

dpkg:Upstream-Version
The upstream version of dpkg (since dpkg 1.13.19).

dpkg:Version
The full version of dpkg (since dpkg 1.13.19).

FILES

debian/substvars
List of substitution variables and values.

98 - Linux cli command pam_env.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command pam_env.conf and provides detailed information about the command pam_env.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the pam_env.conf.

NAME 🖥️ pam_env.conf 🖥️

the environment variables config files

DESCRIPTION

The /etc/security/pam_env.conf file specifies the environment variables to be set, unset or modified by pam_env(8). When someone logs in, this file is read and the environment variables are set according.

Each line starts with the variable name, there are then two possible options for each variable DEFAULT and OVERRIDE. DEFAULT allows an administrator to set the value of the variable to some default value, if none is supplied then the empty string is assumed. The OVERRIDE option tells pam_env that it should enter in its value (overriding the default value) if there is one to use. When OVERRIDE is not used, "" is assumed and no override will be done.

VARIABLE [DEFAULT=[value]] [OVERRIDE=[value]]

(Possibly non-existent) environment variables may be used in values using the ${string} syntax and (possibly non-existent) PAM_ITEMs as well as HOME and SHELL may be used in values using the @{string} syntax. Both the $ and @ characters can be backslash escaped to be used as literal values values can be delimited with “”, escaped " not supported. Note that many environment variables that you would like to use may not be set by the time the module is called. For example, ${HOME} is used below several times, but many PAM applications dont make it available by the time you need it. The special variables @{HOME} and @{SHELL} are expanded to the values for the user from his passwd entry.

The “#” character at start of line (no space at front) can be used to mark this line as a comment line.

The /etc/environment file specifies the environment variables to be set. The file must consist of simple NAME=VALUE pairs on separate lines. The pam_env(8) module will read the file after the pam_env.conf file.

EXAMPLES

These are some example lines which might be specified in /etc/security/pam_env.conf.

Set the REMOTEHOST variable for any hosts that are remote, default to “localhost” rather than not being set at all

  REMOTEHOST     DEFAULT=localhost OVERRIDE=@{PAM_RHOST}

Set the DISPLAY variable if it seems reasonable

  DISPLAY        DEFAULT=${REMOTEHOST}:0.0 OVERRIDE=${DISPLAY}

Now some simple variables

  PAGER          DEFAULT=less
      MANPAGER       DEFAULT=less
      LESS           DEFAULT="M q e h15 z23 b80"
      NNTPSERVER     DEFAULT=localhost
      PATH           DEFAULT=${HOME}/bin:/usr/local/bin:/bin\
      :/usr/bin:/usr/local/bin/X11:/usr/bin/X11
      XDG_DATA_HOME  DEFAULT=@{HOME}/share/

Silly examples of escaped variables, just to show how they work.

  DOLLAR         DEFAULT=\$
      DOLLARDOLLAR   DEFAULT=        OVERRIDE=\$${DOLLAR}
      DOLLARPLUS     DEFAULT=\${REMOTEHOST}${REMOTEHOST}
      ATSIGN         DEFAULT=""      OVERRIDE=\@

AUTHOR

pam_env was written by Dave Kinchlea <[email protected]>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

99 - Linux cli command lmhosts

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command lmhosts and provides detailed information about the command lmhosts, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the lmhosts.

NAME 🖥️ lmhosts 🖥️

The Samba NetBIOS hosts file

SYNOPSIS

lmhosts is the samba(7) NetBIOS name to IP address mapping file.

DESCRIPTION

This file is part of the samba(7) suite.

lmhosts is the Samba NetBIOS name to IP address mapping file. It is very similar to the /etc/hosts file format, except that the hostname component must correspond to the NetBIOS naming format.

FILE FORMAT

It is an ASCII file containing one line for NetBIOS name. The two fields on each line are separated from each other by white space. Any entry beginning with # is ignored. Each line in the lmhosts file contains the following information:

·
IP Address - in dotted decimal format.
·
NetBIOS Name - This name format is a maximum fifteen character host name, with an optional trailing # character followed by the NetBIOS name type as two hexadecimal digits.
If the trailing # is omitted then the given IP address will be returned for all names that match the given name, whatever the NetBIOS name type in the lookup.

An example follows:

# Sample Samba lmhosts file.
#
192.9.200.1	TESTPC
192.9.200.20	NTSERVER#20
192.9.200.21	SAMBASERVER

Contains three IP to NetBIOS name mappings. The first and third will be returned for any queries for the names “TESTPC” and “SAMBASERVER” respectively, whatever the type component of the NetBIOS name requested.

The second mapping will be returned only when the “0x20” name type for a name “NTSERVER” is queried. Any other name type will not be resolved.

The default location of the lmhosts file is in the same directory as the smb.conf(5) file.

FILES

lmhosts is loaded from the configuration directory. This is usually /etc/samba or /usr/local/samba/lib.

VERSION

This man page is part of version 4.20.1-Debian of the Samba suite.

AUTHOR

The original Samba software and related utilities were created by Andrew Tridgell. Samba is now developed by the Samba Team as an Open Source project similar to the way the Linux kernel is developed.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

100 - Linux cli command proc_sys_debug

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_sys_debug and provides detailed information about the command proc_sys_debug, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_sys_debug.

NAME 🖥️ proc_sys_debug 🖥️

debug

DESCRIPTION

/proc/sys/debug/
This directory may be empty.

101 - Linux cli command ts.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ts.conf and provides detailed information about the command ts.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ts.conf.

NAME 🖥️ ts.conf 🖥️

Configuration file for tslib, controlling touch screens for embedded devices.

DESCRIPTION

The idea of tslib is to have a core library that provides standard services, and a set of plugins to manage the conversion and filtering as needed.

The plugins for a particular touchscreen are loaded automatically by the library under the control of a static configuration file, /etc/ts.conf. /etc/ts.conf gives the library basic configuration information. Each line specifies one module, and the parameters for that module. The modules are loaded in order, with the first one processing the touchscreen data first. For example:

module_raw input module variance delta=30 module dejitter delta=100 module linear

ENVIRONMENT VARIABLES

Latest versions of the Xorg tslib input driver use hal to configure the touchscreen within Xorg. Environment variables are only needed for the tslib commands.

TSLIB_TSDEVICE

If the default touchscreen device cannot be found, set the TSLIB_TSDEVICE environment variable to the touchscreen device to use.
Default when using ts_setup(): We try to open /dev/input/ts, /dev/input/touchscreen and /dev/touchscreen/ucb1x00 and on Linux, we then scan /dev/input/event* for the first device with property INPUT_PROP_DIRECT.

TSLIB_CONSOLEDEVICE

Tslib default console device.
Default: /dev/tty

TSLIB_CALIBFILE

Stores calibration data obtained using ts_calibrate.
Default: /etc/pointercal

TSLIB_CONFFILE

Set a different location for the ts.conf configuration file itself.
Default; /etc/ts.conf.

TSLIB_FBDEVICE

Framebuffer device to use for the touchscreen support.
Default: /dev/fb0.

TSLIB_PLUGINDIR

Plugin directory for tslib.
Default: /usr/lib/$triplet/ts0/ where triplet is the MultiArch path, e.g. arm-linux-gnueabi.

MODULE PARAMETERS

dejitter

Removes jitter on the X and Y co-ordinates. This is achieved by applying a weighted smoothing filter. The latest samples have most weight; earlier samples have less weight. This allows one to achieve 1:1 input->output rate.
·
delta
Squared distance between two samples ((X2-X1)^2 + (Y2-Y1)^2) that defines the quick motion threshold. If the pen moves quick, it is not feasible to smooth pen motion, besides quick motion is not precise anyway; so if quick motion is detected the module just discards the backlog and simply copies input to output.

linear

Linear scaling module, primarily used for conversion of touch screen co-ordinates to screen co-ordinates.
·
rot
Rotation of touch coorinates. 0=no, 1=CW, 2=UD, 3=CCW. Default: the screen-rotation that was used with ts_calibrate (-r option).
·
xyswap
Interchange the X and Y co-ordinates – no longer used or needed if the new linear calibration utility ts_calibrate is used.
·
pressure_offset
Offset applied to the pressure value. Default: 0.
·
pressure_mul
Factor to multiply the pressure value with. Default: 1.
·
pressure_div
Value to divide the pressure value by. Default: 1.

iir

Infinite impulse response filter. Similar to dejitter, this is a smoothing filter to remove low-level noise. There is a trade-off between noise removal (smoothing) and responsiveness. The parameters N and D specify the level of smoothing in the form of a fraction (N/D).
·
N
numerator of the smoothing fraction. Default: 0.
·
D
denominator of the smoothing fraction. Default: 1.

pthres

Pressure threshold filter. Given a release is always pressure 0 and a press is always >= 1, this discards samples below / above the specified pressure threshold.
·
pmin
Minimum pressure value for a sample to be valid. Default: 1.
·
pmax
Maximum pressure value for a sample to be valid. Default: INT_MAX.

debounce

Simple debounce mechanism that drops input events for the specified time after a touch gesture stopped.
·
drop_threshold
drop events up to this number of milliseconds after the last release event. Default: 0.

skip

Skip nhead samples after press and ntail samples before release. This should help if for the device the first or last samples are unreliable.
·
nhead
Number of events to drop after pressure. Default: 1.
·
ntail
Number of events to drop before release. Default: 1.

median

Similar to what the variance filter does, the median filter suppresses spikes in the gesture.
·
depth
Number of samples to apply the median filter to. Default: 3.

invert

Invert values in X and/or Y direction around a given value.
·
x0
X-axis (horizontal) value around which to invert. Default: 0.
·
y0
Y-axis (horizontal) value around which to invert. Default: 0.

lowpass

simple exponential averaging lowpass filter
·
factor
floating point values betwenn 0 and 1. Default: 0.4.
·
threshold
x or y minimum distance between two samples to start applying the filter. Default: 2.

evthres

Number of samples needed from the device after considered a valid touch. This filter will drop a tapping when too little samples are between “down” and “up”.
·
N
Minimum number of events needed between “down” and “up”. Default: 5.

variance

Tries to do it’s best in order to filter out random noise coming from touchscreen ADCs. This is achieved by limiting the sample movement speed to some value (e.g. the pen is not supposed to move quicker than some threshold).
This is a greedy filter, e.g. it gives less samples on output than receives on input. There is no multitouch support for this filter.
·
delta
Set the squared distance in touchscreen units between previous and current pen position (e.g. (X2-X1)^2 + (Y2-Y1)^2). This defines the criteria for determining whenever two samples are near or far to each other.
If the distance between previous and current sample is far, the sample is marked as potential noise. This doesn’t mean yet that it will be discarded; if the next reading will be close to it, this will be considered just a regular quick motion event, and it will sneak to the next layer. Also, if the sample after the potential noise is far from both previously discussed samples, this is also considered a quick motion event and the sample sneaks into the output stream.

hardware support

On Linux, use the module_raw input if you can. The other raw access modules are device specific userspace drivers. If you need one of those, enable it explicitly when building tslib. The list of modules enabled by default might shrink in the future. module_raw input supports multitouch (MT) too.

module_raw	supported devices	interface	platforms	MT	how to enable
input	all with Linux evdev drivers	any (driver) /dev/input/	Linux, FreeBSD	yes	enabled by default
arctic2	IBM Arctic II	.	Linux, BSD, Hurd, Haiku	no	--enable-arctic2
collie	Sharp Zaurus SL-5000d/SL-5500	.	Linux, BSD, Hurd, Haiku	no	--enable-collie
corgi	Sharp Zaurus SL-C700	.	Linux, BSD, Hurd, Haiku	no	--enable-corgi
dmc_dus3000	DMC DUS Series (DUS3000, ...)	UART	Linux	no	--enable-dmc_dus3000
dmc	DMC (others)	.	Linux, BSD, Hurd, Haiku	no	--enable-dmc
galax	eGalax 100, 112, 210	any (driver)	Linux, BSD	no	--enable-galax
h3600	Compaq IPAQ	.	Linux, BSD, Hurd, Haiku	no	--enable-h3600
mk712	Hitachi Webpad	.	Linux, BSD, Hurd, Haiku	no	--enable-mk712
tatung	Tatung Webpad	.	Linux, BSD, Hurd, Haiku	no	--enable-tatung
touchkit	Touchkit SAT4000UR	RS232	Linux, BSD, Hurd	no	enabled by default
ucb1x00	UCB1x00 Touchscreens	.	Linux, BSD, Hurd, Haiku	no	--enable-ucb1x00
waveshare	Waveshare Touchscreens	/dev/hidrawX	Linux	no	enabled by default
cy8mrln_palmpre	in Palm Pre/Pre Plus/Pre 2	.	Linux	no	--enable-cy8mrln-palmpre
one_wire_ts_input	FriendlyARM one-wire touch screen	.	Linux	no	--enable-one-wire-ts-input
input_evdev	Linux evdev drivers (libevdev)	.	Linux	yes	--enable-input-evdev

102 - Linux cli command gitformat-commit-graph

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitformat-commit-graph and provides detailed information about the command gitformat-commit-graph, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitformat-commit-graph.

NAME 🖥️ gitformat-commit-graph 🖥️

commit-graph - Git commit-graph format

SYNOPSIS

$GIT_DIR/objects/info/commit-graph
$GIT_DIR/objects/info/commit-graphs/*

DESCRIPTION

The Git commit-graph stores a list of commit OIDs and some associated metadata, including:

·
The generation number of the commit.

·
The root tree OID.

·
The commit date.

·
The parents of the commit, stored using positional references within the graph file.

·
The Bloom filter of the commit carrying the paths that were changed between the commit and its first parent, if requested.

These positional references are stored as unsigned 32-bit integers corresponding to the array position within the list of commit OIDs. Due to some special constants we use to track parents, we can store at most (1 << 30) + (1 << 29) + (1 << 28) - 1 (around 1.8 billion) commits.

COMMIT-GRAPH FILES HAVE THE FOLLOWING FORMAT:

In order to allow extensions that add extra data to the graph, we organize the body into “chunks” and provide a binary lookup table at the beginning of the body. The header includes certain values, such as number of chunks and hash type.

All multi-byte numbers are in network byte order.

4-byte signature: The signature is: {C, G, P, H}

1-byte version number: Currently, the only valid version is 1.

1-byte Hash Version We infer the hash length (H) from this value: 1 => SHA-1 2 => SHA-256 If the hash type does not match the repositorys hash algorithm, the commit-graph file should be ignored with a warning presented to the user.

1-byte number (C) of “chunks”

1-byte number (B) of base commit-graphs We infer the length (H*B) of the Base Graphs chunk from this value.

CHUNK LOOKUP:

(C + 1) * 12 bytes listing the table of contents for the chunks: First 4 bytes describe the chunk id. Value 0 is a terminating label. Other 8 bytes provide the byte-offset in current file for chunk to start. (Chunks are ordered contiguously in the file, so you can infer the length using the next chunk position if necessary.) Each chunk ID appears at most once.

The CHUNK LOOKUP matches the table of contents from the chunk-based file format, see linkgit:gitformat-chunk[5]

The remaining data in the body is described one chunk at a time, and these chunks may be given in any order. Chunks are required unless otherwise specified.

CHUNK DATA:

OID Fanout (ID: {O, I, D, F}) (256 * 4 bytes)

The ith entry, F[i], stores the number of OIDs with first byte at most i. Thus F[255] stores the total number of commits (N).

OID Lookup (ID: {O, I, D, L}) (N * H bytes)

The OIDs for all commits in the graph, sorted in ascending order.

Commit Data (ID: {C, D, A, T }) (N * (H + 16) bytes)

·
The first H bytes are for the OID of the root tree.
·
The next 8 bytes are for the positions of the first two parents of the ith commit. Stores value 0x70000000 if no parent in that position. If there are more than two parents, the second value has its most-significant bit on and the other bits store an array position into the Extra Edge List chunk.
·
The next 8 bytes store the topological level (generation number v1) of the commit and the commit time in seconds since EPOCH. The generation number uses the higher 30 bits of the first 4 bytes, while the commit time uses the 32 bits of the second 4 bytes, along with the lowest 2 bits of the lowest byte, storing the 33rd and 34th bit of the commit time.

Generation Data (ID: {G, D, A, 2 }) (N * 4 bytes) [Optional]

·
This list of 4-byte values store corrected commit date offsets for the commits, arranged in the same order as commit data chunk.
·
If the corrected commit date offset cannot be stored within 31 bits, the value has its most-significant bit on and the other bits store the position of corrected commit date into the Generation Data Overflow chunk.
·
Generation Data chunk is present only when commit-graph file is written by compatible versions of Git and in case of split commit-graph chains, the topmost layer also has Generation Data chunk.

Generation Data Overflow (ID: {G, D, O, 2 }) [Optional]

·
This list of 8-byte values stores the corrected commit date offsets for commits with corrected commit date offsets that cannot be stored within 31 bits.
·
Generation Data Overflow chunk is present only when Generation Data chunk is present and atleast one corrected commit date offset cannot be stored within 31 bits.

Extra Edge List (ID: {E, D, G, E}) [Optional]

This list of 4-byte values store the second through nth parents for all octopus merges. The second parent value in the commit data stores an array position within this list along with the most-significant bit on. Starting at that array position, iterate through this list of commit positions for the parents until reaching a value with the most-significant bit on. The other bits correspond to the position of the last parent.

Bloom Filter Index (ID: {B, I, D, X}) (N * 4 bytes) [Optional]

·
The ith entry, BIDX[i], stores the number of bytes in all Bloom filters from commit 0 to commit i (inclusive) in lexicographic order. The Bloom filter for the i-th commit spans from BIDX[i-1] to BIDX[i] (plus header length), where BIDX[-1] is 0.
·
The BIDX chunk is ignored if the BDAT chunk is not present.

Bloom Filter Data (ID: {B, D, A, T}) [Optional]

·
It starts with header consisting of three unsigned 32-bit integers:
·
Version of the hash algorithm being used. We currently only support value 1 which corresponds to the 32-bit version of the murmur3 hash implemented exactly as described in https://en.wikipedia.org/wiki/MurmurHash#Algorithm and the double hashing technique using seed values 0x293ae76f and 0x7e646e2 as described in https://doi.org/10.1007/978-3-540-30494-4_26 “Bloom Filters in Probabilistic Verification”
·
The number of times a path is hashed and hence the number of bit positions that cumulatively determine whether a file is present in the commit.
·
The minimum number of bits b per entry in the Bloom filter. If the filter contains n entries, then the filter size is the minimum number of 64-bit words that contain n*b bits.
·
The rest of the chunk is the concatenation of all the computed Bloom filters for the commits in lexicographic order.
·
Note: Commits with no changes or more than 512 changes have Bloom filters of length one, with either all bits set to zero or one respectively.
·
The BDAT chunk is present if and only if BIDX is present.

Base Graphs List (ID: {B, A, S, E}) [Optional]

This list of H-byte hashes describe a set of B commit-graph files that form a commit-graph chain. The graph position for the ith commit in this files OID Lookup chunk is equal to i plus the number of commits in all base graphs. If B is non-zero, this chunk must exist.

TRAILER:

H-byte HASH-checksum of all of the above.

HISTORICAL NOTES:

The Generation Data (GDA2) and Generation Data Overflow (GDO2) chunks have the number 2 in their chunk IDs because a previous version of Git wrote possibly erroneous data in these chunks with the IDs “GDAT” and “GDOV”. By changing the IDs, newer versions of Git will silently ignore those older chunks and write the new information without trusting the incorrect data.

GIT

Part of the git(1) suite

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

103 - Linux cli command systemd.positive

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.positive and provides detailed information about the command systemd.positive, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.positive.

NAME 🖥️ systemd.positive 🖥️

trust-anchors.d, systemd.positive, systemd.negative - DNSSEC trust anchor configuration files

SYNOPSIS

/etc/dnssec-trust-anchors.d/*.positive

/run/dnssec-trust-anchors.d/*.positive

/usr/local/lib/dnssec-trust-anchors.d/*.positive

/usr/lib/dnssec-trust-anchors.d/*.positive

/etc/dnssec-trust-anchors.d/*.negative

/run/dnssec-trust-anchors.d/*.negative

/usr/local/lib/dnssec-trust-anchors.d/*.negative

/usr/lib/dnssec-trust-anchors.d/*.negative

DESCRIPTION

The DNSSEC trust anchor configuration files define positive and negative trust anchors systemd-resolved.service(8) bases DNSSEC integrity proofs on.

POSITIVE TRUST ANCHORS

Positive trust anchor configuration files contain DNSKEY and DS resource record definitions to use as base for DNSSEC integrity proofs. See RFC 4035, Section 4.4[1] for more information about DNSSEC trust anchors.

Positive trust anchors are read from files with the suffix .positive located in /etc/dnssec-trust-anchors.d/, /run/dnssec-trust-anchors.d/ and /usr/lib/dnssec-trust-anchors.d/. These directories are searched in the specified order, and a trust anchor file of the same name in an earlier path overrides a trust anchor files in a later path. To disable a trust anchor file shipped in /usr/lib/dnssec-trust-anchors.d/ it is sufficient to provide an identically-named file in /etc/dnssec-trust-anchors.d/ or /run/dnssec-trust-anchors.d/ that is either empty or a symlink to /dev/null (“masked”).

Positive trust anchor files are simple text files resembling DNS zone files, as documented in RFC 1035, Section 5[2]. One DS or DNSKEY resource record may be listed per line. Empty lines and lines starting with “#” or “;” are ignored, which may be used for commenting. A DS resource record is specified like in the following example:

. IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5

The first word specifies the domain, use “.” for the root domain. The domain may be specified with or without trailing dot, which is considered equivalent. The second word must be “IN” the third word “DS”. The following words specify the key tag, signature algorithm, digest algorithm, followed by the hex-encoded key fingerprint. See RFC 4034, Section 5[3] for details about the precise syntax and meaning of these fields.

Alternatively, DNSKEY resource records may be used to define trust anchors, like in the following example:

. IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=

The first word specifies the domain again, the second word must be “IN”, followed by “DNSKEY”. The subsequent words encode the DNSKEY flags, protocol and algorithm fields, followed by the key data encoded in Base64. See RFC 4034, Section 2[4] for details about the precise syntax and meaning of these fields.

If multiple DS or DNSKEY records are defined for the same domain (possibly even in different trust anchor files), all keys are used and are considered equivalent as base for DNSSEC proofs.

Note that systemd-resolved will automatically use a built-in trust anchor key for the Internet root domain if no positive trust anchors are defined for the root domain. In most cases it is hence unnecessary to define an explicit key with trust anchor files. The built-in key is disabled as soon as at least one trust anchor key for the root domain is defined in trust anchor files.

It is generally recommended to encode trust anchors in DS resource records, rather than DNSKEY resource records.

If a trust anchor specified via a DS record is found revoked it is automatically removed from the trust anchor database for the runtime. See RFC 5011[5] for details about revoked trust anchors. Note that systemd-resolved will not update its trust anchor database from DNS servers automatically. Instead, it is recommended to update the resolver software or update the new trust anchor via adding in new trust anchor files.

The current DNSSEC trust anchor for the Internets root domain is available at the IANA Trust Anchor and Keys[6] page.

NEGATIVE TRUST ANCHORS

Negative trust anchors define domains where DNSSEC validation shall be turned off. Negative trust anchor files are found at the same location as positive trust anchor files, and follow the same overriding rules. They are text files with the .negative suffix. Empty lines and lines whose first character is “;” are ignored. Each line specifies one domain name which is the root of a DNS subtree where validation shall be disabled. For example:

Reverse IPv4 mappings

10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
...
# Some custom domains
prod
stag

Negative trust anchors are useful to support private DNS subtrees that are not referenced from the Internet DNS hierarchy, and not signed.

RFC 7646[7] for details on negative trust anchors.

If no negative trust anchor files are configured a built-in set of well-known private DNS zone domains is used as negative trust anchors.

It is also possibly to define per-interface negative trust anchors using the DNSSECNegativeTrustAnchors= setting in systemd.network(5) files.

NOTES

RFC 4035, Section 4.4

https://tools.ietf.org/html/rfc4035#section-4.4

RFC 1035, Section 5

https://tools.ietf.org/html/rfc1035#section-5

RFC 4034, Section 5

https://tools.ietf.org/html/rfc4034#section-5

RFC 4034, Section 2

https://tools.ietf.org/html/rfc4034#section-2

RFC 5011

https://tools.ietf.org/html/rfc5011

IANA Trust Anchor and Keys

https://data.iana.org/root-anchors/root-anchors.xml

RFC 7646

https://tools.ietf.org/html/rfc7646

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

104 - Linux cli command proc_sys_dev

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_sys_dev and provides detailed information about the command proc_sys_dev, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_sys_dev.

NAME 🖥️ proc_sys_dev 🖥️

device-specific information

DESCRIPTION

/proc/sys/dev/
This directory contains device-specific information (e.g., dev/cdrom/info). On some systems, it may be empty.

105 - Linux cli command proc_pid_mountinfo

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_mountinfo and provides detailed information about the command proc_pid_mountinfo, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_mountinfo.

NAME 🖥️ proc_pid_mountinfo 🖥️

mount information

DESCRIPTION

/proc/pid/mountinfo (since Linux 2.6.26)
This file contains information about mounts in the process’s mount namespace (see mount_namespaces(7)). It supplies various information (e.g., propagation state, root of mount for bind mounts, identifier for each mount and its parent) that is missing from the (older) /proc/pid/mounts file, and fixes various other problems with that file (e.g., nonextensibility, failure to distinguish per-mount versus per-superblock options).

The file contains lines of the form:

36 35 98:0 /mnt1 /mnt2 rw,noatime master:1 - ext3 /dev/root rw,errors=continue
(1)(2)(3)   (4)   (5)      (6)      (7)   (8) (9)   (10)         (11)

The numbers in parentheses are labels for the descriptions below:

(1)
mount ID: a unique ID for the mount (may be reused after umount(2)).

(2)
parent ID: the ID of the parent mount (or of self for the root of this mount namespace’s mount tree).

If a new mount is stacked on top of a previous existing mount (so that it hides the existing mount) at pathname P, then the parent of the new mount is the previous mount at that location. Thus, when looking at all the mounts stacked at a particular location, the top-most mount is the one that is not the parent of any other mount at the same location. (Note, however, that this top-most mount will be accessible only if the longest path subprefix of P that is a mount point is not itself hidden by a stacked mount.)

If the parent mount lies outside the process’s root directory (see chroot(2)), the ID shown here won’t have a corresponding record in mountinfo whose mount ID (field 1) matches this parent mount ID (because mounts that lie outside the process’s root directory are not shown in mountinfo). As a special case of this point, the process’s root mount may have a parent mount (for the initramfs filesystem) that lies outside the process’s root directory, and an entry for that mount will not appear in mountinfo.

(3)
major:minor: the value of st_dev for files on this filesystem (see stat(2)).

(4)
root: the pathname of the directory in the filesystem which forms the root of this mount.

(5)
mount point: the pathname of the mount point relative to the process’s root directory.

(6)
mount options: per-mount options (see mount(2)).

(7)
optional fields: zero or more fields of the form “tag[:value]”; see below.

(8)
separator: the end of the optional fields is marked by a single hyphen.

(9)
filesystem type: the filesystem type in the form “type[.subtype]”.

(10)
mount source: filesystem-specific information or “none”.

(11)
super options: per-superblock options (see mount(2)).

Currently, the possible optional fields are shared, master, propagate_from, and unbindable. See mount_namespaces(7) for a description of these fields. Parsers should ignore all unrecognized optional fields.

For more information on mount propagation see Documentation/filesystems/sharedsubtree.rst (or Documentation/filesystems/sharedsubtree.txt before Linux 5.8) in the Linux kernel source tree.

106 - Linux cli command proc_kcore

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_kcore and provides detailed information about the command proc_kcore, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_kcore.

NAME 🖥️ proc_kcore 🖥️

physical memory

DESCRIPTION

/proc/kcore
This file represents the physical memory of the system and is stored in the ELF core file format. With this pseudo-file, and an unstripped kernel (/usr/src/linux/vmlinux) binary, GDB can be used to examine the current state of any kernel data structures.

The total length of the file is the size of physical memory (RAM) plus 4 KiB.

107 - Linux cli command systemd.exec

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.exec and provides detailed information about the command systemd.exec, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.exec.

NAME 🖥️ systemd.exec 🖥️

Execution environment configuration

SYNOPSIS

service.service, socket.socket, mount.mount, swap.swap

DESCRIPTION

Unit configuration files for services, sockets, mount points, and swap devices share a subset of configuration options which define the execution environment of spawned processes.

This man page lists the configuration options shared by these four unit types. See systemd.unit(5) for the common options of all unit configuration files, and systemd.service(5), systemd.socket(5), systemd.swap(5), and systemd.mount(5) for more information on the specific unit configuration files. The execution specific configuration options are configured in the [Service], [Socket], [Mount], or [Swap] sections, depending on the unit type.

In addition, options which control resources through Linux Control Groups (cgroups) are listed in systemd.resource-control(5). Those options complement options listed here.

IMPLICIT DEPENDENCIES

A few execution parameters result in additional, automatic dependencies to be added:

·
Units with WorkingDirectory=, RootDirectory=, RootImage=, RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory= or ConfigurationDirectory= set automatically gain dependencies of type Requires= and After= on all mount units required to access the specified paths. This is equivalent to having them listed explicitly in RequiresMountsFor=.

·
Similarly, units with PrivateTmp= enabled automatically get mount unit dependencies for all mounts required to access /tmp/ and /var/tmp/. They will also gain an automatic After= dependency on systemd-tmpfiles-setup.service(8).

·
Units whose standard output or error output is connected to journal or kmsg (or their combinations with console output, see below) automatically acquire dependencies of type After= on systemd-journald.socket.

·
Units using LogNamespace= will automatically gain ordering and requirement dependencies on the two socket units associated with [email protected] instances.

PATHS

The following settings may be used to change a services view of the filesystem. Please note that the paths must be absolute and must not contain a “..” path component.

ExecSearchPath=

Takes a colon separated list of absolute paths relative to which the executable used by the Exec*= (e.g. ExecStart=, ExecStop=, etc.) properties can be found. ExecSearchPath= overrides $PATH if $PATH is not supplied by the user through Environment=, EnvironmentFile= or PassEnvironment=. Assigning an empty string removes previous assignments and setting ExecSearchPath= to a value multiple times will append to the previous setting.
Added in version 250.

WorkingDirectory=

Takes a directory path relative to the services root directory specified by RootDirectory=, or the special value “~~”. Sets the working directory for executed processes. If set to “~~”, the home directory of the user specified in User= is used. If not set, defaults to the root directory when systemd is running as a system instance and the respective users home directory if run as user. If the setting is prefixed with the “-” character, a missing working directory is not considered fatal. If RootDirectory=/RootImage= is not set, then WorkingDirectory= is relative to the root of the system running the service manager. Note that setting this parameter might result in additional dependencies to be added to the unit (see above).

RootDirectory=

Takes a directory path relative to the hosts root directory (i.e. the root of the system running the service manager). Sets the root directory for executed processes, with the pivot_root(2) or chroot(2) system call. If this is used, it must be ensured that the process binary and all its auxiliary files are available in the new root. Note that setting this parameter might result in additional dependencies to be added to the unit (see above).
The MountAPIVFS= and PrivateUsers= settings are particularly useful in conjunction with RootDirectory=. For details, see below.
If RootDirectory=/RootImage= are used together with NotifyAccess= the notification socket is automatically mounted from the host into the root environment, to ensure the notification interface can work correctly.
Note that services using RootDirectory=/RootImage= will not be able to log via the syslog or journal protocols to the host logging infrastructure, unless the relevant sockets are mounted from the host, specifically:
The hosts os-release(5) file will be made available for the service (read-only) as /run/host/os-release. It will be updated automatically on soft reboot (see: systemd-soft-reboot.service(8)), in case the service is configured to survive it.
Example 1. Mounting logging sockets into root environment
BindReadOnlyPaths=/dev/log /run/systemd/journal/socket /run/systemd/journal/stdout
In place of the directory path a “.v/” versioned directory may be specified, see systemd.v(7) for details.
This option is only available for system services, or for services running in per-user instances of the service manager in which case PrivateUsers= is implicitly enabled (requires unprivileged user namespaces support to be enabled in the kernel via the “kernel.unprivileged_userns_clone=” sysctl).

RootImage=

Takes a path to a block device node or regular file as argument. This call is similar to RootDirectory= however mounts a file system hierarchy from a block device node or loopback file instead of a directory. The device node or file system image file needs to contain a file system without a partition table, or a file system within an MBR/MS-DOS or GPT partition table with only a single Linux-compatible partition, or a set of file systems within a GPT partition table that follows the Discoverable Partitions Specification[1].
When DevicePolicy= is set to “closed” or “strict”, or set to “auto” and DeviceAllow= is set, then this setting adds /dev/loop-control with rw mode, “block-loop” and “block-blkext” with rwm mode to DeviceAllow=. See systemd.resource-control(5) for the details about DevicePolicy= or DeviceAllow=. Also, see PrivateDevices= below, as it may change the setting of DevicePolicy=.
Units making use of RootImage= automatically gain an After= dependency on systemd-udevd.service.
The hosts os-release(5) file will be made available for the service (read-only) as /run/host/os-release. It will be updated automatically on soft reboot (see: systemd-soft-reboot.service(8)), in case the service is configured to survive it.
In place of the image path a “.v/” versioned directory may be specified, see systemd.v(7) for details.
This option is only available for system services and is not supported for services running in per-user instances of the service manager.
Added in version 233.

RootImageOptions=

Takes a comma-separated list of mount options that will be used on disk images specified by RootImage=. Optionally a partition name can be prefixed, followed by colon, in case the image has multiple partitions, otherwise partition name “root” is implied. Options for multiple partitions can be specified in a single line with space separators. Assigning an empty string removes previous assignments. Duplicated options are ignored. For a list of valid mount options, please refer to mount(8).
Valid partition names follow the Discoverable Partitions Specification[1]: root, usr, home, srv, esp, xbootldr, tmp, var.
This option is only available for system services and is not supported for services running in per-user instances of the service manager.
Added in version 247.

RootEphemeral=

Takes a boolean argument. If enabled, executed processes will run in an ephemeral copy of the root directory or root image. The ephemeral copy is placed in /var/lib/systemd/ephemeral-trees/ while the service is active and is cleaned up when the service is stopped or restarted. If RootDirectory= is used and the root directory is a subvolume, the ephemeral copy will be created by making a snapshot of the subvolume.
To make sure making ephemeral copies can be made efficiently, the root directory or root image should be located on the same filesystem as /var/lib/systemd/ephemeral-trees/. When using RootEphemeral= with root directories, btrfs(5) should be used as the filesystem and the root directory should ideally be a subvolume which systemd can snapshot to make the ephemeral copy. For root images, a filesystem with support for reflinks should be used to ensure an efficient ephemeral copy.
This option is only available for system services and is not supported for services running in per-user instances of the service manager.
Added in version 254.

RootHash=

Takes a data integrity (dm-verity) root hash specified in hexadecimal, or the path to a file containing a root hash in ASCII hexadecimal format. This option enables data integrity checks using dm-verity, if the used image contains the appropriate integrity data (see above) or if RootVerity= is used. The specified hash must match the root hash of integrity data, and is usually at least 256 bits (and hence 64 formatted hexadecimal characters) long (in case of SHA256 for example). If this option is not specified, but the image file carries the “user.verity.roothash” extended file attribute (see xattr(7)), then the root hash is read from it, also as formatted hexadecimal characters. If the extended file attribute is not found (or is not supported by the underlying file system), but a file with the .roothash suffix is found next to the image file, bearing otherwise the same name (except if the image has the .raw suffix, in which case the root hash file must not have it in its name), the root hash is read from it and automatically used, also as formatted hexadecimal characters.
If the disk image contains a separate /usr/ partition it may also be Verity protected, in which case the root hash may configured via an extended attribute “user.verity.usrhash” or a .usrhash file adjacent to the disk image. Theres currently no option to configure the root hash for the /usr/ file system via the unit file directly.
This option is only available for system services and is not supported for services running in per-user instances of the service manager.
Added in version 246.

RootHashSignature=

Takes a PKCS7 signature of the RootHash= option as a path to a DER-encoded signature file, or as an ASCII base64 string encoding of a DER-encoded signature prefixed by “base64:”. The dm-verity volume will only be opened if the signature of the root hash is valid and signed by a public key present in the kernel keyring. If this option is not specified, but a file with the .roothash.p7s suffix is found next to the image file, bearing otherwise the same name (except if the image has the .raw suffix, in which case the signature file must not have it in its name), the signature is read from it and automatically used.
If the disk image contains a separate /usr/ partition it may also be Verity protected, in which case the signature for the root hash may configured via a .usrhash.p7s file adjacent to the disk image. Theres currently no option to configure the root hash signature for the /usr/ via the unit file directly.
This option is only available for system services and is not supported for services running in per-user instances of the service manager.
Added in version 246.

RootVerity=

Takes the path to a data integrity (dm-verity) file. This option enables data integrity checks using dm-verity, if RootImage= is used and a root-hash is passed and if the used image itself does not contain the integrity data. The integrity data must be matched by the root hash. If this option is not specified, but a file with the .verity suffix is found next to the image file, bearing otherwise the same name (except if the image has the .raw suffix, in which case the verity data file must not have it in its name), the verity data is read from it and automatically used.
This option is supported only for disk images that contain a single file system, without an enveloping partition table. Images that contain a GPT partition table should instead include both root file system and matching Verity data in the same image, implementing the Discoverable Partitions Specification[1].
This option is only available for system services and is not supported for services running in per-user instances of the service manager.
Added in version 246.

RootImagePolicy=, MountImagePolicy=, ExtensionImagePolicy=

Takes an image policy string as per systemd.image-policy(7) to use when mounting the disk images (DDI) specified in RootImage=, MountImage=, ExtensionImage=, respectively. If not specified the following policy string is the default for RootImagePolicy= and MountImagePolicy:
root=verity+signed+encrypted+unprotected+absent:
usr=verity+signed+encrypted+unprotected+absent:
home=encrypted+unprotected+absent:
srv=encrypted+unprotected+absent:
tmp=encrypted+unprotected+absent:
var=encrypted+unprotected+absent
The default policy for ExtensionImagePolicy= is:
root=verity+signed+encrypted+unprotected+absent:
usr=verity+signed+encrypted+unprotected+absent
Added in version 254.

MountAPIVFS=

Takes a boolean argument. If on, a private mount namespace for the units processes is created and the API file systems /proc/, /sys/, /dev/ and /run/ (as an empty “tmpfs”) are mounted inside of it, unless they are already mounted. Note that this option has no effect unless used in conjunction with RootDirectory=/RootImage= as these four mounts are generally mounted in the host anyway, and unless the root directory is changed, the private mount namespace will be a 1:1 copy of the hosts, and include these four mounts. Note that the /dev/ file system of the host is bind mounted if this option is used without PrivateDevices=. To run the service with a private, minimal version of /dev/, combine this option with PrivateDevices=.
In order to allow propagating mounts at runtime in a safe manner, /run/systemd/propagate/ on the host will be used to set up new mounts, and /run/host/incoming/ in the private namespace will be used as an intermediate step to store them before being moved to the final mount point.
Added in version 233.

ProtectProc=

Takes one of “noaccess”, “invisible”, “ptraceable” or “default” (which it defaults to). When set, this controls the “hidepid=” mount option of the “procfs” instance for the unit that controls which directories with process metainformation (/proc/PID) are visible and accessible: when set to “noaccess” the ability to access most of other users process metadata in /proc/ is taken away for processes of the service. When set to “invisible” processes owned by other users are hidden from /proc/. If “ptraceable” all processes that cannot be **ptrace()**ed by a process are hidden to it. If “default” no restrictions on /proc/ access or visibility are made. For further details see The /proc Filesystem[2]. It is generally recommended to run most system services with this option set to “invisible”. This option is implemented via file system namespacing, and thus cannot be used with services that shall be able to install mount points in the host file system hierarchy. Note that the root user is unaffected by this option, so to be effective it has to be used together with User= or DynamicUser=yes, and also without the “CAP_SYS_PTRACE” capability, which also allows a process to bypass this feature. It cannot be used for services that need to access metainformation about other users processes. This option implies MountAPIVFS=.
If the kernel doesnt support per-mount point hidepid= mount options this setting remains without effect, and the units processes will be able to access and see other process as if the option was not used.
This option is only available for system services and is not supported for services running in per-user instances of the service manager.
Added in version 247.

ProcSubset=

Takes one of “all” (the default) and “pid”. If “pid”, all files and directories not directly associated with process management and introspection are made invisible in the /proc/ file system configured for the units processes. This controls the “subset=” mount option of the “procfs” instance for the unit. For further details see The /proc Filesystem[2]. Note that Linux exposes various kernel APIs via /proc/, which are made unavailable with this setting. Since these APIs are used frequently this option is useful only in a few, specific cases, and is not suitable for most non-trivial programs.
Much like ProtectProc= above, this is implemented via file system mount namespacing, and hence the same restrictions apply: it is only available to system services, it disables mount propagation to the host mount table, and it implies MountAPIVFS=. Also, like ProtectProc= this setting is gracefully disabled if the used kernel does not support the “subset=” mount option of “procfs”.
Added in version 247.

BindPaths=, BindReadOnlyPaths=

Configures unit-specific bind mounts. A bind mount makes a particular file or directory available at an additional place in the units view of the file system. Any bind mounts created with this option are specific to the unit, and are not visible in the hosts mount table. This option expects a whitespace separated list of bind mount definitions. Each definition consists of a colon-separated triple of source path, destination path and option string, where the latter two are optional. If only a source path is specified the source and destination is taken to be the same. The option string may be either “rbind” or “norbind” for configuring a recursive or non-recursive bind mount. If the destination path is omitted, the option string must be omitted too. Each bind mount definition may be prefixed with “-”, in which case it will be ignored when its source path does not exist.
BindPaths= creates regular writable bind mounts (unless the source file system mount is already marked read-only), while BindReadOnlyPaths= creates read-only bind mounts. These settings may be used more than once, each usage appends to the units list of bind mounts. If the empty string is assigned to either of these two options the entire list of bind mounts defined prior to this is reset. Note that in this case both read-only and regular bind mounts are reset, regardless which of the two settings is used.
Using this option implies that a mount namespace is allocated for the unit, i.e. it implies the effect of PrivateMounts= (see below).
This option is particularly useful when RootDirectory=/RootImage= is used. In this case the source path refers to a path on the host file system, while the destination path refers to a path below the root directory of the unit.
Note that the destination directory must exist or systemd must be able to create it. Thus, it is not possible to use those options for mount points nested underneath paths specified in InaccessiblePaths=, or under /home/ and other protected directories if ProtectHome=yes is specified. TemporaryFileSystem= with “:ro” or ProtectHome=tmpfs should be used instead.
Added in version 233.

MountImages=

This setting is similar to RootImage= in that it mounts a file system hierarchy from a block device node or loopback file, but the destination directory can be specified as well as mount options. This option expects a whitespace separated list of mount definitions. Each definition consists of a colon-separated tuple of source path and destination definitions, optionally followed by another colon and a list of mount options.
Mount options may be defined as a single comma-separated list of options, in which case they will be implicitly applied to the root partition on the image, or a series of colon-separated tuples of partition name and mount options. Valid partition names and mount options are the same as for RootImageOptions= setting described above.
Each mount definition may be prefixed with “-”, in which case it will be ignored when its source path does not exist. The source argument is a path to a block device node or regular file. If source or destination contain a “:”, it needs to be escaped as “". The device node or file system image file needs to follow the same rules as specified for RootImage=. Any mounts created with this option are specific to the unit, and are not visible in the hosts mount table.
These settings may be used more than once, each usage appends to the units list of mount paths. If the empty string is assigned, the entire list of mount paths defined prior to this is reset.
Note that the destination directory must exist or systemd must be able to create it. Thus, it is not possible to use those options for mount points nested underneath paths specified in InaccessiblePaths=, or under /home/ and other protected directories if ProtectHome=yes is specified.
When DevicePolicy= is set to “closed” or “strict”, or set to “auto” and DeviceAllow= is set, then this setting adds /dev/loop-control with rw mode, “block-loop” and “block-blkext” with rwm mode to DeviceAllow=. See systemd.resource-control(5) for the details about DevicePolicy= or DeviceAllow=. Also, see PrivateDevices= below, as it may change the setting of DevicePolicy=.
This option is only available for system services and is not supported for services running in per-user instances of the service manager.
Added in version 247.

ExtensionImages=

This setting is similar to MountImages= in that it mounts a file system hierarchy from a block device node or loopback file, but instead of providing a destination path, an overlay will be set up. This option expects a whitespace separated list of mount definitions. Each definition consists of a source path, optionally followed by a colon and a list of mount options.
A read-only OverlayFS will be set up on top of /usr/ and /opt/ hierarchies for sysext images and /etc/ hierarchy for confext images. The order in which the images are listed will determine the order in which the overlay is laid down: images specified first to last will result in overlayfs layers bottom to top.
Mount options may be defined as a single comma-separated list of options, in which case they will be implicitly applied to the root partition on the image, or a series of colon-separated tuples of partition name and mount options. Valid partition names and mount options are the same as for RootImageOptions= setting described above.
Each mount definition may be prefixed with “-”, in which case it will be ignored when its source path does not exist. The source argument is a path to a block device node or regular file. If the source path contains a “:”, it needs to be escaped as “". The device node or file system image file needs to follow the same rules as specified for RootImage=. Any mounts created with this option are specific to the unit, and are not visible in the hosts mount table.
These settings may be used more than once, each usage appends to the units list of image paths. If the empty string is assigned, the entire list of mount paths defined prior to this is reset.
Each sysext image must carry a /usr/lib/extension-release.d/extension-release.IMAGE file while each confext image must carry a /etc/extension-release.d/extension-release.IMAGE file, with the appropriate metadata which matches RootImage=/RootDirectory= or the host. See: os-release(5). To disable the safety check that the extension-release file name matches the image file name, the x-systemd.relax-extension-release-check mount option may be appended.
When DevicePolicy= is set to “closed” or “strict”, or set to “auto” and DeviceAllow= is set, then this setting adds /dev/loop-control with rw mode, “block-loop” and “block-blkext” with rwm mode to DeviceAllow=. See systemd.resource-control(5) for the details about DevicePolicy= or DeviceAllow=. Also, see PrivateDevices= below, as it may change the setting of DevicePolicy=.
In place of the image path a “.v/” versioned directory may be specified, see systemd.v(7) for details.
This option is only available for system services and is not supported for services running in per-user instances of the service manager.
Added in version 248.

ExtensionDirectories=

This setting is similar to BindReadOnlyPaths= in that it mounts a file system hierarchy from a directory, but instead of providing a destination path, an overlay will be set up. This option expects a whitespace separated list of source directories.
A read-only OverlayFS will be set up on top of /usr/ and /opt/ hierarchies for sysext images and /etc/ hierarchy for confext images. The order in which the directories are listed will determine the order in which the overlay is laid down: directories specified first to last will result in overlayfs layers bottom to top.
Each directory listed in ExtensionDirectories= may be prefixed with “-”, in which case it will be ignored when its source path does not exist. Any mounts created with this option are specific to the unit, and are not visible in the hosts mount table.
These settings may be used more than once, each usage appends to the units list of directories paths. If the empty string is assigned, the entire list of mount paths defined prior to this is reset.
Each sysext directory must contain a /usr/lib/extension-release.d/extension-release.IMAGE file while each confext directory must carry a /etc/extension-release.d/extension-release.IMAGE file, with the appropriate metadata which matches RootImage=/RootDirectory= or the host. See: os-release(5).
Note that usage from user units requires overlayfs support in unprivileged user namespaces, which was first introduced in kernel v5.11.
In place of the directory path a “.v/” versioned directory may be specified, see systemd.v(7) for details.
This option is only available for system services, or for services running in per-user instances of the service manager in which case PrivateUsers= is implicitly enabled (requires unprivileged user namespaces support to be enabled in the kernel via the “kernel.unprivileged_userns_clone=” sysctl).
Added in version 251.

USER/GROUP IDENTITY

These options are only available for system services and are not supported for services running in per-user instances of the service manager.

User=, Group=

Set the UNIX user or group that the processes are executed as, respectively. Takes a single user or group name, or a numeric ID as argument. For system services (services run by the system service manager, i.e. managed by PID 1) and for user services of the root user (services managed by roots instance of systemd –user), the default is “root”, but User= may be used to specify a different user. For user services of any other user, switching user identity is not permitted, hence the only valid setting is the same user the users service manager is running as. If no group is set, the default group of the user is used. This setting does not affect commands whose command line is prefixed with “+”.
Note that this enforces only weak restrictions on the user/group name syntax, but will generate warnings in many cases where user/group names do not adhere to the following rules: the specified name should consist only of the characters a-z, A-Z, 0-9, “_” and “-”, except for the first character which must be one of a-z, A-Z and “_” (i.e. digits and “-” are not permitted as first character). The user/group name must have at least one character, and at most 31. These restrictions are made in order to avoid ambiguities and to ensure user/group names and unit files remain portable among Linux systems. For further details on the names accepted and the names warned about see User/Group Name Syntax[3].
When used in conjunction with DynamicUser= the user/group name specified is dynamically allocated at the time the service is started, and released at the time the service is stopped — unless it is already allocated statically (see below). If DynamicUser= is not used the specified user and group must have been created statically in the user database no later than the moment the service is started, for example using the sysusers.d(5) facility, which is applied at boot or package install time. If the user does not exist by then program invocation will fail.
If the User= setting is used the supplementary group list is initialized from the specified users default group list, as defined in the systems user and group database. Additional groups may be configured through the SupplementaryGroups= setting (see below).

DynamicUser=

Takes a boolean parameter. If set, a UNIX user and group pair is allocated dynamically when the unit is started, and released as soon as it is stopped. The user and group will not be added to /etc/passwd or /etc/group, but are managed transiently during runtime. The nss-systemd(8) glibc NSS module provides integration of these dynamic users/groups into the systems user and group databases. The user and group name to use may be configured via User= and Group= (see above). If these options are not used and dynamic user/group allocation is enabled for a unit, the name of the dynamic user/group is implicitly derived from the unit name. If the unit name without the type suffix qualifies as valid user name it is used directly, otherwise a name incorporating a hash of it is used. If a statically allocated user or group of the configured name already exists, it is used and no dynamic user/group is allocated. Note that if User= is specified and the static group with the name exists, then it is required that the static user with the name already exists. Similarly, if Group= is specified and the static user with the name exists, then it is required that the static group with the name already exists. Dynamic users/groups are allocated from the UID/GID range 61184…65519. It is recommended to avoid this range for regular system or login users. At any point in time each UID/GID from this range is only assigned to zero or one dynamically allocated users/groups in use. However, UID/GIDs are recycled after a unit is terminated. Care should be taken that any processes running as part of a unit for which dynamic users/groups are enabled do not leave files or directories owned by these users/groups around, as a different unit might get the same UID/GID assigned later on, and thus gain access to these files or directories. If DynamicUser= is enabled, RemoveIPC= and PrivateTmp= are implied (and cannot be turned off). This ensures that the lifetime of IPC objects and temporary files created by the executed processes is bound to the runtime of the service, and hence the lifetime of the dynamic user/group. Since /tmp/ and /var/tmp/ are usually the only world-writable directories on a system this ensures that a unit making use of dynamic user/group allocation cannot leave files around after unit termination. Furthermore NoNewPrivileges= and RestrictSUIDSGID= are implicitly enabled (and cannot be disabled), to ensure that processes invoked cannot take benefit or create SUID/SGID files or directories. Moreover ProtectSystem=strict and ProtectHome=read-only are implied, thus prohibiting the service to write to arbitrary file system locations. In order to allow the service to write to certain directories, they have to be allow-listed using ReadWritePaths=, but care must be taken so that UID/GID recycling doesnt create security issues involving files created by the service. Use RuntimeDirectory= (see below) in order to assign a writable runtime directory to a service, owned by the dynamic user/group and removed automatically when the unit is terminated. Use StateDirectory=, CacheDirectory= and LogsDirectory= in order to assign a set of writable directories for specific purposes to the service in a way that they are protected from vulnerabilities due to UID reuse (see below). If this option is enabled, care should be taken that the units processes do not get access to directories outside of these explicitly configured and managed ones. Specifically, do not use BindPaths= and be careful with AF_UNIX file descriptor passing for directory file descriptors, as this would permit processes to create files or directories owned by the dynamic user/group that are not subject to the lifecycle and access guarantees of the service. Note that this option is currently incompatible with D-Bus policies, thus a service using this option may currently not allocate a D-Bus service name (note that this does not affect calling into other D-Bus services). Defaults to off.
Added in version 232.

SupplementaryGroups=

Sets the supplementary Unix groups the processes are executed as. This takes a space-separated list of group names or IDs. This option may be specified more than once, in which case all listed groups are set as supplementary groups. When the empty string is assigned, the list of supplementary groups is reset, and all assignments prior to this one will have no effect. In any way, this option does not override, but extends the list of supplementary groups configured in the system group database for the user. This does not affect commands prefixed with “+”.

SetLoginEnvironment=

Takes a boolean parameter that controls whether to set the $HOME, $LOGNAME, and $SHELL environment variables. If not set, this defaults to true if User=, DynamicUser= or PAMName= are set, false otherwise. If set to true, the variables will always be set for system services, i.e. even when the default user “root” is used. If set to false, the mentioned variables are not set by the service manager, no matter whether User=, DynamicUser=, or PAMName= are used or not. This option normally has no effect on services of the per-user service manager, since in that case these variables are typically inherited from user managers own environment anyway.
Added in version 255.

PAMName=

Sets the PAM service name to set up a session as. If set, the executed process will be registered as a PAM session under the specified service name. This is only useful in conjunction with the User= setting, and is otherwise ignored. If not set, no PAM session will be opened for the executed processes. See pam(8) for details.
Note that for each unit making use of this option a PAM session handler process will be maintained as part of the unit and stays around as long as the unit is active, to ensure that appropriate actions can be taken when the unit and hence the PAM session terminates. This process is named “(sd-pam)” and is an immediate child process of the units main process.
Note that when this option is used for a unit it is very likely (depending on PAM configuration) that the main unit process will be migrated to its own session scope unit when it is activated. This process will hence be associated with two units: the unit it was originally started from (and for which PAMName= was configured), and the session scope unit. Any child processes of that process will however be associated with the session scope unit only. This has implications when used in combination with *NotifyAccess=*all, as these child processes will not be able to affect changes in the original unit through notification messages. These messages will be considered belonging to the session scope unit and not the original unit. It is hence not recommended to use PAMName= in combination with *NotifyAccess=*all.

CAPABILITIES

These options are only available for system services, or for services running in per-user instances of the service manager in which case PrivateUsers= is implicitly enabled (requires unprivileged user namespaces support to be enabled in the kernel via the “kernel.unprivileged_userns_clone=” sysctl).

CapabilityBoundingSet=

Controls which capabilities to include in the capability bounding set for the executed process. See capabilities(7) for details. Takes a whitespace-separated list of capability names, e.g. CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, CAP_SYS_PTRACE. Capabilities listed will be included in the bounding set, all others are removed. If the list of capabilities is prefixed with “”, all but the listed capabilities will be included, the effect of the assignment inverted. Note that this option also affects the respective capabilities in the effective, permitted and inheritable capability sets. If this option is not used, the capability bounding set is not modified on process execution, hence no limits on the capabilities of the process are enforced. This option may appear more than once, in which case the bounding sets are merged by OR, or by AND if the lines are prefixed with “” (see below). If the empty string is assigned to this option, the bounding set is reset to the empty capability set, and all prior settings have no effect. If set to “~” (without any further argument), the bounding set is reset to the full set of available capabilities, also undoing any previous settings. This does not affect commands prefixed with “+”.
Use systemd-analyze(1)s capability command to retrieve a list of capabilities defined on the local system.
Example: if a unit has the following,
CapabilityBoundingSet=CAP_A CAP_B CapabilityBoundingSet=CAP_B CAP_C
then CAP_A, CAP_B, and CAP_C are set. If the second line is prefixed with “~”, e.g.,
CapabilityBoundingSet=CAP_A CAP_B CapabilityBoundingSet=~CAP_B CAP_C
then, only CAP_A is set.

AmbientCapabilities=

Controls which capabilities to include in the ambient capability set for the executed process. Takes a whitespace-separated list of capability names, e.g. CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, CAP_SYS_PTRACE. This option may appear more than once, in which case the ambient capability sets are merged (see the above examples in CapabilityBoundingSet=). If the list of capabilities is prefixed with “”, all but the listed capabilities will be included, the effect of the assignment inverted. If the empty string is assigned to this option, the ambient capability set is reset to the empty capability set, and all prior settings have no effect. If set to “” (without any further argument), the ambient capability set is reset to the full set of available capabilities, also undoing any previous settings. Note that adding capabilities to the ambient capability set adds them to the processs inherited capability set.
Ambient capability sets are useful if you want to execute a process as a non-privileged user but still want to give it some capabilities. Note that in this case option keep-caps is automatically added to SecureBits= to retain the capabilities over the user change. AmbientCapabilities= does not affect commands prefixed with “+”.
Added in version 229.

SECURITY

NoNewPrivileges=

Takes a boolean argument. If true, ensures that the service process and all its children can never gain new privileges through execve() (e.g. via setuid or setgid bits, or filesystem capabilities). This is the simplest and most effective way to ensure that a process and its children can never elevate privileges again. Defaults to false. In case the service will be run in a new mount namespace anyway and SELinux is disabled, all file systems are mounted with MS_NOSUID flag. Also see No New Privileges Flag[4].
Note that this setting only has an effect on the units processes themselves (or any processes directly or indirectly forked off them). It has no effect on processes potentially invoked on request of them through tools such as at(1), crontab(1), systemd-run(1), or arbitrary IPC services.
Added in version 187.

SecureBits=

Controls the secure bits set for the executed process. Takes a space-separated combination of options from the following list: keep-caps, keep-caps-locked, no-setuid-fixup, no-setuid-fixup-locked, noroot, and noroot-locked. This option may appear more than once, in which case the secure bits are ORed. If the empty string is assigned to this option, the bits are reset to 0. This does not affect commands prefixed with “+”. See capabilities(7) for details.

MANDATORY ACCESS CONTROL

These options are only available for system services and are not supported for services running in per-user instances of the service manager.

SELinuxContext=

Set the SELinux security context of the executed process. If set, this will override the automated domain transition. However, the policy still needs to authorize the transition. This directive is ignored if SELinux is disabled. If prefixed by “-”, failing to set the SELinux security context will be ignored, but its still possible that the subsequent execve() may fail if the policy doesnt allow the transition for the non-overridden context. This does not affect commands prefixed with “+”. See setexeccon(3) for details.
Added in version 209.

AppArmorProfile=

Takes a profile name as argument. The process executed by the unit will switch to this profile when started. Profiles must already be loaded in the kernel, or the unit will fail. If prefixed by “-”, all errors will be ignored. This setting has no effect if AppArmor is not enabled. This setting does not affect commands prefixed with “+”.
Added in version 210.

SmackProcessLabel=

Takes a SMACK64 security label as argument. The process executed by the unit will be started under this label and SMACK will decide whether the process is allowed to run or not, based on it. The process will continue to run under the label specified here unless the executable has its own SMACK64EXEC label, in which case the process will transition to run under that label. When not specified, the label that systemd is running under is used. This directive is ignored if SMACK is disabled.
The value may be prefixed by “-”, in which case all errors will be ignored. An empty value may be specified to unset previous assignments. This does not affect commands prefixed with “+”.
Added in version 218.

PROCESS PROPERTIES

LimitCPU=, LimitFSIZE=, LimitDATA=, LimitSTACK=, LimitCORE=, LimitRSS=, LimitNOFILE=, LimitAS=, LimitNPROC=, LimitMEMLOCK=, LimitLOCKS=, LimitSIGPENDING=, LimitMSGQUEUE=, LimitNICE=, LimitRTPRIO=, LimitRTTIME=

Set soft and hard limits on various resources for executed processes. See setrlimit(2) for details on the process resource limit concept. Process resource limits may be specified in two formats: either as single value to set a specific soft and hard limit to the same value, or as colon-separated pair soft:hard to set both limits individually (e.g. “LimitAS=4G:16G”). Use the string infinity to configure no limit on a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits measured in bytes (e.g. “LimitAS=16G”). For the limits referring to time values, the usual time units ms, s, min, h and so on may be used (see systemd.time(7) for details). Note that if no time unit is specified for LimitCPU= the default unit of seconds is implied, while for LimitRTTIME= the default unit of microseconds is implied. Also, note that the effective granularity of the limits might influence their enforcement. For example, time limits specified for LimitCPU= will be rounded up implicitly to multiples of 1s. For LimitNICE= the value may be specified in two syntaxes: if prefixed with “+” or “-”, the value is understood as regular Linux nice value in the range -20…19. If not prefixed like this the value is understood as raw resource limit parameter in the range 0…40 (with 0 being equivalent to 1).
Note that most process resource limits configured with these options are per-process, and processes may fork in order to acquire a new set of resources that are accounted independently of the original process, and may thus escape limits set. Also note that LimitRSS= is not implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource controls listed in systemd.resource-control(5) over these per-process limits, as they apply to services as a whole, may be altered dynamically at runtime, and are generally more expressive. For example, MemoryMax= is a more powerful (and working) replacement for LimitRSS=.
Note that LimitNPROC= will limit the number of processes from one (real) UID and not the number of processes started (forked) by the service. Therefore the limit is cumulative for all processes running under the same UID. Please also note that the LimitNPROC= will not be enforced if the service is running as root (and not dropping privileges). Due to these limitations, TasksMax= (see systemd.resource-control(5)) is typically a better choice than LimitNPROC=.
Resource limits not configured explicitly for a unit default to the value configured in the various DefaultLimitCPU=, DefaultLimitFSIZE=, … options available in systemd-system.conf(5), and – if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user services, see below).
For system units these resource limits may be chosen freely. When these settings are configured in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be used to raise the limits above those set for the user manager itself when it was first invoked, as the users service manager generally lacks the privileges to do so. In user context these configuration options are hence only useful to lower the limits passed in or to raise the soft limit to the maximum of the hard limit as configured for the user. To raise the users limits further, the available configuration mechanisms differ between operating systems, but typically require privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by setting limits on the system service encapsulating the users service manager, i.e. the users instance of [email protected]. After making such changes, make sure to restart the users service manager.
Table 1. Resource limit directives, their equivalent ulimit shell commands and the unit used
Directive ulimit equivalent Unit Notes
LimitCPU= ulimit -t Seconds -
LimitFSIZE= ulimit -f Bytes -
LimitDATA= ulimit -d Bytes Dont use. This limits the allowed address range, not memory use! Defaults to unlimited and should not be lowered. To limit memory use, see MemoryMax= in systemd.resource-control(5).
LimitSTACK= ulimit -s Bytes -
LimitCORE= ulimit -c Bytes -
LimitRSS= ulimit -m Bytes Dont use. No effect on Linux.
LimitNOFILE= ulimit -n Number of File Descriptors Dont use. Be careful when raising the soft limit above 1024, since select(2) cannot function with file descriptors above 1023 on Linux. Nowadays, the hard limit defaults to 524288, a very high value compared to historical defaults. Typically applications should increase their soft limit to the hard limit on their own, if they are OK with working with file descriptors above 1023, i.e. do not use select(2). Note that file descriptors are nowadays accounted like any other form of memory, thus there should not be any need to lower the hard limit. Use MemoryMax= to control overall service memory use, including file descriptor memory.
LimitAS= ulimit -v Bytes Dont use. This limits the allowed address range, not memory use! Defaults to unlimited and should not be lowered. To limit memory use, see MemoryMax= in systemd.resource-control(5).
LimitNPROC= ulimit -u Number of Processes This limit is enforced based on the number of processes belonging to the user. Typically its better to track processes per service, i.e. use TasksMax=, see systemd.resource-control(5).
LimitMEMLOCK= ulimit -l Bytes -
LimitLOCKS= ulimit -x Number of Locks -
LimitSIGPENDING= ulimit -i Number of Queued Signals -
LimitMSGQUEUE= ulimit -q Bytes -
LimitNICE= ulimit -e Nice Level -
LimitRTPRIO= ulimit -r Realtime Priority -
LimitRTTIME= ulimit -R Microseconds -

UMask=

Controls the file mode creation mask. Takes an access mode in octal notation. See umask(2) for details. Defaults to 0022 for system units. For user units the default value is inherited from the per-user service manager (whose default is in turn inherited from the system service manager, and thus typically also is 0022 — unless overridden by a PAM module). In order to change the per-user mask for all user services, consider setting the UMask= setting of the users [email protected] system service instance. The per-user umask may also be set via the umask field of a users JSON User Record[5] (for users managed by systemd-homed.service(8) this field may be controlled via homectl –umask=). It may also be set via a PAM module, such as pam_umask(8).

CoredumpFilter=

Controls which types of memory mappings will be saved if the process dumps core (using the /proc/pid/coredump_filter file). Takes a whitespace-separated combination of mapping type names or numbers (with the default base 16). Mapping type names are private-anonymous, shared-anonymous, private-file-backed, shared-file-backed, elf-headers, private-huge, shared-huge, private-dax, shared-dax, and the special values all (all types) and default (the kernel default of “private-anonymous shared-anonymous elf-headers private-huge”). See core(5) for the meaning of the mapping types. When specified multiple times, all specified masks are ORed. When not set, or if the empty value is assigned, the inherited value is not changed.
Example 2. Add DAX pages to the dump filter
CoredumpFilter=default private-dax shared-dax
Added in version 246.

KeyringMode=

Controls how the kernel session keyring is set up for the service (see session-keyring(7) for details on the session keyring). Takes one of inherit, private, shared. If set to inherit no special keyring setup is done, and the kernels default behaviour is applied. If private is used a new session keyring is allocated when a service process is invoked, and it is not linked up with any user keyring. This is the recommended setting for system services, as this ensures that multiple services running under the same system user ID (in particular the root user) do not share their key material among each other. If shared is used a new session keyring is allocated as for private, but the user keyring of the user configured with User= is linked into it, so that keys assigned to the user may be requested by the units processes. In this mode multiple units running processes under the same user ID may share key material. Unless inherit is selected the unique invocation ID for the unit (see below) is added as a protected key by the name “invocation_id” to the newly created session keyring. Defaults to private for services of the system service manager and to inherit for non-service units and for services of the user service manager.
Added in version 235.

OOMScoreAdjust=

Sets the adjustment value for the Linux kernels Out-Of-Memory (OOM) killer score for executed processes. Takes an integer between -1000 (to disable OOM killing of processes of this unit) and 1000 (to make killing of processes of this unit under memory pressure very likely). See The /proc Filesystem[6] for details. If not specified defaults to the OOM score adjustment level of the service manager itself, which is normally at 0.
Use the OOMPolicy= setting of service units to configure how the service manager shall react to the kernel OOM killer or systemd-oomd terminating a process of the service. See systemd.service(5) for details.

TimerSlackNSec=

Sets the timer slack in nanoseconds for the executed processes. The timer slack controls the accuracy of wake-ups triggered by timers. See prctl(2) for more information. Note that in contrast to most other time span definitions this parameter takes an integer value in nano-seconds if no unit is specified. The usual time units are understood too.

Personality=

Controls which kernel architecture uname(2) shall report, when invoked by unit processes. Takes one of the architecture identifiers arm64, arm64-be, arm, arm-be, x86, x86-64, ppc, ppc-le, ppc64, ppc64-le, s390 or s390x. Which personality architectures are supported depends on the kernels native architecture. Usually the 64-bit versions of the various system architectures support their immediate 32-bit personality architecture counterpart, but no others. For example, x86-64 systems support the x86-64 and x86 personalities but no others. The personality feature is useful when running 32-bit services on a 64-bit host system. If not specified, the personality is left unmodified and thus reflects the personality of the host systems kernel. This option is not useful on architectures for which only one native word width was ever available, such as m68k (32-bit only) or alpha (64-bit only).
Added in version 209.

IgnoreSIGPIPE=

Takes a boolean argument. If true, SIGPIPE is ignored in the executed process. Defaults to true since SIGPIPE is generally only useful in shell pipelines.

SCHEDULING

Nice=

Sets the default nice level (scheduling priority) for executed processes. Takes an integer between -20 (highest priority) and 19 (lowest priority). In case of resource contention, smaller values mean more resources will be made available to the units processes, larger values mean less resources will be made available. See setpriority(2) for details.

CPUSchedulingPolicy=

Sets the CPU scheduling policy for executed processes. Takes one of other, batch, idle, fifo or rr. See sched_setscheduler(2) for details.

CPUSchedulingPriority=

Sets the CPU scheduling priority for executed processes. The available priority range depends on the selected CPU scheduling policy (see above). For real-time scheduling policies an integer between 1 (lowest priority) and 99 (highest priority) can be used. In case of CPU resource contention, smaller values mean less CPU time is made available to the service, larger values mean more. See sched_setscheduler(2) for details.

CPUSchedulingResetOnFork=

Takes a boolean argument. If true, elevated CPU scheduling priorities and policies will be reset when the executed processes call fork(2), and can hence not leak into child processes. See sched_setscheduler(2) for details. Defaults to false.

CPUAffinity=

Controls the CPU affinity of the executed processes. Takes a list of CPU indices or ranges separated by either whitespace or commas. Alternatively, takes a special “numa” value in which case systemd automatically derives allowed CPU range based on the value of NUMAMask= option. CPU ranges are specified by the lower and upper CPU indices separated by a dash. This option may be specified more than once, in which case the specified CPU affinity masks are merged. If the empty string is assigned, the mask is reset, all assignments prior to this will have no effect. See sched_setaffinity(2) for details.

NUMAPolicy=

Controls the NUMA memory policy of the executed processes. Takes a policy type, one of: default, preferred, bind, interleave and local. A list of NUMA nodes that should be associated with the policy must be specified in NUMAMask=. For more details on each policy please see, set_mempolicy(2). For overall overview of NUMA support in Linux see, numa(7).
Added in version 243.

NUMAMask=

Controls the NUMA node list which will be applied alongside with selected NUMA policy. Takes a list of NUMA nodes and has the same syntax as a list of CPUs for CPUAffinity= option or special “all” value which will include all available NUMA nodes in the mask. Note that the list of NUMA nodes is not required for default and local policies and for preferred policy we expect a single NUMA node.
Added in version 243.

IOSchedulingClass=

Sets the I/O scheduling class for executed processes. Takes one of the strings realtime, best-effort or idle. The kernels default scheduling class is best-effort at a priority of 4. If the empty string is assigned to this option, all prior assignments to both IOSchedulingClass= and IOSchedulingPriority= have no effect. See ioprio_set(2) for details.

IOSchedulingPriority=

Sets the I/O scheduling priority for executed processes. Takes an integer between 0 (highest priority) and 7 (lowest priority). In case of I/O contention, smaller values mean more I/O bandwidth is made available to the units processes, larger values mean less bandwidth. The available priorities depend on the selected I/O scheduling class (see above). If the empty string is assigned to this option, all prior assignments to both IOSchedulingClass= and IOSchedulingPriority= have no effect. For the kernels default scheduling class (best-effort) this defaults to 4. See ioprio_set(2) for details.

SANDBOXING

The following sandboxing options are an effective way to limit the exposure of the system towards the units processes. It is recommended to turn on as many of these options for each unit as is possible without negatively affecting the process ability to operate. Note that many of these sandboxing features are gracefully turned off on systems where the underlying security mechanism is not available. For example, ProtectSystem= has no effect if the kernel is built without file system namespacing or if the service manager runs in a container manager that makes file system namespacing unavailable to its payload. Similarly, RestrictRealtime= has no effect on systems that lack support for SECCOMP system call filtering, or in containers where support for this is turned off.

Also note that some sandboxing functionality is generally not available in user services (i.e. services run by the per-user service manager). Specifically, the various settings requiring file system namespacing support (such as ProtectSystem=) are not available, as the underlying kernel functionality is only accessible to privileged processes. However, most namespacing settings, that will not work on their own in user services, will work when used in conjunction with *PrivateUsers=*true.

Note that the various options that turn directories read-only (such as ProtectSystem=, ReadOnlyPaths=, …) do not affect the ability for programs to connect to and communicate with AF_UNIX sockets in these directories. These options cannot be used to lock down access to IPC services hence.

ProtectSystem=

Takes a boolean argument or the special values “full” or “strict”. If true, mounts the /usr/ and the boot loader directories (/boot and /efi) read-only for processes invoked by this unit. If set to “full”, the /etc/ directory is mounted read-only, too. If set to “strict” the entire file system hierarchy is mounted read-only, except for the API file system subtrees /dev/, /proc/ and /sys/ (protect these directories using PrivateDevices=, ProtectKernelTunables=, ProtectControlGroups=). This setting ensures that any modification of the vendor-supplied operating system (and optionally its configuration, and local mounts) is prohibited for the service. It is recommended to enable this setting for all long-running services, unless they are involved with system updates or need to modify the operating system in other ways. If this option is used, ReadWritePaths= may be used to exclude specific directories from being made read-only. Similar, StateDirectory=, LogsDirectory=, … and related directory settings (see below) also exclude the specific directories from the effect of ProtectSystem=. This setting is implied if DynamicUser= is set. This setting cannot ensure protection in all cases. In general it has the same limitations as ReadOnlyPaths=, see below. Defaults to off.
Added in version 214.

ProtectHome=

Takes a boolean argument or the special values “read-only” or “tmpfs”. If true, the directories /home/, /root, and /run/user are made inaccessible and empty for processes invoked by this unit. If set to “read-only”, the three directories are made read-only instead. If set to “tmpfs”, temporary file systems are mounted on the three directories in read-only mode. The value “tmpfs” is useful to hide home directories not relevant to the processes invoked by the unit, while still allowing necessary directories to be made visible when listed in BindPaths= or BindReadOnlyPaths=.
Setting this to “yes” is mostly equivalent to setting the three directories in InaccessiblePaths=. Similarly, “read-only” is mostly equivalent to ReadOnlyPaths=, and “tmpfs” is mostly equivalent to TemporaryFileSystem= with “:ro”.
It is recommended to enable this setting for all long-running services (in particular network-facing ones), to ensure they cannot get access to private user data, unless the services actually require access to the users private data. This setting is implied if DynamicUser= is set. This setting cannot ensure protection in all cases. In general it has the same limitations as ReadOnlyPaths=, see below.
This option is only available for system services, or for services running in per-user instances of the service manager in which case PrivateUsers= is implicitly enabled (requires unprivileged user namespaces support to be enabled in the kernel via the “kernel.unprivileged_userns_clone=” sysctl).
Added in version 214.

RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory=, ConfigurationDirectory=

These options take a whitespace-separated list of directory names. The specified directory names must be relative, and may not include “..”. If set, when the unit is started, one or more directories by the specified names will be created (including their parents) below the locations defined in the following table. Also, the corresponding environment variable will be defined with the full paths of the directories. If multiple directories are set, then in the environment variable the paths are concatenated with colon (”:”).
Table 2. Automatic directory creation and environment variables
Directory Below path for system units Below path for user units Environment variable set
RuntimeDirectory= /run/ $XDG_RUNTIME_DIR $RUNTIME_DIRECTORY
StateDirectory= /var/lib/ $XDG_STATE_HOME $STATE_DIRECTORY
CacheDirectory= /var/cache/ $XDG_CACHE_HOME $CACHE_DIRECTORY
LogsDirectory= /var/log/ $XDG_STATE_HOME/log/ $LOGS_DIRECTORY
ConfigurationDirectory= /etc/ $XDG_CONFIG_HOME $CONFIGURATION_DIRECTORY
In case of RuntimeDirectory= the innermost subdirectories are removed when the unit is stopped. It is possible to preserve the specified directories in this case if RuntimeDirectoryPreserve= is configured to restart or yes (see below). The directories specified with StateDirectory=, CacheDirectory=, LogsDirectory=, ConfigurationDirectory= are not removed when the unit is stopped.
Except in case of ConfigurationDirectory=, the innermost specified directories will be owned by the user and group specified in User= and Group=. If the specified directories already exist and their owning user or group do not match the configured ones, all files and directories below the specified directories as well as the directories themselves will have their file ownership recursively changed to match what is configured. As an optimization, if the specified directories are already owned by the right user and group, files and directories below of them are left as-is, even if they do not match what is requested. The innermost specified directories will have their access mode adjusted to the what is specified in RuntimeDirectoryMode=, StateDirectoryMode=, CacheDirectoryMode=, LogsDirectoryMode= and ConfigurationDirectoryMode=.
These options imply BindPaths= for the specified paths. When combined with RootDirectory= or RootImage= these paths always reside on the host and are mounted from there into the units file system namespace.
If DynamicUser= is used, the logic for CacheDirectory=, LogsDirectory= and StateDirectory= is slightly altered: the directories are created below /var/cache/private, /var/log/private and /var/lib/private, respectively, which are host directories made inaccessible to unprivileged users, which ensures that access to these directories cannot be gained through dynamic user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from perspective of the host and from inside the unit, the relevant directories hence always appear directly below /var/cache, /var/log and /var/lib.
Use RuntimeDirectory= to manage one or more runtime directories for the unit and bind their lifetime to the daemon runtime. This is particularly useful for unprivileged daemons that cannot create runtime directories in /run/ due to lack of privileges, and to make sure the runtime directory is cleaned up automatically after use. For runtime directories that require more complex or different configuration or lifetime guarantees, please consider using tmpfiles.d(5).
RuntimeDirectory=, StateDirectory=, CacheDirectory= and LogsDirectory= optionally support a second parameter, separated by “:”. The second parameter will be interpreted as a destination path that will be created as a symlink to the directory. The symlinks will be created after any BindPaths= or TemporaryFileSystem= options have been set up, to make ephemeral symlinking possible. The same source can have multiple symlinks, by using the same first parameter, but a different second parameter.
The directories defined by these options are always created under the standard paths used by systemd (/var/, /run/, /etc/, …). If the service needs directories in a different location, a different mechanism has to be used to create them.
tmpfiles.d(5) provides functionality that overlaps with these options. Using these options is recommended, because the lifetime of the directories is tied directly to the lifetime of the unit, and it is not necessary to ensure that the tmpfiles.d configuration is executed before the unit is started.
To remove any of the directories created by these settings, use the systemctl clean … command on the relevant units, see systemctl(1) for details.
Example: if a system service unit has the following,
RuntimeDirectory=foo/bar baz
the service manager creates /run/foo (if it does not exist), /run/foo/bar, and /run/baz. The directories /run/foo/bar and /run/baz except /run/foo are owned by the user and group specified in User= and Group=, and removed when the service is stopped.
Example: if a system service unit has the following,
RuntimeDirectory=foo/bar StateDirectory=aaa/bbb ccc
then the environment variable “RUNTIME_DIRECTORY” is set with “/run/foo/bar”, and “STATE_DIRECTORY” is set with “/var/lib/aaa/bbb:/var/lib/ccc”.
Example: if a system service unit has the following,
RuntimeDirectory=foo:bar foo:baz
the service manager creates /run/foo (if it does not exist), and /run/bar plus /run/baz as symlinks to /run/foo.
Added in version 211.

RuntimeDirectoryMode=, StateDirectoryMode=, CacheDirectoryMode=, LogsDirectoryMode=, ConfigurationDirectoryMode=

Specifies the access mode of the directories specified in RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory=, or ConfigurationDirectory=, respectively, as an octal number. Defaults to 0755. See “Permissions” in path_resolution(7) for a discussion of the meaning of permission bits.
Added in version 234.

RuntimeDirectoryPreserve=

Takes a boolean argument or restart. If set to no (the default), the directories specified in RuntimeDirectory= are always removed when the service stops. If set to restart the directories are preserved when the service is both automatically and manually restarted. Here, the automatic restart means the operation specified in Restart=, and manual restart means the one triggered by systemctl restart foo.service. If set to yes, then the directories are not removed when the service is stopped. Note that since the runtime directory /run/ is a mount point of “tmpfs”, then for system services the directories specified in RuntimeDirectory= are removed when the system is rebooted.
Added in version 235.

TimeoutCleanSec=

Configures a timeout on the clean-up operation requested through systemctl clean …, see systemctl(1) for details. Takes the usual time values and defaults to infinity, i.e. by default no timeout is applied. If a timeout is configured the clean operation will be aborted forcibly when the timeout is reached, potentially leaving resources on disk.
Added in version 244.

ReadWritePaths=, ReadOnlyPaths=, InaccessiblePaths=, ExecPaths=, NoExecPaths=

Sets up a new file system namespace for executed processes. These options may be used to limit access a process has to the file system. Each setting takes a space-separated list of paths relative to the hosts root directory (i.e. the system running the service manager). Note that if paths contain symlinks, they are resolved relative to the root directory set with RootDirectory=/RootImage=.
Paths listed in ReadWritePaths= are accessible from within the namespace with the same access modes as from outside of it. Paths listed in ReadOnlyPaths= are accessible for reading only, writing will be refused even if the usual file access controls would permit this. Nest ReadWritePaths= inside of ReadOnlyPaths= in order to provide writable subdirectories within read-only directories. Use ReadWritePaths= in order to allow-list specific paths for write access if ProtectSystem=strict is used. Note that ReadWritePaths= cannot be used to gain write access to a file system whose superblock is mounted read-only. On Linux, for each mount point write access is granted only if the mount point itself and the file system superblock backing it are not marked read-only. ReadWritePaths= only controls the former, not the latter, hence a read-only file system superblock remains protected.
Paths listed in InaccessiblePaths= will be made inaccessible for processes inside the namespace along with everything below them in the file system hierarchy. This may be more restrictive than desired, because it is not possible to nest ReadWritePaths=, ReadOnlyPaths=, BindPaths=, or BindReadOnlyPaths= inside it. For a more flexible option, see TemporaryFileSystem=.
Content in paths listed in NoExecPaths= are not executable even if the usual file access controls would permit this. Nest ExecPaths= inside of NoExecPaths= in order to provide executable content within non-executable directories.
Non-directory paths may be specified as well. These options may be specified more than once, in which case all paths listed will have limited access from within the namespace. If the empty string is assigned to this option, the specific list is reset, and all prior assignments have no effect.
Paths in ReadWritePaths=, ReadOnlyPaths=, InaccessiblePaths=, ExecPaths= and NoExecPaths= may be prefixed with “-”, in which case they will be ignored when they do not exist. If prefixed with “+” the paths are taken relative to the root directory of the unit, as configured with RootDirectory=/RootImage=, instead of relative to the root directory of the host (see above). When combining “-” and “+” on the same path make sure to specify “-” first, and “+” second.
Note that these settings will disconnect propagation of mounts from the units processes to the host. This means that this setting may not be used for services which shall be able to install mount points in the main mount namespace. For ReadWritePaths= and ReadOnlyPaths=, propagation in the other direction is not affected, i.e. mounts created on the host generally appear in the unit processes namespace, and mounts removed on the host also disappear there too. In particular, note that mount propagation from host to unit will result in unmodified mounts to be created in the units namespace, i.e. writable mounts appearing on the host will be writable in the units namespace too, even when propagated below a path marked with ReadOnlyPaths=! Restricting access with these options hence does not extend to submounts of a directory that are created later on. This means the lock-down offered by that setting is not complete, and does not offer full protection.
Note that the effect of these settings may be undone by privileged processes. In order to set up an effective sandboxed environment for a unit it is thus recommended to combine these settings with either CapabilityBoundingSet=~CAP_SYS_ADMIN or SystemCallFilter=~@mount.
Please be extra careful when applying these options to API file systems (a list of them could be found in MountAPIVPS=), since they may be required for basic system functionalities. Moreover, /run/ needs to be writable for setting up mount namespace and propagation.
Simple allow-list example using these directives:
[Service] ReadOnlyPaths=/ ReadWritePaths=/var /run InaccessiblePaths=-/lost+found NoExecPaths=/ ExecPaths=/usr/sbin/my_daemon /usr/lib /usr/lib64
These options are only available for system services, or for services running in per-user instances of the service manager in which case PrivateUsers= is implicitly enabled (requires unprivileged user namespaces support to be enabled in the kernel via the “kernel.unprivileged_userns_clone=” sysctl).
Added in version 231.

TemporaryFileSystem=

Takes a space-separated list of mount points for temporary file systems (tmpfs). If set, a new file system namespace is set up for executed processes, and a temporary file system is mounted on each mount point. This option may be specified more than once, in which case temporary file systems are mounted on all listed mount points. If the empty string is assigned to this option, the list is reset, and all prior assignments have no effect. Each mount point may optionally be suffixed with a colon (":") and mount options such as “size=10%” or “ro”. By default, each temporary file system is mounted with “nodev,strictatime,mode=0755”. These can be disabled by explicitly specifying the corresponding mount options, e.g., “dev” or “nostrictatime”.
This is useful to hide files or directories not relevant to the processes invoked by the unit, while necessary files or directories can be still accessed by combining with BindPaths= or BindReadOnlyPaths=:
Example: if a unit has the following,
TemporaryFileSystem=/var:ro BindReadOnlyPaths=/var/lib/systemd
then the invoked processes by the unit cannot see any files or directories under /var/ except for /var/lib/systemd or its contents.
This option is only available for system services, or for services running in per-user instances of the service manager in which case PrivateUsers= is implicitly enabled (requires unprivileged user namespaces support to be enabled in the kernel via the “kernel.unprivileged_userns_clone=” sysctl).
Added in version 238.

PrivateTmp=

Takes a boolean argument. If true, sets up a new file system namespace for the executed processes and mounts private /tmp/ and /var/tmp/ directories inside it that are not shared by processes outside of the namespace. This is useful to secure access to temporary files of the process, but makes sharing between processes via /tmp/ or /var/tmp/ impossible. If true, all temporary files created by a service in these directories will be removed after the service is stopped. Defaults to false. It is possible to run two or more units within the same private /tmp/ and /var/tmp/ namespace by using the JoinsNamespaceOf= directive, see systemd.unit(5) for details. This setting is implied if DynamicUser= is set. For this setting, the same restrictions regarding mount propagation and privileges apply as for ReadOnlyPaths= and related calls, see above. Enabling this setting has the side effect of adding Requires= and After= dependencies on all mount units necessary to access /tmp/ and /var/tmp/. Moreover an implicitly After= ordering on systemd-tmpfiles-setup.service(8) is added.
Note that the implementation of this setting might be impossible (for example if mount namespaces are not available), and the unit should be written in a way that does not solely rely on this setting for security.
This option is only available for system services, or for services running in per-user instances of the service manager in which case PrivateUsers= is implicitly enabled (requires unprivileged user namespaces support to be enabled in the kernel via the “kernel.unprivileged_userns_clone=” sysctl).

PrivateDevices=

Takes a boolean argument. If true, sets up a new /dev/ mount for the executed processes and only adds API pseudo devices such as /dev/null, /dev/zero or /dev/random (as well as the pseudo TTY subsystem) to it, but no physical devices such as /dev/sda, system memory /dev/mem, system ports /dev/port and others. This is useful to turn off physical device access by the executed process. Defaults to false.
Enabling this option will install a system call filter to block low-level I/O system calls that are grouped in the @raw-io set, remove CAP_MKNOD and CAP_SYS_RAWIO from the capability bounding set for the unit, and set DevicePolicy=closed (see systemd.resource-control(5) for details). Note that using this setting will disconnect propagation of mounts from the service to the host (propagation in the opposite direction continues to work). This means that this setting may not be used for services which shall be able to install mount points in the main mount namespace. The new /dev/ will be mounted read-only and noexec. The latter may break old programs which try to set up executable memory by using mmap(2) of /dev/zero instead of using MAP_ANON. For this setting the same restrictions regarding mount propagation and privileges apply as for ReadOnlyPaths= and related calls, see above.
Note that the implementation of this setting might be impossible (for example if mount namespaces are not available), and the unit should be written in a way that does not solely rely on this setting for security.
This option is only available for system services, or for services running in per-user instances of the service manager in which case PrivateUsers= is implicitly enabled (requires unprivileged user namespaces support to be enabled in the kernel via the “kernel.unprivileged_userns_clone=” sysctl).
When access to some but not all devices must be possible, the DeviceAllow= setting might be used instead. See systemd.resource-control(5).
Added in version 209.

PrivateNetwork=

Takes a boolean argument. If true, sets up a new network namespace for the executed processes and configures only the loopback network device “lo” inside it. No other network devices will be available to the executed process. This is useful to turn off network access by the executed process. Defaults to false. It is possible to run two or more units within the same private network namespace by using the JoinsNamespaceOf= directive, see systemd.unit(5) for details. Note that this option will disconnect all socket families from the host, including AF_NETLINK and AF_UNIX. Effectively, for AF_NETLINK this means that device configuration events received from systemd-udevd.service(8) are not delivered to the units processes. And for AF_UNIX this has the effect that AF_UNIX sockets in the abstract socket namespace of the host will become unavailable to the units processes (however, those located in the file system will continue to be accessible).
Note that the implementation of this setting might be impossible (for example if network namespaces are not available), and the unit should be written in a way that does not solely rely on this setting for security.
When this option is enabled, PrivateMounts= is implied unless it is explicitly disabled, and /sys will be remounted to associate it with the new network namespace.
When this option is used on a socket unit any sockets bound on behalf of this unit will be bound within a private network namespace. This may be combined with JoinsNamespaceOf= to listen on sockets inside of network namespaces of other services.
This option is only available for system services, or for services running in per-user instances of the service manager in which case PrivateUsers= is implicitly enabled (requires unprivileged user namespaces support to be enabled in the kernel via the “kernel.unprivileged_userns_clone=” sysctl).

NetworkNamespacePath=

Takes an absolute file system path referring to a Linux network namespace pseudo-file (i.e. a file like /proc/$PID/ns/net or a bind mount or symlink to one). When set the invoked processes are added to the network namespace referenced by that path. The path has to point to a valid namespace file at the moment the processes are forked off. If this option is used PrivateNetwork= has no effect. If this option is used together with JoinsNamespaceOf= then it only has an effect if this unit is started before any of the listed units that have PrivateNetwork= or NetworkNamespacePath= configured, as otherwise the network namespace of those units is reused.
When this option is enabled, PrivateMounts= is implied unless it is explicitly disabled, and /sys will be remounted to associate it with the new network namespace.
When this option is used on a socket unit any sockets bound on behalf of this unit will be bound within the specified network namespace.
This option is only available for system services, or for services running in per-user instances of the service manager in which case PrivateUsers= is implicitly enabled (requires unprivileged user namespaces support to be enabled in the kernel via the “kernel.unprivileged_userns_clone=” sysctl).
Added in version 242.

PrivateIPC=

Takes a boolean argument. If true, sets up a new IPC namespace for the executed processes. Each IPC namespace has its own set of System V IPC identifiers and its own POSIX message queue file system. This is useful to avoid name clash of IPC identifiers. Defaults to false. It is possible to run two or more units within the same private IPC namespace by using the JoinsNamespaceOf= directive, see systemd.unit(5) for details.
Note that IPC namespacing does not have an effect on AF_UNIX sockets, which are the most common form of IPC used on Linux. Instead, AF_UNIX sockets in the file system are subject to mount namespacing, and those in the abstract namespace are subject to network namespacing. IPC namespacing only has an effect on SysV IPC (which is mostly legacy) as well as POSIX message queues (for which AF_UNIX/SOCK_SEQPACKET sockets are typically a better replacement). IPC namespacing also has no effect on POSIX shared memory (which is subject to mount namespacing) either. See ipc_namespaces(7) for the details.
Note that the implementation of this setting might be impossible (for example if IPC namespaces are not available), and the unit should be written in a way that does not solely rely on this setting for security.
This option is only available for system services, or for services running in per-user instances of the service manager in which case PrivateUsers= is implicitly enabled (requires unprivileged user namespaces support to be enabled in the kernel via the “kernel.unprivileged_userns_clone=” sysctl).
Added in version 248.

IPCNamespacePath=

Takes an absolute file system path referring to a Linux IPC namespace pseudo-file (i.e. a file like /proc/$PID/ns/ipc or a bind mount or symlink to one). When set the invoked processes are added to the network namespace referenced by that path. The path has to point to a valid namespace file at the moment the processes are forked off. If this option is used PrivateIPC= has no effect. If this option is used together with JoinsNamespaceOf= then it only has an effect if this unit is started before any of the listed units that have PrivateIPC= or IPCNamespacePath= configured, as otherwise the network namespace of those units is reused.
This option is only available for system services, or for services running in per-user instances of the service manager in which case PrivateUsers= is implicitly enabled (requires unprivileged user namespaces support to be enabled in the kernel via the “kernel.unprivileged_userns_clone=” sysctl).
Added in version 248.

MemoryKSM=

Takes a boolean argument. When set, it enables KSM (kernel samepage merging) for the processes. KSM is a memory-saving de-duplication feature. Anonymous memory pages with identical content can be replaced by a single write-protected page. This feature should only be enabled for jobs that share the same security domain. For details, see Kernel Samepage Merging[7] in the kernel documentation.
Note that this functionality might not be available, for example if KSM is disabled in the kernel, or the kernel doesnt support controlling KSM at the process level through prctl(2).
Added in version 254.

PrivateUsers=

Takes a boolean argument. If true, sets up a new user namespace for the executed processes and configures a minimal user and group mapping, that maps the “root” user and group as well as the units own user and group to themselves and everything else to the “nobody” user and group. This is useful to securely detach the user and group databases used by the unit from the rest of the system, and thus to create an effective sandbox environment. All files, directories, processes, IPC objects and other resources owned by users/groups not equaling “root” or the units own will stay visible from within the unit but appear owned by the “nobody” user and group. If this mode is enabled, all unit processes are run without privileges in the host user namespace (regardless if the units own user/group is “root” or not). Specifically this means that the process will have zero process capabilities on the hosts user namespace, but full capabilities within the services user namespace. Settings such as CapabilityBoundingSet= will affect only the latter, and theres no way to acquire additional capabilities in the hosts user namespace. Defaults to off.
When this setting is set up by a per-user instance of the service manager, the mapping of the “root” user and group to itself is omitted (unless the user manager is root). Additionally, in the per-user instance manager case, the user namespace will be set up before most other namespaces. This means that combining *PrivateUsers=*true with other namespaces will enable use of features not normally supported by the per-user instances of the service manager.
This setting is particularly useful in conjunction with RootDirectory=/RootImage=, as the need to synchronize the user and group databases in the root directory and on the host is reduced, as the only users and groups who need to be matched are “root”, “nobody” and the units own user and group.
Note that the implementation of this setting might be impossible (for example if user namespaces are not available), and the unit should be written in a way that does not solely rely on this setting for security.
Added in version 232.

ProtectHostname=

Takes a boolean argument. When set, sets up a new UTS namespace for the executed processes. In addition, changing hostname or domainname is prevented. Defaults to off.
Note that the implementation of this setting might be impossible (for example if UTS namespaces are not available), and the unit should be written in a way that does not solely rely on this setting for security.
Note that when this option is enabled for a service hostname changes no longer propagate from the system into the service, it is hence not suitable for services that need to take notice of system hostname changes dynamically.
This option is only available for system services, or for services running in per-user instances of the service manager in which case PrivateUsers= is implicitly enabled (requires unprivileged user namespaces support to be enabled in the kernel via the “kernel.unprivileged_userns_clone=” sysctl).
Added in version 242.

ProtectClock=

Takes a boolean argument. If set, writes to the hardware clock or system clock will be denied. Defaults to off. Enabling this option removes CAP_SYS_TIME and CAP_WAKE_ALARM from the capability bounding set for this unit, installs a system call filter to block calls that can set the clock, and DeviceAllow=char-rtc r is implied. Note that the system calls are blocked altogether, the filter does not take into account that some of the calls can be used to read the clock state with some parameter combinations. Effectively, /dev/rtc0, /dev/rtc1, etc. are made read-only to the service. See systemd.resource-control(5) for the details about DeviceAllow=.
It is recommended to turn this on for most services that do not need modify the clock or check its state.
This option is only available for system services, or for services running in per-user instances of the service manager in which case PrivateUsers= is implicitly enabled (requires unprivileged user namespaces support to be enabled in the kernel via the “kernel.unprivileged_userns_clone=” sysctl).
Added in version 245.

ProtectKernelTunables=

Takes a boolean argument. If true, kernel variables accessible through /proc/sys/, /sys/, /proc/sysrq-trigger, /proc/latency_stats, /proc/acpi, /proc/timer_stats, /proc/fs and /proc/irq will be made read-only and /proc/kallsyms as well as /proc/kcore will be inaccessible to all processes of the unit. Usually, tunable kernel variables should be initialized only at boot-time, for example with the sysctl.d(5) mechanism. Few services need to write to these at runtime; it is hence recommended to turn this on for most services. For this setting the same restrictions regarding mount propagation and privileges apply as for ReadOnlyPaths= and related calls, see above. Defaults to off. Note that this option does not prevent indirect changes to kernel tunables effected by IPC calls to other processes. However, InaccessiblePaths= may be used to make relevant IPC file system objects inaccessible. If ProtectKernelTunables= is set, MountAPIVFS=yes is implied.
This option is only available for system services, or for services running in per-user instances of the service manager in which case PrivateUsers= is implicitly enabled (requires unprivileged user namespaces support to be enabled in the kernel via the “kernel.unprivileged_userns_clone=” sysctl).
Added in version 232.

ProtectKernelModules=

Takes a boolean argument. If true, explicit module loading will be denied. This allows module load and unload operations to be turned off on modular kernels. It is recommended to turn this on for most services that do not need special file systems or extra kernel modules to work. Defaults to off. Enabling this option removes CAP_SYS_MODULE from the capability bounding set for the unit, and installs a system call filter to block module system calls, also /usr/lib/modules is made inaccessible. For this setting the same restrictions regarding mount propagation and privileges apply as for ReadOnlyPaths= and related calls, see above. Note that limited automatic module loading due to user configuration or kernel mapping tables might still happen as side effect of requested user operations, both privileged and unprivileged. To disable module auto-load feature please see sysctl.d(5) kernel.modules_disabled mechanism and /proc/sys/kernel/modules_disabled documentation.
This option is only available for system services, or for services running in per-user instances of the service manager in which case PrivateUsers= is implicitly enabled (requires unprivileged user namespaces support to be enabled in the kernel via the “kernel.unprivileged_userns_clone=” sysctl).
Added in version 232.

ProtectKernelLogs=

Takes a boolean argument. If true, access to the kernel log ring buffer will be denied. It is recommended to turn this on for most services that do not need to read from or write to the kernel log ring buffer. Enabling this option removes CAP_SYSLOG from the capability bounding set for this unit, and installs a system call filter to block the syslog(2) system call (not to be confused with the libc API syslog(3) for userspace logging). The kernel exposes its log buffer to userspace via /dev/kmsg and /proc/kmsg. If enabled, these are made inaccessible to all the processes in the unit.
This option is only available for system services, or for services running in per-user instances of the service manager in which case PrivateUsers= is implicitly enabled (requires unprivileged user namespaces support to be enabled in the kernel via the “kernel.unprivileged_userns_clone=” sysctl).
Added in version 244.

ProtectControlGroups=

Takes a boolean argument. If true, the Linux Control Groups (cgroups(7)) hierarchies accessible through /sys/fs/cgroup/ will be made read-only to all processes of the unit. Except for container managers no services should require write access to the control groups hierarchies; it is hence recommended to turn this on for most services. For this setting the same restrictions regarding mount propagation and privileges apply as for ReadOnlyPaths= and related calls, see above. Defaults to off. If ProtectControlGroups= is set, MountAPIVFS=yes is implied.
This option is only available for system services and is not supported for services running in per-user instances of the service manager.
Added in version 232.

RestrictAddressFamilies=

Restricts the set of socket address families accessible to the processes of this unit. Takes “none”, or a space-separated list of address family names to allow-list, such as AF_UNIX, AF_INET or AF_INET6. When “none” is specified, then all address families will be denied. When prefixed with “~” the listed address families will be applied as deny list, otherwise as allow list. Note that this restricts access to the socket(2) system call only. Sockets passed into the process by other means (for example, by using socket activation with socket units, see systemd.socket(5)) are unaffected. Also, sockets created with socketpair() (which creates connected AF_UNIX sockets only) are unaffected. Note that this option has no effect on 32-bit x86, s390, s390x, mips, mips-le, ppc, ppc-le, ppc64, ppc64-le and is ignored (but works correctly on other ABIs, including x86-64). Note that on systems supporting multiple ABIs (such as x86/x86-64) it is recommended to turn off alternative ABIs for services, so that they cannot be used to circumvent the restrictions of this option. Specifically, it is recommended to combine this option with SystemCallArchitectures=native or similar. By default, no restrictions apply, all address families are accessible to processes. If assigned the empty string, any previous address family restriction changes are undone. This setting does not affect commands prefixed with “+”.
Use this option to limit exposure of processes to remote access, in particular via exotic and sensitive network protocols, such as AF_PACKET. Note that in most cases, the local AF_UNIX address family should be included in the configured allow list as it is frequently used for local communication, including for syslog(2) logging.
Added in version 211.

RestrictFileSystems=

Restricts the set of filesystems processes of this unit can open files on. Takes a space-separated list of filesystem names. Any filesystem listed is made accessible to the units processes, access to filesystem types not listed is prohibited (allow-listing). If the first character of the list is “~”, the effect is inverted: access to the filesystems listed is prohibited (deny-listing). If the empty string is assigned, access to filesystems is not restricted.
If you specify both types of this option (i.e. allow-listing and deny-listing), the first encountered will take precedence and will dictate the default action (allow access to the filesystem or deny it). Then the next occurrences of this option will add or delete the listed filesystems from the set of the restricted filesystems, depending on its type and the default action.
Example: if a unit has the following,
RestrictFileSystems=ext4 tmpfs RestrictFileSystems=ext2 ext4
then access to ext4, tmpfs, and ext2 is allowed and access to other filesystems is denied.
Example: if a unit has the following,
RestrictFileSystems=ext4 tmpfs RestrictFileSystems=~ext4
then only access tmpfs is allowed.
Example: if a unit has the following,
RestrictFileSystems=~ext4 tmpfs RestrictFileSystems=ext4
then only access to tmpfs is denied.
As the number of possible filesystems is large, predefined sets of filesystems are provided. A set starts with “@” character, followed by name of the set.
Table 3. Currently predefined filesystem sets
Set Description
@basic-api Basic filesystem API.
@auxiliary-api Auxiliary filesystem API.
@common-block Common block device filesystems.
@historical-block Historical block device filesystems.
@network Well-known network filesystems.
@privileged-api Privileged filesystem API.
@temporary Temporary filesystems: tmpfs, ramfs.
@known All known filesystems defined by the kernel. This list is defined statically in systemd based on a kernel version that was available when this systemd version was released. It will become progressively more out-of-date as the kernel is updated.
Use systemd-analyze(1)s filesystems command to retrieve a list of filesystems defined on the local system.
Note that this setting might not be supported on some systems (for example if the LSM eBPF hook is not enabled in the underlying kernel or if not using the unified control group hierarchy). In that case this setting has no effect.
This option cannot be bypassed by prefixing “+” to the executable path in the service unit, as it applies to the whole control group.
Added in version 250.

RestrictNamespaces=

Restricts access to Linux namespace functionality for the processes of this unit. For details about Linux namespaces, see namespaces(7). Either takes a boolean argument, or a space-separated list of namespace type identifiers. If false (the default), no restrictions on namespace creation and switching are made. If true, access to any kind of namespacing is prohibited. Otherwise, a space-separated list of namespace type identifiers must be specified, consisting of any combination of: cgroup, ipc, net, mnt, pid, user and uts. Any namespace type listed is made accessible to the units processes, access to namespace types not listed is prohibited (allow-listing). By prepending the list with a single tilde character ("") the effect may be inverted: only the listed namespace types will be made inaccessible, all unlisted ones are permitted (deny-listing). If the empty string is assigned, the default namespace restrictions are applied, which is equivalent to false. This option may appear more than once, in which case the namespace types are merged by OR, or by AND if the lines are prefixed with “” (see examples below). Internally, this setting limits access to the unshare(2), clone(2) and setns(2) system calls, taking the specified flags parameters into account. Note that — if this option is used — in addition to restricting creation and switching of the specified types of namespaces (or all of them, if true) access to the setns() system call with a zero flags parameter is prohibited. This setting is only supported on x86, x86-64, mips, mips-le, mips64, mips64-le, mips64-n32, mips64-le-n32, ppc64, ppc64-le, s390 and s390x, and enforces no restrictions on other architectures.
Example: if a unit has the following,
RestrictNamespaces=cgroup ipc RestrictNamespaces=cgroup net
then cgroup, ipc, and net are set. If the second line is prefixed with “~”, e.g.,
RestrictNamespaces=cgroup ipc RestrictNamespaces=~cgroup net
then, only ipc is set.
Added in version 233.

LockPersonality=

Takes a boolean argument. If set, locks down the personality(2) system call so that the kernel execution domain may not be changed from the default or the personality selected with Personality= directive. This may be useful to improve security, because odd personality emulations may be poorly tested and source of vulnerabilities.
Added in version 235.

MemoryDenyWriteExecute=

Takes a boolean argument. If set, attempts to create memory mappings that are writable and executable at the same time, or to change existing memory mappings to become executable, or mapping shared memory segments as executable, are prohibited. Specifically, a system call filter is added (or preferably, an equivalent kernel check is enabled with prctl(2)) that rejects mmap(2) system calls with both PROT_EXEC and PROT_WRITE set, mprotect(2) or pkey_mprotect(2) system calls with PROT_EXEC set and shmat(2) system calls with SHM_EXEC set. Note that this option is incompatible with programs and libraries that generate program code dynamically at runtime, including JIT execution engines, executable stacks, and code “trampoline” feature of various C compilers. This option improves service security, as it makes harder for software exploits to change running code dynamically. However, the protection can be circumvented, if the service can write to a filesystem, which is not mounted with noexec (such as /dev/shm), or it can use memfd_create(). This can be prevented by making such file systems inaccessible to the service (e.g. InaccessiblePaths=/dev/shm) and installing further system call filters (SystemCallFilter=~memfd_create). Note that this feature is fully available on x86-64, and partially on x86. Specifically, the shmat() protection is not available on x86. Note that on systems supporting multiple ABIs (such as x86/x86-64) it is recommended to turn off alternative ABIs for services, so that they cannot be used to circumvent the restrictions of this option. Specifically, it is recommended to combine this option with SystemCallArchitectures=native or similar.
Added in version 231.

RestrictRealtime=

Takes a boolean argument. If set, any attempts to enable realtime scheduling in a process of the unit are refused. This restricts access to realtime task scheduling policies such as SCHED_FIFO, SCHED_RR or SCHED_DEADLINE. See sched(7) for details about these scheduling policies. Realtime scheduling policies may be used to monopolize CPU time for longer periods of time, and may hence be used to lock up or otherwise trigger Denial-of-Service situations on the system. It is hence recommended to restrict access to realtime scheduling to the few programs that actually require them. Defaults to off.
Added in version 231.

RestrictSUIDSGID=

Takes a boolean argument. If set, any attempts to set the set-user-ID (SUID) or set-group-ID (SGID) bits on files or directories will be denied (for details on these bits see inode(7)). As the SUID/SGID bits are mechanisms to elevate privileges, and allow users to acquire the identity of other users, it is recommended to restrict creation of SUID/SGID files to the few programs that actually require them. Note that this restricts marking of any type of file system object with these bits, including both regular files and directories (where the SGID is a different meaning than for files, see documentation). This option is implied if DynamicUser= is enabled. Defaults to off.
Added in version 242.

RemoveIPC=

Takes a boolean parameter. If set, all System V and POSIX IPC objects owned by the user and group the processes of this unit are run as are removed when the unit is stopped. This setting only has an effect if at least one of User=, Group= and DynamicUser= are used. It has no effect on IPC objects owned by the root user. Specifically, this removes System V semaphores, as well as System V and POSIX shared memory segments and message queues. If multiple units use the same user or group the IPC objects are removed when the last of these units is stopped. This setting is implied if DynamicUser= is set.
This option is only available for system services and is not supported for services running in per-user instances of the service manager.
Added in version 232.

PrivateMounts=

Takes a boolean parameter. If set, the processes of this unit will be run in their own private file system (mount) namespace with all mount propagation from the processes towards the hosts main file system namespace turned off. This means any file system mount points established or removed by the units processes will be private to them and not be visible to the host. However, file system mount points established or removed on the host will be propagated to the units processes. See mount_namespaces(7) for details on file system namespaces. Defaults to off.
When turned on, this executes three operations for each invoked process: a new CLONE_NEWNS namespace is created, after which all existing mounts are remounted to MS_SLAVE to disable propagation from the units processes to the host (but leaving propagation in the opposite direction in effect). Finally, the mounts are remounted again to the propagation mode configured with MountFlags=, see below.
File system namespaces are set up individually for each process forked off by the service manager. Mounts established in the namespace of the process created by ExecStartPre= will hence be cleaned up automatically as soon as that process exits and will not be available to subsequent processes forked off for ExecStart= (and similar applies to the various other commands configured for units). Similarly, JoinsNamespaceOf= does not permit sharing kernel mount namespaces between units, it only enables sharing of the /tmp/ and /var/tmp/ directories.
Other file system namespace unit settings — PrivateTmp=, PrivateDevices=, ProtectSystem=, ProtectHome=, ReadOnlyPaths=, InaccessiblePaths=, ReadWritePaths=, BindPaths=, BindReadOnlyPaths=, … — also enable file system namespacing in a fashion equivalent to this option. Hence it is primarily useful to explicitly request this behaviour if none of the other settings are used.
This option is only available for system services, or for services running in per-user instances of the service manager in which case PrivateUsers= is implicitly enabled (requires unprivileged user namespaces support to be enabled in the kernel via the “kernel.unprivileged_userns_clone=” sysctl).
Added in version 239.

MountFlags=

Takes a mount propagation setting: shared, slave or private, which controls whether file system mount points in the file system namespaces set up for this units processes will receive or propagate mounts and unmounts from other file system namespaces. See mount(2) for details on mount propagation, and the three propagation flags in particular.
This setting only controls the final propagation setting in effect on all mount points of the file system namespace created for each process of this unit. Other file system namespacing unit settings (see the discussion in PrivateMounts= above) will implicitly disable mount and unmount propagation from the units processes towards the host by changing the propagation setting of all mount points in the units file system namespace to slave first. Setting this option to shared does not reestablish propagation in that case.
If not set – but file system namespaces are enabled through another file system namespace unit setting – shared mount propagation is used, but — as mentioned — as slave is applied first, propagation from the units processes to the host is still turned off.
It is not recommended to use private mount propagation for units, as this means temporary mounts (such as removable media) of the host will stay mounted and thus indefinitely busy in forked off processes, as unmount propagation events wont be received by the file system namespace of the unit.
Usually, it is best to leave this setting unmodified, and use higher level file system namespacing options instead, in particular PrivateMounts=, see above.
This option is only available for system services, or for services running in per-user instances of the service manager in which case PrivateUsers= is implicitly enabled (requires unprivileged user namespaces support to be enabled in the kernel via the “kernel.unprivileged_userns_clone=” sysctl).

SYSTEM CALL FILTERING

SystemCallFilter=

Takes a space-separated list of system call names. If this setting is used, all system calls executed by the unit processes except for the listed ones will result in immediate process termination with the SIGSYS signal (allow-listing). (See SystemCallErrorNumber= below for changing the default action). If the first character of the list is “~”, the effect is inverted: only the listed system calls will result in immediate process termination (deny-listing). Deny-listed system calls and system call groups may optionally be suffixed with a colon (":") and “errno” error number (between 0 and 4095) or errno name such as EPERM, EACCES or EUCLEAN (see errno(3) for a full list). This value will be returned when a deny-listed system call is triggered, instead of terminating the processes immediately. Special setting “kill” can be used to explicitly specify killing. This value takes precedence over the one given in SystemCallErrorNumber=, see below. This feature makes use of the Secure Computing Mode 2 interfaces of the kernel (seccomp filtering) and is useful for enforcing a minimal sandboxing environment. Note that the execve(), exit(), exit_group(), getrlimit(), rt_sigreturn(), sigreturn() system calls and the system calls for querying time and sleeping are implicitly allow-listed and do not need to be listed explicitly. This option may be specified more than once, in which case the filter masks are merged. If the empty string is assigned, the filter is reset, all prior assignments will have no effect. This does not affect commands prefixed with “+”.
Note that on systems supporting multiple ABIs (such as x86/x86-64) it is recommended to turn off alternative ABIs for services, so that they cannot be used to circumvent the restrictions of this option. Specifically, it is recommended to combine this option with SystemCallArchitectures=native or similar.
Note that strict system call filters may impact execution and error handling code paths of the service invocation. Specifically, access to the execve() system call is required for the execution of the service binary — if it is blocked service invocation will necessarily fail. Also, if execution of the service binary fails for some reason (for example: missing service executable), the error handling logic might require access to an additional set of system calls in order to process and log this failure correctly. It might be necessary to temporarily disable system call filters in order to simplify debugging of such failures.
If you specify both types of this option (i.e. allow-listing and deny-listing), the first encountered will take precedence and will dictate the default action (termination or approval of a system call). Then the next occurrences of this option will add or delete the listed system calls from the set of the filtered system calls, depending of its type and the default action. (For example, if you have started with an allow list rule for read() and write(), and right after it add a deny list rule for write(), then write() will be removed from the set.)
As the number of possible system calls is large, predefined sets of system calls are provided. A set starts with “@” character, followed by name of the set.
Table 4. Currently predefined system call sets
Set Description
@aio Asynchronous I/O (io_setup(2), io_submit(2), and related calls)
@basic-io System calls for basic I/O: reading, writing, seeking, file descriptor duplication and closing (read(2), write(2), and related calls)
@chown Changing file ownership (chown(2), fchownat(2), and related calls)
@clock System calls for changing the system clock (adjtimex(2), settimeofday(2), and related calls)
@cpu-emulation System calls for CPU emulation functionality (vm86(2) and related calls)
@debug Debugging, performance monitoring and tracing functionality (ptrace(2), perf_event_open(2) and related calls)
@file-system File system operations: opening, creating files and directories for read and write, renaming and removing them, reading file properties, or creating hard and symbolic links
@io-event Event loop system calls (poll(2), select(2), epoll(7), eventfd(2) and related calls)
@ipc Pipes, SysV IPC, POSIX Message Queues and other IPC (mq_overview(7), svipc(7))
@keyring Kernel keyring access (keyctl(2) and related calls)
@memlock Locking of memory in RAM (mlock(2), mlockall(2) and related calls)
@module Loading and unloading of kernel modules (init_module(2), delete_module(2) and related calls)
@mount Mounting and unmounting of file systems (mount(2), chroot(2), and related calls)
@network-io Socket I/O (including local AF_UNIX): socket(7), unix(7)
@obsolete Unusual, obsolete or unimplemented (create_module(2), gtty(2), ...)
@pkey System calls that deal with memory protection keys (pkeys(7))
@privileged All system calls which need super-user capabilities (capabilities(7))
@process Process control, execution, namespacing operations (clone(2), kill(2), namespaces(7), ...)
@raw-io Raw I/O port access (ioperm(2), iopl(2), pciconfig_read(), ...)
@reboot System calls for rebooting and reboot preparation (reboot(2), kexec(), ...)
@resources System calls for changing resource limits, memory and scheduling parameters (setrlimit(2), setpriority(2), ...)
@sandbox System calls for sandboxing programs (seccomp(2), Landlock system calls, ...)
@setuid System calls for changing user ID and group ID credentials, (setuid(2), setgid(2), setresuid(2), ...)
@signal System calls for manipulating and handling process signals (signal(2), sigprocmask(2), ...)
@swap System calls for enabling/disabling swap devices (swapon(2), swapoff(2))
@sync Synchronizing files and memory to disk (fsync(2), msync(2), and related calls)
@system-service A reasonable set of system calls used by common system services, excluding any special purpose calls. This is the recommended starting point for allow-listing system calls for system services, as it contains what is typically needed by system services, but excludes overly specific interfaces. For example, the following APIs are excluded: "@clock", "@mount", "@swap", "@reboot".
@timer System calls for scheduling operations by time (alarm(2), timer_create(2), ...)
@known All system calls defined by the kernel. This list is defined statically in systemd based on a kernel version that was available when this systemd version was released. It will become progressively more out-of-date as the kernel is updated.
Note, that as new system calls are added to the kernel, additional system calls might be added to the groups above. Contents of the sets may also change between systemd versions. In addition, the list of system calls depends on the kernel version and architecture for which systemd was compiled. Use systemd-analyze syscall-filter to list the actual list of system calls in each filter.
Generally, allow-listing system calls (rather than deny-listing) is the safer mode of operation. It is recommended to enforce system call allow lists for all long-running system services. Specifically, the following lines are a relatively safe basic choice for the majority of system services:
[Service] SystemCallFilter=@system-service SystemCallErrorNumber=EPERM
Note that various kernel system calls are defined redundantly: there are multiple system calls for executing the same operation. For example, the pidfd_send_signal() system call may be used to execute operations similar to what can be done with the older kill() system call, hence blocking the latter without the former only provides weak protection. Since new system calls are added regularly to the kernel as development progresses, keeping system call deny lists comprehensive requires constant work. It is thus recommended to use allow-listing instead, which offers the benefit that new system calls are by default implicitly blocked until the allow list is updated.
Also note that a number of system calls are required to be accessible for the dynamic linker to work. The dynamic linker is required for running most regular programs (specifically: all dynamic ELF binaries, which is how most distributions build packaged programs). This means that blocking these system calls (which include open(), openat() or mmap()) will make most programs typically shipped with generic distributions unusable.
It is recommended to combine the file system namespacing related options with SystemCallFilter=~@mount, in order to prohibit the units processes to undo the mappings. Specifically these are the options PrivateTmp=, PrivateDevices=, ProtectSystem=, ProtectHome=, ProtectKernelTunables=, ProtectControlGroups=, ProtectKernelLogs=, ProtectClock=, ReadOnlyPaths=, InaccessiblePaths= and ReadWritePaths=.
Added in version 187.

SystemCallErrorNumber=

Takes an “errno” error number (between 1 and 4095) or errno name such as EPERM, EACCES or EUCLEAN, to return when the system call filter configured with SystemCallFilter= is triggered, instead of terminating the process immediately. See errno(3) for a full list of error codes. When this setting is not used, or when the empty string or the special setting “kill” is assigned, the process will be terminated immediately when the filter is triggered.
Added in version 209.

SystemCallArchitectures=

Takes a space-separated list of architecture identifiers to include in the system call filter. The known architecture identifiers are the same as for ConditionArchitecture= described in systemd.unit(5), as well as x32, mips64-n32, mips64-le-n32, and the special identifier native. The special identifier native implicitly maps to the native architecture of the system (or more precisely: to the architecture the system manager is compiled for). By default, this option is set to the empty list, i.e. no filtering is applied.
If this setting is used, processes of this unit will only be permitted to call native system calls, and system calls of the specified architectures. For the purposes of this option, the x32 architecture is treated as including x86-64 system calls. However, this setting still fulfills its purpose, as explained below, on x32.
System call filtering is not equally effective on all architectures. For example, on x86 filtering of network socket-related calls is not possible, due to ABI limitations — a limitation that x86-64 does not have, however. On systems supporting multiple ABIs at the same time — such as x86/x86-64 — it is hence recommended to limit the set of permitted system call architectures so that secondary ABIs may not be used to circumvent the restrictions applied to the native ABI of the system. In particular, setting SystemCallArchitectures=native is a good choice for disabling non-native ABIs.
System call architectures may also be restricted system-wide via the SystemCallArchitectures= option in the global configuration. See systemd-system.conf(5) for details.
Added in version 209.

SystemCallLog=

Takes a space-separated list of system call names. If this setting is used, all system calls executed by the unit processes for the listed ones will be logged. If the first character of the list is “~”, the effect is inverted: all system calls except the listed system calls will be logged. This feature makes use of the Secure Computing Mode 2 interfaces of the kernel (seccomp filtering) and is useful for auditing or setting up a minimal sandboxing environment. This option may be specified more than once, in which case the filter masks are merged. If the empty string is assigned, the filter is reset, all prior assignments will have no effect. This does not affect commands prefixed with “+”.
Added in version 247.

ENVIRONMENT

Environment=

Sets environment variables for executed processes. Each line is unquoted using the rules described in “Quoting” section in systemd.syntax(7) and becomes a list of variable assignments. If you need to assign a value containing spaces or the equals sign to a variable, put quotes around the whole assignment. Variable expansion is not performed inside the strings and the “$” character has no special meaning. Specifier expansion is performed, see the “Specifiers” section in systemd.unit(5).
This option may be specified more than once, in which case all listed variables will be set. If the same variable is listed twice, the later setting will override the earlier setting. If the empty string is assigned to this option, the list of environment variables is reset, all prior assignments have no effect.
The names of the variables can contain ASCII letters, digits, and the underscore character. Variable names cannot be empty or start with a digit. In variable values, most characters are allowed, but non-printable characters are currently rejected.
Example:
Environment=“VAR1=word1 word2” VAR2=word3 “VAR3=$word 5 6”
gives three variables “VAR1”, “VAR2”, “VAR3” with the values “word1 word2”, “word3”, “$word 5 6”.
See environ(7) for details about environment variables.
Note that environment variables are not suitable for passing secrets (such as passwords, key material, …) to service processes. Environment variables set for a unit are exposed to unprivileged clients via D-Bus IPC, and generally not understood as being data that requires protection. Moreover, environment variables are propagated down the process tree, including across security boundaries (such as setuid/setgid executables), and hence might leak to processes that should not have access to the secret data. Use LoadCredential=, LoadCredentialEncrypted= or SetCredentialEncrypted= (see below) to pass data to unit processes securely.

EnvironmentFile=

Similar to Environment=, but reads the environment variables from a text file. The text file should contain newline-separated variable assignments. Empty lines, lines without an “=” separator, or lines starting with “;” or “#” will be ignored, which may be used for commenting. The file must be encoded with UTF-8. Valid characters are unicode scalar values[8] other than unicode noncharacters[9], U+0000 NUL, and U+FEFF unicode byte order mark[10]. Control codes other than NUL are allowed.
In the file, an unquoted value after the “=” is parsed with the same backslash-escape rules as POSIX shell unquoted text[11], but unlike in a shell, interior whitespace is preserved and quotes after the first non-whitespace character are preserved. Leading and trailing whitespace (space, tab, carriage return) is discarded, but interior whitespace within the line is preserved verbatim. A line ending with a backslash will be continued to the following one, with the newline itself discarded. A backslash “\ followed by any character other than newline will preserve the following character, so that “" will become the value “.
In the file, a “"-quoted value after the “=” can span multiple lines and contain any character verbatim other than single quote, like POSIX shell single-quoted text[12]. No backslash-escape sequences are recognized. Leading and trailing whitespace outside of the single quotes is discarded.
In the file, a “”"-quoted value after the “=” can span multiple lines, and the same escape sequences are recognized as in POSIX shell double-quoted text[13]. Backslash (”) followed by any of “”$” will preserve that character. A backslash followed by newline is a line continuation, and the newline itself is discarded. A backslash followed by any other character is ignored; both the backslash and the following character are preserved verbatim. Leading and trailing whitespace outside of the double quotes is discarded.
The argument passed should be an absolute filename or wildcard expression, optionally prefixed with “-”, which indicates that if the file does not exist, it will not be read and no error or warning message is logged. This option may be specified more than once in which case all specified files are read. If the empty string is assigned to this option, the list of file to read is reset, all prior assignments have no effect.
The files listed with this directive will be read shortly before the process is executed (more specifically, after all processes from a previous unit state terminated. This means you can generate these files in one unit state, and read it with this option in the next. The files are read from the file system of the service manager, before any file system changes like bind mounts take place).
Settings from these files override settings made with Environment=. If the same variable is set twice from these files, the files will be read in the order they are specified and the later setting will override the earlier setting.

PassEnvironment=

Pass environment variables set for the system service manager to executed processes. Takes a space-separated list of variable names. This option may be specified more than once, in which case all listed variables will be passed. If the empty string is assigned to this option, the list of environment variables to pass is reset, all prior assignments have no effect. Variables specified that are not set for the system manager will not be passed and will be silently ignored. Note that this option is only relevant for the system service manager, as system services by default do not automatically inherit any environment variables set for the service manager itself. However, in case of the user service manager all environment variables are passed to the executed processes anyway, hence this option is without effect for the user service manager.
Variables set for invoked processes due to this setting are subject to being overridden by those configured with Environment= or EnvironmentFile=.
Example:
PassEnvironment=VAR1 VAR2 VAR3
passes three variables “VAR1”, “VAR2”, “VAR3” with the values set for those variables in PID1.
See environ(7) for details about environment variables.
Added in version 228.

UnsetEnvironment=

Explicitly unset environment variable assignments that would normally be passed from the service manager to invoked processes of this unit. Takes a space-separated list of variable names or variable assignments. This option may be specified more than once, in which case all listed variables/assignments will be unset. If the empty string is assigned to this option, the list of environment variables/assignments to unset is reset. If a variable assignment is specified (that is: a variable name, followed by “=”, followed by its value), then any environment variable matching this precise assignment is removed. If a variable name is specified (that is a variable name without any following “=” or value), then any assignment matching the variable name, regardless of its value is removed. Note that the effect of UnsetEnvironment= is applied as final step when the environment list passed to executed processes is compiled. That means it may undo assignments from any configuration source, including assignments made through Environment= or EnvironmentFile=, inherited from the system managers global set of environment variables, inherited via PassEnvironment=, set by the service manager itself (such as $NOTIFY_SOCKET and such), or set by a PAM module (in case PAMName= is used).
See “Environment Variables in Spawned Processes” below for a description of how those settings combine to form the inherited environment. See environ(7) for general information about environment variables.
Added in version 235.

LOGGING AND STANDARD INPUT/OUTPUT

StandardInput=

Controls where file descriptor 0 (STDIN) of the executed processes is connected to. Takes one of null, tty, tty-force, tty-fail, data, **file:**path, socket or **fd:**name.
If null is selected, standard input will be connected to /dev/null, i.e. all read attempts by the process will result in immediate EOF.
If tty is selected, standard input is connected to a TTY (as configured by TTYPath=, see below) and the executed process becomes the controlling process of the terminal. If the terminal is already being controlled by another process, the executed process waits until the current controlling process releases the terminal.
tty-force is similar to tty, but the executed process is forcefully and immediately made the controlling process of the terminal, potentially removing previous controlling processes from the terminal.
tty-fail is similar to tty, but if the terminal already has a controlling process start-up of the executed process fails.
The data option may be used to configure arbitrary textual or binary data to pass via standard input to the executed process. The data to pass is configured via StandardInputText=/StandardInputData= (see below). Note that the actual file descriptor type passed (memory file, regular file, UNIX pipe, …) might depend on the kernel and available privileges. In any case, the file descriptor is read-only, and when read returns the specified data followed by EOF.
The **file:**path option may be used to connect a specific file system object to standard input. An absolute path following the “:” character is expected, which may refer to a regular file, a FIFO or special file. If an AF_UNIX socket in the file system is specified, a stream socket is connected to it. The latter is useful for connecting standard input of processes to arbitrary system services.
The socket option is valid in socket-activated services only, and requires the relevant socket unit file (see systemd.socket(5) for details) to have Accept=yes set, or to specify a single socket only. If this option is set, standard input will be connected to the socket the service was activated from, which is primarily useful for compatibility with daemons designed for use with the traditional inetd(8) socket activation daemon ($LISTEN_FDS (and related) environment variables are not passed when socket value is configured).
The **fd:**name option connects standard input to a specific, named file descriptor provided by a socket unit. The name may be specified as part of this option, following a “:” character (e.g. “fd:foobar”). If no name is specified, the name “stdin” is implied (i.e. “fd” is equivalent to “fd:stdin”). At least one socket unit defining the specified name must be provided via the Sockets= option, and the file descriptor name may differ from the name of its containing socket unit. If multiple matches are found, the first one will be used. See FileDescriptorName= in systemd.socket(5) for more details about named file descriptors and their ordering.
This setting defaults to null, unless StandardInputText=/StandardInputData= are set, in which case it defaults to data.

StandardOutput=

Controls where file descriptor 1 (stdout) of the executed processes is connected to. Takes one of inherit, null, tty, journal, kmsg, journal+console, kmsg+console, **file:**path, **append:**path, **truncate:**path, socket or **fd:**name.
inherit duplicates the file descriptor of standard input for standard output.
null connects standard output to /dev/null, i.e. everything written to it will be lost.
tty connects standard output to a tty (as configured via TTYPath=, see below). If the TTY is used for output only, the executed process will not become the controlling process of the terminal, and will not fail or wait for other processes to release the terminal.
journal connects standard output with the journal, which is accessible via journalctl(1). Note that everything that is written to kmsg (see below) is implicitly stored in the journal as well, the specific option listed below is hence a superset of this one. (Also note that any external, additional syslog daemons receive their log data from the journal, too, hence this is the option to use when logging shall be processed with such a daemon.)
kmsg connects standard output with the kernel log buffer which is accessible via dmesg(1), in addition to the journal. The journal daemon might be configured to send all logs to kmsg anyway, in which case this option is no different from journal.
journal+console and kmsg+console work in a similar way as the two options above but copy the output to the system console as well.
The **file:**path option may be used to connect a specific file system object to standard output. The semantics are similar to the same option of StandardInput=, see above. If path refers to a regular file on the filesystem, it is opened (created if it doesnt exist yet using privileges of the user executing the systemd process) for writing at the beginning of the file, but without truncating it. If standard input and output are directed to the same file path, it is opened only once — for reading as well as writing — and duplicated. This is particularly useful when the specified path refers to an AF_UNIX socket in the file system, as in that case only a single stream connection is created for both input and output.
**append:**path is similar to **file:**path above, but it opens the file in append mode.
**truncate:**path is similar to **file:**path above, but it truncates the file when opening it. For units with multiple command lines, e.g. Type=oneshot services with multiple ExecStart=, or services with ExecCondition=, ExecStartPre= or ExecStartPost=, the output file is reopened and therefore re-truncated for each command line. If the output file is truncated while another process still has the file open, e.g. by an ExecReload= running concurrently with an ExecStart=, and the other process continues writing to the file without adjusting its offset, then the space between the file pointers of the two processes may be filled with NUL bytes, producing a sparse file. Thus, **truncate:**path is typically only useful for units where only one process runs at a time, such as services with a single ExecStart= and no ExecStartPost=, ExecReload=, ExecStop= or similar.
socket connects standard output to a socket acquired via socket activation. The semantics are similar to the same option of StandardInput=, see above.
The **fd:**name option connects standard output to a specific, named file descriptor provided by a socket unit. A name may be specified as part of this option, following a “:” character (e.g. “fd:foobar”). If no name is specified, the name “stdout” is implied (i.e. “fd” is equivalent to “fd:stdout”). At least one socket unit defining the specified name must be provided via the Sockets= option, and the file descriptor name may differ from the name of its containing socket unit. If multiple matches are found, the first one will be used. See FileDescriptorName= in systemd.socket(5) for more details about named descriptors and their ordering.
If the standard output (or error output, see below) of a unit is connected to the journal or the kernel log buffer, the unit will implicitly gain a dependency of type After= on systemd-journald.socket (also see the “Implicit Dependencies” section above). Also note that in this case stdout (or stderr, see below) will be an AF_UNIX stream socket, and not a pipe or FIFO that can be reopened. This means when executing shell scripts the construct echo “hello” > /dev/stderr for writing text to stderr will not work. To mitigate this use the construct echo “hello” >&2 instead, which is mostly equivalent and avoids this pitfall.
If StandardInput= is set to one of tty, tty-force, tty-fail, socket, or **fd:**name, this setting defaults to inherit.
In other cases, this setting defaults to the value set with DefaultStandardOutput= in systemd-system.conf(5), which defaults to journal. Note that setting this parameter might result in additional dependencies to be added to the unit (see above).

StandardError=

Controls where file descriptor 2 (stderr) of the executed processes is connected to. The available options are identical to those of StandardOutput=, with some exceptions: if set to inherit the file descriptor used for standard output is duplicated for standard error, while **fd:**name will use a default file descriptor name of “stderr”.
This setting defaults to the value set with DefaultStandardError= in systemd-system.conf(5), which defaults to inherit. Note that setting this parameter might result in additional dependencies to be added to the unit (see above).

StandardInputText=, StandardInputData=

Configures arbitrary textual or binary data to pass via file descriptor 0 (STDIN) to the executed processes. These settings have no effect unless StandardInput= is set to data (which is the default if StandardInput= is not set otherwise, but StandardInputText=/StandardInputData= is). Use this option to embed process input data directly in the unit file.
StandardInputText= accepts arbitrary textual data. C-style escapes for special characters as well as the usual “%"-specifiers are resolved. Each time this setting is used the specified text is appended to the per-unit data buffer, followed by a newline character (thus every use appends a new line to the end of the buffer). Note that leading and trailing whitespace of lines configured with this option is removed. If an empty line is specified the buffer is cleared (hence, in order to insert an empty line, add an additional " " to the end or beginning of a line).
StandardInputData= accepts arbitrary binary data, encoded in Base64[14]. No escape sequences or specifiers are resolved. Any whitespace in the encoded version is ignored during decoding.
Note that StandardInputText= and StandardInputData= operate on the same data buffer, and may be mixed in order to configure both binary and textual data for the same input stream. The textual or binary data is joined strictly in the order the settings appear in the unit file. Assigning an empty string to either will reset the data buffer.
Please keep in mind that in order to maintain readability long unit file settings may be split into multiple lines, by suffixing each line (except for the last) with a “\ character (see systemd.unit(5) for details). This is particularly useful for large data configured with these two options. Example:
… StandardInput=data StandardInputData=V2XigLJyZSBubyBzdHJhbmdlcnMgdG8gbG92ZQpZb3Uga25vdyB0aGUgcnVsZXMgYW5kIHNvIGRv
IEkKQSBmdWxsIGNvbW1pdG1lbnQncyB3aGF0IEnigLJtIHRoaW5raW5nIG9mCllvdSB3b3VsZG4n
dCBnZXQgdGhpcyBmcm9tIGFueSBvdGhlciBndXkKSSBqdXN0IHdhbm5hIHRlbGwgeW91IGhvdyBJ
J20gZmVlbGluZwpHb3R0YSBtYWtlIHlvdSB1bmRlcnN0YW5kCgpOZXZlciBnb25uYSBnaXZlIHlv
dSB1cApOZXZlciBnb25uYSBsZXQgeW91IGRvd24KTmV2ZXIgZ29ubmEgcnVuIGFyb3VuZCBhbmQg
ZGVzZXJ0IHlvdQpOZXZlciBnb25uYSBtYWtlIHlvdSBjcnkKTmV2ZXIgZ29ubmEgc2F5IGdvb2Ri
eWUKTmV2ZXIgZ29ubmEgdGVsbCBhIGxpZSBhbmQgaHVydCB5b3UK …
Added in version 236.

LogLevelMax=

Configures filtering by log level of log messages generated by this unit. Takes a syslog log level, one of emerg (lowest log level, only highest priority messages), alert, crit, err, warning, notice, info, debug (highest log level, also lowest priority messages). See syslog(3) for details. By default no filtering is applied (i.e. the default maximum log level is debug). Use this option to configure the logging system to drop log messages of a specific service above the specified level. For example, set *LogLevelMax=*info in order to turn off debug logging of a particularly chatty unit. Note that the configured level is applied to any log messages written by any of the processes belonging to this unit, as well as any log messages written by the system manager process (PID 1) in reference to this unit, sent via any supported logging protocol. The filtering is applied early in the logging pipeline, before any kind of further processing is done. Moreover, messages which pass through this filter successfully might still be dropped by filters applied at a later stage in the logging subsystem. For example, MaxLevelStore= configured in journald.conf(5) might prohibit messages of higher log levels to be stored on disk, even though the per-unit LogLevelMax= permitted it to be processed.
Added in version 236.

LogExtraFields=

Configures additional log metadata fields to include in all log records generated by processes associated with this unit, including systemd. This setting takes one or more journal field assignments in the format “FIELD=VALUE” separated by whitespace. See systemd.journal-fields(7) for details on the journal field concept. Even though the underlying journal implementation permits binary field values, this setting accepts only valid UTF-8 values. To include space characters in a journal field value, enclose the assignment in double quotes (”). The usual specifiers are expanded in all assignments (see below). Note that this setting is not only useful for attaching additional metadata to log records of a unit, but given that all fields and values are indexed may also be used to implement cross-unit log record matching. Assign an empty string to reset the list.
Note that this functionality is currently only available in system services, not in per-user services.
Added in version 236.

LogRateLimitIntervalSec=, LogRateLimitBurst=

Configures the rate limiting that is applied to log messages generated by this unit. If, in the time interval defined by LogRateLimitIntervalSec=, more messages than specified in LogRateLimitBurst= are logged by a service, all further messages within the interval are dropped until the interval is over. A message about the number of dropped messages is generated. The time specification for LogRateLimitIntervalSec= may be specified in the following units: “s”, “min”, “h”, “ms”, “us”. See systemd.time(7) for details. The default settings are set by RateLimitIntervalSec= and RateLimitBurst= configured in journald.conf(5). Note that this only applies to log messages that are processed by the logging subsystem, i.e. by systemd-journald.service(8). This means that if you connect a services stderr directly to a file via StandardOutput=file:… or a similar setting, the rate limiting will not be applied to messages written that way (but it will be enforced for messages generated via syslog(3) and similar functions).
Added in version 240.

LogFilterPatterns=

Define an extended regular expression to filter log messages based on the MESSAGE= field of the structured message. If the first character of the pattern is “~”, log entries matching the pattern should be discarded. This option takes a single pattern as an argument but can be used multiple times to create a list of allowed and denied patterns. If the empty string is assigned, the filter is reset, and all prior assignments will have no effect.
Because the “~~” character is used to define denied patterns, it must be replaced with “~~” to allow a message starting with “~”. For example, “~foobar” would add a pattern matching “foobar” to the deny list, while “~foobar” would add a pattern matching “~foobar” to the allow list.
Log messages are tested against denied patterns (if any), then against allowed patterns (if any). If a log message matches any of the denied patterns, it is discarded immediately without considering allowed patterns. Remaining log messages are tested against allowed patterns. Messages matching against none of the allowed pattern are discarded. If no allowed patterns are defined, then all messages are processed directly after going through denied filters.
Filtering is based on the unit for which LogFilterPatterns= is defined, meaning log messages coming from systemd(1) about the unit are not taken into account. Filtered log messages wont be forwarded to traditional syslog daemons, the kernel log buffer (kmsg), the systemd console, or sent as wall messages to all logged-in users.
Note that this functionality is currently only available in system services, not in per-user services.
Added in version 253.

LogNamespace=

Run the units processes in the specified journal namespace. Expects a short user-defined string identifying the namespace. If not used the processes of the service are run in the default journal namespace, i.e. their log stream is collected and processed by systemd-journald.service. If this option is used any log data generated by processes of this unit (regardless if via the syslog(), journal native logging or stdout/stderr logging) is collected and processed by an instance of the [email protected] template unit, which manages the specified namespace. The log data is stored in a data store independent from the default log namespaces data store. See systemd-journald.service(8) for details about journal namespaces.
Internally, journal namespaces are implemented through Linux mount namespacing and over-mounting the directory that contains the relevant AF_UNIX sockets used for logging in the units mount namespace. Since mount namespaces are used this setting disconnects propagation of mounts from the units processes to the host, similarly to how ReadOnlyPaths= and similar settings describe above work. Journal namespaces may hence not be used for services that need to establish mount points on the host.
When this option is used the unit will automatically gain ordering and requirement dependencies on the two socket units associated with the [email protected] instance so that they are automatically established prior to the unit starting up. Note that when this option is used log output of this service does not appear in the regular journalctl(1) output, unless the –namespace= option is used.
This option is only available for system services and is not supported for services running in per-user instances of the service manager.
Added in version 245.

SyslogIdentifier=

Sets the process name (”syslog tag”) to prefix log lines sent to the logging system or the kernel log buffer with. If not set, defaults to the process name of the executed process. This option is only useful when StandardOutput= or StandardError= are set to journal or kmsg (or to the same settings in combination with +console) and only applies to log messages written to stdout or stderr.

SyslogFacility=

Sets the syslog facility identifier to use when logging. One of kern, user, mail, daemon, auth, syslog, lpr, news, uucp, cron, authpriv, ftp, local0, local1, local2, local3, local4, local5, local6 or local7. See syslog(3) for details. This option is only useful when StandardOutput= or StandardError= are set to journal or kmsg (or to the same settings in combination with +console), and only applies to log messages written to stdout or stderr. Defaults to daemon.

SyslogLevel=

The default syslog log level to use when logging to the logging system or the kernel log buffer. One of emerg, alert, crit, err, warning, notice, info, debug. See syslog(3) for details. This option is only useful when StandardOutput= or StandardError= are set to journal or kmsg (or to the same settings in combination with +console), and only applies to log messages written to stdout or stderr. Note that individual lines output by executed processes may be prefixed with a different log level which can be used to override the default log level specified here. The interpretation of these prefixes may be disabled with SyslogLevelPrefix=, see below. For details, see sd-daemon(3). Defaults to info.

SyslogLevelPrefix=

Takes a boolean argument. If true and StandardOutput= or StandardError= are set to journal or kmsg (or to the same settings in combination with +console), log lines written by the executed process that are prefixed with a log level will be processed with this log level set but the prefix removed. If set to false, the interpretation of these prefixes is disabled and the logged lines are passed on as-is. This only applies to log messages written to stdout or stderr. For details about this prefixing see sd-daemon(3). Defaults to true.

TTYPath=

Sets the terminal device node to use if standard input, output, or error are connected to a TTY (see above). Defaults to /dev/console.

TTYReset=

Reset the terminal device specified with TTYPath= before and after execution. Defaults to “no”.

TTYVHangup=

Disconnect all clients which have opened the terminal device specified with TTYPath= before and after execution. Defaults to “no”.

TTYRows=, TTYColumns=

Configure the size of the TTY specified with TTYPath=. If unset or set to the empty string, the kernel default is used.
Added in version 250.

TTYVTDisallocate=

If the terminal device specified with TTYPath= is a virtual console terminal, try to deallocate the TTY before and after execution. This ensures that the screen and scrollback buffer is cleared. Defaults to “no”.

CREDENTIALS

LoadCredential=ID[:PATH], LoadCredentialEncrypted=ID[:PATH]

Pass a credential to the unit. Credentials are limited-size binary or textual objects that may be passed to unit processes. They are primarily used for passing cryptographic keys (both public and private) or certificates, user account information or identity information from host to services. The data is accessible from the units processes via the file system, at a read-only location that (if possible and permitted) is backed by non-swappable memory. The data is only accessible to the user associated with the unit, via the User=/DynamicUser= settings (as well as the superuser). When available, the location of credentials is exported as the $CREDENTIALS_DIRECTORY environment variable to the units processes.
The LoadCredential= setting takes a textual ID to use as name for a credential plus a file system path, separated by a colon. The ID must be a short ASCII string suitable as filename in the filesystem, and may be chosen freely by the user. If the specified path is absolute it is opened as regular file and the credential data is read from it. If the absolute path refers to an AF_UNIX stream socket in the file system a connection is made to it (only once at unit start-up) and the credential data read from the connection, providing an easy IPC integration point for dynamically transferring credentials from other services.
If the specified path is not absolute and itself qualifies as valid credential identifier it is attempted to find a credential that the service manager itself received under the specified name — which may be used to propagate credentials from an invoking environment (e.g. a container manager that invoked the service manager) into a service. If no matching system credential is found, the directories /etc/credstore/, /run/credstore/ and /usr/lib/credstore/ are searched for files under the credentials name — which hence are recommended locations for credential data on disk. If LoadCredentialEncrypted= is used /run/credstore.encrypted/, /etc/credstore.encrypted/, and /usr/lib/credstore.encrypted/ are searched as well.
If the file system path is omitted it is chosen identical to the credential name, i.e. this is a terse way to declare credentials to inherit from the service manager into a service. This option may be used multiple times, each time defining an additional credential to pass to the unit.
Note that if the path is not specified or a valid credential identifier is given, i.e. in the above two cases, a missing credential is not considered fatal.
If an absolute path referring to a directory is specified, every file in that directory (recursively) will be loaded as a separate credential. The ID for each credential will be the provided ID suffixed with “_$FILENAME” (e.g., “Key_file1”). When loading from a directory, symlinks will be ignored.
The contents of the file/socket may be arbitrary binary or textual data, including newline characters and NUL bytes.
The LoadCredentialEncrypted= setting is identical to LoadCredential=, except that the credential data is decrypted and authenticated before being passed on to the executed processes. Specifically, the referenced path should refer to a file or socket with an encrypted credential, as implemented by systemd-creds(1). This credential is loaded, decrypted, authenticated and then passed to the application in plaintext form, in the same way a regular credential specified via LoadCredential= would be. A credential configured this way may be symmetrically encrypted/authenticated with a secret key derived from the systems TPM2 security chip, or with a secret key stored in /var/lib/systemd/credentials.secret, or with both. Using encrypted and authenticated credentials improves security as credentials are not stored in plaintext and only authenticated and decrypted into plaintext the moment a service requiring them is started. Moreover, credentials may be bound to the local hardware and installations, so that they cannot easily be analyzed offline, or be generated externally. When DevicePolicy= is set to “closed” or “strict”, or set to “auto” and DeviceAllow= is set, or PrivateDevices= is set, then this setting adds /dev/tpmrm0 with rw mode to DeviceAllow=. See systemd.resource-control(5) for the details about DevicePolicy= or DeviceAllow=.
Note that encrypted credentials targeted for services of the per-user service manager must be encrypted with systemd-creds encrypt –user, and those for the system service manager without the –user switch. Encrypted credentials are always targeted to a specific user or the system as a whole, and it is ensured that per-user service managers cannot decrypt secrets intended for the system or for other users.
The credential files/IPC sockets must be accessible to the service manager, but dont have to be directly accessible to the units processes: the credential data is read and copied into separate, read-only copies for the unit that are accessible to appropriately privileged processes. This is particularly useful in combination with DynamicUser= as this way privileged data can be made available to processes running under a dynamic UID (i.e. not a previously known one) without having to open up access to all users.
In order to reference the path a credential may be read from within a ExecStart= command line use “${CREDENTIALS_DIRECTORY}/mycred”, e.g. “ExecStart=cat ${CREDENTIALS_DIRECTORY}/mycred”. In order to reference the path a credential may be read from within a Environment= line use “%d/mycred”, e.g. “Environment=MYCREDPATH=%d/mycred”. For system services the path may also be referenced as “/run/credentials/UNITNAME” in cases where no interpolation is possible, e.g. configuration files of software that does not yet support credentials natively. $CREDENTIALS_DIRECTORY is considered the primary interface to look for credentials, though, since it also works for user services.
Currently, an accumulated credential size limit of 1 MB per unit is enforced.
The service manager itself may receive system credentials that can be propagated to services from a hosting container manager or VM hypervisor. See the Container Interface[15] documentation for details about the former. For the latter, pass DMI/SMBIOS[16] OEM string table entries (field type 11) with a prefix of “io.systemd.credential:” or “io.systemd.credential.binary:”. In both cases a key/value pair separated by “=” is expected, in the latter case the right-hand side is Base64 decoded when parsed (thus permitting binary data to be passed in). Example qemu[17] switch: “-smbios type=11,value=io.systemd.credential:xx=yy”, or “-smbios type=11,value=io.systemd.credential.binary:rick=TmV2ZXIgR29ubmEgR2l2ZSBZb3UgVXA=”. Alternatively, use the qemu “fw_cfg” node “opt/io.systemd.credentials/”. Example qemu switch: “-fw_cfg name=opt/io.systemd.credentials/mycred,string=supersecret”. They may also be passed from the UEFI firmware environment via systemd-stub(7), from the initrd (see systemd(1)), or be specified on the kernel command line using the “systemd.set_credential=” and “systemd.set_credential_binary=” switches (see systemd(1) – this is not recommended since unprivileged userspace can read the kernel command line).
If referencing an AF_UNIX stream socket to connect to, the connection will originate from an abstract namespace socket, that includes information about the unit and the credential ID in its socket name. Use getpeername(2) to query this information. The returned socket name is formatted as NUL RANDOM “/unit/” UNIT “/” ID, i.e. a NUL byte (as required for abstract namespace socket names), followed by a random string (consisting of alphadecimal characters), followed by the literal string “/unit/”, followed by the requesting unit name, followed by the literal character “/”, followed by the textual credential ID requested. Example: “�adf9d86b6eda275e/unit/foobar.service/credx” in case the credential “credx” is requested for a unit “foobar.service”. This functionality is useful for using a single listening socket to serve credentials to multiple consumers.
For further information see System and Service Credentials[18] documentation.
Added in version 247.

ImportCredential=GLOB

Pass one or more credentials to the unit. Takes a credential name for which well attempt to find a credential that the service manager itself received under the specified name — which may be used to propagate credentials from an invoking environment (e.g. a container manager that invoked the service manager) into a service. If the credential name is a glob, all credentials matching the glob are passed to the unit. Matching credentials are searched for in the system credentials, the encrypted system credentials, and under /etc/credstore/, /run/credstore/, /usr/lib/credstore/, /run/credstore.encrypted/, /etc/credstore.encrypted/, and /usr/lib/credstore.encrypted/ in that order. When multiple credentials of the same name are found, the first one found is used.
The globbing expression implements a restrictive subset of glob(7): only a single trailing “*” wildcard may be specified. Both “?” and “[]” wildcards are not permitted, nor are “*” wildcards anywhere except at the end of the glob expression.
When multiple credentials of the same name are found, credentials found by LoadCredential= and LoadCredentialEncrypted= take priority over credentials found by ImportCredential=.
Added in version 254.

SetCredential=ID:VALUE, SetCredentialEncrypted=ID:VALUE

The SetCredential= setting is similar to LoadCredential= but accepts a literal value to use as data for the credential, instead of a file system path to read the data from. Do not use this option for data that is supposed to be secret, as it is accessible to unprivileged processes via IPC. Its only safe to use this for user IDs, public key material and similar non-sensitive data. For everything else use LoadCredential=. In order to embed binary data into the credential data use C-style escaping (i.e. " " to embed a newline, or “�” to embed a NUL byte).
The SetCredentialEncrypted= setting is identical to SetCredential= but expects an encrypted credential in literal form as value. This allows embedding confidential credentials securely directly in unit files. Use systemd-creds(1) -p switch to generate suitable SetCredentialEncrypted= lines directly from plaintext credentials. For further details see LoadCredentialEncrypted= above.
When multiple credentials of the same name are found, credentials found by LoadCredential=, LoadCredentialEncrypted= and ImportCredential= take priority over credentials found by SetCredential=. As such, SetCredential= will act as default if no credentials are found by any of the former. In this case not being able to retrieve the credential from the path specified in LoadCredential= or LoadCredentialEncrypted= is not considered fatal.
Added in version 247.

SYSTEM V COMPATIBILITY

UtmpIdentifier=

Takes a four character identifier string for an utmp(5) and wtmp entry for this service. This should only be set for services such as getty implementations (such as agetty(8)) where utmp/wtmp entries must be created and cleared before and after execution, or for services that shall be executed as if they were run by a getty process (see below). If the configured string is longer than four characters, it is truncated and the terminal four characters are used. This setting interprets %I style string replacements. This setting is unset by default, i.e. no utmp/wtmp entries are created or cleaned up for this service.

UtmpMode=

Takes one of “init”, “login” or “user”. If UtmpIdentifier= is set, controls which type of utmp(5)/wtmp entries for this service are generated. This setting has no effect unless UtmpIdentifier= is set too. If “init” is set, only an INIT_PROCESS entry is generated and the invoked process must implement a getty-compatible utmp/wtmp logic. If “login” is set, first an INIT_PROCESS entry, followed by a LOGIN_PROCESS entry is generated. In this case, the invoked process must implement a login(1)-compatible utmp/wtmp logic. If “user” is set, first an INIT_PROCESS entry, then a LOGIN_PROCESS entry and finally a USER_PROCESS entry is generated. In this case, the invoked process may be any process that is suitable to be run as session leader. Defaults to “init”.
Added in version 225.

ENVIRONMENT VARIABLES IN SPAWNED PROCESSES

Processes started by the service manager are executed with an environment variable block assembled from multiple sources. Processes started by the system service manager generally do not inherit environment variables set for the service manager itself (but this may be altered via PassEnvironment=), but processes started by the user service manager instances generally do inherit all environment variables set for the service manager itself.

For each invoked process the list of environment variables set is compiled from the following sources:

·
Variables globally configured for the service manager, using the DefaultEnvironment= setting in systemd-system.conf(5), the kernel command line option systemd.setenv= understood by systemd(1), or via systemctl(1) set-environment verb.

·
Variables defined by the service manager itself (see the list below).

·
Variables set in the service managers own environment variable block (subject to PassEnvironment= for the system service manager).

·
Variables set via Environment= in the unit file.

·
Variables read from files specified via EnvironmentFile= in the unit file.

·
Variables set by any PAM modules in case PAMName= is in effect, cf. pam_env(8).

If the same environment variable is set by multiple of these sources, the later source — according to the order of the list above — wins. Note that as the final step all variables listed in UnsetEnvironment= are removed from the compiled environment variable list, immediately before it is passed to the executed process.

The general philosophy is to expose a small curated list of environment variables to processes. Services started by the system manager (PID 1) will be started, without additional service-specific configuration, with just a few environment variables. The user manager inherits environment variables as any other system service, but in addition may receive additional environment variables from PAM, and, typically, additional imported variables when the user starts a graphical session. It is recommended to keep the environment blocks in both the system and user managers lean. Importing all variables inherited by the graphical session or by one of the user shells is strongly discouraged.

Hint: systemd-run -P env and systemd-run –user -P env print the effective system and user service environment blocks.

Environment Variables Set or Propagated by the Service Manager

The following environment variables are propagated by the service manager or generated internally for each invoked process:

$PATH

Colon-separated list of directories to use when launching executables. systemd uses a fixed value of “/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin” in the system manager. In case of the user manager, a different path may be configured by the distribution. It is recommended to not rely on the order of entries, and have only one program with a given name in $PATH.
Added in version 208.

$LANG

Locale. Can be set in locale.conf(5) or on the kernel command line (see systemd(1) and kernel-command-line(7)).
Added in version 208.

$USER, $LOGNAME, $HOME, $SHELL

User name (twice), home directory, and the login shell. $USER is set unconditionally, while $HOME, $LOGNAME, and $SHELL are only set for the units that have User= set and SetLoginEnvironment= unset or set to true. For user services, these variables are typically inherited from the user manager itself. See passwd(5).
Added in version 208.

$INVOCATION_ID

Contains a randomized, unique 128-bit ID identifying each runtime cycle of the unit, formatted as 32 character hexadecimal string. A new ID is assigned each time the unit changes from an inactive state into an activating or active state, and may be used to identify this specific runtime cycle, in particular in data stored offline, such as the journal. The same ID is passed to all processes run as part of the unit.
Added in version 232.

$XDG_RUNTIME_DIR

The directory to use for runtime objects (such as IPC objects) and volatile state. Set for all services run by the user systemd instance, as well as any system services that use PAMName= with a PAM stack that includes pam_systemd. See below and pam_systemd(8) for more information.
Added in version 208.

$RUNTIME_DIRECTORY, $STATE_DIRECTORY, $CACHE_DIRECTORY, $LOGS_DIRECTORY, $CONFIGURATION_DIRECTORY

Absolute paths to the directories defined with RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory=, and ConfigurationDirectory= when those settings are used.
Added in version 244.

$CREDENTIALS_DIRECTORY

An absolute path to the per-unit directory with credentials configured via ImportCredential=/LoadCredential=/SetCredential=. The directory is marked read-only and is placed in unswappable memory (if supported and permitted), and is only accessible to the UID associated with the unit via User= or DynamicUser= (and the superuser).
Added in version 247.

$MAINPID

The PID of the units main process if it is known. This is only set for control processes as invoked by ExecReload= and similar.
Added in version 209.

$MANAGERPID

The PID of the user systemd instance, set for processes spawned by it.
Added in version 208.

$LISTEN_FDS, $LISTEN_PID, $LISTEN_FDNAMES

Information about file descriptors passed to a service for socket activation. See sd_listen_fds(3).
Added in version 208.

$NOTIFY_SOCKET

The socket sd_notify() talks to. See sd_notify(3).
Added in version 229.

$WATCHDOG_PID, $WATCHDOG_USEC

Information about watchdog keep-alive notifications. See sd_watchdog_enabled(3).
Added in version 229.

$SYSTEMD_EXEC_PID

The PID of the unit process (e.g. process invoked by ExecStart=). The child process can use this information to determine whether the process is directly invoked by the service manager or indirectly as a child of another process by comparing this value with the current PID (similarly to the scheme used in sd_listen_fds(3) with $LISTEN_PID and $LISTEN_FDS).
Added in version 248.

$TERM

Terminal type, set only for units connected to a terminal (StandardInput=tty, StandardOutput=tty, or StandardError=tty). See termcap(5).
Added in version 209.

$LOG_NAMESPACE

Contains the name of the selected logging namespace when the LogNamespace= service setting is used.
Added in version 246.

$JOURNAL_STREAM

If the standard output or standard error output of the executed processes are connected to the journal (for example, by setting StandardError=journal) $JOURNAL_STREAM contains the device and inode numbers of the connection file descriptor, formatted in decimal, separated by a colon (”:"). This permits invoked processes to safely detect whether their standard output or standard error output are connected to the journal. The device and inode numbers of the file descriptors should be compared with the values set in the environment variable to determine whether the process output is still connected to the journal. Note that it is generally not sufficient to only check whether $JOURNAL_STREAM is set at all as services might invoke external processes replacing their standard output or standard error output, without unsetting the environment variable.
If both standard output and standard error of the executed processes are connected to the journal via a stream socket, this environment variable will contain information about the standard error stream, as thats usually the preferred destination for log data. (Note that typically the same stream is used for both standard output and standard error, hence very likely the environment variable contains device and inode information matching both stream file descriptors.)
This environment variable is primarily useful to allow services to optionally upgrade their used log protocol to the native journal protocol (using sd_journal_print(3) and other functions) if their standard output or standard error output is connected to the journal anyway, thus enabling delivery of structured metadata along with logged messages.
Added in version 231.

$SERVICE_RESULT

Only used for the service unit type. This environment variable is passed to all ExecStop= and ExecStopPost= processes, and encodes the service “result”. Currently, the following values are defined:
Table 5. Defined $SERVICE_RESULT values
Value Meaning
"success" The service ran successfully and exited cleanly.
"protocol" A protocol violation occurred: the service did not take the steps required by its unit configuration (specifically what is configured in its Type= setting).
"timeout" One of the steps timed out.
"exit-code" Service process exited with a non-zero exit code; see $EXIT_CODE below for the actual exit code returned.
"signal" A service process was terminated abnormally by a signal, without dumping core. See $EXIT_CODE below for the actual signal causing the termination.
"core-dump" A service process terminated abnormally with a signal and dumped core. See $EXIT_CODE below for the signal causing the termination.
"watchdog" Watchdog keep-alive ping was enabled for the service, but the deadline was missed.
"exec-condition" Service did not run because ExecCondition= failed.
"oom-kill" A service process was terminated by the Out-Of-Memory (OOM) killer.
"start-limit-hit" A start limit was defined for the unit and it was hit, causing the unit to fail to start. See systemd.unit(5)s StartLimitIntervalSec= and StartLimitBurst= for details.
"resources" A catch-all condition in case a system operation failed.
This environment variable is useful to monitor failure or successful termination of a service. Even though this variable is available in both ExecStop= and ExecStopPost=, it is usually a better choice to place monitoring tools in the latter, as the former is only invoked for services that managed to start up correctly, and the latter covers both services that failed during their start-up and those which failed during their runtime.
Added in version 232.

$EXIT_CODE, $EXIT_STATUS

Only defined for the service unit type. These environment variables are passed to all ExecStop=, ExecStopPost= processes and contain exit status/code information of the main process of the service. For the precise definition of the exit code and status, see wait(2). $EXIT_CODE is one of “exited”, “killed”, “dumped”. $EXIT_STATUS contains the numeric exit code formatted as string if $EXIT_CODE is “exited”, and the signal name in all other cases. Note that these environment variables are only set if the service manager succeeded to start and identify the main process of the service.
Table 6. Summary of possible service result variable values
$SERVICE_RESULT $EXIT_CODE $EXIT_STATUS
"success" "killed" "HUP", "INT", "TERM", "PIPE"
"exited" "0"
"protocol" not set not set
"exited" "0"
"timeout" "killed" "TERM", "KILL"
"exited" "0", "1", "2", "3", ..., "255"
"exit-code" "exited" "1", "2", "3", ..., "255"
"signal" "killed" "HUP", "INT", "KILL", ...
"core-dump" "dumped" "ABRT", "SEGV", "QUIT", ...
"watchdog" "dumped" "ABRT"
"killed" "TERM", "KILL"
"exited" "0", "1", "2", "3", ..., "255"
"exec-condition" "exited" "1", "2", "3", "4", ..., "254"
"oom-kill" "killed" "TERM", "KILL"
"start-limit-hit" not set not set
"resources" any of the above any of the above
Note: the process may be also terminated by a signal not sent by systemd. In particular the process may send an arbitrary signal to itself in a handler for any of the non-maskable signals. Nevertheless, in the "timeout" and "watchdog" rows above only the signals that systemd sends have been included. Moreover, using SuccessExitStatus= additional exit statuses may be declared to indicate clean termination, which is not reflected by this table.
Added in version 232.

$MONITOR_SERVICE_RESULT, $MONITOR_EXIT_CODE, $MONITOR_EXIT_STATUS, $MONITOR_INVOCATION_ID, $MONITOR_UNIT

Only defined for the service unit type. Those environment variables are passed to all ExecStart= and ExecStartPre= processes which run in services triggered by OnFailure= or OnSuccess= dependencies.
Variables $MONITOR_SERVICE_RESULT, $MONITOR_EXIT_CODE and $MONITOR_EXIT_STATUS take the same values as for ExecStop= and ExecStopPost= processes. Variables $MONITOR_INVOCATION_ID and $MONITOR_UNIT are set to the invocation id and unit name of the service which triggered the dependency.
Note that when multiple services trigger the same unit, those variables will be not be passed. Consider using a template handler unit for that case instead: “OnFailure=handler@%n.service” for non-templated units, or “OnFailure=handler@%p-%i.service” for templated units.
Added in version 251.

$PIDFILE

The path to the configured PID file, in case the process is forked off on behalf of a service that uses the PIDFile= setting, see systemd.service(5) for details. Service code may use this environment variable to automatically generate a PID file at the location configured in the unit file. This field is set to an absolute path in the file system.
Added in version 242.

$REMOTE_ADDR, $REMOTE_PORT

If this is a unit started via per-connection socket activation (i.e. via a socket unit with Accept=yes), these environment variables contain the IP address and port number of the remote peer of the socket connection.
Added in version 254.

$TRIGGER_UNIT, $TRIGGER_PATH, $TRIGGER_TIMER_REALTIME_USEC, $TRIGGER_TIMER_MONOTONIC_USEC

If the unit was activated dynamically (e.g.: a corresponding path unit or timer unit), the unit that triggered it and other type-dependent information will be passed via these variables. Note that this information is provided in a best-effort way. For example, multiple triggers happening one after another will be coalesced and only one will be reported, with no guarantee as to which one it will be. Because of this, in most cases this variable will be primarily informational, i.e. useful for debugging purposes, is lossy, and should not be relied upon to propagate a comprehensive reason for activation.
Added in version 252.

$MEMORY_PRESSURE_WATCH, $MEMORY_PRESSURE_WRITE

If memory pressure monitoring is enabled for this service unit, the path to watch and the data to write into it. See Memory Pressure Handling[19] for details about these variables and the service protocol data they convey.
Added in version 254.

$FDSTORE

The maximum number of file descriptors that may be stored in the manager for the service. This variable is set when the file descriptor store is enabled for the service, i.e. FileDescriptorStoreMax= is set to a non-zero value (see systemd.service(5) for details). Applications may check this environment variable before sending file descriptors to the service manager via sd_pid_notify_with_fds(3).
Added in version 254.

For system services, when PAMName= is enabled and pam_systemd is part of the selected PAM stack, additional environment variables defined by systemd may be set for services. Specifically, these are $XDG_SEAT, $XDG_VTNR, see pam_systemd(8) for details.

PROCESS EXIT CODES

When invoking a unit process the service manager possibly fails to apply the execution parameters configured with the settings above. In that case the already created service process will exit with a non-zero exit code before the configured command line is executed. (Or in other words, the child process possibly exits with these error codes, after having been created by the fork(2) system call, but before the matching execve(2) system call is called.) Specifically, exit codes defined by the C library, by the LSB specification and by the systemd service manager itself are used.

The following basic service exit codes are defined by the C library.

Table 7. Basic C library exit codes

Exit Code	Symbolic Name	Description
0	EXIT_SUCCESS	Generic success code.
1	EXIT_FAILURE	Generic failure or unspecified error.

The following service exit codes are defined by the LSB specification[20].

Table 8. LSB service exit codes

Exit Code	Symbolic Name	Description
2	EXIT_INVALIDARGUMENT	Invalid or excess arguments.
3	EXIT_NOTIMPLEMENTED	Unimplemented feature.
4	EXIT_NOPERMISSION	The user has insufficient privileges.
5	EXIT_NOTINSTALLED	The program is not installed.
6	EXIT_NOTCONFIGURED	The program is not configured.
7	EXIT_NOTRUNNING	The program is not running.

The LSB specification suggests that error codes 200 and above are reserved for implementations. Some of them are used by the service manager to indicate problems during process invocation:

Table 9. systemd-specific exit codes

Exit Code	Symbolic Name	Description
200	EXIT_CHDIR	Changing to the requested working directory failed. See WorkingDirectory= above.
201	EXIT_NICE	Failed to set up process scheduling priority (nice level). See Nice= above.
202	EXIT_FDS	Failed to close unwanted file descriptors, or to adjust passed file descriptors.
203	EXIT_EXEC	The actual process execution failed (specifically, the execve(2) system call). Most likely this is caused by a missing or non-accessible executable file.
204	EXIT_MEMORY	Failed to perform an action due to memory shortage.
205	EXIT_LIMITS	Failed to adjust resource limits. See LimitCPU= and related settings above.
206	EXIT_OOM_ADJUST	Failed to adjust the OOM setting. See OOMScoreAdjust= above.
207	EXIT_SIGNAL_MASK	Failed to set process signal mask.
208	EXIT_STDIN	Failed to set up standard input. See StandardInput= above.
209	EXIT_STDOUT	Failed to set up standard output. See StandardOutput= above.
210	EXIT_CHROOT	Failed to change root directory (chroot(2)). See RootDirectory=/RootImage= above.
211	EXIT_IOPRIO	Failed to set up IO scheduling priority. See IOSchedulingClass=/IOSchedulingPriority= above.
212	EXIT_TIMERSLACK	Failed to set up timer slack. See TimerSlackNSec= above.
213	EXIT_SECUREBITS	Failed to set process secure bits. See SecureBits= above.
214	EXIT_SETSCHEDULER	Failed to set up CPU scheduling. See CPUSchedulingPolicy=/CPUSchedulingPriority= above.
215	EXIT_CPUAFFINITY	Failed to set up CPU affinity. See CPUAffinity= above.
216	EXIT_GROUP	Failed to determine or change group credentials. See Group=/SupplementaryGroups= above.
217	EXIT_USER	Failed to determine or change user credentials, or to set up user namespacing. See User=/PrivateUsers= above.
218	EXIT_CAPABILITIES	Failed to drop capabilities, or apply ambient capabilities. See CapabilityBoundingSet=/AmbientCapabilities= above.
219	EXIT_CGROUP	Setting up the service control group failed.
220	EXIT_SETSID	Failed to create new process session.
221	EXIT_CONFIRM	Execution has been cancelled by the user. See the systemd.confirm_spawn= kernel command line setting on kernel-command-line(7) for details.
222	EXIT_STDERR	Failed to set up standard error output. See StandardError= above.
224	EXIT_PAM	Failed to set up PAM session. See PAMName= above.
225	EXIT_NETWORK	Failed to set up network namespacing. See PrivateNetwork= above.
226	EXIT_NAMESPACE	Failed to set up mount, UTS, or IPC namespacing. See ReadOnlyPaths=, ProtectHostname=, PrivateIPC=, and related settings above.
227	EXIT_NO_NEW_PRIVILEGES	Failed to disable new privileges. See NoNewPrivileges=yes above.
228	EXIT_SECCOMP	Failed to apply system call filters. See SystemCallFilter= and related settings above.
229	EXIT_SELINUX_CONTEXT	Determining or changing SELinux context failed. See SELinuxContext= above.
230	EXIT_PERSONALITY	Failed to set up an execution domain (personality). See Personality= above.
231	EXIT_APPARMOR_PROFILE	Failed to prepare changing AppArmor profile. See AppArmorProfile= above.
232	EXIT_ADDRESS_FAMILIES	Failed to restrict address families. See RestrictAddressFamilies= above.
233	EXIT_RUNTIME_DIRECTORY	Setting up runtime directory failed. See RuntimeDirectory= and related settings above.
235	EXIT_CHOWN	Failed to adjust socket ownership. Used for socket units only.
236	EXIT_SMACK_PROCESS_LABEL	Failed to set SMACK label. See SmackProcessLabel= above.
237	EXIT_KEYRING	Failed to set up kernel keyring.
238	EXIT_STATE_DIRECTORY	Failed to set up units state directory. See StateDirectory= above.
239	EXIT_CACHE_DIRECTORY	Failed to set up units cache directory. See CacheDirectory= above.
240	EXIT_LOGS_DIRECTORY	Failed to set up units logging directory. See LogsDirectory= above.
241	EXIT_CONFIGURATION_DIRECTORY	Failed to set up units configuration directory. See ConfigurationDirectory= above.
242	EXIT_NUMA_POLICY	Failed to set up units NUMA memory policy. See NUMAPolicy= and NUMAMask= above.
243	EXIT_CREDENTIALS	Failed to set up units credentials. See ImportCredential=, LoadCredential= and SetCredential= above.
245	EXIT_BPF	Failed to apply BPF restrictions. See RestrictFileSystems= above.

Finally, the BSD operating systems define a set of exit codes, typically defined on Linux systems too:

Table 10. BSD exit codes

Exit Code	Symbolic Name	Description
64	EX_USAGE	Command line usage error
65	EX_DATAERR	Data format error
66	EX_NOINPUT	Cannot open input
67	EX_NOUSER	Addressee unknown
68	EX_NOHOST	Host name unknown
69	EX_UNAVAILABLE	Service unavailable
70	EX_SOFTWARE	internal software error
71	EX_OSERR	System error (e.g., cant fork)
72	EX_OSFILE	Critical OS file missing
73	EX_CANTCREAT	Cant create (user) output file
74	EX_IOERR	Input/output error
75	EX_TEMPFAIL	Temporary failure; user is invited to retry
76	EX_PROTOCOL	Remote error in protocol
77	EX_NOPERM	Permission denied
78	EX_CONFIG	Configuration error

EXAMPLES

Example 3. $MONITOR_* usage

A service myfailer.service which can trigger an OnFailure= dependency.

[Unit] Description=Service which can trigger an OnFailure= dependency OnFailure=myhandler.service
[Service]
ExecStart=/bin/myprogram

A service mysuccess.service which can trigger an OnSuccess= dependency.

[Unit] Description=Service which can trigger an OnSuccess= dependency OnSuccess=myhandler.service
[Service]
ExecStart=/bin/mysecondprogram

A service myhandler.service which can be triggered by any of the above services.

[Unit] Description=Acts on service failing or succeeding

[Service]
ExecStart=/bin/bash -c "echo $MONITOR_SERVICE_RESULT $MONITOR_EXIT_CODE $MONITOR_EXIT_STATUS $MONITOR_INVOCATION_ID $MONITOR_UNIT"

If myfailer.service were to run and exit in failure, then myhandler.service would be triggered and the monitor variables would be set as follows:

MONITOR_SERVICE_RESULT=exit-code MONITOR_EXIT_CODE=exited MONITOR_EXIT_STATUS=1 MONITOR_INVOCATION_ID=cc8fdc149b2b4ca698d4f259f4054236 MONITOR_UNIT=myfailer.service

If mysuccess.service were to run and exit in success, then myhandler.service would be triggered and the monitor variables would be set as follows:

MONITOR_SERVICE_RESULT=success MONITOR_EXIT_CODE=exited MONITOR_EXIT_STATUS=0 MONITOR_INVOCATION_ID=6ab9af147b8c4a3ebe36e7a5f8611697 MONITOR_UNIT=mysuccess.service

NOTES

Discoverable Partitions Specification

https://uapi-group.org/specifications/specs/discoverable_partitions_specification

The /proc Filesystem

https://docs.kernel.org/filesystems/proc.html#mount-options

User/Group Name Syntax

https://systemd.io/USER_NAMES

No New Privileges Flag

https://docs.kernel.org/userspace-api/no_new_privs.html

JSON User Record

https://systemd.io/USER_RECORD

The /proc Filesystem

https://docs.kernel.org/filesystems/proc.html

Kernel Samepage Merging

https://docs.kernel.org/admin-guide/mm/ksm.html

unicode scalar values

https://www.unicode.org/glossary/#unicode_scalar_value

unicode noncharacters

https://www.unicode.org/glossary/#noncharacter

unicode byte order mark
https://www.unicode.org/glossary/#byte_order_mark
POSIX shell unquoted text
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_01
POSIX shell single-quoted text
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_02
POSIX shell double-quoted text
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_03
Base64
https://tools.ietf.org/html/rfc2045#section-6.8
Container Interface
https://systemd.io/CONTAINER_INTERFACE
DMI/SMBIOS
https://www.dmtf.org/standards/smbios
qemu
https://www.qemu.org/docs/master/system/index.html
System and Service Credentials
https://systemd.io/CREDENTIALS
Memory Pressure Handling
https://systemd.io/MEMORY_PRESSURE
LSB specification
https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

108 - Linux cli command snmpd.examples

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command snmpd.examples and provides detailed information about the command snmpd.examples, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the snmpd.examples.

NAME 🖥️ snmpd.examples 🖥️

example configuration for the Net-SNMP agent

DESCRIPTION

The snmpd.conf(5) man page defines the syntax and behaviour of the various configuration directives that can be used to control the operation of the Net-SNMP agent, and the management information it provides.

This companion man page illustrates these directives, showing some practical examples of how they might be used.

AGENT BEHAVIOUR

Listening addresses

The default agent behaviour (listing on the standard SNMP UDP port on all interfaces) is equivalent to the directive:

agentaddress udp:161

or simply

agentaddress 161

The agent can be configured to only accept requests sent to the local loopback interface (again listening on the SNMP UDP port), using:

agentaddress localhost:161 # (udp implicit)

agentaddress 127.0.0.1 # (udp and standard port implicit)

It can be configured to accept both UDP and TCP requests (over both IPv4 and IPv6), using:

agentaddress udp:161,tcp:161,udp6:161,tcp6:161

Other combinations are also valid.

Run-time privileges

The agent can be configured to relinquish any privileged access once it has opened the initial listening ports. Given a suitable “snmp” group (defined in /etc/group), this could be done using the directives:

agentuser nobody agentgroup snmp

A similar effect could be achieved using numeric UID and/or GID values:

agentuser #10 agentgroup #10

SNMPv3 Configuration

Rather than being generated pseudo-randomly, the engine ID for the agent could be calculated based on the MAC address of the second network interface (eth1), using the directives:

engineIDType 3 engineIDNic eth1

or it could be calculated from the (first) IP address, using:

engineIDType 1

or it could be specified explicitly, using:

engineID “XXX - WHAT FORMAT”

ACCESS CONTROL

SNMPv3 Users

The following directives will create three users, all using exactly the same authentication and encryption settings:

createUser me MD5 “single pass phrase” createUser myself MD5 “single pass phrase” DES createUser andI MD5 “single pass phrase” DES “single pass phrase”

Note that this defines three distinct users, who could be granted different levels of access. Changing the passphrase for any one of these would not affect the other two.

Separate pass phrases can be specified for authentication and encryption:

createUser onering SHA “to rule them all” AES “to bind them”

Remember that these createUser directives should be defined in the /var/lib/snmp/snmpd.conf file, rather than the usual location.

Traditional Access Control

The SNMPv3 users defined above can be granted access to the full MIB tree using the directives:

rouser me rwuser onering

Or selective access to individual subtrees using:

rouser myself .1.3.6.1.2 rwuser andI system

Note that a combination repeating the same user, such as:

rouser onering rwuser onering

should not be used. This would configure the user onering with read-only access (and ignore the rwuser entry altogether). The same holds for the community-based directives.

The directives:

rocommunity public rwcommunity private

would define the commonly-expected read and write community strings for SNMPv1 and SNMPv2c requests. This behaviour is not configured by default, and would need to be set up explicitly.

Note:
It would also be a very good idea to change private to something a little less predictable!

A slightly less vulnerable configuration might restrict what information could be retrieved:

rocommunity public default system

or the management systems that settings could be manipulated from:

rwcommunity private 10.10.10.0/24

or a combination of the two.

VACM Configuration

This last pair of settings are equivalent to the full VACM definitions:

sec.name source community

com2sec   public    default       public
com2sec   mynet     10.10.10.0/24 private
com2sec6  mynet     fec0::/64     private

#                  sec.model  sec.name
group  worldGroup  v1         public
group  worldGroup  v2c        public
group  myGroup     v1         mynet
group  myGroup     v2c        mynet

#              incl/excl   subtree     [mask]
view   all     included    .1
view   sysView included    system

#              context model level   prefix  read    write  notify (unused)
access  worldGroup  ""  any  noauth  exact   system  none   none
access  myGroup     ""  any  noauth  exact   all     all    none

There are several points to note in this example:

The group directives must be repeated for both SNMPv1 and SNMPv2c requests.

The com2sec security name is distinct from the community string that is mapped to it. They can be the same (“public”) or different (“mynet”/“private”) - but what appears in the group directive is the security name, regardless of the original community string.

Both of the view directives are defining simple OID subtrees, so neither of these require an explicit mask. The same holds for the “combined subtree2 view defined below. In fact, a mask field is only needed when defining row slices across a table (or similar views), and can almost always be omitted.

In general, it is advisible not to mix traditional and VACM-based access configuration settings, as these can sometimes interfere with each other in unexpected ways. Choose a particular style of access configuration, and stick to it.

Typed-View Configuration

A similar configuration could also be configured as follows:

view sys2View included system view sys2View included .1.3.6.1.2.1.25.1
authcommunity read       public  default      -v sys2View
authcommunity read,write private 10.10.10.0/8

This mechanism allows multi-subtree (or other non-simple) views to be used with the one-line rocommunity style of configuration.

It would also support configuring “write-only” access, should this be required.

SYSTEM INFORMATION

System Group

The full contents of the ‘system’ group (with the exception of sysUpTime) can be explicitly configured using:

Override ‘uname -a’ and hardcoded system OID - inherently read-only values

sysDescr     Universal Turing Machine mk I
sysObjectID  .1.3.6.1.4.1.8072.3.2.1066

# Override default values from 'configure' - makes these objects read-only
sysContact   [email protected]
sysName      tortoise.turing.com
sysLocation  An idea in the mind of AT

# Standard end-host behaviour
sysServices  72

Host Resources Group

The list of devices probed for potential inclusion in the hrDiskStorageTable (and hrDeviceTable) can be amended using any of the following directives:

ignoredisk /dev/rdsk/c0t2d0

which prevents the device /dev/rdsk/c0t2d0 from being scanned,

ignoredisk /dev/rdsk/c0t[!6]d0 ignoredisk /dev/rdsk/c0t[0-57-9a-f]d0

either of which prevents all devices /dev/rdsk/c0tXd0 (except …/c0t6d0) from being scanned,

ignoredisk /dev/rdsk/c1*

which prevents all devices whose device names start with /dev/rdsk/c1 from being scanned, or

ignoredisk /dev/rdsk/c?t0d0

which prevents all devices /dev/rdsk/cXt0d0 (where ‘X’ is any single character) from being scanned.

Process Monitoring

The list of services running on a system can be monitored (and provision made for correcting any problems), using:

At least one web server process must be running at all times

proc    httpd
procfix httpd  /etc/rc.d/init.d/httpd restart

# There should never be more than 10 mail processes running
#    (more implies a probable mail storm, so shut down the mail system)
proc    sendmail   10
procfix sendmail  /etc/rc.d/init.d/sendmail stop

# There should be a single network management agent running
#   ("There can be only one")
proc    snmpd    1  1

Also see the “DisMan Event MIB” section later on.

Disk Usage Monitoring

The state of disk storage can be monitored using:

includeAllDisks 10% disk /var 20% disk /usr 3% # Keep 100 MB free for crash dumps disk /mnt/crash 100000

System Load Monitoring

A simple check for an overloaded system might be:

load 10

A more refined check (to allow brief periods of heavy use, but recognise sustained medium-heavy load) might be:

load 30 10 5

Log File Monitoring

TODO

file FILE [MAXSIZE]

logmatch NAME PATH CYCLETIME REGEX

ACTIVE MONITORING

Notification Handling

Configuring the agent to report invalid access attempts might be done by:

authtrapenable 1 trapcommunity public trap2sink localhost

Alternatively, the second and third directives could be combined (and an acknowledgement requested) using:

informsink localhost public

A configuration with repeated sink destinations, such as:

trapsink localhost trap2sink localhost informsink localhost

should NOT be used, as this will cause multiple copies of each trap to be sent to the same trap receiver.

TODO - discuss SNMPv3 traps

trapsess snmpv3 options localhost:162

TODO - mention trapd access configuration

DisMan Event MIB

The simplest configuration for active self-monitoring of the agent, by the agent, for the agent, is probably:

Set up the credentials to retrieve monitored values

createUser    _internal MD5 "the first sign of madness"
iquerySecName _internal
rouser        _internal

# Active the standard monitoring entries
defaultMonitors         yes
linkUpDownNotifications yes

# If there's a problem, then tell someone!
trap2sink localhost

The first block sets up a suitable user for retrieving the information to by monitored, while the following pair of directives activates various built-in monitoring entries.

Note that the DisMan directives are not themselves sufficient to actively report problems - there also needs to be a suitable destination configured to actually send the resulting notifications to.

A more detailed monitor example is given by:

monitor -u me -o hrSWRunName “high process memory” hrSWRunPerfMem > 10000

This defines an explicit boolean monitor entry, looking for any process using more than 10MB of active memory. Such processes will be reported using the (standard) DisMan trap mteTriggerFired, but adding an extra (wildcarded) varbind hrSWRunName.

This entry also specifies an explicit user (me, as defined earlier) for retrieving the monitored values, and building the trap.

Objects that could potentially fluctuate around the specified level are better monitored using a threshold monitor entry:

monitor -D -r 10 “network traffic” ifInOctets 1000000 5000000

This will send a mteTriggerRising trap whenever the incoming traffic rises above (roughly) 500 kB/s on any network interface, and a corresponding mteTriggerFalling trap when it falls below 100 kB/s again.

Note that this monitors the deltas between successive samples (-D) rather than the actual sample values themselves. The same effect could be obtained using:

monitor -r 10 “network traffic” ifInOctets - - 1000000 5000000

The linkUpDownNotifications directive above is broadly equivalent to:

notificationEvent linkUpTrap linkUp ifIndex ifAdminStatus ifOperStatus notificationEvent linkDownTrap linkDown ifIndex ifAdminStatus ifOperStatus
monitor  -r 60 -e linkUpTrap   "Generate linkUp"   ifOperStatus != 2
monitor  -r 60 -e linkDownTrap "Generate linkDown" ifOperStatus == 2

This defines the traps to be sent (using notificationEvent), and explicitly references the relevant notification in the corresponding monitor entry (rather than using the default DisMan traps).

The defaultMonitors directive above is equivalent to a series of (boolean) monitor entries:

monitor -o prNames -o prErrMessage “procTable” prErrorFlag != 0 monitor -o memErrorName -o memSwapErrorMsg “memory” memSwapError != 0 monitor -o extNames -o extOutput “extTable” extResult != 0 monitor -o dskPath -o dskErrorMsg “dskTable” dskErrorFlag != 0 monitor -o laNames -o laErrMessage “laTable” laErrorFlag != 0 monitor -o fileName -o fileErrorMsg “fileTable” fileErrorFlag != 0

and will send a trap whenever any of these entries indicate a problem.

An alternative approach would be to automatically invoke the corresponding “fix” action:

setEvent prFixIt prErrFix = 1 monitor -e prFixIt “procTable” prErrorFlag != 0

(and similarly for any of the other defaultMonitor entries).

DisMan Schedule MIB

The agent could be configured to reload its configuration once an hour, using:

repeat 3600 versionUpdateConfig.0 = 1

Alternatively this could be configured to be run at specific times of day (perhaps following rotation of the logs):

cron 10 0 * * * versionUpdateConfig.0 = 1

The one-shot style of scheduling is rather less common, but the secret SNMP virus could be activated on the next occurance of Friday 13th using:

at 13 13 13 * 5 snmpVirus.0 = 1

EXTENDING AGENT FUNCTIONALITY

Arbitrary Extension Commands

Old Style

exec [MIBOID] NAME PROG ARGS” sh [MIBOID] NAME PROG ARGS" execfix NAME PROG ARGS"

New Style

extend [MIBOID] NAME PROG ARGS" extendfix [MIBOID] NAME PROG ARGS"

MIB-Specific Extension Commands

One-Shot

“pass [-p priority] MIBOID PROG”

Persistent

“pass_persist [-p priority] MIBOID PROG”

Embedded Perl Support

If embedded perl support is enabled in the agent, the default initialisation is equivalent to the directives:

disablePerl false perlInitFile /usr/share/snmp/snmp_perl.pl

The main mechanism for defining embedded perl scripts is the perl directive. A very simple (if somewhat pointless) MIB handler could be registered using:

perl use Data::Dumper; perl sub myroutine { print “got called: “,Dumper(@_),” “; } perl $agent->register(‘mylink’, ‘.1.3.6.1.8765’, &myroutine);

This relies on the $agent object, defined in the example snmp_perl.pl file.

A more realistic MIB handler might be:

XXX - WHAT ???

Alternatively, this code could be stored in an external file, and loaded using:

perl ‘do /usr/share/snmp/perl_example.pl’;

Dynamically Loadable Modules

TODO

dlmod NAME PATH”

Proxy Support

A configuration for acting as a simple proxy for two other SNMP agents (running on remote systems) might be:

com2sec -Cn rem1context rem1user default remotehost1 com2sec -Cn rem2context rem2user default remotehost2
proxy -Cn rem1context  -v 1 -c public  remotehost1  .1.3
proxy -Cn rem2context  -v 1 -c public  remotehost2  .1.3

(plus suitable access control entries).

The same proxy directives would also work with (incoming) SNMPv3 requests, which can specify a context directly. It would probably be more sensible to use contexts of remotehost1 and remotehost2 - the names above were chosen to indicate how these directives work together.

Note that the administrative settings for the proxied request are specified explicitly, and are independent of the settings from the incoming request.

An alternative use for the proxy directive is to pass part of the OID tree to another agent (either on a remote host or listening on a different port on the same system), while handling the rest internally:

proxy -v 1 -c public localhost:6161 .1.3.6.1.4.1.99

This mechanism can be used to link together two separate SNMP agents.

A less usual approach is to map one subtree into a different area of the overall MIB tree (either locally or on a remote system):

uses SNMPv3 to access the MIB tree .1.3.6.1.2.1.1 on ‘remotehost’
# and maps this to the local tree .1.3.6.1.3.10
proxy -v 3 -l noAuthNoPriv -u user remotehost .1.3.6.1.3.10 .1.3.6.1.2.1.1

SMUX Sub-Agents

smuxsocket 127.0.0.1 smuxpeer .1.3.6.1.2.1.14 ospf_pass

AgentX Sub-Agents

The Net-SNMP agent could be configured to operate as an AgentX master agent (listening on a non-standard named socket, and running using the access privileges defined earlier), using:

master agentx agentXSocket /tmp/agentx/master agentXPerms 0660 0550 nobody snmp

A sub-agent wishing to connect to this master agent would need the same agentXSocket directive, or the equivalent code:

netsnmp_ds_set_string(NETSNMP_DS_APPLICATION_ID, NETSNMP_DS_AGENT_X_SOCKET, “/tmp/agentx/master”);

A loopback networked AgentX configuration could be set up using:

agentXSocket tcp:localhost:705 agentXTimeout 5 agentXRetries 2

on the master side, and:

agentXSocket tcp:localhost:705 agentXTimeout 10 agentXRetries 1 agentXPingInterval 600

on the client.

Note that the timeout and retry settings can be asymmetric for the two directions, and the sub-agent can poll the master agent at regular intervals (600s = every 10 minutes), to ensure the connection is still working.

OTHER CONFIGURATION

override sysDescr.0 octet_str “my own sysDescr”

injectHandler stash_cache NAME table_iterator

FILES

/etc/snmp/snmpd.conf

109 - Linux cli command iocost.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iocost.conf and provides detailed information about the command iocost.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iocost.conf.

NAME 🖥️ iocost.conf 🖥️

Configuration files for the iocost solution manager

SYNOPSIS

/etc/systemd/iocost.conf /etc/systemd/iocost.conf.d/*.conf

DESCRIPTION

This file configures the behavior of “iocost”, a tool mostly used by systemd-udevd(8) rules to automatically apply I/O cost solutions to /sys/fs/cgroup/io.cost.*.

The qos and model values are calculated based on benchmarks collected on the iocost-benchmark[1] project and turned into a set of solutions that go from most to least isolated. Isolation allows the system to remain responsive in face of high I/O load. Which solutions are available for a device can be queried from the udev metadata attached to it. By default the naive solution is used, which provides the most bandwidth.

CONFIGURATION DIRECTORIES AND PRECEDENCE

The default configuration is set during compilation, so configuration is only needed when it is necessary to deviate from those defaults. The main configuration file is loaded from one of the listed directories in order of priority, only the first file found is used: /etc/systemd/, /run/systemd/, /usr/local/lib/systemd/ [2], /usr/lib/systemd/. The vendor version of the file contains commented out entries showing the defaults as a guide to the administrator. Local overrides can also be created by creating drop-ins, as described below. The main configuration file can also be edited for this purpose (or a copy in /etc/ if its shipped under /usr/), however using drop-ins for local configuration is recommended over modifications to the main configuration file.

OPTIONS

All options are configured in the [IOCost] section:

TargetSolution=

Chooses which I/O cost solution (identified by named string) should be used for the devices in this system. The known solutions can be queried from the udev metadata attached to the devices. If a device does not have the specified solution, the first one listed in IOCOST_SOLUTIONS is used instead.
E.g. “TargetSolution=isolated-bandwidth”.
Added in version 254.

NOTES

iocost-benchmark

https://github.com/iocost-benchmark/iocost-benchmarks

The resctl-bench documentation details how the values are obtained

https://github.com/facebookexperimental/resctl-demo/tree/main/resctl-bench/doc

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

110 - Linux cli command sudo_logsrvd.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command sudo_logsrvd.conf and provides detailed information about the command sudo_logsrvd.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the sudo_logsrvd.conf.

The

file is used to configure the

log server. It uses an INI-style format made up of sections in square brackets and

pairs specific to each section below the section name. Depending on the key, values may be integers, booleans, or strings. Section and key names are not case sensitive, but values are.

The pound sign

is used to indicate a comment. Both the comment character and any text after it, up to the end of the line, are ignored. Lines beginning with a semi-colon

are also ignored.

Long lines can be continued with a backslash

as the last character on the line. Leading white space is removed from the beginning of lines even when the continuation character is used.

The

section contains a copy of the default

file.

The following configuration sections are recognized:

server

relay

iolog

eventlog

syslog

logfile

Each section is described in detail below.

The

section configures the address and port the server will listen on. The following keys are recognized:

The host name or IP address, optional port to listen on and an optional Transport Layer Security (TLS) flag in parentheses.

The host may be a host name, an IPv4 address, an IPv6 address in square brackets or the wild card entry

A host setting of

will cause

to listen on all configured network interfaces.

If the optional tls flag is present,

will secure the connection with TLS version 1.2 or 1.3. Versions of TLS prior to 1.2 are not supported. See

for details on generating TLS keys and certificates.

If a port is specified, it may either be a port number or a known service name as defined by the system service name database. If no port is specified, port 30343 will be used for plaintext connections and port 30344 will be used for TLS connections.

The default value is:

listen_address = *:30343 listen_address = *:30344(tls)

which will listen on all configured network interfaces for both plaintext and TLS connections. Multiple

lines may be specified to listen on more than one port or interface.

Where to log server warning and error messages. Supported values are

or a path name beginning with the

character. A value of

is only effective when used in conjunction with the

option. The default value is

The path to the file containing the process ID of the running

If set to an empty value, or if

is run with the

option, no

will be created. If

refers to a symbolic link, it will be ignored. The default value is

If true,

will enable the TCP keepalive socket option on the client connection. This enables the periodic transmission of keepalive messages to the client. If the client does not respond to a message in time, the connection will be closed. Defaults to

The amount of time, in seconds,

will wait for the client to respond. A value of 0 will disable the timeout. The default value is

The path to a certificate authority bundle file, in PEM format, to use instead of the system’s default certificate authority database when authenticating clients. The default is to use

if it exists, otherwise the system’s default certificate authority database is used.

The path to the server’s certificate file, in PEM format. The default value is

If true, client certificates will be validated by

clients without a valid certificate will be unable to connect. If false, no validation of client certificates will be performed. It true and client certificates are created using a private certificate authority, the

setting must be set to a CA bundle that contains the CA certificate used to generate the client certificate. The default value is

A list of ciphers to use for connections secured by TLS version 1.2 only, separated by a colon

See the

section in

for full details. The default value is

which consists of encryption cipher suites with key lengths larger than 128 bits, and some cipher suites with 128-bit keys. Cipher suites that offer no authentication are excluded.

A list of ciphers to use for connections secured by TLS version 1.3 only, separated by a colon

Supported cipher suites depend on the version of OpenSSL used, but should include the following:

The default cipher suite is

The path to a file containing custom Diffie-Hellman parameters in PEM format. This file can be created with the following command:

openssl dhparam -out /etc/sudo_logsrvd_dhparams.pem 2048

By default,

will use the OpenSSL defaults for Diffie-Hellman key generation.

The path to the server’s private key file, in PEM format. The default value is

If true,

will validate its own certificate at startup time or when the configuration is changed. If false, no verification is performed of the server certificate. When using self-signed certificates without a certificate authority, this setting should be set to false. The default value is

The

section configures the optional logsrv relay host and port the server will connect to. The TLS configuration keys are optional, by default the corresponding keys in the

section will be used. They are only present in this section to make it possible for the relay connection to use a different set of TLS parameters from the client-facing server. The following keys are recognized:

The amount of time, in seconds,

will wait for the connection to a

(see below) to complete. Once the connection is complete, the

setting controls the amount of time

will wait for the relay to respond. A value of 0 will disable the timeout. The default value is

The directory in which log messages are temporarily stored before they are sent to the relay host. Messages are stored in the wire format specified by

The default value is

The relay host name or IP address, optional port to connect to and an optional Transport Layer Security (TLS) flag in parentheses. The syntax is identical to

in the

section with one exception: the wild card

syntax is not supported.

When this setting is enabled, messages from the client will be forwarded to one of the specified relay hosts instead of being stored locally. The

could be running an instance of

or another server that supports the

protocol.

If multiple

lines are specified, the first available relay host will be used.

The number of seconds to wait after a connection error before making a new attempt to forward a message to a relay host. The default value is

If true,

will store logs locally before relaying them. Once the log is complete, a connection to the relay host is opened and the log is relayed. If the network connection is interrupted before the log can be fully transferred, it will be retransmitted later. The default is to relay logs in real-time.

If true,

will enable the TCP keepalive socket option on the relay connection. This enables the periodic transmission of keepalive messages to the relay server. If the relay does not respond to a message in time, the connection will be closed.

The amount of time, in seconds,

will wait for the relay server to respond after a connection has succeeded. A value of 0 will disable the timeout. The default value is

The path to a certificate authority bundle file, in PEM format, to use instead of the system’s default certificate authority database when authenticating clients. The default is to use the value specified in the

section, or the system’s default certificate authority database if no value is set.

The path to the server’s certificate file, in PEM format. The default is to use the value specified in the

section.

If true, the relay host’s certificate will be validated by

connections to a relay without a valid certificate will fail. If false, no validation of relay certificates will be performed. It true and relay certificates are created using a private certificate authority, the

setting must be set to a CA bundle that contains the CA certificate used to generate the relay certificate. The default is to use the value specified in the

section.

A list of ciphers to use for connections secured by TLS version 1.2 only, separated by a colon

See the

section in

for full details. The default is to use the value specified in the

section.

A list of ciphers to use for connections secured by TLS version 1.3 only, separated by a colon

Supported cipher suites depend on the version of OpenSSL used, see the

section for more information. The default is to use the value specified in the

section.

The path to a file containing custom Diffie-Hellman parameters in PEM format. The default is to use the value specified in the

section.

The path to the server’s private key file, in PEM format. The default is to use the value specified in the

section.

If true, the server’s certificate used for relaying will be verified at startup. If false, no verification is performed of the server certificate. When using self-signed certificates without a certificate authority, this setting should be set to false. The default is to use the value specified in the

section.

The

section configures I/O log parameters. These settings are identical to the I/O configuration in

The following keys are recognized:

If set, I/O logs will be compressed using

Enabling compression can make it harder to view the logs in real-time as the program is executing due to buffering. The default value is

The top-level directory to use when constructing the path name for the I/O log directory. The session sequence number, if any, is stored in the directory. The default value is

The following percent

escape sequences are supported:

expanded to a monotonically increasing base-36 sequence number, such as 0100A5, where every two digits are used to form a new directory, e.g.,

expanded to the invoking user’s login name

expanded to the name of the invoking user’s real group-ID

expanded to the login name of the user the command will be run as (e.g., root)

expanded to the group name of the user the command will be run as (e.g., wheel)

expanded to the local host name without the domain name

expanded to the base name of the command being run

In addition, any escape sequences supported by the system’s

function will be expanded.

To include a literal

character, the string

should be used.

The path name, relative to

in which to store I/O logs. It is possible for

to contain directory components. The default value is

See the

setting above for a list of supported percent

escape sequences.

In addition to the escape sequences, path names that end in six or more

will have the

replaced with a unique combination of digits and letters, similar to the

function.

If the path created by concatenating

and

already exists, the existing I/O log file will be truncated and overwritten unless

ends in six or more

If set, I/O log data is flushed to disk after each write instead of buffering it. This makes it possible to view the logs in real-time as the program is executing but may significantly reduce the effectiveness of I/O log compression. I/O logs are always flushed before sending a commit point to the client regardless of this setting. The default value is

The group name to look up when setting the group-ID on new I/O log files and directories. If

is not set, the primary group-ID of the user specified by

If neither

nor

are set, I/O log files and directories are created with group-ID 0.

The file mode to use when creating I/O log files. Mode bits for read and write permissions for owner, group, or other are honored, everything else is ignored. The file permissions will always include the owner read and write bits, even if they are not present in the specified mode. When creating I/O log directories, search (execute) bits are added to match the read and write bits specified by

The default value is

The user name to look up when setting the owner of new I/O log files and directories. If

is set, it will be used instead of the user’s primary group-ID. By default, I/O log files and directories are created with user and group-ID 0.

Most programs that require a user’s password will disable echo before reading the password to avoid displaying the plaintext password on the screen. However, if terminal input is being logged, the password will still be present in the I/O log. If

is set to

will attempt to prevent passwords from being logged. It does this by using the regular expressions in

to match a password prompt in the terminal output buffer. When a match is found, input characters in the I/O log will be replaced with

until either a line feed or carriage return is found in the terminal input or a new terminal output buffer is received. If, however, a program displays characters as the user types them (such as

when the

option is set), only the first character of the password will be replaced in the I/O log. The default value is

The maximum sequence number that will be substituted for the

escape in the I/O log file (see the

description above for more information). While the value substituted for

is in base 36,

itself should be expressed in decimal. Values larger than 2176782336 (which corresponds to the base 36 sequence number

will be silently truncated to 2176782336. The default value is

One or more POSIX extended regular expressions used to match password prompts in the terminal output when

is disabled. As an extension, if the regular expression begins with

it will be matched in a case-insensitive manner. Multiple

settings may be specified. Each regular expression is limited to 1024 characters. The default value is

The

section configures how (and if) security policy events are logged.

Where to log accept, reject, and alert events reported by the policy. Supported values are

and

The default value is

If true,

will log an event when a command exits or is terminated by a signal. Defaults to

The event log format. Supported log formats are

for traditional sudo-style logs and

for JSON-format logs. The JSON log entries contain the full contents of the accept, reject, exit and alert messages. The default value is

The

section configures how events are logged via

Syslog facility if syslog is being used for logging. Defaults to

The following syslog facilities are supported:

(if your OS supports it),

and

Syslog priority to use when the user is allowed to run a command and authentication is successful. Defaults to

The following syslog priorities are supported:

and

Setting it to a value of

will disable logging of successful commands.

Syslog priority to use when the user is not allowed to run a command or when authentication is unsuccessful. Defaults to

See

for the list of supported syslog priorities.

Syslog priority to use for event log alert messages received from the client. Defaults to

See

for the list of supported syslog priorities.

On many systems,

has a relatively small log buffer. IETF RFC 5424 states that syslog servers must support messages of at least 480 bytes and should support messages up to 2048 bytes. By default,

creates log messages up to 960 bytes which corresponds to the historic

syslog implementation which used a 1024 byte buffer to store the message, date, hostname, and program name.

To prevent syslog messages from being truncated,

will split up sudo-style log messages that are larger than

bytes. When a message is split, additional parts will include the string

after the user name and before the continued command line arguments. JSON-format log entries are never split and are not affected by

Syslog facility if syslog is being used for server warning messages. See above for a list of supported facilities. Defaults to

The

section consists of settings related to logging to a plain file (not syslog).

The path to the file-based event log. This path must be fully-qualified and start with a

character. The default value is

The string used when formatting the date and time for file-based event logs. Formatting is performed via the system’s

function so any escape sequences supported by that function will be expanded. The default value is

which produces dates like

in the

locale.

Sudo log server configuration file

# # sudo logsrv daemon configuration #

[server] # The host name or IP address and port to listen on with an optional TLS # flag. If no port is specified, port 30343 will be used for plaintext # connections and port 30344 will be used to TLS connections. # The following forms are accepted: # listen_address = hostname(tls) # listen_address = hostname:port(tls) # listen_address = IPv4_address(tls) # listen_address = IPv4_address:port(tls) # listen_address = [IPv6_address](tls) # listen_address = [IPv6_address]:port(tls) # # The (tls) suffix should be omitted for plaintext connections. # # Multiple listen_address settings may be specified. # The default is to listen on all addresses. #listen_address = *:30343 #listen_address = *:30344(tls)

# The file containing the ID of the running sudo_logsrvd process. #pid_file = /run/sudo/sudo_logsrvd.pid

# Where to log server warnings: none, stderr, syslog, or a path name. #server_log = syslog

# If true, enable the SO_KEEPALIVE socket option on client connections. # Defaults to true. #tcp_keepalive = true

# The amount of time, in seconds, the server will wait for the client to # respond. A value of 0 will disable the timeout. The default value is 30. #timeout = 30

# If true, the server will validate its own certificate at startup. # Defaults to true. #tls_verify = true

# If true, client certificates will be validated by the server; # clients without a valid certificate will be unable to connect. # By default, client certs are not checked. #tls_checkpeer = false

# Path to a certificate authority bundle file in PEM format to use # instead of the system’s default certificate authority database. #tls_cacert = /etc/ssl/sudo/cacert.pem

# Path to the server’s certificate file in PEM format. # Required for TLS connections. #tls_cert = /etc/ssl/sudo/certs/logsrvd_cert.pem

# Path to the server’s private key file in PEM format. # Required for TLS connections. #tls_key = /etc/ssl/sudo/private/logsrvd_key.pem

# TLS cipher list (see “CIPHER LIST FORMAT” in the openssl-ciphers manual). # This setting is only effective if the negotiated protocol is TLS version # 1.2. The default cipher list is HIGH:!aNULL. #tls_ciphers_v12 = HIGH:!aNULL

# TLS cipher list if the negotiated protocol is TLS version 1.3. # The default cipher list is TLS_AES_256_GCM_SHA384. #tls_ciphers_v13 = TLS_AES_256_GCM_SHA384

# Path to the Diffie-Hellman parameter file in PEM format. # If not set, the server will use the OpenSSL defaults. #tls_dhparams = /etc/ssl/sudo/logsrvd_dhparams.pem

[relay] # The host name or IP address and port to send logs to in relay mode. # The syntax is identical to listen_address with the exception of # the wild card (’*’) syntax. When this setting is enabled, logs will # be relayed to the specified host instead of being stored locally. # This setting is not enabled by default. #relay_host = relayhost.dom.ain #relay_host = relayhost.dom.ain(tls)

# The amount of time, in seconds, the server will wait for a connection # to the relay server to complete. A value of 0 will disable the timeout. # The default value is 30. #connect_timeout = 30

# The directory to store messages in before they are sent to the relay. # Messages are stored in wire format. # The default value is /var/log/sudo_logsrvd. #relay_dir = /var/log/sudo_logsrvd

# The number of seconds to wait after a connection error before # making a new attempt to forward a message to a relay host. # The default value is 30. #retry_interval = 30

# Whether to store the log before relaying it. If true, enable store # and forward mode. If false, the client connection is immediately # relayed. Defaults to false. #store_first = true

# If true, enable the SO_KEEPALIVE socket option on relay connections. # Defaults to true. #tcp_keepalive = true

# The amount of time, in seconds, the server will wait for the relay to # respond. A value of 0 will disable the timeout. The default value is 30. #timeout = 30

# If true, the server’s relay certificate will be verified at startup. # The default is to use the value in the [server] section. #tls_verify = true

# Whether to verify the relay’s certificate for TLS connections. # The default is to use the value in the [server] section. #tls_checkpeer = false

# Path to a certificate authority bundle file in PEM format to use # instead of the system’s default certificate authority database. # The default is to use the value in the [server] section. #tls_cacert = /etc/ssl/sudo/cacert.pem

# Path to the server’s certificate file in PEM format. # The default is to use the certificate in the [server] section. #tls_cert = /etc/ssl/sudo/certs/logsrvd_cert.pem

# Path to the server’s private key file in PEM format. # The default is to use the key in the [server] section. #tls_key = /etc/ssl/sudo/private/logsrvd_key.pem

# TLS cipher list (see “CIPHER LIST FORMAT” in the openssl-ciphers manual). # this setting is only effective if the negotiated protocol is TLS version # 1.2. The default is to use the value in the [server] section. #tls_ciphers_v12 = HIGH:!aNULL

# TLS cipher list if the negotiated protocol is TLS version 1.3. # The default is to use the value in the [server] section. #tls_ciphers_v13 = TLS_AES_256_GCM_SHA384

# Path to the Diffie-Hellman parameter file in PEM format. # The default is to use the value in the [server] section. #tls_dhparams = /etc/ssl/sudo/logsrvd_dhparams.pem

[iolog] # The top-level directory to use when constructing the path name for the # I/O log directory. The session sequence number, if any, is stored here. #iolog_dir = /var/log/sudo-io

# The path name, relative to iolog_dir, in which to store I/O logs. # It is possible for iolog_file to contain directory components. #iolog_file = %{seq}

# If set, I/O logs will be compressed using zlib. Enabling compression can # make it harder to view the logs in real-time as the program is executing. #iolog_compress = false

# If set, I/O log data is flushed to disk after each write instead of # buffering it. This makes it possible to view the logs in real-time # as the program is executing but reduces the effectiveness of compression. #iolog_flush = true

# The group to use when creating new I/O log files and directories. # If iolog_group is not set, the primary group-ID of the user specified # by iolog_user is used. If neither iolog_group nor iolog_user # are set, I/O log files and directories are created with group-ID 0. #iolog_group = wheel

# The user to use when setting the user-ID and group-ID of new I/O # log files and directories. If iolog_group is set, it will be used # instead of the user’s primary group-ID. By default, I/O log files # and directories are created with user and group-ID 0. #iolog_user = root

# The file mode to use when creating I/O log files. The file permissions # will always include the owner read and write bits, even if they are # not present in the specified mode. When creating I/O log directories, # search (execute) bits are added to match the read and write bits # specified by iolog_mode. #iolog_mode = 0600

# If disabled, sudo_logsrvd will attempt to avoid logging plaintext # password in the terminal input using passprompt_regex. #log_passwords = true

# The maximum sequence number that will be substituted for the “%{seq}” # escape in the I/O log file. While the value substituted for “%{seq}” # is in base 36, maxseq itself should be expressed in decimal. Values # larger than 2176782336 (which corresponds to the base 36 sequence # number “ZZZZZZ”) will be silently truncated to 2176782336. #maxseq = 2176782336

# One or more POSIX extended regular expressions used to match # password prompts in the terminal output when log_passwords is # disabled. Multiple passprompt_regex settings may be specified. #passprompt_regex = [Pp]assword[: ]* #passprompt_regex = [Pp]assword for [a-z0-9]+: *

[eventlog] # Where to log accept, reject, exit, and alert events. # Accepted values are syslog, logfile, or none. # Defaults to syslog #log_type = syslog

# Whether to log an event when a command exits or is terminated by a signal. # Defaults to false #log_exit = true

# Event log format. # Currently only sudo-style event logs are supported. #log_format = sudo

[syslog] # The maximum length of a syslog payload. # On many systems, syslog(3) has a relatively small log buffer. # IETF RFC 5424 states that syslog servers must support messages # of at least 480 bytes and should support messages up to 2048 bytes. # Messages larger than this value will be split into multiple messages. #maxlen = 960

# The syslog facility to use for event log messages. # The following syslog facilities are supported: authpriv (if your OS # supports it), auth, daemon, user, local0, local1, local2, local3, # local4, local5, local6, and local7. #facility = authpriv

# Syslog priority to use for event log accept messages, when the command # is allowed by the security policy. The following syslog priorities are # supported: alert, crit, debug, emerg, err, info, notice, warning, none. #accept_priority = notice

# Syslog priority to use for event log reject messages, when the command # is not allowed by the security policy. #reject_priority = alert

# Syslog priority to use for event log alert messages reported by the # client. #alert_priority = alert

# The syslog facility to use for server warning messages. # Defaults to daemon. #server_facility = daemon

[logfile] # The path to the file-based event log. # This path must be fully-qualified and start with a ‘/’ character. #path = /var/log/sudo.log

# The format string used when formatting the date and time for # file-based event logs. Formatting is performed via strftime(3) so # any format string supported by that function is allowed. #time_format = %h %e %T

Many people have worked on

over the years; this version consists of code written primarily by:

See the CONTRIBUTORS.md file in the

distribution (https://www.sudo.ws/about/contributors/) for an exhaustive list of people who have contributed to

If you believe you have found a bug in

you can submit a bug report at https://bugzilla.sudo.ws/

Limited free support is available via the sudo-users mailing list, see https://www.sudo.ws/mailman/listinfo/sudo-users to subscribe or search the archives.

is provided

or https://www.sudo.ws/about/license/ for complete details.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

111 - Linux cli command deb-conffiles

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command deb-conffiles and provides detailed information about the command deb-conffiles, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the deb-conffiles.

NAME 🖥️ deb-conffiles 🖥️

conffiles - package conffiles

SYNOPSIS

DEBIAN/conffiles

DESCRIPTION

A package declares its list of conffiles by including a conffiles file in its control archive (i.e. DEBIAN/conffiles during package creation).

This file contains a list of files, one per line, with an optional leading flag separated by whitespace. The conffiles must be listed as absolute pathnames. Trailing whitespace will be trimmed, but empty or whitespace-only lines are not accepted.

Files without a flag should exist in the binary package, otherwise dpkg (1) will ignore them.

There is currently only one flag supported, remove-on-upgrade, to mark that a conffile needs to be removed on the next upgrade (since dpkg 1.20.6). These files must not exist in the binary package, as both dpkg (1) and dpkg-deb (1) will not accept building nor processing such binary packages.

EXAMPLE

/etc/alternatives/README /etc/cron.daily/dpkg /etc/dpkg/dpkg.cfg /etc/logrotate.d/dpkg remove-on-upgrade /etc/some-old-file.conf

112 - Linux cli command proc_pid_mountstats

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_mountstats and provides detailed information about the command proc_pid_mountstats, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_mountstats.

NAME 🖥️ proc_pid_mountstats 🖥️

mount statistics

DESCRIPTION

/proc/pid/mountstats (since Linux 2.6.17)
This file exports information (statistics, configuration information) about the mounts in the process’s mount namespace (see mount_namespaces(7)). Lines in this file have the form:

device /dev/sda7 mounted on /home with fstype ext3 [stats]
(       1      )            ( 2 )             (3 ) (  4  )

The fields in each line are:

(1)
The name of the mounted device (or “nodevice” if there is no corresponding device).

(2)
The mount point within the filesystem tree.

(3)
The filesystem type.

(4)
Optional statistics and configuration information. Currently (as at Linux 2.6.26), only NFS filesystems export information via this field.

This file is readable only by the owner of the process.

113 - Linux cli command localtime

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command localtime and provides detailed information about the command localtime, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the localtime.

NAME 🖥️ localtime 🖥️

Local timezone configuration file

SYNOPSIS

/etc/localtime -> ../usr/share/zoneinfo/…

DESCRIPTION

The /etc/localtime file configures the system-wide timezone of the local system that is used by applications for presentation to the user. It should be an absolute or relative symbolic link pointing to /usr/share/zoneinfo/, followed by a timezone identifier such as “Europe/Berlin” or “Etc/UTC”. The resulting link should lead to the corresponding binary tzfile(5) timezone data for the configured timezone.

Because the timezone identifier is extracted from the symlink target name of /etc/localtime, this file may not be a normal file or hardlink.

If /etc/localtime is missing, the default “UTC” timezone is used.

The timezone may be overridden for individual programs by using the $TZ environment variable. See environ(7).

You may use timedatectl(1) to change the settings of this file from the command line during runtime. Use systemd-firstboot(1) to initialize the time zone on mounted (but not booted) system images.

114 - Linux cli command init-d-script

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command init-d-script and provides detailed information about the command init-d-script, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the init-d-script.

Generic init.d script framework to reduce the redundant code in

The goal is to create an init.d script that is Debian and LSB compliant. When the Debian policy conflicts with the LSB, the Debian policy takes precedence.

This is a simple example on how init-d-script can be used to start and stop a daemon with PID file support:

#!/bin/sh /lib/init/init-d-script ### BEGIN INIT INFO # Provides: atd # Required-Start: $syslog $time $remote_fs # Required-Stop: $syslog $time $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: run at jobs # Description: Debian init script to start the daemon # running at jobs. ### END INIT INFO DAEMON=/usr/sbin/atd

The following variables affect behaviour of an init script:

Path to daemon being started. If the init script is not supposed to start any kind of daemon, it should be set to

and the functions

and

should be defined instead.

Additional arguments, passed to daemon during start.

Full name or short description of the daemon, printed on screen. If unset, this variable defaults to the

value.

Additional environment variables are sourced from

If unset, this variable defaults to the basename of the

value.

If this variable is set, it is used as argument to the

option of

It may be useful if the value of the

variable is longer than the command name length supported by the running kernel. If the value is verbatim

the command name will not be used to match the processes. If unset, this variable defaults to the

value.

Path to file where the process identifier of the started daemon will be stored during start. If the value is verbatim

the process identifier will not be stored in any file. If this variable is not set, it gets a sensible default value, so it is rarely necessary to set this variable explicitly.

Signal number or name (without the SIG prefix) that will be sent to the process on

If the daemon performs reload action upon receiving a

signal, this variable should be set to

The variables

and

are additional arguments, passed to

during reload, start and stop actions, to override the default options.

Additionally, it is possible to change the behaviour of the resulting shell script by overriding some of the internal functions. To do so, define function with an

suffix. So, for example, to override the

function, one should define a

function. The

to this rule is the

function, whose override should be defined as-is,

the above-mentioned suffix.

Here is a control flow chart that explains what functions are called and when:

/etc/init.d/script start do_start do_start_prepare # no-op do_start_cmd # start-stop-daemon is called here do_start_cleanup # no-op

/etc/init.d/script stop do_stop do_stop_prepare # no-op do_stop_cmd # start-stop-daemon is called here do_stop_cleanup # no-op

/etc/init.d/script status do_status

/etc/init.d/script reload do_reload do_usage exit 3

/etc/init.d/script force-reload do_force_reload do_reload # if overridden do_restart do_restart_prepare do_stop_cmd do_start_cmd do_restart_cleanup

/etc/init.d/script restart do_force_restart /etc/init.d/script try-restart if do_status; then do_restart do_restart_prepare do_stop_cmd # start-stop-daemon is called here do_start_cmd # start-stop-daemon is called here do_restart_cleanup

/etc/init.d/script arg do_unknown arg exit 3

/etc/init.d/script do_usage

As can be seen, by default, the script does not support the

action; it should be implemented by the script writer by defining a

function.

is not defined but

is, the latter will be called on

after

and before

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

115 - Linux cli command org.freedesktop.network1

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.freedesktop.network1 and provides detailed information about the command org.freedesktop.network1, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.freedesktop.network1.

NAME 🖥️ org.freedesktop.network1 🖥️

The D-Bus interface of systemd-networkd

INTRODUCTION

systemd-networkd.service(8) is a system service that manages and configures network interfaces. This page describes the D-Bus interface.

THE MANAGER OBJECT

The service exposes the following interfaces on the Manager object on the bus:

node /org/freedesktop/network1 { interface org.freedesktop.network1.Manager { methods: ListLinks(out a(iso) links); GetLinkByName(in s name, out i ifindex, out o path); GetLinkByIndex(in i ifindex, out s name, out o path); SetLinkNTP(in i ifindex, in as servers); SetLinkDNS(in i ifindex, in a(iay) addresses); SetLinkDNSEx(in i ifindex, in a(iayqs) addresses); SetLinkDomains(in i ifindex, in a(sb) domains); SetLinkDefaultRoute(in i ifindex, in b enable); SetLinkLLMNR(in i ifindex, in s mode); SetLinkMulticastDNS(in i ifindex, in s mode); SetLinkDNSOverTLS(in i ifindex, in s mode); SetLinkDNSSEC(in i ifindex, in s mode); SetLinkDNSSECNegativeTrustAnchors(in i ifindex, in as names); RevertLinkNTP(in i ifindex); RevertLinkDNS(in i ifindex); RenewLink(in i ifindex); ForceRenewLink(in i ifindex); ReconfigureLink(in i ifindex); Reload(); DescribeLink(in i ifindex, out s json); Describe(out s json); properties: readonly s OperationalState = …; readonly s CarrierState = …; readonly s AddressState = …; readonly s IPv4AddressState = …; readonly s IPv6AddressState = …; readonly s OnlineState = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t NamespaceId = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly u NamespaceNSID = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; };

Provides information about the manager.

Properties

NamespaceId contains the inode number of the network namespace that the network service runs in. A client may compare this with the inode number of its own network namespace to verify whether the service manages the same network namespace.

NamespaceNSID contains the “nsid” identifier the kernel maintains for the network namespace, if theres one assigned.

LINK OBJECT

node /org/freedesktop/network1/link/_1 { interface org.freedesktop.network1.Link { methods: SetNTP(in as servers); SetDNS(in a(iay) addresses); SetDNSEx(in a(iayqs) addresses); SetDomains(in a(sb) domains); SetDefaultRoute(in b enable); SetLLMNR(in s mode); SetMulticastDNS(in s mode); SetDNSOverTLS(in s mode); SetDNSSEC(in s mode); SetDNSSECNegativeTrustAnchors(in as names); RevertNTP(); RevertDNS(); Renew(); ForceRenew(); Reconfigure(); Describe(out s json); properties: readonly s OperationalState = …; readonly s CarrierState = …; readonly s AddressState = …; readonly s IPv4AddressState = …; readonly s IPv6AddressState = …; readonly s OnlineState = …; readonly s AdministrativeState = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly (tt) BitRates = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; };

Provides information about interfaces.

NETWORK OBJECT

node /org/freedesktop/network1/network/_1 { interface org.freedesktop.network1.Network { properties: @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Description = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s SourcePath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as MatchMAC = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as MatchPath = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as MatchDriver = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as MatchType = […, …]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly as MatchName = […, …]; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; };

Provides information about .network files.

DHCP SERVER OBJECT

node /org/freedesktop/network1/link/_1 { interface org.freedesktop.network1.DHCPServer { properties: readonly a(uayayayayt) Leases = […]; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; interface org.freedesktop.network1.Link { … }; };

Provides information about leases.

DHCPV4 CLIENT OBJECT

node /org/freedesktop/network1/link/_1 { interface org.freedesktop.network1.DHCPv4Client { properties: readonly s State = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; interface org.freedesktop.network1.Link { … }; };

Provides information about DHCPv4 client status.

DHCPV6 CLIENT OBJECT

node /org/freedesktop/network1/link/_1 { interface org.freedesktop.network1.DHCPv6Client { properties: readonly s State = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; interface org.freedesktop.network1.Link { … }; };

Provides information about DHCPv6 client status.

EXAMPLES

Example 1. Introspect org.freedesktop.network1.Manager on the bus

$ gdbus introspect –system
–dest org.freedesktop.network1
–object-path /org/freedesktop/network1

Example 2. Introspect org.freedesktop.network1.Link on the bus

$ gdbus introspect –system
–dest org.freedesktop.network1
–object-path /org/freedesktop/network1/link/_11

VERSIONING

These D-Bus interfaces follow the usual interface versioning guidelines[1].

HISTORY

DHCPv4 Client Object

State was added in version 255.

DHCPv6 Client Object

State was added in version 255.

Manager Object

NamespaceNSID was added in version 256.

NOTES

the usual interface versioning guidelines

https://0pointer.de/blog/projects/versioning-dbus.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

116 - Linux cli command opensc.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command opensc.conf and provides detailed information about the command opensc.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the opensc.conf.

NAME 🖥️ opensc.conf 🖥️

configuration file for OpenSC

DESCRIPTION

OpenSC obtains configuration data from the following sources in the following order

1.
command-line options

2.
environment variables

3.
Windows registry key in HKEY_CURRENT_USER (if available)

4.
Windows registry key in HKEY_LOCAL_MACHINE (if available)

5.
system-wide configuration file (/etc/opensc.conf)

The configuration file, opensc.conf, is composed of blocks, which, in general, have the following format:

key [, name…] { block_contents }

block_contents is one or more block_items where a block_item is one of

·
# comment string

·
key[, name…] = value;

·
block

At the root level, opensc.conf should contain one or more application specific configuration blocks:

app application { block_contents }

application specifies one of:

·
filename: Configuration block for the application with specified file path.

·
default: The fall-back configuration block for all applications

·
opensc-pkcs11: Configuration block for the PKCS#11 module (opensc-pkcs11.so)

·
onepin-opensc-pkcs11: Configuration block for the PKCS#11 one-PIN-module (onepin-opensc-pkcs11.so)

·
cardmod: Configuration block for Windows minidriver (opensc-minidriver.dll)

·
tokend: Configuration block for macOS tokend (OpenSC.tokend)

·
cardos-tool, cryptoflex-tool, dnie-tool, egk-tool, eidenv, gids-tool, iasecc-tool, netkey-tool, npa-tool, openpgp-tool, opensc-asn1, opensc-explorer, opensc-notify, opensc-tool, piv-tool, pkcs11-tool, pkcs15-crypt, pkcs15-init, pkcs15-tool, sc-hsm-tool, westcos-tool: Configuration block for OpenSC tools

CONFIGURATION OPTIONS

debug = num**;**

Amount of debug info to print (Default: 0). A greater value means more debug info.
The environment variable OPENSC_DEBUG overwrites this setting.

debug_file = filename**;**

The file to which debug output will be written (Default: stderr). Special values stdout and stderr are recognized.

profile_dir = filename**;**

PKCS#15 initialization/personalization profiles directory for pkcs15-init(1) (Default: /usr/share/opensc).
If this configuration value is not found on Windows, the registry key Software\OpenSC Project\OpenSC\ProfileDir is checked.

disable_colors = bool**;**

Disable colors of log messages (Default: false if attached to a console, true otherwise).

disable_popups = bool**;**

Disable pop-ups of built-in GUI (Default: false).

enable_default_driver = bool**;**

Enable default card driver (Default: false). Default card driver is explicitly enabled for opensc-explorer(1) and opensc-tool(1)

card_drivers = name…;

Allowlist of card drivers to load at start-up. The special value internal (the default) will load all statically linked drivers.
If an unknown (i.e. not internal or old) driver is supplied, a separate configuration block has to be written for the driver. A special value old will load all statically linked drivers that may be removed in the future.
The list of supported card driver names can be retrieved from the output of opensc-tool –list-drivers.
The environment variable OPENSC_DRIVER overwrites this setting.

ignored_readers = name…;

List of readers to ignore (Default: empty). If any of the comma separated strings listed is matched in a reader name (case sensitive, partial matching possible), the reader is ignored by OpenSC. Use opensc-tool –list-readers to see all currently connected readers.

reader_driver name { block_contents }

Configuration of the smart card reader driver where name is one of:
·
ctapi: See the section called “Configuration of CT-API Readers”
·
pcsc: See the section called “Configuration of PC/SC Readers”
·
openct: See the section called “Configuration of OpenCT Readers”
·
cryptotokenkit: Configuration block for CryptoTokenKit readers
See the section called “Configuration of Smart Card Reader Driver”.

card_driver name { block_contents }

Configuration of the card driver where name is one of:
·
npa: See the section called “Configuration Options for German ID Card”
·
dnie: See the section called “Configuration Options for DNIe”
·
edo: See the section called “Configuration Options for Polish eID Card”
·
eoi: See the section called “Configuration Options for Slovenian eID Card”
·
myeid: See the section called “Configuration Options for MyEID Card”
·
Any other value: Configuration block for an externally loaded card driver

card_atr hexstring { block_contents }

In addition to the built-in list of known cards in the card driver, you can configure a new card for the driver using the card_atr block.
For details see the section called “Configuration based on ATR”.

disable_hw_pkcs1_padding = value**;**

Disabling PKCS#1 v1.5 padding in HW when card supports doing raw RSA operations. Known parameters:
·
no: PKCS#1 v1.5 padding is enabled in HW when card supports it.
·
sign: PKCS#1 v1.5 padding is disabled only for signatures (PKCS#1 v1.5 type 1).
·
decipher: PKCS#1 v1.5 padding is disabled only for decryption (PKCS#1 v1.5 type 2).
·
both: PKCS#1 v1.5 padding is disabled both for signatures and decryption (PKCS#1 v1.5 type 1 and 2).
(Default: decipher).

secure_messaging name { block_contents }

Configuration options for the secure messaging profile name:
module_name = filename**;**
Name of external SM module (Default: libsmm-local.so).
module_path = filename**;**
Directory with external SM module (Default: /usr/lib/x86_64-linux-gnu).
If this configuration value is not found on Windows, the registry key Software\OpenSC Project\OpenSC\SmDir is checked.
module_data = value**;**
Specific data to tune the module initialization.
mode = value**;**
Secure messaging mode. Known parameters:
·
transmit: In this mode the procedure to securize an APDU is called by the OpenSC general APDU transmit procedure. In this mode all APDUs, except the ones filtered by the card specific procedure, are securized.
·
acl: In this mode APDU are securized only if needed by the ACLs of the command to be executed.
flags = value**;**
Secure messaging type specific flags.
kmc = hexstring**;**
Default KMC of the GP Card Manager for the Oberthurs Java cards.
ifd_serial = hexstring**;**
keyset[_aid]_num_enc = value**;** keyset[_aid]_num_mac = value**;**
Keyset values from IAM profiles of the Gemalto IAS/ECC cards with an optional application identifier

framework name { block_contents }

Internal configuration options where name is one of:
·
pkcs15: See the section called “Configuration of PKCS#15 Framework”
·
tokend: See the section called “Configuration of Tokend”

pkcs11 { block_contents }

Parameters for the OpenSC PKCS11 module.
For details see the section called “Configuration of PKCS#11”.

Configuration of Smart Card Reader Driver

Configuration Options for all Reader Drivers

max_send_size = num**;** max_recv_size = num**;**
Limit command and response sizes (Default: max_send_size = 255, max_recv_size = 256) . Some Readers dont propagate their transceive capabilities correctly. max_send_size and max_recv_size allow setting the limits manually, for example to enable extended length capabilities.
enable_escape bool**;**
Detect reader capabilities with escape commands (wrapped APDUs with CLA=0xFF as defined by PC/SC pt. 3 and BSI TR-03119, e.g. for getting the UID, escaped PIN commands and the readers firmware version, Default: false)

Configuration of CT-API Readers

module filename { ports = nums**; }**
Load the specified CT-API module with the specified number of ports.

Configuration of PC/SC Readers

connect_exclusive = bool**;**
Connect to reader in exclusive mode (Default: false)? This option has no effect in Windows minidriver.
disconnect_action = action**;**
What to do when disconnecting from a card (SCardDisconnect). Valid values are leave, reset, unpower (Default: leave). This option has no effect in Windows minidriver.
transaction_end_action = action**;**
What to do at the end of a transaction (SCardEndTransaction). Valid values are leave, reset, unpower (Default: leave). This option has no effect in Windows minidriver.
reconnect_action = action**;**
What to do when reconnection to a card (SCardReconnect). Valid values are leave, reset, unpower (Default: leave). This option has no effect in Windows minidriver.
enable_pinpad = bool**;**
Enable pinpad if detected (PC/SC v2.0.2 Part 10, Default: true)
fixed_pinlength = num**;**
Some pinpad readers can only handle one exact length of the PIN. fixed_pinlength sets this value so that OpenSC expands the padding to this length (Default: 0, i.e. not fixed).
provider_library = filename**;**
Use specific PC/SC provider (Default: libpcsclite.so.1).

Configuration of OpenCT Readers

readers = num**;**
Virtual readers to allocate (Default: 2).

Configuration Options for MyEID Card

disable_hw_pkcs1_padding = bool**;**

The MyEID card can internally encapsulate the data (hash code) into a DigestInfo ASN.1 structure according to the selected hash algorithm (currently only for SHA1). DigestInfo is padded to RSA key modulus length according to PKCS#1 v1.5, block type 01h. Size of the DigestInfo must not exceed 40% of the RSA key modulus length. If this limit is unsatisfactory (for example someone needs RSA 1024 with SHA512), the user can disable this feature. In this case, the card driver will do everything necessary before sending the data (hash code) to the card.
PKCS#1 v1.5 padding in HW can be globally disabled by option disable_hw_pkcs1_padding. When the global option is used to disable padding, the padding will be disabled even though the MyEID-specific option does not turn it off.

Configuration Options for German ID Card

can = value**;**

German ID card requires the CAN to be verified before QES PIN. This, however, is not part of the PKCS#15 profile of the card. So for verifying the QES PIN we actually need both. The CAN may be given here. If the CAN is not given here, it will be prompted on the command line or on the reader (depending on the readers capabilities).

st_dv_certificate = filename**;** st_certificate = filename**;** st_key = filename**;**

QES is only possible with a Comfort Reader (CAT-K), which holds a cryptographic key to authenticate itself as signature terminal (ST). We usually will use the readers capability to sign the data. However, during development you may specify soft certificates and keys for a ST.
An example PKI can be found in the example data for the German ID card emulator[1]

Configuration Options for DNIe

user_consent_enabled = bool**;**

Configure the warning message when performing a signature operation with the DNIe. Only used if compiled with –enable-dnie-ui

user_consent_app = filename**;**

Specify the pinentry application to use if warning is configured to be displayed using pinentry (Default: /usr/bin/pinentry). Only used if compiled with –enable-dnie-ui

Configuration Options for Polish eID Card

can = value**;**

CAN (Card Access Number – 6 digit number printed on the right bottom corner of the front side of the document) is required to establish connection with the card. It might be overwritten by EDO_CAN environment variable. Currently, it is not possible to set it in any other way.

Configuration Options for Slovenian eID Card

can = value**;**

CAN (Card Access Number – 6 digit number printed on the right bottom corner of the front side of the document) is required to establish connection with the card. It might be overwritten by EOI_CAN environment variable. As CAN is also stored on the card (in encrypted form) it can be used to automatically establish secure connection, but only if the card is accessed over the contact interface.

Configuration Options for PIV Card

Configuration based on ATR

atrmask = hexstring**;**

The mask is logically ANDd with an card ATR prior to comparison with the ATR reference value above. Using this mask allows identifying and configuring multiple ATRs as the same card model.

driver = name**;**

When enabled, overrides all possible settings from the card drivers built-in card configuration list.

name = name**;**

Set card name for card drivers that allows it.

type = num**;**

Allows setting the exact type of the card internally used by the card driver. Allowed values can be found in the source code of cards.h.

flags = value…;

Card flags as an hex value. Multiple values are ORd together. Depending on card driver, this allows fine-tuning the capabilities in the card driver for your card.
Optionally, some known parameters can be specified as strings:
·
rng: On-board random number source
·
keep_alive: Request the card driver to send a “keep alive” command before each transaction to make sure that the required applet is still selected.

pkcs15emu = name**;**

When using PKCS#15 emulation, force the emulation driver for specific cards. Required for external drivers, but can be used with built-in drivers, too.

force_protocol = value**;**

Force protocol selection for specific cards. Known parameters:
·
t0
·
t1
·
raw

read_only = bool**;**

Mark card as read/only card in PKCS#11/Minidriver/BaseCSP interface (Default: false).

md_supports_X509_enrollment = bool**;**

Indicate X509 enrollment support at Minidriver/BaseCSP interface (Default: false).

md_guid_as_id = bool**;**

Use the GUID generated for the key as id in the PKCS#15 structure (Default: false, i.e. auto generated)

md_guid_as_label = bool**;**

Use the GUID generated for the key as label in the PKCS#15 structure (Default: false, i.e. no label set).

md_supports_container_key_gen = bool**;**

Card allows generating key pairs on the card (Default: false).

md_supports_container_key_import = bool**;**

Card allows importing private keys (Default: false).

md_pinpad_dlg_title = value**;**

Window title of the PIN pad dialog (Default: “Windows Security”).

md_pinpad_dlg_icon = filename**;**

Filename of the icon for the PIN pad dialog; use "" for no icon (Default: Built-in smart card icon).

md_pinpad_dlg_main = value**;**

Main instruction of the PIN pad dialog (Default: “OpenSC Smart Card Provider”).

md_pinpad_dlg_content_user = value**;**

Content of the PIN pad dialog for role “user” (Default: “Please enter your PIN on the PIN pad.”).

md_pinpad_dlg_content_user_sign = value**;**

Content of the PIN pad dialog for role “user+signature” (Default: “Please enter your digital signature PIN on the PIN pad.”).

md_pinpad_dlg_content_admin = value**;**

Content of the PIN pad dialog for role “admin” (Default: “Please enter your PIN to unblock the user PIN on the PIN pad.”)

md_pinpad_dlg_expanded = value**;**

Expanded information of the PIN pad dialog (Default: “This window will be closed automatically after the PIN has been submitted on the PIN pad (timeout typically after 30 seconds).”)

md_pinpad_dlg_enable_cancel = bool**;**

Allow the user to cancel the PIN pad dialog (Default: false). If this value is set to true, the user needs to click “OK” to start the PIN verification on the PIN pad. The user can choose the default behavior by enabling or disabling the checkbox of the dialog. The setting is saved by the programs full path (program_path) that uses OpenSC.
The registry key HKCU\Software\OpenSC Project\OpenSC\md_pinpad_dlg_enable_cancel*program_path* overwrites this setting with a DWORD set to either 1 (enabled) or 0 (disabled).

md_pinpad_dlg_timeout = num**;**

Time in seconds for the progress bar of the PIN pad dialog to tick. 0 removes the progress bar (Default: 30).

notify_card_inserted = value**;** notify_card_inserted_text = value**;**

Notification title and text when card was inserted (Default: “Smart card detected”, ATR of the card).

notify_card_removed = value**;** notify_card_removed_text = value**;**

Notification title and text when card was removed (Default: “Smart card removed”, name of smart card reader).

notify_pin_good = value**;** notify_pin_good_text = value**;**

Notification title and text when PIN was verified (Default: “PIN verified”, “Smart card is unlocked”).

notify_pin_bad = value**;** notify_pin_bad_text = value**;**

Notification title and text when PIN was wrong (Default: “PIN not verified”, “Smart card is locked”).

Configuration of PKCS#15 Framework

use_file_caching = value**;**

Whether to cache the cards files (e.g. certificates) on disk in file_cache_dir. Possible parameters:
·
yes: Cache all files (public and private).
·
public: Cache only public files.
·
no: File caching disabled.
(Default: public for the following card drivers atrust-acos, belpic, cac1, cac, coolkey, dnie, edo, esteid2018, flex, cyberflex, gemsafeV1, idprime, itacns, jpki, MaskTech, mcrd, npa, nqapplet, tcos and otherwise no).
If caching is done by a system process, the cached files may be placed inaccessible from the user account. Use a globally readable and writable location if you wish to share the cached information. Note that the cached files may contain personal data such as name and mail address.

file_cache_dir = filename**;**

Where to cache the cards files. The default values are:
·
$XDG_CACHE_HOME/opensc/ (If $XDG_CACHE_HOME is defined)
·
$HOME/.cache/opensc/ (Unix)
·
$USERPROFILE\eid-cache\ (Windows)
If caching is done by a system process, the cached files may be placed inaccessible from a user account. Use a globally readable and writable location if you wish to share the cached information. Note that the cached files may contain personal data such as name and mail address.
The PIV-II card driver supports the history objects list of retired keys and certificates if they are readable in the file cache directory. If the specified objects URL is “http://"DNS name”/"ASCII-HEX OffCardKeyHistoryFile, then the searches for the file name OffCardKeyHistoryFile in the cache directory.

use_pin_caching = bool**;**

Use PIN caching (Default: true)?

pin_cache_counter = num**;**

How many times to use a PIN from cache before re-authenticating it (Default: 10)?

pin_cache_ignore_user_consent = bool**;**

Older PKCS#11 applications not supporting CKA_ALWAYS_AUTHENTICATE may need to set this to get signatures to work with some cards (Default: false).
It is recommended to enable also PIN caching using use_pin_caching option for OpenSC to be able to provide PIN for the card when needed.

private_certificate = value**;**

How to handle a PIN-protected certificate. Known parameters:
·
protect: The certificate stays PIN-protected.
·
declassify: Allow reading the certificate without enforcing verification of the PIN.
·
ignore: Ignore PIN-protected certificates.
(Default: ignore in Tokend, protect otherwise).

enable_pkcs15_emulation = bool**;**

Enable pkcs15 emulation (Default: true).

try_emulation_first = bool**;**

Prefer pkcs15 emulation code before the normal pkcs15 processing (Default: no). Some cards work in emu-only mode, and do not depend on this option.

enable_builtin_emulation = bool**;**

Enable builtin emulators (Default: true).

builtin_emulators = emulators**;**

List of the builtin pkcs15 emulators to test (Default: internal)
Special value of internal will try all not disabled builtin pkcs15 emulators.
Special value of old will try all disabled pkcs15 emulators.

pkcs11_enable_InitToken = bool**;**

Enable initialization and card recognition (Default: false).

emulate name { block_contents }

Configuration options for a PKCS#15 emulator where name is a short name for an external card driver.
module = filename**;**
For pkcs15 emulators loaded from an external shared library/DLL, you need to specify the path name of the module and customize the card_atr example above correctly.
function = name**;**
Get the init function name of the emulator (Default: sc_pkcs15_init_func_ex)

application hexstring { block_contents }

Configuration of the on-card-application where hexstring is the application identifier (AID).
type = name**;**
Type of application where name is one of:
·
generic
·
protected
Used to distinguish the common access application and application for which authentication to perform some operation cannot be obtained with the common procedures (ex. object creation protected by secure messaging). Used by PKCS#11 module configured to expose restricted number of slots. (for ex. configured to expose only User PIN slot, User and Sign PINs slots, …)
model = name**;**
disable = bool**;**
Do not expose application in PKCS#15 framework (Default: false)
user_pin = name**;**
Name of the User PIN object that will be used as the main PIN.
sign_pin = name**;**
Name of the PIN object that will be used for signing.

Configuration of Tokend

score = num**;**

Score for OpenSC.tokend (Default: 300). The tokend with the highest score shall be used.

Configuration of PKCS#11

max_virtual_slots = num**;**

Maximum Number of virtual slots (Default: 16). If there are more slots than defined here, the remaining slots will be hidden from PKCS#11.

slots_per_card = num**;**

Maximum number of PIN slots per smart card (Default: 4). If the card has fewer PINs than defined here, the remaining number of slots will be empty. For Firefox, Chrome and Chromium, the slots_per_card is set to 1, to avoid prompting for unrelated PINs. Typically, this effectively disables signature PINs and keys.

lock_login = bool**;**

By default, the OpenSC PKCS#11 module will not lock your card once you authenticate to the card via C_Login (Default: false). Thus the other users or other applications is not prevented from connecting to the card and perform crypto operations (which may be possible because you have already authenticated with the card). This setting is not very secure.
Also, if your card is not locked, you can enconter problems due to limitation of the OpenSC framework, that still is not thoroughly tested in the multi threads environment.
Your settings will be more secure if you choose to lock your card. Nevertheless this behavior is a known violation of PKCS#11 specification. Now once one application has started using your card with C_Login, no other application can use it, until the first is done and calls C_Logout or C_Finalize. In the case of many PKCS#11 application this does not happen until you exit the application.
Thus it is impossible to use several smart card aware applications at the same time, e.g. you cannot run both Firefox and Thunderbird at the same time, if both are configured to use your smart card.

atomic = bool**;**

By default, interacting with the OpenSC PKCS#11 module may change the state of the token, e.g. whether a user is logged in or not (Default: false).
Thus other users or other applications may change or use the state of the token unknowingly. Other applications may create signatures abusing an existing login or they may logout unnoticed.
With this setting enabled the login state of the token is tracked and cached (including the PIN). Every transaction is preceded by restoring the login state. After every transaction a logout is performed. This setting by default also enables lock_login to disable access for other applications during the atomic transactions.
Please note that any PIN-pad should be disabled (see enable_pinpad), because the user would have to input his PIN for every transaction.

init_sloppy = bool**;**

With this setting disabled, the OpenSC PKCS#11 module will initialize the slots available when the application calls C_GetSlotList. With this setting enabled, the slots will also get initialized when C_GetSlotInfo is called (Default: true).
This setting is a workaround for Java which does not call C_GetSlotList when configured with a static slot instead of slotListIndex.

user_pin_unblock_style = mode**;**

User PIN unblock style mode is one of:
·
none (Default): PIN unblock is not possible with PKCS#11 API
·
set_pin_in_unlogged_session: C_SetPIN in unlogged session: PUK is passed as the OldPin argument of the C_SetPIN call.
·
set_pin_in_specific_context: C_SetPIN in the CKU_SPECIFIC_CONTEXT logged session: PUK is passed as the OldPin argument of the C_SetPIN call.
·
init_pin_in_so_session: C_InitPIN in CKU_SO logged session: User PIN UNBLOCK is protected by SOPIN. (PUK == SOPIN).

create_puk_slot = bool**;**

Create slot for unblocking PIN with PUK (Default: false). This way PKCS#11 API can be used to login with PUK and change a PIN. May cause problems with some applications like Firefox and Thunderbird.

create_slots_for_pins = mode…;

Symbolic names of PINs for which slots are created where mode is a list of:
·
all (Default): All non-SO-PIN, non-unblocking PINs
·
user: The first global or first local PIN
·
sign: The second PIN (first local, second global or second local)
Card can contain more then one PINs or more then one on-card application with its own PINs. Normally, to access all of them with the PKCS#11 API a slot has to be created for all of them. Many slots could be annoying for some of widely used application, like FireFox. This configuration parameter allows to select the PIN(s) for which PKCS#11 slot will be created.
Only PINs initialised, non-SO-PIN, non-unblocking are associated with symbolic name.
For the module to simulate the opensc-onepin module behavior the following option create_slots_for_pins = “user”;

ENVIRONMENT

OPENSC_CONF

Filename for a user defined configuration file
If this environment variable is not found on Windows, the registry key Software\OpenSC Project\OpenSC\ConfigFile is checked.

OPENSC_DEBUG

See debug = num**;**

OPENSC_DRIVER

See card_drivers = name…;

CARDMOD_LOW_LEVEL_DEBUG

Write minidriver debug information to C: mp\md.log, if set to 1.
If this environment variable is not found on Windows, the registry key Software\OpenSC Project\OpenSC\MiniDriverDebug is checked.

PIV_EXT_AUTH_KEY, PIV_9A_KEY, PIV_9C_KEY, PIV_9D_KEY, PIV_9E_KEY

PIV configuration during initialization with piv-tool.

PIV_USE_SM, PIV_PAIRING_CODE

PIV configuration during initialization See Configuration Options for PIV Card.

FILES

/etc/opensc.conf

System-wide configuration file

/usr/share/doc/opensc/opensc.conf

Extended example configuration file

NOTES

German ID card emulator

https://github.com/frankmorgner/vsmartcard/tree/master/virtualsmartcard/npa-example-data

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

117 - Linux cli command proc_pci

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pci and provides detailed information about the command proc_pci, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pci.

NAME 🖥️ proc_pci 🖥️

PCI devices

DESCRIPTION

/proc/pci
This is a listing of all PCI devices found during kernel initialization and their configuration.

This file has been deprecated in favor of a new /proc interface for PCI (/proc/bus/pci). It became optional in Linux 2.2 (available with CONFIG_PCI_OLD_PROC set at kernel compilation). It became once more nonoptionally enabled in Linux 2.4. Next, it was deprecated in Linux 2.6 (still available with CONFIG_PCI_LEGACY_PROC set), and finally removed altogether since Linux 2.6.17.

118 - Linux cli command proc_pid_statm

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_statm and provides detailed information about the command proc_pid_statm, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_statm.

NAME 🖥️ proc_pid_statm 🖥️

memory usage information

DESCRIPTION

/proc/pid/statm
Provides information about memory usage, measured in pages. The columns are:

size       (1) total program size
           (same as VmSize in /proc/pid/status)
resident   (2) resident set size
           (inaccurate; same as VmRSS in /proc/pid/status)
shared     (3) number of resident shared pages
           (i.e., backed by a file)
           (inaccurate; same as RssFile+RssShmem in
           /proc/pid/status)
text       (4) text (code)
lib        (5) library (unused since Linux 2.6; always 0)
data       (6) data + stack
dt         (7) dirty pages (unused since Linux 2.6; always 0)

Some of these values are inaccurate because of a kernel-internal scalability optimization. If accurate values are required, use /proc/pid/smaps or /proc/pid/smaps_rollup instead, which are much slower but provide accurate, detailed information.

119 - Linux cli command utmp

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command utmp and provides detailed information about the command utmp, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the utmp.

NAME 🖥️ utmp 🖥️

SYNOPSIS

#include <utmp.h>

DESCRIPTION

The utmp file allows one to discover information about who is currently using the system. There may be more users currently using the system, because not all programs use utmp logging.

Warning: utmp must not be writable by the user class “other”, because many system programs (foolishly) depend on its integrity. You risk faked system logfiles and modifications of system files if you leave utmp writable to any user other than the owner and group owner of the file.

The file is a sequence of utmp structures, declared as follows in <utmp.h> (note that this is only one of several definitions around; details depend on the version of libc):

/* Values for ut_type field, below */
#define EMPTY         0 /* Record does not contain valid info
                           (formerly known as UT_UNKNOWN on Linux) */
#define RUN_LVL       1 /* Change in system run-level (see
                           init(1)) */
#define BOOT_TIME     2 /* Time of system boot (in ut_tv) */
#define NEW_TIME      3 /* Time after system clock change
                           (in ut_tv) */
#define OLD_TIME      4 /* Time before system clock change
                           (in ut_tv) */
#define INIT_PROCESS  5 /* Process spawned by init(1) */
#define LOGIN_PROCESS 6 /* Session leader process for user login */
#define USER_PROCESS  7 /* Normal process */
#define DEAD_PROCESS  8 /* Terminated process */
#define ACCOUNTING    9 /* Not implemented */
#define UT_LINESIZE      32
#define UT_NAMESIZE      32
#define UT_HOSTSIZE     256
struct exit_status {              /* Type for ut_exit, below */
    short e_termination;          /* Process termination status */
    short e_exit;                 /* Process exit status */
};
struct utmp {
    short   ut_type;              /* Type of record */
    pid_t   ut_pid;               /* PID of login process */
    char    ut_line[UT_LINESIZE]; /* Device name of tty - "/dev/" */
    char    ut_id[4];             /* Terminal name suffix,
                                     or inittab(5) ID */
    char    ut_user[UT_NAMESIZE]; /* Username */
    char    ut_host[UT_HOSTSIZE]; /* Hostname for remote login, or
                                     kernel version for run-level
                                     messages */
    struct  exit_status ut_exit;  /* Exit status of a process
                                     marked as DEAD_PROCESS; not
                                     used by Linux init(1) */
    /* The ut_session and ut_tv fields must be the same size when
       compiled 32- and 64-bit.  This allows data files and shared
       memory to be shared between 32- and 64-bit applications. */
#if __WORDSIZE == 64 && defined __WORDSIZE_COMPAT32
    int32_t ut_session;           /* Session ID (getsid(2)),
                                     used for windowing */
    struct {
        int32_t tv_sec;           /* Seconds */
        int32_t tv_usec;          /* Microseconds */
    } ut_tv;                      /* Time entry was made */
#else
     long   ut_session;           /* Session ID */
     struct timeval ut_tv;        /* Time entry was made */
#endif
    int32_t ut_addr_v6[4];        /* Internet address of remote
                                     host; IPv4 address uses
                                     just ut_addr_v6[0] */
    char __unused[20];            /* Reserved for future use */
};
/* Backward compatibility hacks */
#define ut_name ut_user
#ifndef _NO_UT_TIME
#define ut_time ut_tv.tv_sec
#endif
#define ut_xtime ut_tv.tv_sec
#define ut_addr ut_addr_v6[0]

This structure gives the name of the special file associated with the user’s terminal, the user’s login name, and the time of login in the form of time(2). String fields are terminated by a null byte (‘�’) if they are shorter than the size of the field.

The first entries ever created result from init(1) processing inittab(5). Before an entry is processed, though, init(1) cleans up utmp by setting ut_type to DEAD_PROCESS, clearing ut_user, ut_host, and ut_time with null bytes for each record which ut_type is not DEAD_PROCESS or RUN_LVL and where no process with PID ut_pid exists. If no empty record with the needed ut_id can be found, init(1) creates a new one. It sets ut_id from the inittab, ut_pid and ut_time to the current values, and ut_type to INIT_PROCESS.

mingetty(8) (or agetty(8)) locates the entry by the PID, changes ut_type to LOGIN_PROCESS, changes ut_time, sets ut_line, and waits for connection to be established. login(1), after a user has been authenticated, changes ut_type to USER_PROCESS, changes ut_time, and sets ut_host and ut_addr. Depending on mingetty(8) (or agetty(8)) and login(1), records may be located by ut_line instead of the preferable ut_pid.

When init(1) finds that a process has exited, it locates its utmp entry by ut_pid, sets ut_type to DEAD_PROCESS, and clears ut_user, ut_host, and ut_time with null bytes.

xterm(1) and other terminal emulators directly create a USER_PROCESS record and generate the ut_id by using the string that suffix part of the terminal name (the characters following /dev/[pt]ty). If they find a DEAD_PROCESS for this ID, they recycle it, otherwise they create a new entry. If they can, they will mark it as DEAD_PROCESS on exiting and it is advised that they null ut_line, ut_time, ut_user, and ut_host as well.

telnetd(8) sets up a LOGIN_PROCESS entry and leaves the rest to login(1) as usual. After the telnet session ends, telnetd(8) cleans up utmp in the described way.

The wtmp file records all logins and logouts. Its format is exactly like utmp except that a null username indicates a logout on the associated terminal. Furthermore, the terminal name ~ with username shutdown or reboot indicates a system shutdown or reboot and the pair of terminal names |/} logs the old/new system time when date(1) changes it. wtmp is maintained by login(1), init(1), and some versions of getty(8) (e.g., mingetty(8) or agetty(8)). None of these programs creates the file, so if it is removed, record-keeping is turned off.

FILES

/var/run/utmp
/var/log/wtmp

VERSIONS

POSIX.1 does not specify a utmp structure, but rather one named utmpx (as part of the XSI extension), with specifications for the fields ut_type, ut_pid, ut_line, ut_id, ut_user, and ut_tv. POSIX.1 does not specify the lengths of the ut_line and ut_user fields.

Linux defines the utmpx structure to be the same as the utmp structure.

STANDARDS

Linux.

HISTORY

Linux utmp entries conform neither to v7/BSD nor to System V; they are a mix of the two.

v7/BSD has fewer fields; most importantly it lacks ut_type, which causes native v7/BSD-like programs to display (for example) dead or login entries. Further, there is no configuration file which allocates slots to sessions. BSD does so because it lacks ut_id fields.

In Linux (as in System V), the ut_id field of a record will never change once it has been set, which reserves that slot without needing a configuration file. Clearing ut_id may result in race conditions leading to corrupted utmp entries and potential security holes. Clearing the abovementioned fields by filling them with null bytes is not required by System V semantics, but makes it possible to run many programs which assume BSD semantics and which do not modify utmp. Linux uses the BSD conventions for line contents, as documented above.

System V has no ut_host or ut_addr_v6 fields.

NOTES

Unlike various other systems, where utmp logging can be disabled by removing the file, utmp must always exist on Linux. If you want to disable who(1), then do not make utmp world readable.

The file format is machine-dependent, so it is recommended that it be processed only on the machine architecture where it was created.

Note that on biarch platforms, that is, systems which can run both 32-bit and 64-bit applications (x86-64, ppc64, s390x, etc.), ut_tv is the same size in 32-bit mode as in 64-bit mode. The same goes for ut_session and ut_time if they are present. This allows data files and shared memory to be shared between 32-bit and 64-bit applications. This is achieved by changing the type of ut_session to int32_t, and that of ut_tv to a struct with two int32_t fields tv_sec and tv_usec. Since ut_tv may not be the same as struct timeval, then instead of the call:

gettimeofday((struct timeval *) &ut.ut_tv, NULL);

the following method of setting this field is recommended:

struct utmp ut;
struct timeval tv;
gettimeofday(&tv, NULL);
ut.ut_tv.tv_sec = tv.tv_sec;
ut.ut_tv.tv_usec = tv.tv_usec;

120 - Linux cli command charmap

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command charmap and provides detailed information about the command charmap, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the charmap.

NAME 🖥️ charmap 🖥️

character set description file

DESCRIPTION

A character set description (charmap) defines all available characters and their encodings in a character set. localedef(1) can use charmaps to create locale variants for different character sets.

Syntax

The charmap file starts with a header that may consist of the following keywords:

<code_set_name>
is followed by the name of the character map.

<comment_char>
is followed by a character that will be used as the comment character for the rest of the file. It defaults to the number sign (#).

<escape_char>
is followed by a character that should be used as the escape character for the rest of the file to mark characters that should be interpreted in a special way. It defaults to the backslash (.

<mb_cur_max>
is followed by the maximum number of bytes for a character. The default value is 1.

<mb_cur_min>
is followed by the minimum number of bytes for a character. This value must be less than or equal than <mb_cur_max>. If not specified, it defaults to <mb_cur_max>.

The character set definition section starts with the keyword CHARMAP in the first column.

The following lines may have one of the two following forms to define the character set:

<character> byte-sequence comment
This form defines exactly one character and its byte sequence, comment being optional.

<character>..<character> byte-sequence comment
This form defines a character range and its byte sequence, comment being optional.

The character set definition section ends with the string END CHARMAP.

The character set definition section may optionally be followed by a section to define widths of characters.

The WIDTH_DEFAULT keyword can be used to define the default width for all characters not explicitly listed. The default character width is 1.

The width section for individual characters starts with the keyword WIDTH in the first column.

The following lines may have one of the two following forms to define the widths of the characters:

<character> width
This form defines the width of exactly one character.

<character>…<character> width
This form defines the width for all the characters in the range.

The width definition section ends with the string END WIDTH.

FILES

/usr/share/i18n/charmaps
Usual default character map path.

STANDARDS

POSIX.2.

EXAMPLES

The Euro sign is defined as follows in the UTF-8 charmap:

<U20AC>     /xe2/x82/xac EURO SIGN

121 - Linux cli command configssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command configssl and provides detailed information about the command configssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the configssl.

NAME 🖥️ configssl 🖥️

OpenSSL CONF library configuration files

DESCRIPTION

This page documents the syntax of OpenSSL configuration files, as parsed by NCONF_load (3) and related functions. This format is used by many of the OpenSSL commands, and to initialize the libraries when used by any application.

The first part describes the general syntax of the configuration files, and subsequent sections describe the semantics of individual modules. Other modules are described in fips_config (5) and x509v3_config (5). The syntax for defining ASN.1 values is described in ASN1_generate_nconf (3).

SYNTAX

A configuration file is a series of lines. Blank lines, and whitespace between the elements of a line, have no significance. A comment starts with a # character; the rest of the line is ignored. If the # is the first non-space character in a line, the entire line is ignored.

Directives

Two directives can be used to control the parsing of configuration files: .include and .pragma.

For compatibility with older versions of OpenSSL, an equal sign after the directive will be ignored. Older versions will treat it as an assignment, so care should be taken if the difference in semantics is important.

A file can include other files using the include syntax:

.include [=] pathname

If pathname is a simple filename, that file is included directly at that point. Included files can have .include statements that specify other files. If pathname is a directory, all files within that directory that have a .cnf or .conf extension will be included. (This is only available on systems with POSIX IO support.) Any sub-directories found inside the pathname are ignored. Similarly, if a file is opened while scanning a directory, and that file has an .include directive that specifies a directory, that is also ignored.

As a general rule, the pathname should be an absolute path; this can be enforced with the abspath and includedir pragmas, described below. The environment variable OPENSSL_CONF_INCLUDE, if it exists, is prepended to all relative pathnames. If the pathname is still relative, it is interpreted based on the current working directory.

To require all file inclusions to name absolute paths, use the following directive:

.pragma [=] abspath:value

The default behavior, where the value is false or off, is to allow relative paths. To require all .include pathnames to be absolute paths, use a value of true or on.

In these files, the dollar sign, $, is used to reference a variable, as described below. On some platforms, however, it is common to treat $ as a regular character in symbol names. Supporting this behavior can be done with the following directive:

.pragma [=] dollarid:value

The default behavior, where the value is false or off, is to treat the dollarsign as indicating a variable name; foo$bar is interpreted as foo followed by the expansion of the variable bar. If value is true or on, then foo$bar is a single seven-character name and variable expansions must be specified using braces or parentheses.

.pragma [=] includedir:value

If a relative pathname is specified in the .include directive, and the OPENSSL_CONF_INCLUDE environment variable doesn’t exist, then the value of the includedir pragma, if it exists, is prepended to the pathname.

Settings

A configuration file is divided into a number of sections. A section begins with the section name in square brackets, and ends when a new section starts, or at the end of the file. The section name can consist of alphanumeric characters and underscores. Whitespace between the name and the brackets is removed.

The first section of a configuration file is special and is referred to as the default section. This section is usually unnamed and spans from the start of file until the first named section. When a name is being looked up, it is first looked up in the current or named section, and then the default section if necessary.

The environment is mapped onto a section called ENV.

Within a section are a series of name/value assignments, described in more detail below. As a reminder, the square brackets shown in this example are required, not optional:

[ section ] name1 = This is value1 name2 = Another value … [ newsection ] name1 = New value1 name3 = Value 3

The name can contain any alphanumeric characters as well as a few punctuation symbols such as . , ; and _. Whitespace after the name and before the equal sign is ignored.

If a name is repeated in the same section, then all but the last value are ignored. In certain circumstances, such as with Certificate DNs, the same field may occur multiple times. In order to support this, commands like openssl-req (1) ignore any leading text that is preceded with a period. For example:

1.OU = First OU 2.OU = Second OU

The value consists of the string following the = character until end of line with any leading and trailing whitespace removed.

The value string undergoes variable expansion. The text $var or ${var} inserts the value of the named variable from the current section. To use a value from another section use $section::name or ${section::name}. By using $ENV::name, the value of the specified environment variable will be substituted.

Variables must be defined before their value is referenced, otherwise an error is flagged and the file will not load. This can be worked around by specifying a default value in the default section before the variable is used.

Any name/value settings in an ENV section are available to the configuration file, but are not propagated to the environment.

It is an error if the value ends up longer than 64k.

It is possible to escape certain characters by using a single ’ or double " quote around the value, or using a backslash ** before the character, By making the last character of a line a ** a value string can be spread across multiple lines. In addition the sequences ** **, ** **, and ** ** are recognized.

The expansion and escape rules as described above that apply to value also apply to the pathname of the .include directive.

OPENSSL LIBRARY CONFIGURATION

The sections below use the informal term module to refer to a part of the OpenSSL functionality. This is not the same as the formal term FIPS module, for example.

The OpenSSL configuration looks up the value of openssl_conf in the default section and takes that as the name of a section that specifies how to configure any modules in the library. It is not an error to leave any module in its default configuration. An application can specify a different name by calling CONF_modules_load_file(), for example, directly.

OpenSSL also looks up the value of config_diagnostics. If this exists and has a nonzero numeric value, any error suppressing flags passed to CONF_modules_load() will be ignored. This is useful for diagnosing misconfigurations but its use in production requires additional consideration. With this option enabled, a configuration error will completely prevent access to a service. Without this option and in the presence of a configuration error, access will be allowed but the desired configuration will not be used.

# These must be in the default section config_diagnostics = 1 openssl_conf = openssl_init [openssl_init] oid_section = oids providers = providers alg_section = evp_properties ssl_conf = ssl_configuration engines = engines random = random [oids] … new oids here … [providers] … provider stuff here … [evp_properties] … EVP properties here … [ssl_configuration] … SSL/TLS configuration properties here … [engines] … engine properties here … [random] … random properties here …

The semantics of each module are described below. The phrase “in the initialization section” refers to the section identified by the openssl_conf or other name (given as openssl_init in the example above). The examples below assume the configuration above is used to specify the individual sections.

ASN.1 Object Identifier Configuration

The name oid_section in the initialization section names the section containing name/value pairs of OID’s. The name is the short name; the value is an optional long name followed by a comma, and the numeric value. While some OpenSSL commands have their own section for specifying OID’s, this section makes them available to all commands and applications.

[oids] shortName = a very long OID name, 1.2.3.4 newoid1 = 1.2.3.4.1 some_other_oid = 1.2.3.5

If a full configuration with the above fragment is in the file example.cnf, then the following command line:

OPENSSL_CONF=example.cnf openssl asn1parse -genstr OID:1.2.3.4.1

will output:

0:d=0 hl=2 l= 4 prim: OBJECT :newoid1

showing that the OID “newoid1” has been added as “1.2.3.4.1”.

Provider Configuration

The name providers in the initialization section names the section containing cryptographic provider configuration. The name/value assignments in this section each name a provider, and point to the configuration section for that provider. The provider-specific section is used to specify how to load the module, activate it, and set other parameters.

Within a provider section, the following names have meaning:

identity
This is used to specify an alternate name, overriding the default name specified in the list of providers. For example: [providers] foo = foo_provider [foo_provider] identity = my_fips_module

module
Specifies the pathname of the module (typically a shared library) to load.

activate
If present, the module is activated. The value assigned to this name is not significant.

All parameters in the section as well as sub-sections are made available to the provider.

Default provider and its activation

If no providers are activated explicitly, the default one is activated implicitly. See OSSL_PROVIDER-default (7) for more details.

If you add a section explicitly activating any other provider(s), you most probably need to explicitly activate the default provider, otherwise it becomes unavailable in openssl. It may make the system remotely unavailable.

EVP Configuration

The name alg_section in the initialization section names the section containing algorithmic properties when using the EVP API.

Within the algorithm properties section, the following names have meaning:

default_properties
The value may be anything that is acceptable as a property query string for EVP_set_default_properties().

fips_mode (deprecated)
The value is a boolean that can be yes or no. If the value is yes, this is exactly equivalent to: default_properties = fips=yes If the value is no, nothing happens. Using this name is deprecated, and if used, it must be the only name in the section.

SSL Configuration

The name ssl_conf in the initialization section names the section containing the list of SSL/TLS configurations. As with the providers, each name in this section identifies a section with the configuration for that name. For example:

[ssl_configuration] server = server_tls_config client = client_tls_config system_default = tls_system_default [server_tls_config] … configuration for SSL/TLS servers … [client_tls_config] … configuration for SSL/TLS clients …

The configuration name system_default has a special meaning. If it exists, it is applied whenever an SSL_CTX object is created. For example, to impose system-wide minimum TLS and DTLS protocol versions:

[tls_system_default] MinProtocol = TLSv1.2 MinProtocol = DTLSv1.2

The minimum TLS protocol is applied to SSL_CTX objects that are TLS-based, and the minimum DTLS protocol to those are DTLS-based. The same applies also to maximum versions set with MaxProtocol.

Each configuration section consists of name/value pairs that are parsed by SSL_CONF_cmd (3), which will be called by SSL_CTX_config() or SSL_config(), appropriately. Note that any characters before an initial dot in the configuration section are ignored, so that the same command can be used multiple times. This probably is most useful for loading different key types, as shown here:

[server_tls_config] RSA.Certificate = server-rsa.pem ECDSA.Certificate = server-ecdsa.pem

Engine Configuration

The name engines in the initialization section names the section containing the list of ENGINE configurations. As with the providers, each name in this section identifies an engine with the configuration for that engine. The engine-specific section is used to specify how to load the engine, activate it, and set other parameters.

Within an engine section, the following names have meaning:

engine_id
This is used to specify an alternate name, overriding the default name specified in the list of engines. If present, it must be first. For example: [engines] foo = foo_engine [foo_engine] engine_id = myfoo

dynamic_path
This loads and adds an ENGINE from the given path. It is equivalent to sending the ctrls SO_PATH with the path argument followed by LIST_ADD with value 2 and LOAD to the dynamic ENGINE. If this is not the required behaviour then alternative ctrls can be sent directly to the dynamic ENGINE using ctrl commands.

init
This specifies whether to initialize the ENGINE. If the value is 0 the ENGINE will not be initialized, if the value is 1 an attempt is made to initialize the ENGINE immediately. If the init command is not present then an attempt will be made to initialize the ENGINE after all commands in its section have been processed.

default_algorithms
This sets the default algorithms an ENGINE will supply using the function ENGINE_set_default_string().

All other names are taken to be the name of a ctrl command that is sent to the ENGINE, and the value is the argument passed with the command. The special value EMPTY means no value is sent with the command. For example:

[engines] foo = foo_engine [foo_engine] dynamic_path = /some/path/fooengine.so some_ctrl = some_value default_algorithms = ALL other_ctrl = EMPTY

Random Configuration

The name random in the initialization section names the section containing the random number generator settings.

Within the random section, the following names have meaning:

random
This is used to specify the random bit generator. For example: [random] random = CTR-DRBG The available random bit generators are:

CTR-DRBG

HASH-DRBG

HMAC-DRBG

cipher

This specifies what cipher a CTR-DRBG random bit generator will use. Other random bit generators ignore this name. The default value is AES-256-CTR.

digest
This specifies what digest the HASH-DRBG or HMAC-DRBG random bit generators will use. Other random bit generators ignore this name.

properties
This sets the property query used when fetching the random bit generator and any underlying algorithms.

seed
This sets the randomness source that should be used. By default SEED-SRC will be used outside of the FIPS provider. The FIPS provider uses call backs to access the same randomness sources from outside the validated boundary.

seed_properties
This sets the property query used when fetching the randomness source.

EXAMPLES

This example shows how to use quoting and escaping.

# This is the default section. HOME = /temp configdir = $ENV::HOME/config [ section_one ] # Quotes permit leading and trailing whitespace any = " any variable name " other = A string that can \ cover several lines \ by including \ characters message = Hello World [ section_two ] greeting = $section_one::message

This example shows how to expand environment variables safely. In this example, the variable tempfile is intended to refer to a temporary file, and the environment variable TEMP or TMP, if present, specify the directory where the file should be put. Since the default section is checked if a variable does not exist, it is possible to set TMP to default to /tmp, and TEMP to default to TMP.

# These two lines must be in the default section. TMP = /tmp TEMP = $ENV::TMP # This can be used anywhere tmpfile = ${ENV::TEMP}/tmp.filename

This example shows how to enforce FIPS mode for the application sample.

sample = fips_config [fips_config] alg_section = evp_properties [evp_properties] default_properties = “fips=yes”

ENVIRONMENT

OPENSSL_CONF
The path to the config file, or the empty string for none. Ignored in set-user-ID and set-group-ID programs.

OPENSSL_ENGINES
The path to the engines directory. Ignored in set-user-ID and set-group-ID programs.

OPENSSL_MODULES
The path to the directory with OpenSSL modules, such as providers. Ignored in set-user-ID and set-group-ID programs.

OPENSSL_CONF_INCLUDE
The optional path to prepend to all .include paths.

BUGS

There is no way to include characters using the octal ** nn** form. Strings are all null terminated so nulls cannot form part of the value.

The escaping isn’t quite right: if you want to use sequences like ** ** you can’t use any quote escaping on the same line.

The limit that only one directory can be opened and read at a time can be considered a bug and should be fixed.

HISTORY

An undocumented API, NCONF_WIN32(), used a slightly different set of parsing rules there were intended to be tailored to the Microsoft Windows platform. Specifically, the backslash character was not an escape character and could be used in pathnames, only the double-quote character was recognized, and comments began with a semi-colon. This function was deprecated in OpenSSL 3.0; applications with configuration files using that syntax will have to be modified.

COPYRIGHT

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

122 - Linux cli command systemd.target

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.target and provides detailed information about the command systemd.target, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.target.

NAME 🖥️ systemd.target 🖥️

Target unit configuration

SYNOPSIS

target.target

DESCRIPTION

A unit configuration file whose name ends in “.target” encodes information about a target unit of systemd. Target units are used to group units and to set synchronization points for ordering dependencies with other unit files.

This unit type has no specific options. See systemd.unit(5) for the common options of all unit configuration files. The common configuration items are configured in the generic [Unit] and [Install] sections. A separate [Target] section does not exist, since no target-specific options may be configured.

Target units do not offer any additional functionality on top of the generic functionality provided by units. They merely group units, allowing a single target name to be used in Wants= and Requires= settings to establish a dependency on a set of units defined by the target, and in Before= and After= settings to establish ordering. Targets establish standardized names for synchronization points during boot and shutdown. Importantly, see systemd.special(7) for examples and descriptions of standard systemd targets.

Target units provide a more flexible replacement for SysV runlevels in the classic SysV init system. For compatibility reasons special target units such as runlevel3.target exist which are used by the SysV runlevel compatibility code in systemd, see systemd.special(7) for details.

Note that a target unit file must not be empty, lest it be considered a masked unit. It is recommended to provide a [Unit] section which includes informative Description= and Documentation= options.

AUTOMATIC DEPENDENCIES

Implicit Dependencies

There are no implicit dependencies for target units.

Default Dependencies

The following dependencies are added unless DefaultDependencies=no is set:

·
Target units will automatically complement all configured dependencies of type Wants= or Requires= with dependencies of type After= unless DefaultDependencies=no is set in the specified units.
Note that the reverse is not true. For example, defining Wants=that.target in some.service will not automatically add the After=that.target ordering dependency for some.service. Instead, some.service should use the primary synchronization function of target type units, by setting a specific After=that.target or Before=that.target ordering dependency in its .service unit file.

·
Target units automatically gain Conflicts= and Before= dependencies against shutdown.target.

OPTIONS

Target unit files may include [Unit] and [Install] sections, which are described in systemd.unit(5). No options specific to this file type are supported.

EXAMPLE

Example 1. Simple standalone target

emergency-net.target

[Unit]
Description=Emergency Mode with Networking
Requires=emergency.target systemd-networkd.service
After=emergency.target systemd-networkd.service
AllowIsolate=yes

When adding dependencies to other units, its important to check if they set DefaultDependencies=. Service units, unless they set DefaultDependencies=no, automatically get a dependency on sysinit.target. In this case, both emergency.target and systemd-networkd.service have DefaultDependencies=no, so they are suitable for use in this target, and do not pull in sysinit.target.

You can now switch into this emergency mode by running systemctl isolate emergency-net.target or by passing the option systemd.unit=emergency-net.target on the kernel command line.

Other units can have WantedBy=emergency-net.target in the [Install] section. After they are enabled using systemctl enable, they will be started before emergency-net.target is started. It is also possible to add arbitrary units as dependencies of emergency.target without modifying them by using systemctl add-wants.

123 - Linux cli command deb-symbols

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command deb-symbols and provides detailed information about the command deb-symbols, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the deb-symbols.

NAME 🖥️ deb-symbols 🖥️

symbols - Debian’s extended shared library information file

SYNOPSIS

DEBIAN/symbols

DESCRIPTION

The symbol files are shipped in Debian binary packages, and its format is a subset of the template symbol files used by dpkg-gensymbols (1) in Debian source packages, see deb-src-symbols (5).

The format for an extended shared library dependency information entry in these files is:

library-soname main-dependency-template [| alternative-dependency-template] […] [* field-name: field-value] […] symbol minimal-version [id-of-dependency-template]

The library-soname is exactly the value of the SONAME field as exported by objdump (1). A dependency-template is a dependency where #MINVER# is dynamically replaced either by a version check like “(>= minimal-version)” or by nothing (if an unversioned dependency is deemed sufficient).

Each exported symbol (listed as name@version, with version being “Base” if the library is not versioned) is associated to a minimal-version of its dependency template (the main dependency template is always used and will end up being combined with the dependency template referenced by id-of-dependency-template if present). The first alternative dependency template is numbered 1, the second one 2, etc. Each column is separated by exactly a single whitespace.

Each entry for a library can also have some fields of meta-information. Those fields are stored on lines starting with an asterisk. Currently, the only valid fields are:

Build-Depends-Package
It indicates the name of the “-dev” package associated to the library and is used by dpkg-shlibdeps to make sure that the dependency generated is at least as strict as the corresponding build dependency (since dpkg 1.14.13).

Build-Depends-Packages
The same as Build-Depends-Package but accepts a comma-separated list of package names (since dpkg 1.20.0). This field will override any Build-Depends-Package field present, and is mostly useful with “-dev” packages and metapackages depending on these, say for a transition period.

Allow-Internal-Symbol-Groups
It indicates what internal symbol groups should be ignored, as a whitespace separated list, so that the symbols contained in those groups get included in the output file (since dpkg 1.20.1). This should only be necessary for toolchain packages providing those internal symbols. The available groups are system dependent, for ELF and GNU-based systems these are aeabi and gomp.

Ignore-Blacklist-Groups
A deprecated alias for Allow-Internal-Symbol-Groups (since dpkg 1.20.1, supported since dpkg 1.17.6).

EXAMPLES

Simple symbols file

libftp.so.3 libftp3 #MINVER# DefaultNetbuf@Base 3.1-1-6 FtpAccess@Base 3.1-1-6 […]

Advanced symbols file

libGL.so.1 libgl1 | libgl1-mesa-glx #MINVER# * Build-Depends-Package: libgl1-mesa-dev publicGlSymbol@Base 6.3-1 […] implementationSpecificSymbol@Base 6.5.2-7 1 […]

124 - Linux cli command user-dirs.dirs

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command user-dirs.dirs and provides detailed information about the command user-dirs.dirs, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the user-dirs.dirs.

NAME 🖥️ user-dirs.dirs 🖥️

dirs.dirs - settings for XDG user dirs

DESCRIPTION

The $HOME/.config/user-dirs.dirs file is a text file that contains the user-specific values for the XDG user dirs. It is created and updated by the xdg-user-dirs-update command.

This file contains lines of the form

XDG_NAME_DIR=VALUE

The following names are recognised:

DESKTOP

DOWNLOAD

TEMPLATES

PUBLICSHARE

DOCUMENTS

MUSIC

PICTURES

VIDEOS

VALUE must be of the form “$HOME/Path” or “/Path”.

Lines beginning with a # character are ignored.

The format of user-dirs.dirs is designed to allow direct sourcing of this file in shell scripts.

ENVIRONMENT

XDG_CONFIG_DIRS

The user-dirs.defaults file is located in this directory. The default is /etc/xdg.

125 - Linux cli command crypttab

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command crypttab and provides detailed information about the command crypttab, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the crypttab.

NAME 🖥️ crypttab 🖥️

static information about encrypted filesystems

DESCRIPTION

The file /etc/crypttab contains descriptive information about encrypted devices. crypttab is only read by programs (e.g. cryptdisks_start and cryptdisks_stop), and not written; it is the duty of the system administrator to properly create and maintain this file. crypttab entries are treated sequentially, so their order matters (dependencies need to listed first).

Each encrypted device is described on a separate line. Fields on each line are separated by tabs or spaces. Lines starting with # are comments, and blank lines are ignored. Octal sequences �num within a field are decoded, which can be used for values containing spaces or special characters. A backslash which doesnt start an octal sequence yields undefined behavior.

The first field, target, describes the mapped device name. It must be a plain filename without any directory components. A mapped device which encrypts/decrypts data to/from the source device will be created at /dev/mapper/target by cryptsetup.

The second field, source device, describes either the block special device or file that contains the encrypted data. Instead of giving the source device explicitly, the UUID (resp. LABEL, PARTUUID and PARTLABEL) is supported as well, using “UUID=<uuid>” (resp. “LABEL=<label>”, “PARTUUID=<partuuid>” and “PARTLABEL=<partlabel>”).

The third field, key file, describes the file to use as a key for decrypting the data of the source device. In case of a keyscript, the value of this field is given as argument to the keyscript. Note that the entire key file will be used as the passphrase; the passphrase must not be followed by a newline character.

It can also be a device name (e.g. /dev/urandom), note however that LUKS requires a persistent key and therefore does not support random data keys.

If the key file is the string none, a passphrase will be read interactively from the console. In this case, the options check, checkargs and tries may be useful.

The fourth field, options, is an optional comma-separated list of options and/or flags describing the device type (luks, tcrypt, bitlk, fvault2, or plain which is also the default) and cryptsetup options associated with the encryption process. The supported options are described below. For plain dm-crypt devices the cipher, hash and size options are required. Some options can be changed on active mappings using cryptsetup refresh [<options>] <name>. Furthermore some options can be permanently written into metadata of LUKS2 headers using cryptsetups –persistent flag.

Note that the first three fields are required and that a missing field will lead to unspecified behaviour.

ON DIFFERENT CRYPTTAB FORMATS

Please note that there are several independent cryptsetup wrappers with their own crypttab format. This manpage covers Debians implementation for initramfs scripts and SysVinit init scripts. systemd brings its own crypttab implementation. We try to cover the differences between the systemd and our implementation in this manpage, but if in doubt, better check the systemd crypttab(5) manpage, e.g. online at https://www.freedesktop.org/software/systemd/man/crypttab.html.

OPTIONS

cipher=<cipher>

Encryption algorithm (ignored for LUKS and TCRYPT devices). See cryptsetup -c.

size=<size>

Encryption key size (ignored for LUKS and TCRYPT devices). See cryptsetup -s.

sector-size=<bytes>

Sector size. See cryptsetup(8) for possible values and the default value of this option.

hash=<hash>

Hash algorithm (ignored for LUKS and TCRYPT devices). See cryptsetup -h.

offset=<offset>

Start offset (ignored for LUKS and TCRYPT devices). Uses cryptsetup -o.

skip=<skip>

Skip sectors at the beginning (ignored for LUKS and TCRYPT devices). Uses cryptsetup -p.

keyfile-offset=<keyfile-offset>

Specifies the number of bytes to skip at the start of the key file.

keyfile-size=<keyfile-size>

Specifies the maximum number of bytes to read from the key file. The default is to read the whole file up to the compiled-in maximum, that can be queried with cryptsetup –help. This option is ignored for plain dm-crypt devices, as the key file size is then given by the encryption key size (option size).

keyslot=<slot>, key-slot=<slot>

Key slot (ignored for non-LUKS devices). See cryptsetup -S.

header=<path>

Detached header file (ignored for plain dm-crypt devices). See cryptsetup –header.

verify

Verify password. Uses cryptsetup -y.

readonly, read-only

Set up a read-only mapping.

tries=<num>

Try to unlock the device <num> before failing. Its particularly useful when using a passphrase or a keyscript that asks for interactive input. If you want to disable retries, pass “tries=1”. Default is “3”. Setting “tries=0” means infinitive retries.

discard

Allow using of discards (TRIM) requests for device.
Starting with Debian 10 (Buster), this option is added per default to new dm-crypt devices by the Debian Installer. If you dont care about leaking access patterns (filesystem type, used space) and dont have hidden truecrypt volumes inside this volume, then it should be safe to enable this option. See the following warning for further information.
WARNING: Assess the specific security risks carefully before enabling this option. For example, allowing discards on encrypted devices may lead to the leak of information about the ciphertext device (filesystem type, used space etc.) if the discarded blocks can be located easily on the device later.

luks

Force LUKS mode. When this mode is used, the following options are ignored since they are provided by the LUKS header on the device: cipher=, hash=, size=

plain

Force plain encryption mode.

bitlk

Force BITLK (Windows BitLocker-compatible) mode. WARNING: crypttab support is currently experimental.

fvault2

Force Apples FileVault2 mode. Only the (legacy) FileVault2 format based on Core Storage and HFS+ filesystem (introduced in MacOS X 10.7 Lion) is currently supported; the new version of FileVault based on the APFS filesystem used in recent macOS versions is not supported.

tcrypt

Use TrueCrypt encryption mode. When this mode is used, the following options are ignored since they are provided by the TrueCrypt header on the device or do not apply: cipher=, hash=, keyfile-offset=, keyfile-size=, size=

veracrypt, tcrypt-veracrypt

Use VeraCrypt extension to TrueCrypt device. Only useful in conjunction with tcrypt option (ignored for non-TrueCrypt devices).

tcrypthidden, tcrypt-hidden

Use hidden TCRYPT header (ignored for non-TCRYPT devices).

same-cpu-crypt

Perform encryption using the same cpu that IO was submitted on.

submit-from-crypt-cpus

Disable offloading writes to a separate thread after encryption.

no-read-workqueue, no-write-workqueue

Bypass dm-crypt internal workqueue and process read or write requests synchronously.

swap

Run mkswap on the created device.
This option is ignored for initramfs devices.

tmp[=<tmpfs>]

Run mkfs with filesystem type <tmpfs> (or ext4 if omitted) on the created device.
This option is ignored for initramfs devices.

check[=<check>]

Check the content of the target device by a suitable program; if the check fails, the device is closed immediately. The program is being run with decrypted volume (target device) as first positional argument and, if the checkargs option is used, its value as second argument. See the CHECKSCRIPTS section for more information.
The program is either specified by full path or relative to /lib/cryptsetup/checks/. If omitted, then the value of $CRYPTDISKS_CHECK set in /etc/default/cryptdisks is used (blkid by default).
This option is specific to the Debian crypttab format. Its not supported by systemd.

checkargs=<arguments>

Give <arguments> as the second argument to the check script. See the CHECKSCRIPTS section for more information.
This option is specific to the Debian crypttab format. Its not supported by systemd.

initramfs

The initramfs hook processes the root device, any resume devices and any devices with the initramfs option set. These devices are processed within the initramfs stage of boot. As an example, that allows the use of remote unlocking using dropbear.
This option is specific to the Debian crypttab format. Its not supported by systemd.

noearly

The cryptsetup init scripts are invoked twice during the boot process - once before lvm, raid, etc. are started and once again after that. Sometimes you need to start your encrypted disks in a special order. With this option the device is ignored during the first invocation of the cryptsetup init scripts.
This option is ignored for initramfs devices and specific to the Debian crypttab format. Its not supported by systemd.

noauto

Entirely ignore the device at the boot process. Its still possible to map the device manually using cryptdisks_start.
This option is ignored for initramfs devices and specific to the Debian crypttab format. Its not supported by systemd.

loud

Be loud. Print warnings if a device does not exist. This option overrides the option quiet.
This option is ignored for initramfs devices and specific to the Debian crypttab format. Its not supported by systemd.

quiet

Be quiet. Dont print warnings if a device does not exist. This option overrides the option loud.
This option is ignored for initramfs devices and specific to the Debian crypttab format. Its not supported by systemd.

keyscript=<path>

The executable at the indicated path is executed with the value of the third field as only argument. The keyscripts standard output is passed to cryptsetup as decyption key. Its exit status is currently ignored, but no assumption should be made in that regard. When used in initramfs, the executable either needs to be self-contained (i.e. doesnt rely on any external program which is not present in the initramfs environment) or the dependencies have to added to the initramfs image by other means. The program is either specified by full path or relative to /lib/cryptsetup/scripts/.
LIMITATIONS: All binaries and files on which the keyscript depends must be available at the time of execution. Special care needs to be taken for encrypted filesystems like /usr or /var. As an example, unlocking encrypted /usr must not depend on binaries from /usr/(s)bin.
This option is specific to the Debian crypttab format. Its not supported by systemd.
WARNING: With systemd as init system, this option might be ignored. At the time this is written (December 2016), the systemd cryptsetup helper doesnt support the keyscript option to /etc/crypttab. For the time being, the only option to use keyscripts along with systemd is to force processing of the corresponding crypto devices in the initramfs. See the initramfs option for further information.
All fields of the appropriate crypttab entry are available to the keyscript as exported environment variables:
CRYPTTAB_NAME, _CRYPTTAB_NAME
The target name (after resp. before octal sequence decoding).
CRYPTTAB_SOURCE, _CRYPTTAB_SOURCE
The source device (after resp. before octal sequence decoding and device resolution).
CRYPTTAB_KEY, _CRYPTTAB_KEY
The value of the third field (after resp. before octal sequence decoding).
CRYPTTAB_OPTIONS, _CRYPTTAB_OPTIONS
A list of exported crypttab options (after resp. before octal sequence decoding).
CRYPTTAB_OPTION_<option>
The value of the appropriate crypttab option, with value set to yes in case the option is merely a flag. For option aliases, such as readonly and read-only, the variable name refers to the first alternative listed (thus CRYPTTAB_OPTION_readonly in that case). If the crypttab option name contains - characters, then they are replaced with _ in the exported variable name. For instance, the value of the CRYPTTAB_OPTION_keyfile_offset environment variable is set to the value of the keyfile-offset crypttab option.
CRYPTTAB_TRIED
Number of previous tries since start of cryptdisks (counts until maximum number of tries is reached).

CHECKSCRIPTS

blkid

Checks for any known filesystem. Supports a filesystem type as argument via <checkargs>:
·
no checkargs - succeeds if any valid filesystem is found on the device.
·
“none” - succeeds if no valid filesystem is found on the device.
·
“ext4” [or another filesystem type like xfs, swap, crypto_LUKS, …] - succeeds if ext4 filesystem is found on the device.

un_blkid

Checks for no known filesystem. Supports a filesystem type as argument via <checkargs>:
·
no checkargs - succeeds if no valid filesystem is found on the device.
·
“ext4” [or another filesystem type like xfs, swap, crypto_LUKS, …] - succeeds if no ext4 filesystem is found on the device.

EXAMPLES

Encrypted swap device

cswap /dev/sda6 /dev/urandom plain,cipher=aes-xts-plain64,size=256,hash=sha1,swap

# Encrypted LUKS disk with interactive password, identified by its UUID, discard enabled
cdisk0 UUID=12345678-9abc-def012345-6789abcdef01 none luks,discard

# Encrypted TCRYPT disk with interactive password, discard enabled
tdisk0 /dev/sr0 none tcrypt,discard

# Encrypted ext4 disk with interactive password, discard enabled
# - retry 5 times if the check fails
cdisk1 /dev/sda2 none plain,cipher=aes-xts-plain64,size=256,hash=sha1,check,checkargs=ext4,tries=5,discard

# Encrypted disk with interactive password, discard enabled
# - use a nondefault check script
# - no retries
cdisk2 /dev/sdc1 none plain,cipher=aes-xts-plain64,size=256,hash=sha1,check=customscript,tries=1,discard

# Encrypted disk with interactive password, discard enabled
# - Twofish as the cipher, RIPEMD-160 as the hash
cdisk3 /dev/sda3 none plain,cipher=twofish,size=256,hash=ripemd160,discard

ENVIRONMENT

CRYPTDISKS_ENABLE

Set to yes to run cryptdisks initscripts at startup. Set to no to disable cryptdisks initscripts. Default is yes.

CRYPTDISKS_MOUNT

Specifies the mountpoints that are mounted before cryptdisks is invoked. Takes mountpoints configured in /etc/fstab as arguments. Separate mountpoints by space. This is useful for keys on removable devices, such as cdrom, usbstick, flashcard, etc. Default is unset.

CRYPTDISKS_CHECK

Specifies the default checkscript to be run against the target device, after cryptdisks has been invoked. The target device is passed as the first and only argument to the checkscript. Takes effect if the check option is given in crypttab with no value. See documentation for check option above for more information.

KNOWN UPGRADE ISSUES

The upstream defaults for encryption cipher, hash and keysize have changed several times in the past, and theyre expected to change again in future, for example if security issues arise. On LUKS devices, the used settings are stored in the LUKS header, and thus dont need to be configured in /etc/crypttab. For plain dm-crypt devices, no information about used cipher, hash and keysize are available at all. Therefore we strongly suggest to configure the cipher, hash and keysize in /etc/crypttab for plain dm-crypt devices, even if they match the current default.

AUTHOR

This manual page was originally written by Bastian Kleineidam <[email protected]> for the Debian distribution of cryptsetup. It has been further improved by Michael Gebetsroither <[email protected]>, David Härdeman <[email protected]> and Jonas Meurer <[email protected]>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

126 - Linux cli command groff_font

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command groff_font and provides detailed information about the command groff_font, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the groff_font.

Name

groff_font - GNU roff device and font description files

Description

The groff font and output device description formats are slight extensions of those used by AT&T device-independent troff. In distinction to the AT&T implementation, groff lacks a binary format; all files are text files. (Plan 9 troff has also abandoned the binary format.) The device and font description files for a device name are stored in a devname directory. The device description file is called DESC, and, for each font supported by the device, a font description file is called f, where f is usually an abbreviation of a font’s name and/or style. For example, the ps (PostScript) device has groff font description files for Times roman (TR) and Zapf Chancery Medium italic (ZCMI), among many others, while the utf8 device (for terminal emulators) has only font descriptions for the roman, italic, bold, and bold-italic styles (R, I, B, and BI, respectively).

Device and font description files are read by the formatter, troff, and by output drivers. The programs typically delegate these files’ processing to an internal library, libgroff, ensuring their consistent interpretation.

DESC file format

The DESC file contains a series of directives; each begins a line. Their order is not important, with two exceptions: (1) the res directive must precede any papersize directive; and (2) the charset directive must come last (if at all). If a directive name is repeated, later entries in the file override previous ones (except that the paper dimensions are computed based on the res directive last seen when papersize is encountered). Spaces and/or tabs separate words and are ignored at line boundaries. Comments start with the “#” character and extend to the end of a line. Empty lines are ignored.

**family **fam
The default font family is fam.

**fonts n F1 **
. . . Fn Fonts F1, . . . , Fn are mounted at font positions m + 1, . . ., m + n where m is the number of styles (see below). This directive may extend over more than one line. A font name of 0 causes no font to be mounted at the corresponding position.

**hor **n
The horizontal motion quantum is n basic units. Horizontal quantities are rounded to multiples of n.

**image_generator **program
Use program to generate PNG images from PostScript input. Under GNU/Linux, this is usually

but under other systems (notably Cygwin) it might be set to another name. The

driver uses this directive.

**paperlength **n
The vertical dimension of the output medium is n basic units (deprecated: use papersize instead).

**papersize **format-or-dimension-pair-or-file-name
. . . The dimensions of the output medium are as according to the argument, which is either a standard paper format, a pair of dimensions, or the name of a plain text file containing either of the foregoing. Recognized paper formats are the ISO and DIN formats A0–A7, B0–B7, C0–C7, and D0–D7; the U.S. formats letter, legal, tabloid, ledger, statement, and executive; and the envelope formats com10, monarch, and DL. Matching is performed without regard for lettercase.

Alternatively, the argument can be a custom paper format length**,**width (with no spaces before or after the comma). Both length and width must have a unit appended; valid units are “i” for inches, “c” for centimeters, “p” for points, and “P” for picas. Example: “12c,235p”. An argument that starts with a digit is always treated as a custom paper format.

Finally, the argument can be a file name (e.g., /etc/papersize); if the file can be opened, the first line is read and a match attempted against each other form. No comment syntax is supported.

More than one argument can be specified; each is scanned in turn and the first valid paper specification used.

**paperwidth **n
The horizontal dimension of the output medium is n basic units (deprecated: use papersize instead).

pass_filenames
Direct troff to emit the name of the source file being processed. This is achieved with the intermediate output command “x F”, which grohtml interprets.

**postpro **program
Use program as the postprocessor.

**prepro **program
Use program as a preprocessor. The html and xhtml output devices use this directive.

**print **program
Use program as the print spooler. If omitted, groff’s -l and -L options are ignored.

**res **n
The device resolution is n basic units per inch.

**sizes ***s1 *
. . . *sn * 0 The device has fonts at s1, . . ., sn scaled points (see below). The list of sizes must be terminated by a 0. Each si can also be a range of sizes m–n. The list can extend over more than one line.

**sizescale **n
A typographical point is subdivided into n scaled points. The default is 1.

**styles ***S1 *
. . . Sm The first m font mounting positions are associated with styles S1, . . ., Sm.

tcommand
The postprocessor can handle the t and u intermediate output commands.

unicode
The output device supports the complete Unicode repertoire. This directive is useful only for devices which produce character entities instead of glyphs.

If unicode is present, no charset section is required in the font description files since the Unicode handling built into groff is used. However, if there are entries in a font description file’s charset section, they either override the default mappings for those particular characters or add new mappings (normally for composite characters).

The utf8, html, and xhtml output devices use this directive.

**unitwidth **n
Quantities in the font description files are in basic units for fonts whose type size is n scaled points.

unscaled_charwidths
Make the font handling module always return unscaled glyph widths. The grohtml driver uses this directive.

use_charnames_in_special
troff should encode named glyphs inside device control commands. The grohtml driver uses this directive.

**vert **n
The vertical motion quantum is n basic units. Vertical quantities are rounded to multiples of n.

charset
This directive and the rest of the file are ignored. It is recognized for compatibility with other troff implementations. In GNU troff, character set repertoire is described on a per-font basis.

troff recognizes but ignores the directives spare1, spare2, and biggestfont.

The res, unitwidth, fonts, and sizes lines are mandatory. Directives not listed above are ignored by troff but may be used by postprocessors to obtain further information about the device.

Font description file format

On typesetting output devices, each font is typically available at multiple sizes. While paper measurements in the device description file are in absolute units, measurements applicable to fonts must be proportional to the type size. groff achieves this using the precedent set by AT&T device-independent troff: one font size is chosen as a norm, and all others are scaled linearly relative to that basis. The “unit width” is the number of basic units per point when the font is rendered at this nominal size.

For instance, groff’s lbp device uses a unitwidth of 800. Its Times roman font (“TR”) has a spacewidth of 833; this is also the width of its comma, period, centered period, and mathematical asterisk, while its “M” is 2,963 basic units. Thus, an “M” on the lbp device is 2,963 basic units wide at a notional type size of 800 points. (800-point type is not practical for most purposes, but using it enables the quantities in the font description files to be expressed as integers.)

A font description file has two sections. The first is a sequence of directives, and is parsed similarly to the DESC file described above. Except for the directive names that begin the second section, their ordering is immaterial. Later directives of the same name override earlier ones, spaces and tabs are handled in the same way, and the same comment syntax is supported. Empty lines are ignored throughout.

**name **F
The name of the font is F. “DESC” is an invalid font name. Simple integers are valid, but their use is discouraged. (groff requests and escape sequences interpret non-negative font names as mounting positions instead. Further, a font named “0” cannot be automatically mounted by the fonts directive of a DESC file.)

**spacewidth **n
The width of an unadjusted inter-word space is n basic units.

The directives above must appear in the first section; those below are optional.

**slant **n
The font’s glyphs have a slant of n degrees; a positive n slants in the direction of text flow.

**ligatures ***lig1 *
. . . *lign * [0] Glyphs lig1, . . ., lign are ligatures; possible ligatures are ff, fi, fl, ffi, and ffl. For compatibility with other troff implementations, the list of ligatures may be terminated with a 0. The list of ligatures must not extend over more than one line.

special
The font is special: when a glyph is requested that is not present in the current font, it is sought in any mounted fonts that bear this property.

Other directives in this section are ignored by troff, but may be used by postprocessors to obtain further information about the font.

The second section contains one or two subsections. These can appear in either order; the first one encountered commences the second section. Each starts with a directive on a line by itself. A charset subsection is mandatory unless the associated DESC file contains the unicode directive. Another subsection, kernpairs, is optional.

The directive charset starts the character set subsection. (For typesetter devices, this directive is misnamed since it starts a list of glyphs, not characters.) It precedes a series of glyph descriptions, one per line. Each such glyph description comprises a set of fields separated by spaces or tabs and organized as follows.

name metrics type code [entity-name] [– comment]

name identifies the glyph: if name is a printable character c, it corresponds to the troff ordinary character c. If name is a multi-character sequence not beginning with **, it corresponds to the GNU troff special character escape sequence “ *name] ”. A name consisting of three minus signs, “—”, indicates that the glyph is unnamed: such glyphs can be accessed only by the \N escape sequence in troff. A special character named “—” can still be defined using .char and similar requests. The name “***” defines the minus sign glyph. Finally, name can be the horizontal motion escape sequences, ** and ** (“thin” and “hair” spaces, respectively), in which case only the width metric described below is applied; a font can thus customize the widths of these spaces.

The form of the metrics field is as follows (on one line; it may be broken here for readability).

width [,[height [,[depth [,[italic-correction [,[left-italic-correction [,[subscript-correction]]]]]]]]]]

There must not be any spaces, tabs, or newlines between these subfields, which are in basic units expressed as decimal integers. Unspecified subfields default to 0. Since there is no associated binary format, these values are not required to fit into the C language data type char as they are in AT&T device-independent troff.

The width subfield gives the width of the glyph. The height subfield gives the height of the glyph (upwards is positive); if a glyph does not extend above the baseline, it should be given a zero height, rather than a negative height. The depth subfield gives the depth of the glyph, that is, the distance below the baseline to which the glyph extends (downwards is positive); if a glyph does not extend below the baseline, it should be given a zero depth, rather than a negative depth. Italic corrections are relevant to glyphs in italic or oblique styles. The italic-correction is the amount of space that should be added after an oblique glyph to be followed immediately by an upright glyph. The left-italic-correction is the amount of space that should be added before an oblique glyph to be preceded immediately by an upright glyph. The subscript-correction is the amount of space that should be added after an oblique glyph to be followed by a subscript; it should be less than the italic correction.

For fonts used with typesetting devices, the type field gives a featural description of the glyph: it is a bit mask recording whether the glyph is an ascender, descender, both, or neither. When a \w escape sequence is interpolated, these values are bitwise or-ed together for each glyph and stored in the ct register. In font descriptions for terminal devices, all glyphs might have a type of zero, regardless of their appearance.

0
means the glyph lies entirely between the baseline and a horizontal line at the “x-height” of the font, as with “a”, “c”, and “x”;

1
means the glyph descends below the baseline, like “p”;

2
means the glyph ascends above the font’s x-height, like “A” or “b”); and

3
means the glyph is both an ascender and a descender—this is true of parentheses in some fonts.

The code field gives a numeric identifier that the postprocessor uses to render the glyph. The glyph can be specified to troff using this code by means of the \N escape sequence. The code can be any integer (that is, any integer parsable by the C standard library’s

function).

The entity-name field defines an identifier for the glyph that the postprocessor uses to print the troff glyph name. This field is optional; it was introduced so that the grohtml output driver could encode its character set. For example, the glyph \Po] is represented by “£” in HTML 4.0. For efficiency, these data are now compiled directly into grohtml. grops uses the field to build sub-encoding arrays for PostScript fonts containing more than 256 glyphs. Anything on the line after the entity-name field or “–” is ignored.

A line in the charset section can also have the form

*name *"

identifying name as another name for the glyph mentioned in the preceding line. Such aliases can be chained.

The directive kernpairs starts a list of kerning adjustments to be made to adjacent glyph pairs from this font. It contains a sequence of lines formatted as follows.

g1 g2 n

The foregoing means that when glyph g1 is typeset immediately before g2, the space between them should be increased by n. Most kerning pairs should have a negative value for n.

Files

/usr/share/groff/1.23.0/font/devname*/DESC*
describes the output device name.

/usr/share/groff/1.23.0/font/devname*/*F
describes the font known as F on device name.

127 - Linux cli command updmap.cfg

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command updmap.cfg and provides detailed information about the command updmap.cfg, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the updmap.cfg.

NAME 🖥️ updmap.cfg 🖥️

configuration of font mapping/inclusion for dvips and friends.

DESCRIPTION

The file updmap.cfg is the central font configuration file of a teTeX system and is read by updmap(1). It describes if and how fonts should be included (or not included) into PS-/PDF-files. This works for Outline (Postscript Type1) and Bitmap Fonts (Postscript Type3) mostly coming from MetaFont.

updmap is a utility that creates font configuration files for dvips(1), pdftex(1), xdvi(1), ps2pk(1), gsftopk(1), and dvipdfmx(1). In an ideal world, updmap would be unnecessary – each of these programs would read the same configuration file to learn what fonts are available and how they should be treated. As things stand, however, each of these tools has subtly different requirements and thereby needs its own font configuration file. updmap creates font configuration files for all of these programs from several sources, namely all updmap.cfg, allowing you to easily keep all the different configuration files in sync.

Running “updmap –help” will output the main documentation for using updmap.

dvipsPreferOutline
Configures if dvips (by default) should prefer bitmap fonts or outline fonts if both are available? Independent of this setting, outlines can be forced by putting “p psfonts_t1.map” into a config file that dvips reads. Bitmaps can be forced by putting “p psfonts_pk.map” into a config file. We provide such config files which can be enabled via dvips -Poutline (resp. dvips -Ppk).
Valid settings for dvipsPreferOutline are true / false.

LW35
Which fonts of the “Basic 35 Laserwriter Fonts” do you want to use and how are the filenames chosen? Valid settings:
URW: URW fonts with “vendor” filenames (e.g. n019064l.pfb)
URWkb: URW fonts with “berry” filenames (e.g. uhvbo8ac.pfb)
ADOBE: Adobe fonts with “vendor” filenames (e.g. hvnbo___.pfb)
ADOBEkb: Adobe fonts with “berry” filenames (e.g. phvbo8an.pfb)

dvipsDownloadBase35
Configures if dvips (by default) should download the 35 base PostScript fonts into the document (set true) or should these fonts be used from the ps interpreter / printer (set false).
The user can override the default by specifying dvips -Pdownload35 (resp. dvips -Pbuiltin35) to download the LW35 fonts (resp. use the built-in fonts).
Valid settings are true / false.

pdftexDownloadBase14
Should pdftex download the 14 base PDF fonts? Since some configurations (ps / pdf tools / printers) use bad default fonts, it is safer to download the fonts. The pdf files get bigger, but that is the cost.
Valid settings are true (download the fonts) or false (don’t download the fonts). Adobe recommends embedding all fonts.

pxdviUse
Should special map files for pxdvi be created? pxdvi is an adaption of xdvi with support for reading and displaying files generated by the ptex family of engines.
Valid settings are true (generate configuration) or false. See http://www.tug.org/texlive/updmap-kanji.html for detailed discussion.

kanjiEmbed
kanjiVariant
The options kanjiEmbed and kanjiVariant specify special replacements in the map lines. In a map, the string “@kanjiEmbed@” will be replaced by the value of that option; similarly for kanjiVariant. In this way, users of Japanese TeX can select different fonts to be included in the final output.

Map
Points to a map file, which describes a mapping from a font (called in the TeX document) to the pfb file containing the Postscript code.
Usage: Map filename.map

The syntax of map files is the same as dvips(1) uses, see the section “psfonts.map” in the manual of dvips(1).

MixedMap
Similar to Map. It should be used when there is Type1 and a bitmap implementation of the font (the latter mostly coming from MetaFont). These entries will not be used in the default map of dvips if dvipsPreferOutline is set to false.
Usage: MixedMap filename.map

KanjiMap
Similar to Map. This should be used for kanji fonts.
Usage: KanjiMap filename.map

The sign # precedes a comment.

Map files not to be used should be commented out using the string #! at the beginning of the line. Such entries can be (de-)activated using updmap with the options –enable and –disable, respectively.

AUTHOR

This manual page was written by Hilmar Preusse <[email protected]> and extended by Norbert Preining <[email protected]>, for the Debian GNU/Linux system by simply copying the comments from updmap.cfg and rewriting some of them. It may be used by other distributions without contacting the author. Any mistakes or omissions in the manual page are our fault; inquiries about or corrections to this manual page should be directed to [email protected].

THANKS TO

Frank Kuester, Thomas Esser.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

128 - Linux cli command deb-triggers

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command deb-triggers and provides detailed information about the command deb-triggers, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the deb-triggers.

NAME 🖥️ deb-triggers 🖥️

triggers - package triggers

SYNOPSIS

debian/triggers, debian/binary-package.triggers, DEBIAN/triggers

DESCRIPTION

A package declares its relationship to some trigger(s) by including a triggers file in its control archive (i.e. DEBIAN/triggers during package creation).

This file contains directives, one per line. Leading and trailing whitespace and everything after the first # on any line will be trimmed, and empty lines will be ignored.

The trigger control directives currently supported are:

interest trigger-name

interest-await trigger-name

interest-noawait trigger-name

Specifies that the package is interested in the named trigger. All triggers in which a package is interested must be listed using this directive in the triggers control file. The “await” variants put the triggering package in triggers-awaited state depending on how the trigger was activated. The “noawait” variant does not put the triggering packages in triggers-awaited state, even if the triggering package declared an “await” activation (either with an activate-await or activate directive, or by using the dpkg-trigger –no-await command-line option). The “noawait” variant should be used when the functionality provided by the trigger is not crucial.

activate trigger-name

activate-await trigger-name

activate-noawait trigger-name

Arranges that changes to this package’s state will activate the specified trigger. The trigger will be activated at the start of the following operations: unpack, configure, remove (including for the benefit of a conflicting package), purge and deconfigure. The “await” variants only put the triggering package in triggers-awaited state if the interest directive is also “await”. The “noawait” variant never puts the triggering packages in triggers-awaited state. The “noawait” variant should be used when the functionality provided by the trigger is not crucial. If this package disappears during the unpacking of another package the trigger will be activated when the disappearance is noted towards the end of the unpack. Trigger processing, and transition from triggers-awaited to installed, does not cause activations. In the case of unpack, triggers mentioned in both the old and new versions of the package will be activated.

Unknown directives are an error which will prevent installation of the package.

The “-noawait” variants should always be favored when possible since triggering packages are not put in triggers-awaited state and can thus be immediately configured without requiring the processing of the trigger. If the triggering packages are dependencies of other upgraded packages, it will avoid an early trigger processing run and make it possible to run the trigger only once as one of the last steps of the upgrade.

The “-noawait” variants are supported since dpkg 1.16.1, and will lead to errors if used with an older dpkg.

The “-await” alias variants are supported since dpkg 1.17.21, and will lead to errors if used with an older dpkg.

When a package provides an interest-noawait directive, any activation will set the triggering package into “noawait” mode, regardless of the awaiting mode requested by the activation (either “await” or “noawait”). When a package provides an interest or interest-await directive, any activation will set the triggering package into “await” or “noawait“ depending on how it was activated.

129 - Linux cli command proc_buddyinfo

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_buddyinfo and provides detailed information about the command proc_buddyinfo, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_buddyinfo.

NAME 🖥️ proc_buddyinfo 🖥️

memory fragmentation

DESCRIPTION

/proc/buddyinfo
This file contains information which is used for diagnosing memory fragmentation issues. Each line starts with the identification of the node and the name of the zone which together identify a memory region. This is then followed by the count of available chunks of a certain order in which these zones are split. The size in bytes of a certain order is given by the formula:

(2^order) * PAGE_SIZE

The binary buddy allocator algorithm inside the kernel will split one chunk into two chunks of a smaller order (thus with half the size) or combine two contiguous chunks into one larger chunk of a higher order (thus with double the size) to satisfy allocation requests and to counter memory fragmentation. The order matches the column number, when starting to count at zero.

For example on an x86-64 system:

Node 0, zone     DMA     1    1    1    0    2    1    1    0    1    1    3
Node 0, zone   DMA32    65   47    4   81   52   28   13   10    5    1  404
Node 0, zone  Normal   216   55  189  101   84   38   37   27    5    3  587

In this example, there is one node containing three zones and there are 11 different chunk sizes. If the page size is 4 kilobytes, then the first zone called DMA (on x86 the first 16 megabyte of memory) has 1 chunk of 4 kilobytes (order 0) available and has 3 chunks of 4 megabytes (order 10) available.

If the memory is heavily fragmented, the counters for higher order chunks will be zero and allocation of large contiguous areas will fail.

Further information about the zones can be found in /proc/zoneinfo.

130 - Linux cli command proc_pid_limits

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_limits and provides detailed information about the command proc_pid_limits, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_limits.

NAME 🖥️ proc_pid_limits 🖥️

resource limits

DESCRIPTION

/proc/pid/limits (since Linux 2.6.24)
This file displays the soft limit, hard limit, and units of measurement for each of the process’s resource limits (see getrlimit(2)). Up to and including Linux 2.6.35, this file is protected to allow reading only by the real UID of the process. Since Linux 2.6.36, this file is readable by all users on the system.

131 - Linux cli command mosquitto.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command mosquitto.conf and provides detailed information about the command mosquitto.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the mosquitto.conf.

NAME 🖥️ mosquitto.conf 🖥️

the configuration file for mosquitto

SYNOPSIS

mosquitto.conf

DESCRIPTION

mosquitto.conf is the configuration file for mosquitto. This file can reside anywhere as long as mosquitto can read it. By default, mosquitto does not need a configuration file and will use the default values listed below. See mosquitto(8) for information on how to load a configuration file.

Mosquitto can be instructed to reload the configuration file by sending a SIGHUP signal as described in the Signals section of mosquitto(8). Not all configuration options can be reloaded, as detailed in the options below.

FILE FORMAT

All lines with a # as the very first character are treated as a comment.

Configuration lines start with a variable name. The variable value is separated from the name by a single space.

AUTHENTICATION

The authentication options described below allow a wide range of possibilities in conjunction with the listener options. This section aims to clarify the possibilities. An overview is also available at https://mosquitto.org/documentation/authentication-methods/

The simplest option is to have no authentication at all. This is the default if no other options are given. Unauthenticated encrypted support is provided by using the certificate based SSL/TLS based options certfile and keyfile.

MQTT provides username/password authentication as part of the protocol. Use the password_file option to define the valid usernames and passwords. Be sure to use network encryption if you are using this option otherwise the username and password will be vulnerable to interception. Use the per_listener_settings to control whether passwords are required globally or on a per-listener basis.

Mosquitto provides the Dynamic Security plugin which handles username/password authentication and access control in a much more flexible way than a password file. See https://mosquitto.org/documentation/dynamic-security/

When using certificate based encryption there are three options that affect authentication. The first is require_certificate, which may be set to true or false. If false, the SSL/TLS component of the client will verify the server but there is no requirement for the client to provide anything for the server: authentication is limited to the MQTT built in username/password. If require_certificate is true, the client must provide a valid certificate in order to connect successfully. In this case, the second and third options, use_identity_as_username and use_subject_as_username, become relevant. If set to true, use_identity_as_username causes the Common Name (CN) from the client certificate to be used instead of the MQTT username for access control purposes. The password is not used because it is assumed that only authenticated clients have valid certificates. This means that any CA certificates you include in cafile or capath will be able to issue client certificates that are valid for connecting to your broker. If use_identity_as_username is false, the client must authenticate as normal (if required by password_file) through the MQTT options. The same principle applies for the use_subject_as_username option, but the entire certificate subject is used as the username instead of just the CN.

When using pre-shared-key based encryption through the psk_hint and psk_file options, the client must provide a valid identity and key in order to connect to the broker before any MQTT communication takes place. If use_identity_as_username is true, the PSK identity is used instead of the MQTT username for access control purposes. If use_identity_as_username is false, the client may still authenticate using the MQTT username/password if using the password_file option.

Both certificate and PSK based encryption are configured on a per-listener basis.

Authentication plugins can be created to augment the password_file, acl_file and psk_file options with e.g. SQL based lookups.

It is possible to support multiple authentication schemes at once. A config could be created that had a listener for all of the different encryption options described above and hence a large number of ways of authenticating.

GENERAL OPTIONS

acl_file file path

Set the path to an access control list file. If defined, the contents of the file are used to control client access to topics on the broker.
If this parameter is defined then only the topics listed will have access. Topic access is added with lines of the format:
topic [read|write|readwrite|deny] <topic>
The access type is controlled using “read”, “write”, “readwrite” or “deny”. This parameter is optional (unless <topic> includes a space character) - if not given then the access is read/write. <topic> can contain the + or # wildcards as in subscriptions. The “deny” option can used to explicitly deny access to a topic that would otherwise be granted by a broader read/write/readwrite statement. Any “deny” topics are handled before topics that grant read/write access.
The first set of topics are applied to anonymous clients, assuming allow_anonymous is true. User specific topic ACLs are added after a user line as follows:
user <username>
The username referred to here is the same as in password_file. It is not the clientid.
It is also possible to define ACLs based on pattern substitution within the topic. The form is the same as for the topic keyword, but using pattern as the keyword.
pattern [read|write|readwrite|deny] <topic>
The patterns available for substition are:
·
%c to match the client id of the client
·
%u to match the username of the client
The substitution pattern must be the only text for that level of hierarchy. Pattern ACLs apply to all users even if the “user” keyword has previously been given.
Example:
pattern write sensor/%u/data
Allow access for bridge connection messages:
pattern write $SYS/broker/connection/%c/state
If the first character of a line of the ACL file is a # it is treated as a comment.
If per_listener_settings is true, this option applies to the current listener being configured only. If per_listener_settings is false, this option applies to all listeners.
Reloaded on reload signal. The currently loaded ACLs will be freed and reloaded. Existing subscriptions will be affected after the reload.
See also https://mosquitto.org/documentation/dynamic-security/

allow_anonymous [ true | false ]

Boolean value that determines whether clients that connect without providing a username are allowed to connect. If set to false then another means of connection should be created to control authenticated client access.
Defaults to false, unless no listeners are defined in the configuration file, in which case it set to true, but connections are only allowed from the local machine.
If per_listener_settings is true, this option applies to the current listener being configured only. If per_listener_settings is false, this option applies to all listeners.
Important
In version 1.6.x and earlier, this option defaulted to true unless there was another security option set.
Reloaded on reload signal.

allow_duplicate_messages [ true | false ]

This option is deprecated and will be removed in a future version. The behaviour will default to true.
If a client is subscribed to multiple subscriptions that overlap, e.g. foo/# and foo/+/baz , then MQTT expects that when the broker receives a message on a topic that matches both subscriptions, such as foo/bar/baz, then the client should only receive the message once.
Mosquitto keeps track of which clients a message has been sent to in order to meet this requirement. This option allows this behaviour to be disabled, which may be useful if you have a large number of clients subscribed to the same set of topics and want to minimise memory usage.
It can be safely set to true if you know in advance that your clients will never have overlapping subscriptions, otherwise your clients must be able to correctly deal with duplicate messages even when then have QoS=2.
Defaults to true.
This option applies globally.
Reloaded on reload signal.

allow_zero_length_clientid [ true | false ]

MQTT 3.1.1 and MQTT 5 allow clients to connect with a zero length client id and have the broker generate a client id for them. Use this option to allow/disallow this behaviour. Defaults to true.
See also the auto_id_prefix option.
If per_listener_settings is true, this option applies to the current listener being configured only. If per_listener_settings is false, this option applies to all listeners.
Reloaded on reload signal.

auth_plugin_deny_special_chars [ true | false ]

If true then before an ACL check is made, the username/client id of the client needing the check is searched for the presence of either a + or # character. If either of these characters is found in either the username or client id, then the ACL check is denied before it is sent to the plugin.
This check prevents the case where a malicious user could circumvent an ACL check by using one of these characters as their username or client id. This is the same issue as was reported with mosquitto itself as CVE-2017-7650.
If you are entirely sure that the plugin you are using is not vulnerable to this attack (i.e. if you never use usernames or client ids in topics) then you can disable this extra check and hence have all ACL checks delivered to your plugin by setting this option to false.
Defaults to true.
Applies to the current authentication plugin being configured.
Not currently reloaded on reload signal.

auto_id_prefix prefix

If allow_zero_length_clientid is true, this option allows you to set a string that will be prefixed to the automatically generated client ids to aid visibility in logs. Defaults to auto-.
If per_listener_settings is true, this option applies to the current listener being configured only. If per_listener_settings is false, this option applies to all listeners.
Reloaded on reload signal.

autosave_interval seconds

The number of seconds that mosquitto will wait between each time it saves the in-memory database to disk. If set to 0, the in-memory database will only be saved when mosquitto exits or when receiving the SIGUSR1 signal. Note that this setting only has an effect if persistence is enabled. Defaults to 1800 seconds (30 minutes).
This option applies globally.
Reloaded on reload signal.

autosave_on_changes [ true | false ]

If true, mosquitto will count the number of subscription changes, retained messages received and queued messages and if the total exceeds autosave_interval then the in-memory database will be saved to disk. If false, mosquitto will save the in-memory database to disk by treating autosave_interval as a time in seconds.
This option applies globally.
Reloaded on reload signal.

check_retain_source [ true | false ]

This option affects the scenario when a client subscribes to a topic that has retained messages. It is possible that the client that published the retained message to the topic had access at the time they published, but that access has been subsequently removed. If check_retain_source is set to true, the default, the source of a retained message will be checked for access rights before it is republished. When set to false, no check will be made and the retained message will always be published.
This option applies globally, regardless of the per_listener_settings option.

clientid_prefixes prefix

This option is deprecated and will be removed in a future version.
If defined, only clients that have a clientid with a prefix that matches clientid_prefixes will be allowed to connect to the broker. For example, setting “secure-” here would mean a client “secure-client” could connect but another with clientid “mqtt” couldnt. By default, all client ids are valid.
This option applies globally.
Reloaded on reload signal. Note that currently connected clients will be unaffected by any changes.

connection_messages [ true | false ]

If set to true, the log will include entries when clients connect and disconnect. If set to false, these entries will not appear.
This option applies globally.
Reloaded on reload signal.

include_dir dir

External configuration files may be included by using the include_dir option. This defines a directory that will be searched for config files. All files that end in .conf will be loaded as a configuration file. It is best to have this as the last option in the main file. This option will only be processed from the main configuration file. The directory specified must not contain the main configuration file.
The configuration files in include_dir are loaded in case sensitive alphabetical order, with the upper case of each letter ordered before the lower case of the same letter.
Example Load Order for include_dir. Given the files b.conf, A.conf, 01.conf, a.conf, B.conf, and 00.conf inside include_dir, the config files would be loaded in this order:
00.conf 01.conf A.conf a.conf B.conf b.conf
If this option is used multiple times, then each include_dir option is processed completely in the order that they are written in the main configuration file.
Example Load Order for Multiple include_dir. Assuming a directory one.d containing files B.conf and C.conf, and a second directory two.d containing files A.conf and D.conf, and a config:
include_dir one.d include_dir two.d
Then the config files would be loaded in this order:
files from one.d
B.conf
C.conf
# files from two.d
A.conf
D.conf

log_dest destinations

Send log messages to a particular destination. Possible destinations are: stdout stderr syslog topic file dlt.
stdout and stderr log to the console on the named output.
syslog uses the userspace syslog facility which usually ends up in /var/log/messages or similar.
topic logs to the broker topic $SYS/broker/log/<severity>, where severity is one of E, W, N, I, M which are error, warning, notice, information and message. Message type severity is used by the subscribe and unsubscribe log_type options and publishes log messages at $SYS/broker/log/M/subscribe and $SYS/broker/log/M/unsubscribe. Debug messages are never logged on topics.
The file destination requires an additional parameter which is the file to be logged to, e.g. “log_dest file /var/log/mosquitto.log”. The file will be closed and reopened when the broker receives a HUP signal. Only a single file destination may be configured.
The dlt destination is for the automotive `Diagnostic Log and Trace` tool. This requires that Mosquitto has been compiled with DLT support.
Use “log_dest none” if you wish to disable logging. Defaults to stderr. This option may be specified multiple times.
Note that if the broker is running as a Windows service it will default to “log_dest none” and neither stdout nor stderr logging is available.
Reloaded on reload signal.

log_facility local facility

If using syslog logging (not on Windows), messages will be logged to the “daemon” facility by default. Use the log_facility option to choose which of local0 to local7 to log to instead. The option value should be an integer value, e.g. “log_facility 5” to use local5.

log_timestamp [ true | false ]

Boolean value, if set to true a timestamp value will be added to each log entry. The default is true.
Reloaded on reload signal.

log_timestamp_format format

Set the format of the log timestamp. If left unset, this is the number of seconds since the Unix epoch. This option is a free text string which will be passed to the strftime function as the format specifier. To get an ISO 8601 datetime, for example:
log_timestamp_format %Y-%m-%dT%H:%M:%S
Reloaded on reload signal.

log_type types

Choose types of messages to log. Possible types are: debug, error, warning, notice, information, subscribe, unsubscribe, websockets, none, all.
Defaults to error, warning, notice and information. This option may be specified multiple times. Note that the debug type (used for decoding incoming/outgoing network packets) is never logged in topics.
Reloaded on reload signal.

max_inflight_bytes count

Outgoing QoS 1 and 2 messages will be allowed in flight until this byte limit is reached. This allows control of outgoing message rate based on message size rather than message count. If the limit is set to 100, messages of over 100 bytes are still allowed, but only a single message can be in flight at once. Defaults to 0. (No limit).
See also the max_inflight_messages option.
This option applies globally.
Reloaded on reload signal.

max_inflight_messages count

The maximum number of outgoing QoS 1 or 2 messages that can be in the process of being transmitted simultaneously. This includes messages currently going through handshakes and messages that are being retried. Defaults to 20. Set to 0 for no maximum. If set to 1, this will guarantee in-order delivery of messages.
This option applies globally.
Reloaded on reload signal.

max_keepalive value

For MQTT v5 clients, it is possible to have the server send a “server keepalive” value that will override the keepalive value set by the client. This is intended to be used as a mechanism to say that the server will disconnect the client earlier than it anticipated, and that the client should use the new keepalive value. The max_keepalive option allows you to specify that clients may only connect with keepalive less than or equal to this value, otherwise they will be sent a server keepalive telling them to use max_keepalive. This only applies to MQTT v5 clients. The maximum value allowable, and default value, is 65535.
Set to 0 to allow clients to set keepalive = 0, which means no keepalive checks are made and the client will never be disconnected by the broker if no messages are received. You should be very sure this is the behaviour that you want.
For MQTT v3.1.1 and v3.1 clients, there is no mechanism to tell the client what keepalive value they should use. If an MQTT v3.1.1 or v3.1 client specifies a keepalive time greater than max_keepalive they will be sent a CONNACK message with the “identifier rejected” reason code, and disconnected.
This option applies globally.
Reloaded on reload signal.

max_packet_size value

For MQTT v5 clients, it is possible to have the server send a “maximum packet size” value that will instruct the client it will not accept MQTT packets with size greater than value bytes. This applies to the full MQTT packet, not just the payload. Setting this option to a positive value will set the maximum packet size to that number of bytes. If a client sends a packet which is larger than this value, it will be disconnected. This applies to all clients regardless of the protocol version they are using, but v3.1.1 and earlier clients will of course not have received the maximum packet size information. Defaults to no limit.
This option applies to all clients, not just those using MQTT v5, but it is not possible to notify clients using MQTT v3.1.1 or MQTT v3.1 of the limit.
Setting below 20 bytes is forbidden because it is likely to interfere with normal client operation even with small payloads.
This option applies globally.
Reloaded on reload signal.

max_queued_bytes count

The number of outgoing QoS 1 and 2 messages above those currently in-flight will be queued (per client) by the broker. Once this limit has been reached, subsequent messages will be silently dropped. This is an important option if you are sending messages at a high rate and/or have clients who are slow to respond or may be offline for extended periods of time. Defaults to 0. (No maximum).
See also the max_queued_messages option. If both max_queued_messages and max_queued_bytes are specified, packets will be queued until the first limit is reached.
This option applies globally.
Reloaded on reload signal.

max_queued_messages count

The maximum number of QoS 1 or 2 messages to hold in the queue (per client) above those messages that are currently in flight. Defaults to 1000. Set to 0 for no maximum (not recommended). See also the queue_qos0_messages and max_queued_bytes options.
This option applies globally.
Reloaded on reload signal.

memory_limit limit

This option sets the maximum number of heap memory bytes that the broker will allocate, and hence sets a hard limit on memory use by the broker. Memory requests that exceed this value will be denied. The effect will vary depending on what has been denied. If an incoming message is being processed, then the message will be dropped and the publishing client will be disconnected. If an outgoing message is being sent, then the individual message will be dropped and the receiving client will be disconnected. Defaults to no limit.
This option is only available if memory tracking support is compiled in.
Reloaded on reload signal. Setting to a lower value and reloading will not result in memory being freed.

message_size_limit limit

This option sets the maximum publish payload size that the broker will allow. Received messages that exceed this size will not be accepted by the broker. This means that the message will not be forwarded on to subscribing clients, but the QoS flow will be completed for QoS 1 or QoS 2 messages. MQTT v5 clients using QoS 1 or QoS 2 will receive a PUBACK or PUBREC with the “implementation specific error” reason code.
The default value is 0, which means that all valid MQTT messages are accepted. MQTT imposes a maximum payload size of 268435455 bytes.
This option applies globally.
Reloaded on reload signal.

password_file file path

Set the path to a password file. If defined, the contents of the file are used to control client access to the broker. The file can be created using the mosquitto_passwd(1) utility. If mosquitto is compiled without TLS support (it is recommended that TLS support is included), then the password file should be a text file with each line in the format “username:password”, where the colon and password are optional but recommended. If allow_anonymous is set to false, only users defined in this file will be able to connect. Setting allow_anonymous to true when password_fileis defined is valid and could be used with acl_file to have e.g. read only guest/anonymous accounts and defined users that can publish.
If per_listener_settings is true, this option applies to the current listener being configured only. If per_listener_settings is false, this option applies to all listeners.
Reloaded on reload signal. The currently loaded username and password data will be freed and reloaded. Clients that are already connected will not be affected.
See also mosquitto_passwd(1) and https://mosquitto.org/documentation/dynamic-security/

per_listener_settings [ true | false ]

If true, then authentication and access control settings will be controlled on a per-listener basis. The following options are affected:
password_file, acl_file, psk_file, allow_anonymous, allow_zero_length_clientid, auto_id_prefix. plugin, plugin_opt_*, Note that if set to true, then a durable client (i.e. with clean session set to false) that has disconnected will use the ACL settings defined for the listener that it was most recently connected to.
The default behaviour is for this to be set to false, which maintains the settings behaviour from previous versions of mosquitto.
Reloaded on reload signal.

persistence [ true | false ]

If true, connection, subscription and message data will be written to the disk in mosquitto.db at the location dictated by persistence_location. When mosquitto is restarted, it will reload the information stored in mosquitto.db. The data will be written to disk when mosquitto closes and also at periodic intervals as defined by autosave_interval. Writing of the persistence database may also be forced by sending mosquitto the SIGUSR1 signal. If false, the data will be stored in memory only. Defaults to false.
The persistence file may change its format in a new version. The broker can currently read all old formats, but will only save in the latest format. It should always be safe to upgrade, but cautious users may wish to take a copy of the persistence file before installing a new version so that they can roll back to an earlier version if necessary.
This option applies globally.
Reloaded on reload signal.

persistence_file file name

The filename to use for the persistent database. Defaults to mosquitto.db.
This option applies globally.
Reloaded on reload signal.

persistence_location path

The path where the persistence database should be stored. If not given, then the current directory is used.
This option applies globally.
Reloaded on reload signal.

persistent_client_expiration duration

This option allows the session of persistent clients (those with clean session set to false) that are not currently connected to be removed if they do not reconnect within a certain time frame. This is a non-standard option in MQTT v3.1. MQTT v3.1.1 and v5.0 allow brokers to remove client sessions.
Badly designed clients may set clean session to false whilst using a randomly generated client id. This leads to persistent clients that connect once and never reconnect. This option allows these clients to be removed. This option allows persistent clients (those with clean session set to false) to be removed if they do not reconnect within a certain time frame.
The expiration period should be an integer followed by one of h d w m y for hour, day, week, month and year respectively. For example:
·
persistent_client_expiration 2m
·
persistent_client_expiration 14d
·
persistent_client_expiration 1y
As this is a non-standard option, the default if not set is to never expire persistent clients.
This option applies globally.
Reloaded on reload signal.

pid_file file path

Write a pid file to the file specified. If not given (the default), no pid file will be written. If the pid file cannot be written, mosquitto will exit.
If mosquitto is being automatically started by an init script it will usually be required to write a pid file. This should then be configured as e.g. /var/run/mosquitto/mosquitto.pid
Not reloaded on reload signal.

plugin_opt_* value

Options to be passed to the most recent plugin defined in the configuration file. See the specific plugin instructions for details of what options are available.
Applies to the current plugin being configured.
This is also available as the auth_opt_* option, but this use is deprecated and will be removed in a future version.

plugin file path

Specify an external module to use for authentication and access control. This allows custom username/password and access control functions to be created.
Can be specified multiple times to load multiple plugins. The plugins will be processed in the order that they are specified.
If password_file, or acl_file are used in the config file alongsize plugin, the plugin checks will run after the built in checks.
Not currently reloaded on reload signal.
See also https://mosquitto.org/documentation/dynamic-security/
This is also available as the auth_plugin option, but this use is deprecated and will be removed in a future version.

psk_file file path

Set the path to a pre-shared-key file. This option requires a listener to be have PSK support enabled. If defined, the contents of the file are used to control client access to the broker. Each line should be in the format “identity:key”, where the key is a hexadecimal string with no leading “0x”. A client connecting to a listener that has PSK support enabled must provide a matching identity and PSK to allow the encrypted connection to proceed.
If per_listener_settings is true, this option applies to the current listener being configured only. If per_listener_settings is false, this option applies to all listeners.
Reloaded on reload signal. The currently loaded identity and key data will be freed and reloaded. Clients that are already connected will not be affected.

queue_qos0_messages [ true | false ]

Set to true to queue messages with QoS 0 when a persistent client is disconnected. When bridges topics are configured with QoS level 1 or 2 incoming QoS 0 messages for these topics are also queued. These messages are included in the limit imposed by max_queued_messages. Defaults to false.
Note that the MQTT v3.1.1 spec states that only QoS 1 and 2 messages should be saved in this situation so this is a non-standard option.
This option applies globally.
Reloaded on reload signal.

retain_available [ true | false ]

If set to false, then retained messages are not supported. Clients that send a message with the retain bit will be disconnected if this option is set to false. Defaults to true.
This option applies globally.
Reloaded on reload signal.

set_tcp_nodelay [ true | false ]

If set to true, the TCP_NODELAY option will be set on client sockets to disable Nagles algorithm. This has the effect of reducing latency of some messages at potentially increasing the number of TCP packets being sent. Defaults to false.
This option applies globally.
Reloaded on reload signal.

sys_interval seconds

The integer number of seconds between updates of the $SYS subscription hierarchy, which provides status information about the broker. If unset, defaults to 10 seconds.
Set to 0 to disable publishing the $SYS hierarchy completely.
This option applies globally.
Reloaded on reload signal.

upgrade_outgoing_qos [ true | false ]

The MQTT specification requires that the QoS of a message delivered to a subscriber is never upgraded to match the QoS of the subscription. Enabling this option changes this behaviour. If upgrade_outgoing_qos is set true, messages sent to a subscriber will always match the QoS of its subscription. This is a non-standard option not provided for by the spec. Defaults to false.
This option applies globally.
Reloaded on reload signal.

user username

When run as root, change to this user and its primary group on startup. If set to “mosquitto” or left unset, and if the “mosquitto” user does not exist, then mosquitto will change to the “nobody” user instead. If this is set to another value and mosquitto is unable to change to this user and group, it will exit with an error. The user specified must have read/write access to the persistence database if it is to be written. If run as a non-root user, this setting has no effect. Defaults to mosquitto.
This setting has no effect on Windows and so you should run mosquitto as the user you wish it to run as.
Not reloaded on reload signal.

LISTENERS

The network ports that mosquitto listens on can be controlled using listeners. The default listener options can be overridden and further listeners can be created.

General Options

bind_address address

This option is deprecated and will be removed in a future version. Use the listener instead.
Listen for incoming network connections on the specified IP address/hostname only. This is useful to restrict access to certain network interfaces. To restrict access to mosquitto to the local host only, use “bind_address localhost”. This only applies to the default listener. Use the listener option to control other listeners.
It is recommended to use an explicit listener rather than rely on the implicit default listener options like this.
Not reloaded on reload signal.

bind_interface device

Listen for incoming network connections only on the specified interface. This is similar to the bind_address option but is useful when an interface has multiple addresses or the address may change.
If used at the same time as the bind_address for the default listener, or the bind address/host part of the listener, then bind_interface will take priority.
This option is not available on Windows.
Not reloaded on reload signal.

http_dir directory

When a listener is using the websockets protocol, it is possible to serve http data as well. Set http_dir to a directory which contains the files you wish to serve. If this option is not specified, then no normal http connections will be possible.
Not reloaded on reload signal.

listener port [bind address/host/unix socket path]

Listen for incoming network connection on the specified port. A second optional argument allows the listener to be bound to a specific ip address/hostname. If this variable is used and neither the global bind_address nor port options are used then the default listener will not be started.
The bind address/host option allows this listener to be bound to a specific IP address by passing an IP address or hostname. For websockets listeners, it is only possible to pass an IP address here.
On systems that support Unix Domain Sockets, this option can also be used to create a Unix socket rather than opening a TCP socket. In this case, the port must be set to 0, and the unix socket path must be given.
This option may be specified multiple times. See also the mount_point option.
Not reloaded on reload signal.

max_connections count

Limit the total number of clients connected for the current listener. Set to -1 to have “unlimited” connections. Note that other limits may be imposed that are outside the control of mosquitto. See e.g. limits.conf().
Not reloaded on reload signal.

max_qos value

Limit the QoS value allowed for clients connecting to this listener. Defaults to 2, which means any QoS can be used. Set to 0 or 1 to limit to those QoS values. This makes use of an MQTT v5 feature to notify clients of the limitation. MQTT v3.1.1 clients will not be aware of the limitation. Clients publishing to this listener with a too-high QoS will be disconnected.
Not reloaded on reload signal.

max_topic_alias number

This option sets the maximum number topic aliases that an MQTT v5 client is allowed to create. This option applies per listener. Defaults to 10. Set to 0 to disallow topic aliases. The maximum value possible is 65535.
Not reloaded on reload signal.

mount_point topic prefix

This option is used with the listener option to isolate groups of clients. When a client connects to a listener which uses this option, the string argument is attached to the start of all topics for this client. This prefix is removed when any messages are sent to the client. This means a client connected to a listener with mount point example can only see messages that are published in the topic hierarchy example and below.
Not reloaded on reload signal.

port port number

This option is deprecated and will be removed in a future version. Use the listener instead.
Set the network port for the default listener to listen on. Defaults to 1883.
Not reloaded on reload signal.
It is recommended to use an explicit listener rather than rely on the implicit default listener options like this.

protocol value

Set the protocol to accept for the current listener. Can be mqtt, the default, or websockets if available.
Websockets support is currently disabled by default at compile time. Certificate based TLS may be used with websockets, except that only the cafile, certfile, keyfile, ciphers, and ciphers_tls1.3 options are supported.
Not reloaded on reload signal.

socket_domain [ ipv4 | ipv6 ]

By default, a listener will attempt to listen on all supported IP protocol versions. If you do not have an IPv4 or IPv6 interface you may wish to disable support for either of those protocol versions. In particular, note that due to the limitations of the websockets library, it will only ever attempt to open IPv6 sockets if IPv6 support is compiled in, and so will fail if IPv6 is not available.
Set to ipv4 to force the listener to only use IPv4, or set to ipv6 to force the listener to only use IPv6. If you want support for both IPv4 and IPv6, then do not use the socket_domain option.
Not reloaded on reload signal.

use_username_as_clientid [ true | false ]

Set use_username_as_clientid to true to replace the clientid that a client connected with its username. This allows authentication to be tied to the clientid, which means that it is possible to prevent one client disconnecting another by using the same clientid. Defaults to false.
If a client connects with no username it will be disconnected as not authorised when this option is set to true. Do not use in conjunction with clientid_prefixes.
This does not apply globally, but on a per-listener basis.
See also use_identity_as_username.
Not reloaded on reload signal.

websockets_log_level level

Change the websockets logging level. This is a global option, it is not possible to set per listener. This is an integer that is interpreted by libwebsockets as a bit mask for its lws_log_levels enum. See the libwebsockets documentation for more details.
To use this option, log_type websockets must also be enabled. Defaults to 0.

websockets_headers_size size

Change the websockets headers size. This is a global option, it is not possible to set per listener. This option sets the size of the buffer used in the libwebsockets library when reading HTTP headers. If you are passing large header data such as cookies then you may need to increase this value. If left unset, or set to 0, then the default of 1024 bytes will be used.

Certificate based SSL/TLS Support

The following options are available for all listeners to configure certificate based SSL support. See also “Pre-shared-key based SSL/TLS support”.

cafile file path

cafile is used to define the path to a file containing the PEM encoded CA certificates that are trusted when checking incoming client certificates.

capath directory path

capath is used to define a directory that contains PEM encoded CA certificates that are trusted when checking incoming client certificates. For capath to work correctly, the certificates files must have “.pem” as the file ending and you must run “openssl rehash <path to capath>” each time you add/remove a certificate.

certfile file path

Path to the PEM encoded server certificate. This option and keyfile must be present to enable certificate based TLS encryption.
The certificate pointed to by this option will be reloaded when Mosquitto receives a SIGHUP signal. This can be used to load new certificates prior to the existing ones expiring.

ciphers cipher:list

The list of allowed ciphers for this listener, for TLS v1.2 and earlier only, each separated with a colon. Available ciphers can be obtained using the “openssl ciphers” command.

ciphers_tls1.3 cipher:list

The list of allowed ciphersuites for this listener, for TLS v1.3, each separated with a colon.

crlfile file path

If you have require_certificate set to true, you can create a certificate revocation list file to revoke access to particular client certificates. If you have done this, use crlfile to point to the PEM encoded revocation file.

dhparamfile file path

To allow the use of ephemeral DH key exchange, which provides forward security, the listener must load DH parameters. This can be specified with the dhparamfile option. The dhparamfile can be generated with the command e.g.
openssl dhparam -out dhparam.pem 2048

keyfile file path

If tls_keyform equals “pem” this is the path to the PEM encoded server key. This option and certfile must be present to enable certificate based TLS encryption. If tls_keyform is “engine” this represents the engine handle of the private key.
The private key pointed to by this option will be reloaded when Mosquitto receives a SIGHUP signal. This can be used to load new keys prior to the existing ones expiring.

require_certificate [ true | false ]

By default an SSL/TLS enabled listener will operate in a similar fashion to a https enabled web server, in that the server has a certificate signed by a CA and the client will verify that it is a trusted certificate. The overall aim is encryption of the network traffic. By setting require_certificate to true, a client connecting to this listener must provide a valid certificate in order for the network connection to proceed. This allows access to the broker to be controlled outside of the mechanisms provided by MQTT.

tls_engine engine

A valid openssl engine id. These can be listed with openssl engine command.

tls_engine_kpass_sha1 engine_kpass_sha1

SHA1 of the private key password when using an TLS engine. Some TLS engines such as the TPM engine may require the use of a password in order to be accessed. This option allows a hex encoded SHA1 hash of the password to the engine directly, instead of the user being prompted for the password.

tls_keyform [ pem | engine ]

Specifies the type of private key in use when making TLS connections.. This can be “pem” or “engine”. This parameter is useful when a TPM module is being used and the private key has been created with it. Defaults to “pem”, which means normal private key files are used.

tls_version version

Configure the minimum version of the TLS protocol to be used for this listener. Possible values are tlsv1.3, tlsv1.2 and tlsv1.1. If left unset, the default allows TLS v1.3 and v1.2.
In Mosquitto version 1.6.x and earlier, this option set the only TLS protocol version that was allowed, rather than the minimum.

use_identity_as_username [ true | false ]

If require_certificate is true, you may set use_identity_as_username to true to use the CN value from the client certificate as a username. If this is true, the password_file option will not be used for this listener.
This takes priority over use_subject_as_username if both are set to true.
See also use_subject_as_username

use_subject_as_username [ true | false ]

If require_certificate is true, you may set use_subject_as_username to true to use the complete subject value from the client certificate as a username. If this is true, the password_file option will not be used for this listener.
The subject will be generated in a form similar to CN=test client,OU=Production,O=Server,L=Nottingham,ST=Nottinghamshire,C=GB.
See also use_identity_as_username

Pre-shared-key based SSL/TLS Support

The following options are available for all listeners to configure pre-shared-key based SSL support. See also “Certificate based SSL/TLS support”.

ciphers cipher:list

When using PSK, the encryption ciphers used will be chosen from the list of available PSK ciphers. If you want to control which ciphers are available, use this option. The list of available ciphers can be optained using the “openssl ciphers” command and should be provided in the same format as the output of that command.

psk_hint hint

The psk_hint option enables pre-shared-key support for this listener and also acts as an identifier for this listener. The hint is sent to clients and may be used locally to aid authentication. The hint is a free form string that doesnt have much meaning in itself, so feel free to be creative.
If this option is provided, see psk_file to define the pre-shared keys to be used or create a security plugin to handle them.

tls_version version

Configure the minimum version of the TLS protocol to be used for this listener. Possible values are tlsv1.3, tlsv1.2 and tlsv1.1. If left unset, the default of allowing TLS v1.3 and v1.2.
In Mosquitto version 1.6.x and earlier, this option set the only TLS protocol version that was allowed, rather than the minimum.

use_identity_as_username [ true | false ]

Set use_identity_as_username to have the psk identity sent by the client used as its username. The username will be checked as normal, so password_file or another means of authentication checking must be used. No password will be used.

CONFIGURING BRIDGES

Multiple bridges (connections to other brokers) can be configured using the following variables.

Bridges cannot currently be reloaded on reload signal.

address address[:port] [address[:port]], addresses address[:port] [address[:port]]

Specify the address and optionally the port of the bridge to connect to. This must be given for each bridge connection. If the port is not specified, the default of 1883 is used.
If you use an IPv6 address, then the port is not optional.
Multiple host addresses can be specified on the address config. See the round_robin option for more details on the behaviour of bridges with multiple addresses.

bridge_attempt_unsubscribe [ true | false ]

If a bridge has topics that have “out” direction, the default behaviour is to send an unsubscribe request to the remote broker on that topic. This means that changing a topic direction from “in” to “out” will not keep receiving incoming messages. Sending these unsubscribe requests is not always desirable, setting bridge_attempt_unsubscribe to false will disable sending the unsubscribe request. Defaults to true.

bridge_bind_address ip address

If you need to have the bridge connect over a particular network interface, use bridge_bind_address to tell the bridge which local IP address the socket should bind to, e.g. bridge_bind_address 192.168.1.10.

bridge_max_packet_size value

If you wish to restrict the size of messages sent to a remote bridge, use this option. This sets the maximum number of bytes for the total message, including headers and payload. Note that MQTT v5 brokers may provide their own maximum-packet-size property. In this case, the smaller of the two limits will be used. Set to 0 for “unlimited”.

bridge_outgoing_retain [ true | false ]

Some MQTT brokers do not allow retained messages. MQTT v5 gives a mechanism for brokers to tell clients that they do not support retained messages, but this is not possible for MQTT v3.1.1 or v3.1. If you need to bridge to a v3.1.1 or v3.1 broker that does not support retained messages, set the bridge_outgoing_retain option to false. This will remove the retain bit on all outgoing messages to that bridge, regardless of any other setting. Defaults to true.

bridge_protocol_version version

Set the version of the MQTT protocol to use with for this bridge. Can be one of mqttv50, mqttv311 or mqttv31. Defaults to mqttv311.

cleansession [ true | false ]

Set the clean session option for this bridge. Setting to false (the default), means that all subscriptions on the remote broker are kept in case of the network connection dropping. If set to true, all subscriptions and messages on the remote broker will be cleaned up if the connection drops. Note that setting to true may cause a large amount of retained messages to be sent each time the bridge reconnects.
If you are using bridges with cleansession set to false (the default), then you may get unexpected behaviour from incoming topics if you change what topics you are subscribing to. This is because the remote broker keeps the subscription for the old topic. If you have this problem, connect your bridge with cleansession set to true, then reconnect with cleansession set to false as normal.

local_cleansession [ true | false]

The regular cleansession covers both the local subscriptions and the remote subscriptions. local_cleansession allows splitting this. Setting false will mean that the local connection will preserve subscription, independent of the remote connection.
Defaults to the value of bridge.cleansession unless explicitly specified.

connection name

This variable marks the start of a new bridge connection. It is also used to give the bridge a name which is used as the client id on the remote broker.

keepalive_interval seconds

Set the number of seconds after which the bridge should send a ping if no other traffic has occurred. Defaults to 60. A minimum value of 5 seconds is allowed.

idle_timeout seconds

Set the amount of time a bridge using the lazy start type must be idle before it will be stopped. Defaults to 60 seconds.

local_clientid id

Set the clientid to use on the local broker. If not defined, this defaults to local.<remote_clientid>. If you are bridging a broker to itself, it is important that local_clientid and remote_clientid do not match.

local_password password

Configure the password to be used when connecting this bridge to the local broker. This may be important when authentication and ACLs are being used.

local_username username

Configure the username to be used when connecting this bridge to the local broker. This may be important when authentication and ACLs are being used.

notifications [ true | false ]

If set to true, publish notification messages to the local and remote brokers giving information about the state of the bridge connection. Retained messages are published to the topic $SYS/broker/connection/<remote_clientid>/state unless otherwise set with notification_topics. If the message is 1 then the connection is active, or 0 if the connection has failed. Defaults to true.
This uses the Last Will and Testament (LWT) feature.

notifications_local_only [ true | false ]

If set to true, only publish notification messages to the local broker giving information about the state of the bridge connection. Defaults to false.

notification_topic topic

Choose the topic on which notifications will be published for this bridge. If not set the messages will be sent on the topic $SYS/broker/connection/<remote_clientid>/state.

remote_clientid id

Set the client id for this bridge connection. If not defined, this defaults to name.hostname, where name is the connection name and hostname is the hostname of this computer.
This replaces the old “clientid” option to avoid confusion with local/remote sides of the bridge. “clientid” remains valid for the time being.

remote_password value

Configure a password for the bridge. This is used for authentication purposes when connecting to a broker that supports MQTT v3.1 and up and requires a username and/or password to connect. This option is only valid if a remote_username is also supplied.
This replaces the old “password” option to avoid confusion with local/remote sides of the bridge. “password” remains valid for the time being.

remote_username name

Configure a username for the bridge. This is used for authentication purposes when connecting to a broker that supports MQTT v3.1 and up and requires a username and/or password to connect. See also the remote_password option.
This replaces the old “username” option to avoid confusion with local/remote sides of the bridge. “username” remains valid for the time being.

restart_timeout base cap, restart_timeout constant

Set the amount of time a bridge using the automatic start type will wait until attempting to reconnect.
This option can be configured to use a constant delay time in seconds, or to use a backoff mechanism based on “Decorrelated Jitter”, which adds a degree of randomness to when the restart occurs, starting at the base and increasing up to the cap. Set a constant timeout of 20 seconds:
restart_timeout 20
Set backoff with a base (start value) of 10 seconds and a cap (upper limit) of 60 seconds:
restart_timeout 10 30
Defaults to jitter with a base of 5 seconds and cap of 30 seconds.

round_robin [ true | false ]

If the bridge has more than one address given in the address/addresses configuration, the round_robin option defines the behaviour of the bridge on a failure of the bridge connection. If round_robin is false, the default value, then the first address is treated as the main bridge connection. If the connection fails, the other secondary addresses will be attempted in turn. Whilst connected to a secondary bridge, the bridge will periodically attempt to reconnect to the main bridge until successful.
If round_robin is true, then all addresses are treated as equals. If a connection fails, the next address will be tried and if successful will remain connected until it fails.

start_type [ automatic | lazy | once ]

Set the start type of the bridge. This controls how the bridge starts and can be one of three types: automatic, lazy and once. Note that RSMB provides a fourth start type “manual” which isnt currently supported by mosquitto.
automatic is the default start type and means that the bridge connection will be started automatically when the broker starts and also restarted after a short delay (30 seconds) if the connection fails.
Bridges using the lazy start type will be started automatically when the number of queued messages exceeds the number set with the threshold option. It will be stopped automatically after the time set by the idle_timeout parameter. Use this start type if you wish the connection to only be active when it is needed.
A bridge using the once start type will be started automatically when the broker starts but will not be restarted if the connection fails.

threshold count

Set the number of messages that need to be queued for a bridge with lazy start type to be restarted. Defaults to 10 messages.

topic pattern [[[ out | in | both ] qos-level] local-prefix remote-prefix]

Define a topic pattern to be shared between the two brokers. Any topics matching the pattern (which may include wildcards) are shared. The second parameter defines the direction that the messages will be shared in, so it is possible to import messages from a remote broker using in, export messages to a remote broker using out or share messages in both directions. If this parameter is not defined, the default of out is used. The QoS level defines the publish/subscribe QoS level used for this topic and defaults to 0.
The local-prefix and remote-prefix options allow topics to be remapped when publishing to and receiving from remote brokers. This allows a topic tree from the local broker to be inserted into the topic tree of the remote broker at an appropriate place.
For incoming topics, the bridge will prepend the pattern with the remote prefix and subscribe to the resulting topic on the remote broker. When a matching incoming message is received, the remote prefix will be removed from the topic and then the local prefix added.
For outgoing topics, the bridge will prepend the pattern with the local prefix and subscribe to the resulting topic on the local broker. When an outgoing message is processed, the local prefix will be removed from the topic then the remote prefix added.
When using topic mapping, an empty prefix can be defined using the place marker "". Using the empty marker for the topic itself is also valid. The table below defines what combination of empty or value is valid. The Full Local Topic and Full Remote Topic show the resulting topics that would be used on the local and remote ends of the bridge. For example, for the first table row if you publish to L/topic on the local broker, then the remote broker will receive a message on the topic R/topic.
Pattern Local Prefix Remote Prefix Validity Full Local Topic Full Remote Topic
pattern L/ R/ valid L/pattern R/pattern
pattern L/ "" valid L/pattern pattern
pattern "" R/ valid pattern R/pattern
pattern "" "" valid (no remapping) pattern pattern
"" local remote valid (remap single local topic to remote) local remote
"" local "" invalid
"" "" remote invalid
"" "" "" invalid
To remap an entire topic tree, use e.g.:
topic # both 2 local/topic/ remote/topic/
This option can be specified multiple times per bridge.
Care must be taken to ensure that loops are not created with this option. If you are experiencing high CPU load from a broker, it is possible that you have a loop where each broker is forever forwarding each other the same messages.
See also the cleansession option if you have messages arriving on unexpected topics when using incoming topics.
Example Bridge Topic Remapping. The configuration below connects a bridge to the broker at test.mosquitto.org. It subscribes to the remote topic $SYS/broker/clients/total and republishes the messages received to the local topic test/mosquitto/org/clients/total
connection test-mosquitto-org address test.mosquitto.org cleansession true topic clients/total in 0 test/mosquitto/org/ $SYS/broker/

try_private [ true | false ]

If try_private is set to true, the bridge will attempt to indicate to the remote broker that it is a bridge not an ordinary client. If successful, this means that loop detection will be more effective and that retained messages will be propagated correctly. Not all brokers support this feature so it may be necessary to set try_private to false if your bridge does not connect properly.
Defaults to true.

SSL/TLS Support

The following options are available for all bridges to configure SSL/TLS support.

bridge_alpn alpn

Configure the application layer protocol negotiation option for the TLS session. Useful for brokers that support both websockets and MQTT on the same port.

bridge_cafile file path

One of bridge_cafile or bridge_capath must be provided to allow SSL/TLS support.
bridge_cafile is used to define the path to a file containing the PEM encoded CA certificates that have signed the certificate for the remote broker.

bridge_capath file path

One of bridge_capath or bridge_cafile must be provided to allow SSL/TLS support.
bridge_capath is used to define the path to a directory containing the PEM encoded CA certificates that have signed the certificate for the remote broker. For bridge_capath to work correctly, the certificate files must have “.crt” as the file ending and you must run “openssl rehash <path to bridge_capath>” each time you add/remove a certificate.

bridge_certfile file path

Path to the PEM encoded client certificate for this bridge, if required by the remote broker.

bridge_identity identity

Pre-shared-key encryption provides an alternative to certificate based encryption. A bridge can be configured to use PSK with the bridge_identity and bridge_psk options. This is the client identity used with PSK encryption. Only one of certificate and PSK based encryption can be used on one bridge at once.

bridge_insecure [ true | false ]

When using certificate based TLS, the bridge will attempt to verify the hostname provided in the remote certificate matches the host/address being connected to. This may cause problems in testing scenarios, so bridge_insecure may be set to true to disable the hostname verification.
Setting this option to true means that a malicious third party could potentially impersonate your server, so it should always be set to false in production environments.

bridge_keyfile file path

Path to the PEM encoded private key for this bridge, if required by the remote broker.

bridge_psk key

Pre-shared-key encryption provides an alternative to certificate based encryption. A bridge can be configured to use PSK with the bridge_identity and bridge_psk options. This is the pre-shared-key in hexadecimal format with no “0x”. Only one of certificate and PSK based encryption can be used on one bridge at once.

bridge_require_ocsp [ true | false ]

When set to true, the bridge requires OCSP on the TLS connection it opens as client.

bridge_tls_version version

Configure the version of the TLS protocol to be used for this bridge. Possible values are tlsv1.3, tlsv1.2 and tlsv1.1. Defaults to tlsv1.2. The remote broker must support the same version of TLS for the connection to succeed.

FILES

mosquitto.conf

BUGS

mosquitto bug information can be found at https://github.com/eclipse/mosquitto/issues

AUTHOR

Roger Light <[email protected]>

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

132 - Linux cli command proc_pid_personality

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_personality and provides detailed information about the command proc_pid_personality, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_personality.

NAME 🖥️ proc_pid_personality 🖥️

execution domain

DESCRIPTION

/proc/pid/personality (since Linux 2.6.28)
This read-only file exposes the process’s execution domain, as set by personality(2). The value is displayed in hexadecimal notation.

Permission to access this file is governed by a ptrace access mode PTRACE_MODE_ATTACH_FSCREDS check; see ptrace(2).

133 - Linux cli command udev.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command udev.conf and provides detailed information about the command udev.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the udev.conf.

NAME 🖥️ udev.conf 🖥️

Configuration for device event managing daemon

SYNOPSIS

/etc/udev/udev.conf

/run/udev/udev.conf

/usr/local/lib/udev/udev.conf

/usr/lib/udev/udev.conf

/etc/udev/udev.conf.d/*.conf

/run/udev/udev.conf.d/*.conf

/usr/local/lib/udev/udev.conf.d/*.conf

/usr/lib/udev/udev.conf.d/*.conf

DESCRIPTION

These files contain configuration options for systemd-udevd(8). The syntax of these files is very simple: a list of assignments, one per line. All empty lines or lines beginning with “#” are ignored.

The following options can be set:

udev_log=

The log level. Valid values are the numerical syslog priorities or their textual representations: err, info and debug.
Note
This option is also honored by udevadm(8).
Added in version 216.

children_max=

An integer. The maximum number of events executed in parallel. When unspecified or 0 is specified, the maximum is determined based on the system resources.
This is the same as the –children-max= option.
Added in version 240.

exec_delay=

An integer. Delay the execution of each RUN{program} parameter by the given number of seconds. This option might be useful when debugging system crashes during coldplug caused by loading non-working kernel modules.
This is the same as the –exec-delay= option.
Added in version 240.

event_timeout=

An integer. The number of seconds to wait for events to finish. After this time, the event will be terminated. The default is 180 seconds.
This is the same as the –event-timeout= option.
Added in version 240.

resolve_names=

Specifies when systemd-udevd should resolve names of users and groups. When set to early (the default), names will be resolved when the rules are parsed. When set to late, names will be resolved for every event. When set to never, names will never be resolved and all devices will be owned by root.
This is the same as the –resolve-names= option.
Added in version 240.

timeout_signal=

Specifies a signal that systemd-udevd will send on worker timeouts. Note that both workers and spawned processes will be killed using this signal. Defaults to SIGKILL.
Added in version 246.

In addition, systemd-udevd can be configured by command line options and the kernel command line (see systemd-udevd(8)).

134 - Linux cli command wtmp

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command wtmp and provides detailed information about the command wtmp, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the wtmp.

NAME 🖥️ wtmp 🖥️

SYNOPSIS

#include <utmp.h>

DESCRIPTION

The utmp file allows one to discover information about who is currently using the system. There may be more users currently using the system, because not all programs use utmp logging.

The file is a sequence of utmp structures, declared as follows in <utmp.h> (note that this is only one of several definitions around; details depend on the version of libc):

/* Values for ut_type field, below */
#define EMPTY         0 /* Record does not contain valid info
                           (formerly known as UT_UNKNOWN on Linux) */
#define RUN_LVL       1 /* Change in system run-level (see
                           init(1)) */
#define BOOT_TIME     2 /* Time of system boot (in ut_tv) */
#define NEW_TIME      3 /* Time after system clock change
                           (in ut_tv) */
#define OLD_TIME      4 /* Time before system clock change
                           (in ut_tv) */
#define INIT_PROCESS  5 /* Process spawned by init(1) */
#define LOGIN_PROCESS 6 /* Session leader process for user login */
#define USER_PROCESS  7 /* Normal process */
#define DEAD_PROCESS  8 /* Terminated process */
#define ACCOUNTING    9 /* Not implemented */
#define UT_LINESIZE      32
#define UT_NAMESIZE      32
#define UT_HOSTSIZE     256
struct exit_status {              /* Type for ut_exit, below */
    short e_termination;          /* Process termination status */
    short e_exit;                 /* Process exit status */
};
struct utmp {
    short   ut_type;              /* Type of record */
    pid_t   ut_pid;               /* PID of login process */
    char    ut_line[UT_LINESIZE]; /* Device name of tty - "/dev/" */
    char    ut_id[4];             /* Terminal name suffix,
                                     or inittab(5) ID */
    char    ut_user[UT_NAMESIZE]; /* Username */
    char    ut_host[UT_HOSTSIZE]; /* Hostname for remote login, or
                                     kernel version for run-level
                                     messages */
    struct  exit_status ut_exit;  /* Exit status of a process
                                     marked as DEAD_PROCESS; not
                                     used by Linux init(1) */
    /* The ut_session and ut_tv fields must be the same size when
       compiled 32- and 64-bit.  This allows data files and shared
       memory to be shared between 32- and 64-bit applications. */
#if __WORDSIZE == 64 && defined __WORDSIZE_COMPAT32
    int32_t ut_session;           /* Session ID (getsid(2)),
                                     used for windowing */
    struct {
        int32_t tv_sec;           /* Seconds */
        int32_t tv_usec;          /* Microseconds */
    } ut_tv;                      /* Time entry was made */
#else
     long   ut_session;           /* Session ID */
     struct timeval ut_tv;        /* Time entry was made */
#endif
    int32_t ut_addr_v6[4];        /* Internet address of remote
                                     host; IPv4 address uses
                                     just ut_addr_v6[0] */
    char __unused[20];            /* Reserved for future use */
};
/* Backward compatibility hacks */
#define ut_name ut_user
#ifndef _NO_UT_TIME
#define ut_time ut_tv.tv_sec
#endif
#define ut_xtime ut_tv.tv_sec
#define ut_addr ut_addr_v6[0]

When init(1) finds that a process has exited, it locates its utmp entry by ut_pid, sets ut_type to DEAD_PROCESS, and clears ut_user, ut_host, and ut_time with null bytes.

telnetd(8) sets up a LOGIN_PROCESS entry and leaves the rest to login(1) as usual. After the telnet session ends, telnetd(8) cleans up utmp in the described way.

FILES

/var/run/utmp
/var/log/wtmp

VERSIONS

Linux defines the utmpx structure to be the same as the utmp structure.

STANDARDS

Linux.

HISTORY

Linux utmp entries conform neither to v7/BSD nor to System V; they are a mix of the two.

System V has no ut_host or ut_addr_v6 fields.

NOTES

Unlike various other systems, where utmp logging can be disabled by removing the file, utmp must always exist on Linux. If you want to disable who(1), then do not make utmp world readable.

The file format is machine-dependent, so it is recommended that it be processed only on the machine architecture where it was created.

gettimeofday((struct timeval *) &ut.ut_tv, NULL);

the following method of setting this field is recommended:

struct utmp ut;
struct timeval tv;
gettimeofday(&tv, NULL);
ut.ut_tv.tv_sec = tv.tv_sec;
ut.ut_tv.tv_usec = tv.tv_usec;

135 - Linux cli command proc_ksyms

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_ksyms and provides detailed information about the command proc_ksyms, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_ksyms.

NAME 🖥️ proc_ksyms 🖥️

kernel exported symbols

DESCRIPTION

HISTORY

/proc/ksyms (Linux 1.1.23–2.5.47)
See /proc/kallsyms.

136 - Linux cli command proc_sys_fs

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_sys_fs and provides detailed information about the command proc_sys_fs, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_sys_fs.

NAME 🖥️ proc_sys_fs 🖥️

kernel variables related to filesystems

DESCRIPTION

/proc/sys/fs/
This directory contains the files and subdirectories for kernel variables related to filesystems.

/proc/sys/fs/aio-max-nr and /proc/sys/fs/aio-nr (since Linux 2.6.4)
aio-nr is the running total of the number of events specified by io_setup(2) calls for all currently active AIO contexts. If aio-nr reaches aio-max-nr, then io_setup(2) will fail with the error EAGAIN. Raising aio-max-nr does not result in the preallocation or resizing of any kernel data structures.

/proc/sys/fs/binfmt_misc
Documentation for files in this directory can be found in the Linux kernel source in the file Documentation/admin-guide/binfmt-misc.rst (or in Documentation/binfmt_misc.txt on older kernels).

/proc/sys/fs/dentry-state (since Linux 2.2)
This file contains information about the status of the directory cache (dcache). The file contains six numbers, nr_dentry, nr_unused, age_limit (age in seconds), want_pages (pages requested by system) and two dummy values.

nr_dentry is the number of allocated dentries (dcache entries). This field is unused in Linux 2.2.
nr_unused is the number of unused dentries.
age_limit is the age in seconds after which dcache entries can be reclaimed when memory is short.
want_pages is nonzero when the kernel has called shrink_dcache_pages() and the dcache isn’t pruned yet.

/proc/sys/fs/dir-notify-enable
This file can be used to disable or enable the dnotify interface described in fcntl(2) on a system-wide basis. A value of 0 in this file disables the interface, and a value of 1 enables it.

/proc/sys/fs/dquot-max
This file shows the maximum number of cached disk quota entries. On some (2.4) systems, it is not present. If the number of free cached disk quota entries is very low and you have some awesome number of simultaneous system users, you might want to raise the limit.

/proc/sys/fs/dquot-nr
This file shows the number of allocated disk quota entries and the number of free disk quota entries.

/proc/sys/fs/epoll/ (since Linux 2.6.28)
This directory contains the file max_user_watches, which can be used to limit the amount of kernel memory consumed by the epoll interface. For further details, see epoll(7).

/proc/sys/fs/file-max
This file defines a system-wide limit on the number of open files for all processes. System calls that fail when encountering this limit fail with the error ENFILE. (See also setrlimit(2), which can be used by a process to set the per-process limit, RLIMIT_NOFILE, on the number of files it may open.) If you get lots of error messages in the kernel log about running out of file handles (open file descriptions) (look for “VFS: file-max limit <number> reached”), try increasing this value:

echo 100000 > /proc/sys/fs/file-max

Privileged processes (CAP_SYS_ADMIN) can override the file-max limit.

/proc/sys/fs/file-nr
This (read-only) file contains three numbers: the number of allocated file handles (i.e., the number of open file descriptions; see open(2)); the number of free file handles; and the maximum number of file handles (i.e., the same value as /proc/sys/fs/file-max). If the number of allocated file handles is close to the maximum, you should consider increasing the maximum. Before Linux 2.6, the kernel allocated file handles dynamically, but it didn’t free them again. Instead the free file handles were kept in a list for reallocation; the “free file handles” value indicates the size of that list. A large number of free file handles indicates that there was a past peak in the usage of open file handles. Since Linux 2.6, the kernel does deallocate freed file handles, and the “free file handles” value is always zero.

/proc/sys/fs/inode-max (only present until Linux 2.2)
This file contains the maximum number of in-memory inodes. This value should be 3–4 times larger than the value in file-max, since stdin, stdout and network sockets also need an inode to handle them. When you regularly run out of inodes, you need to increase this value.

Starting with Linux 2.4, there is no longer a static limit on the number of inodes, and this file is removed.

/proc/sys/fs/inode-nr
This file contains the first two values from inode-state.

/proc/sys/fs/inode-state
This file contains seven numbers: nr_inodes, nr_free_inodes, preshrink, and four dummy values (always zero).

nr_inodes is the number of inodes the system has allocated. nr_free_inodes represents the number of free inodes.

preshrink is nonzero when the nr_inodes > inode-max and the system needs to prune the inode list instead of allocating more; since Linux 2.4, this field is a dummy value (always zero).

/proc/sys/fs/inotify/ (since Linux 2.6.13)
This directory contains files max_queued_events, max_user_instances, and max_user_watches, that can be used to limit the amount of kernel memory consumed by the inotify interface. For further details, see inotify(7).

/proc/sys/fs/lease-break-time
This file specifies the grace period that the kernel grants to a process holding a file lease (fcntl(2)) after it has sent a signal to that process notifying it that another process is waiting to open the file. If the lease holder does not remove or downgrade the lease within this grace period, the kernel forcibly breaks the lease.

/proc/sys/fs/leases-enable
This file can be used to enable or disable file leases (fcntl(2)) on a system-wide basis. If this file contains the value 0, leases are disabled. A nonzero value enables leases.

/proc/sys/fs/mount-max (since Linux 4.9)
The value in this file specifies the maximum number of mounts that may exist in a mount namespace. The default value in this file is 100,000.

/proc/sys/fs/mqueue/ (since Linux 2.6.6)
This directory contains files msg_max, msgsize_max, and queues_max, controlling the resources used by POSIX message queues. See mq_overview(7) for details.

/proc/sys/fs/nr_open (since Linux 2.6.25)
This file imposes a ceiling on the value to which the RLIMIT_NOFILE resource limit can be raised (see getrlimit(2)). This ceiling is enforced for both unprivileged and privileged process. The default value in this file is 1048576. (Before Linux 2.6.25, the ceiling for RLIMIT_NOFILE was hard-coded to the same value.)

/proc/sys/fs/overflowgid and /proc/sys/fs/overflowuid
These files allow you to change the value of the fixed UID and GID. The default is 65534. Some filesystems support only 16-bit UIDs and GIDs, although in Linux UIDs and GIDs are 32 bits. When one of these filesystems is mounted with writes enabled, any UID or GID that would exceed 65535 is translated to the overflow value before being written to disk.

/proc/sys/fs/pipe-max-size (since Linux 2.6.35)
See pipe(7).

/proc/sys/fs/pipe-user-pages-hard (since Linux 4.5)
See pipe(7).

/proc/sys/fs/pipe-user-pages-soft (since Linux 4.5)
See pipe(7).

/proc/sys/fs/protected_fifos (since Linux 4.19)
The value in this file is/can be set to one of the following:

0
Writing to FIFOs is unrestricted.

1
Don’t allow O_CREAT open(2) on FIFOs that the caller doesn’t own in world-writable sticky directories, unless the FIFO is owned by the owner of the directory.

2
As for the value 1, but the restriction also applies to group-writable sticky directories.

The intent of the above protections is to avoid unintentional writes to an attacker-controlled FIFO when a program expected to create a regular file.

/proc/sys/fs/protected_hardlinks (since Linux 3.6)
When the value in this file is 0, no restrictions are placed on the creation of hard links (i.e., this is the historical behavior before Linux 3.6). When the value in this file is 1, a hard link can be created to a target file only if one of the following conditions is true:

The calling process has the CAP_FOWNER capability in its user namespace and the file UID has a mapping in the namespace.
The filesystem UID of the process creating the link matches the owner (UID) of the target file (as described in credentials(7), a process’s filesystem UID is normally the same as its effective UID).
All of the following conditions are true:
- the target is a regular file;
- the target file does not have its set-user-ID mode bit enabled;
- the target file does not have both its set-group-ID and group-executable mode bits enabled; and
- the caller has permission to read and write the target file (either via the file’s permissions mask or because it has suitable capabilities).

The default value in this file is 0. Setting the value to 1 prevents a longstanding class of security issues caused by hard-link-based time-of-check, time-of-use races, most commonly seen in world-writable directories such as /tmp. The common method of exploiting this flaw is to cross privilege boundaries when following a given hard link (i.e., a root process follows a hard link created by another user). Additionally, on systems without separated partitions, this stops unauthorized users from “pinning” vulnerable set-user-ID and set-group-ID files against being upgraded by the administrator, or linking to special files.

/proc/sys/fs/protected_regular (since Linux 4.19)
The value in this file is/can be set to one of the following:

0
Writing to regular files is unrestricted.

1
Don’t allow O_CREAT open(2) on regular files that the caller doesn’t own in world-writable sticky directories, unless the regular file is owned by the owner of the directory.

2
As for the value 1, but the restriction also applies to group-writable sticky directories.

The intent of the above protections is similar to protected_fifos, but allows an application to avoid writes to an attacker-controlled regular file, where the application expected to create one.

/proc/sys/fs/protected_symlinks (since Linux 3.6)
When the value in this file is 0, no restrictions are placed on following symbolic links (i.e., this is the historical behavior before Linux 3.6). When the value in this file is 1, symbolic links are followed only in the following circumstances:

the filesystem UID of the process following the link matches the owner (UID) of the symbolic link (as described in credentials(7), a process’s filesystem UID is normally the same as its effective UID);
the link is not in a sticky world-writable directory; or
the symbolic link and its parent directory have the same owner (UID)

A system call that fails to follow a symbolic link because of the above restrictions returns the error EACCES in errno.

The default value in this file is 0. Setting the value to 1 avoids a longstanding class of security issues based on time-of-check, time-of-use races when accessing symbolic links.

/proc/sys/fs/suid_dumpable (since Linux 2.6.13)
The value in this file is assigned to a process’s “dumpable” flag in the circumstances described in prctl(2). In effect, the value in this file determines whether core dump files are produced for set-user-ID or otherwise protected/tainted binaries. The “dumpable” setting also affects the ownership of files in a process’s */proc/*pid directory, as described above.

Three different integer values can be specified:

0 (default)
This provides the traditional (pre-Linux 2.6.13) behavior. A core dump will not be produced for a process which has changed credentials (by calling seteuid(2), setgid(2), or similar, or by executing a set-user-ID or set-group-ID program) or whose binary does not have read permission enabled.

1 (“debug”)
All processes dump core when possible. (Reasons why a process might nevertheless not dump core are described in core(5).) The core dump is owned by the filesystem user ID of the dumping process and no security is applied. This is intended for system debugging situations only: this mode is insecure because it allows unprivileged users to examine the memory contents of privileged processes.

2 (“suidsafe”)
Any binary which normally would not be dumped (see “0” above) is dumped readable by root only. This allows the user to remove the core dump file but not to read it. For security reasons core dumps in this mode will not overwrite one another or other files. This mode is appropriate when administrators are attempting to debug problems in a normal environment.

Additionally, since Linux 3.6, /proc/sys/kernel/core_pattern must either be an absolute pathname or a pipe command, as detailed in core(5). Warnings will be written to the kernel log if core_pattern does not follow these rules, and no core dump will be produced.

For details of the effect of a process’s “dumpable” setting on ptrace access mode checking, see ptrace(2).

/proc/sys/fs/super-max
This file controls the maximum number of superblocks, and thus the maximum number of mounted filesystems the kernel can have. You need increase only super-max if you need to mount more filesystems than the current value in super-max allows you to.

/proc/sys/fs/super-nr
This file contains the number of filesystems currently mounted.

137 - Linux cli command proc_sys_net

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_sys_net and provides detailed information about the command proc_sys_net, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_sys_net.

NAME 🖥️ proc_sys_net 🖥️

networking

DESCRIPTION

/proc/sys/net/
This directory contains networking stuff. Explanations for some of the files under this directory can be found in tcp(7) and ip(7).

/proc/sys/net/core/bpf_jit_enable
See bpf(2).

/proc/sys/net/core/somaxconn
This file defines a ceiling value for the backlog argument of listen(2); see the listen(2) manual page for details.

138 - Linux cli command org.bluez.obex.Synchronization

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.obex.Synchronization and provides detailed information about the command org.bluez.obex.Synchronization, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.obex.Synchronization.

NAME 🖥️ org.bluez.obex.Synchronization 🖥️

BlueZ D-Bus OBEX Synchronization API documentation

INTERFACE

Service
org.bluez.obex
Interface
org.bluez.obex.Synchronization1
Object path
[Session object path]

Methods

void SetLocation(string location)

Sets the phonebook object store location for other operations. Should be called before all the other operations.
Possible location:
“int” ( “internal” which is default )
Store in the interval memory.
“sim{#}”
Store in sim card number #.
Possible errors:
org.bluez.obex.Error.InvalidArguments

object, dict GetPhonebook(string targetfile)

Retrieves an entire Phonebook Object store from remote device, and stores it in a local file.
If an empty target file is given, a name will be automatically calculated for the temporary file.
The returned path represents the newly created transfer, which should be used to find out if the content has been successfully transferred or if the operation fails.
The properties of this transfer are also returned along with the object path, to avoid a call to GetProperties, see org.bluez.obex.Transfer(5) for the possible list of properties.
Possible errors:
org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Error.Failed

object, dict PutPhonebook(string sourcefile)

Sends an entire Phonebook Object store to remote device.
The returned path represents the newly created transfer, which should be used to find out if the content has been successfully transferred or if the operation fails.
The properties of this transfer are also returned along with the object path, to avoid a call to GetProperties, see org.bluez.obex.Transfer(5) for the possible list of properties.
Possible errors:
org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Error.Failed

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

139 - Linux cli command proc_pid_auxv

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_auxv and provides detailed information about the command proc_pid_auxv, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_auxv.

NAME 🖥️ proc_pid_auxv 🖥️

exec(3) information

DESCRIPTION

/proc/pid/auxv (since Linux 2.6.0)
This contains the contents of the ELF interpreter information passed to the process at exec time. The format is one unsigned long ID plus one unsigned long value for each entry. The last entry contains two zeros. See also getauxval(3).

Permission to access this file is governed by a ptrace access mode PTRACE_MODE_READ_FSCREDS check; see ptrace(2).

140 - Linux cli command proc_pid_timerslack_ns

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_timerslack_ns and provides detailed information about the command proc_pid_timerslack_ns, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_timerslack_ns.

NAME 🖥️ proc_pid_timerslack_ns 🖥️

timer slack in nanoseconds

DESCRIPTION

/proc/pid/timerslack_ns (since Linux 4.6)
This file exposes the process’s “current” timer slack value, expressed in nanoseconds. The file is writable, allowing the process’s timer slack value to be changed. Writing 0 to this file resets the “current” timer slack to the “default” timer slack value. For further details, see the discussion of PR_SET_TIMERSLACK in prctl(2).

Initially, permission to access this file was governed by a ptrace access mode PTRACE_MODE_ATTACH_FSCREDS check (see ptrace(2)). However, this was subsequently deemed too strict a requirement (and had the side effect that requiring a process to have the CAP_SYS_PTRACE capability would also allow it to view and change any process’s memory). Therefore, since Linux 4.9, only the (weaker) CAP_SYS_NICE capability is required to access this file.

141 - Linux cli command repertoiremap

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command repertoiremap and provides detailed information about the command repertoiremap, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the repertoiremap.

NAME 🖥️ repertoiremap 🖥️

map symbolic character names to Unicode code points

DESCRIPTION

A repertoire map defines mappings between symbolic character names (mnemonics) and Unicode code points when compiling a locale with localedef(1). Using a repertoire map is optional, it is needed only when symbolic names are used instead of now preferred Unicode code points.

Syntax

The repertoiremap file starts with a header that may consist of the following keywords:

comment_char
is followed by a character that will be used as the comment character for the rest of the file. It defaults to the number sign (#).

escape_char
is followed by a character that should be used as the escape character for the rest of the file to mark characters that should be interpreted in a special way. It defaults to the backslash (.

The mapping section starts with the keyword CHARIDS in the first column.

The mapping lines have the following form:

<symbolic-name> <code-point> comment
This defines exactly one mapping, comment being optional.

The mapping section ends with the string END CHARIDS.

FILES

/usr/share/i18n/repertoiremaps
Usual default repertoire map path.

STANDARDS

POSIX.2.

NOTES

Repertoire maps are deprecated in favor of Unicode code points.

EXAMPLES

A mnemonic for the Euro sign can be defined as follows:

<Eu> <U20AC> EURO SIGN

142 - Linux cli command update-initramfs.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command update-initramfs.conf and provides detailed information about the command update-initramfs.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the update-initramfs.conf.

NAME 🖥️ update-initramfs.conf 🖥️

initramfs.conf - configuration file for update-initramfs

DESCRIPTION

The configuration file allows one to disable the update action from update-initramfs.

GENERAL VARIABLES

update_initramfs
Default is yes for running the latest initramfs-tools hooks in the newest Linux image. Setting it to all updates any known initramfs. It is possible to set it to no for remote servers or boxes where conservative manners needs to be applied. This disables the update_initramfs -u call.

backup_initramfs
If set update_initramfs keeps an .bak file of the previous initramfs. If unset the backup initramfs will not be kept.

FILES

/etc/initramfs-tools/update-initramfs.conf

AUTHOR

The initramfs-tools are written by Maximilian Attems <[email protected]>, Jeff Bailey <[email protected]> and numerous others.

143 - Linux cli command wpa_supplicant.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command wpa_supplicant.conf and provides detailed information about the command wpa_supplicant.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the wpa_supplicant.conf.

NAME 🖥️ wpa_supplicant.conf 🖥️

configuration file for wpa_supplicant

OVERVIEW

wpa_supplicant is configured using a text file that lists all accepted networks and security policies, including pre-shared keys. See the example configuration file, probably in /usr/share/doc/wpa_supplicant/, for detailed information about the configuration format and supported fields.

All file paths in this configuration file should use full (absolute, not relative to working directory) path in order to allow working directory to be changed. This can happen if wpa_supplicant is run in the background.

Changes to configuration file can be reloaded be sending SIGHUP signal to wpa_supplicant (‘killall -HUP wpa_supplicant’). Similarly, reloading can be triggered with the wpa_cli reconfigure command.

Configuration file can include one or more network blocks, e.g., one for each used SSID. wpa_supplicant will automatically select the best network based on the order of network blocks in the configuration file, network security level (WPA/WPA2 is preferred), and signal strength.

QUICK EXAMPLES

1.
WPA-Personal (PSK) as home network and WPA-Enterprise with EAP-TLS as work network.

allow frontend (e.g., wpa_cli) to be used by all users in ’netdev’ group

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
#
# home network; allow all valid ciphers
network={
	ssid="home"
	scan_ssid=1
	key_mgmt=WPA-PSK
	psk="very secret passphrase"
}
#
# work network; use EAP-TLS with WPA; allow only CCMP and TKIP ciphers
network={
	ssid="work"
	scan_ssid=1
	key_mgmt=WPA-EAP
	pairwise=CCMP TKIP
	group=CCMP TKIP
	eap=TLS
	identity="[email protected]"
	ca_cert="/etc/cert/ca.pem"
	client_cert="/etc/cert/user.pem"
	private_key="/etc/cert/user.prv"
	private_key_passwd="password"
}

2.
WPA-RADIUS/EAP-PEAP/MSCHAPv2 with RADIUS servers that use old peaplabel (e.g., Funk Odyssey and SBR, Meetinghouse Aegis, Interlink RAD-Series)

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev network={ ssid=“example” scan_ssid=1 key_mgmt=WPA-EAP eap=PEAP identity=“[email protected]” password=“foobar” ca_cert="/etc/cert/ca.pem" phase1=“peaplabel=0” phase2=“auth=MSCHAPV2” }

3.
EAP-TTLS/EAP-MD5-Challenge configuration with anonymous identity for the unencrypted use. Real identity is sent only within an encrypted TLS tunnel.

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev network={ ssid=“example” scan_ssid=1 key_mgmt=WPA-EAP eap=TTLS identity=“[email protected]” anonymous_identity=“[email protected]” password=“foobar” ca_cert="/etc/cert/ca.pem" phase2=“auth=MD5” }

4.
IEEE 802.1X (i.e., no WPA) with dynamic WEP keys (require both unicast and broadcast); use EAP-TLS for authentication

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev network={ ssid=“1x-test” scan_ssid=1 key_mgmt=IEEE8021X eap=TLS identity=“[email protected]” ca_cert="/etc/cert/ca.pem" client_cert="/etc/cert/user.pem" private_key="/etc/cert/user.prv" private_key_passwd=“password” eapol_flags=3 }

5.
Catch all example that allows more or less all configuration modes. The configuration options are used based on what security policy is used in the selected SSID. This is mostly for testing and is not recommended for normal use.

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev network={ ssid=“example” scan_ssid=1 key_mgmt=WPA-EAP WPA-PSK IEEE8021X NONE pairwise=CCMP TKIP group=CCMP TKIP WEP104 WEP40 psk=“very secret passphrase” eap=TTLS PEAP TLS identity=“[email protected]” password=“foobar” ca_cert="/etc/cert/ca.pem" client_cert="/etc/cert/user.pem" private_key="/etc/cert/user.prv" private_key_passwd=“password” phase1=“peaplabel=0” ca_cert2="/etc/cert/ca2.pem" client_cert2="/etc/cer/user.pem" private_key2="/etc/cer/user.prv" private_key2_passwd=“password” }

6.
Authentication for wired Ethernet. This can be used with wired or roboswitch interface (-Dwired or -Droboswitch on command line).

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev ap_scan=0 network={ key_mgmt=IEEE8021X eap=MD5 identity=“user” password=“password” eapol_flags=0 }

CERTIFICATES

Some EAP authentication methods require use of certificates. EAP-TLS uses both server side and client certificates whereas EAP-PEAP and EAP-TTLS only require the server side certificate. When client certificate is used, a matching private key file has to also be included in configuration. If the private key uses a passphrase, this has to be configured in wpa_supplicant.conf (“private_key_passwd”).

wpa_supplicant supports X.509 certificates in PEM and DER formats. User certificate and private key can be included in the same file.

If the user certificate and private key is received in PKCS#12/PFX format, they need to be converted to suitable PEM/DER format for wpa_supplicant. This can be done, e.g., with following commands:

convert client certificate and private key to PEM format

openssl pkcs12 -in example.pfx -out user.pem -clcerts
# convert CA certificate (if included in PFX file) to PEM format
openssl pkcs12 -in example.pfx -out ca.pem -cacerts -nokeys

144 - Linux cli command proc_pid_comm

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_comm and provides detailed information about the command proc_pid_comm, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_comm.

NAME 🖥️ proc_pid_comm 🖥️

command name

DESCRIPTION

/proc/pid/comm (since Linux 2.6.33)
This file exposes the process’s comm value—that is, the command name associated with the process. Different threads in the same process may have different comm values, accessible via /proc/pid/task/tid/comm. A thread may modify its comm value, or that of any of other thread in the same thread group (see the discussion of CLONE_THREAD in clone(2)), by writing to the file /proc/self/task/tid/comm. Strings longer than TASK_COMM_LEN (16) characters (including the terminating null byte) are silently truncated.

This file provides a superset of the prctl(2) PR_SET_NAME and PR_GET_NAME operations, and is employed by pthread_setname_np(3) when used to rename threads other than the caller. The value in this file is used for the %e specifier in /proc/sys/kernel/core_pattern; see core(5).

145 - Linux cli command gitrepository-layout

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitrepository-layout and provides detailed information about the command gitrepository-layout, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitrepository-layout.

NAME 🖥️ gitrepository-layout 🖥️

layout - Git Repository Layout

SYNOPSIS

$GIT_DIR/*

DESCRIPTION

A Git repository comes in two different flavours:

·
a .git directory at the root of the working tree;

·
a <project>.git directory that is a bare repository (i.e. without its own working tree), that is typically used for exchanging histories with others by pushing into it and fetching from it.

Note: Also you can have a plain text file .git at the root of your working tree, containing gitdir: <path> to point at the real directory that has the repository. This mechanism is often used for a working tree of a submodule checkout, to allow you in the containing superproject to git checkout a branch that does not have the submodule. The checkout has to remove the entire submodule working tree, without losing the submodule repository.

These things may exist in a Git repository.

objects

Object store associated with this repository. Usually an object store is self sufficient (i.e. all the objects that are referred to by an object found in it are also found in it), but there are a few ways to violate it.
1.
You could have an incomplete but locally usable repository by creating a shallow clone. See git-clone(1).
2.
You could be using the objects/info/alternates or $GIT_ALTERNATE_OBJECT_DIRECTORIES mechanisms to borrow objects from other object stores. A repository with this kind of incomplete object store is not suitable to be published for use with dumb transports but otherwise is OK as long as objects/info/alternates points at the object stores it borrows from.
This directory is ignored if $GIT_COMMON_DIR is set and “$GIT_COMMON_DIR/objects” will be used instead.

objects/[0-9a-f][0-9a-f]

A newly created object is stored in its own file. The objects are splayed over 256 subdirectories using the first two characters of the sha1 object name to keep the number of directory entries in objects itself to a manageable number. Objects found here are often called unpacked (or loose) objects.

objects/pack

Packs (files that store many objects in compressed form, along with index files to allow them to be randomly accessed) are found in this directory.

objects/info

Additional information about the object store is recorded in this directory.

objects/info/packs

This file is to help dumb transports discover what packs are available in this object store. Whenever a pack is added or removed, git update-server-info should be run to keep this file up to date if the repository is published for dumb transports. git repack does this by default.

objects/info/alternates

This file records paths to alternate object stores that this object store borrows objects from, one pathname per line. Note that not only native Git tools use it locally, but the HTTP fetcher also tries to use it remotely; this will usually work if you have relative paths (relative to the object database, not to the repository!) in your alternates file, but it will not work if you use absolute paths unless the absolute path in filesystem and web URL is the same. See also objects/info/http-alternates.

objects/info/http-alternates

This file records URLs to alternate object stores that this object store borrows objects from, to be used when the repository is fetched over HTTP.

refs

References are stored in subdirectories of this directory. The git prune command knows to preserve objects reachable from refs found in this directory and its subdirectories. This directory is ignored (except refs/bisect, refs/rewritten and refs/worktree) if $GIT_COMMON_DIR is set and “$GIT_COMMON_DIR/refs” will be used instead.

refs/heads/name

records tip-of-the-tree commit objects of branch name

refs/tags/name

records any object name (not necessarily a commit object, or a tag object that points at a commit object).

refs/remotes/name

records tip-of-the-tree commit objects of branches copied from a remote repository.

refs/replace/<obj-sha1>

records the SHA-1 of the object that replaces <obj-sha1>. This is similar to info/grafts and is internally used and maintained by git-replace(1). Such refs can be exchanged between repositories while grafts are not.

packed-refs

records the same information as refs/heads/, refs/tags/, and friends record in a more efficient way. See git-pack-refs(1). This file is ignored if $GIT_COMMON_DIR is set and “$GIT_COMMON_DIR/packed-refs” will be used instead.

HEAD

A symref (see glossary) to the refs/heads/ namespace describing the currently active branch. It does not mean much if the repository is not associated with any working tree (i.e. a bare repository), but a valid Git repository must have the HEAD file; some porcelains may use it to guess the designated “default” branch of the repository (usually master). It is legal if the named branch name does not (yet) exist. In some legacy setups, it is a symbolic link instead of a symref that points at the current branch.
HEAD can also record a specific commit directly, instead of being a symref to point at the current branch. Such a state is often called detached HEAD. See git-checkout(1) for details.

config

Repository specific configuration file. This file is ignored if $GIT_COMMON_DIR is set and “$GIT_COMMON_DIR/config” will be used instead.

config.worktree

Working directory specific configuration file for the main working directory in multiple working directory setup (see git-worktree(1)).

branches

A slightly deprecated way to store shorthands to be used to specify a URL to git fetch, git pull and git push. A file can be stored as branches/<name> and then name can be given to these commands in place of repository argument. See the REMOTES section in git-fetch(1) for details. This mechanism is legacy and not likely to be found in modern repositories. This directory is ignored if $GIT_COMMON_DIR is set and “$GIT_COMMON_DIR/branches” will be used instead.

hooks

Hooks are customization scripts used by various Git commands. A handful of sample hooks are installed when git init is run, but all of them are disabled by default. To enable, the .sample suffix has to be removed from the filename by renaming. Read githooks(5) for more details about each hook. This directory is ignored if $GIT_COMMON_DIR is set and “$GIT_COMMON_DIR/hooks” will be used instead.

common

When multiple working trees are used, most of files in $GIT_DIR are per-worktree with a few known exceptions. All files under common however will be shared between all working trees.

index

The current index file for the repository. It is usually not found in a bare repository.

sharedindex.<SHA-1>

The shared index part, to be referenced by $GIT_DIR/index and other temporary index files. Only valid in split index mode.

info

Additional information about the repository is recorded in this directory. This directory is ignored if $GIT_COMMON_DIR is set and “$GIT_COMMON_DIR/info” will be used instead.

info/refs

This file helps dumb transports discover what refs are available in this repository. If the repository is published for dumb transports, this file should be regenerated by git update-server-info every time a tag or branch is created or modified. This is normally done from the hooks/update hook, which is run by the git-receive-pack command when you git push into the repository.

info/grafts

This file records fake commit ancestry information, to pretend the set of parents a commit has is different from how the commit was actually created. One record per line describes a commit and its fake parents by listing their 40-byte hexadecimal object names separated by a space and terminated by a newline.
Note that the grafts mechanism is outdated and can lead to problems transferring objects between repositories; see git-replace(1) for a more flexible and robust system to do the same thing.

info/exclude

This file, by convention among Porcelains, stores the exclude pattern list. .gitignore is the per-directory ignore file. git status, git add, git rm and git clean look at it but the core Git commands do not look at it. See also: gitignore(5).

info/attributes

Defines which attributes to assign to a path, similar to per-directory .gitattributes files. See also: gitattributes(5).

info/sparse-checkout

This file stores sparse checkout patterns. See also: git-read-tree(1).

remotes

Stores shorthands for URL and default refnames for use when interacting with remote repositories via git fetch, git pull and git push commands. See the REMOTES section in git-fetch(1) for details. This mechanism is legacy and not likely to be found in modern repositories. This directory is ignored if $GIT_COMMON_DIR is set and “$GIT_COMMON_DIR/remotes” will be used instead.

logs

Records of changes made to refs are stored in this directory. See git-update-ref(1) for more information. This directory is ignored (except logs/HEAD) if $GIT_COMMON_DIR is set and “$GIT_COMMON_DIR/logs” will be used instead.

logs/refs/heads/name

Records all changes made to the branch tip named name.

logs/refs/tags/name

Records all changes made to the tag named name.

shallow

This is similar to info/grafts but is internally used and maintained by shallow clone mechanism. See –depth option to git-clone(1) and git-fetch(1). This file is ignored if $GIT_COMMON_DIR is set and “$GIT_COMMON_DIR/shallow” will be used instead.

commondir

If this file exists, $GIT_COMMON_DIR (see git(1)) will be set to the path specified in this file if it is not explicitly set. If the specified path is relative, it is relative to $GIT_DIR. The repository with commondir is incomplete without the repository pointed by “commondir”.

modules

Contains the git-repositories of the submodules.

worktrees

Contains administrative data for linked working trees. Each subdirectory contains the working tree-related part of a linked working tree. This directory is ignored if $GIT_COMMON_DIR is set, in which case “$GIT_COMMON_DIR/worktrees” will be used instead.

worktrees/<id>/gitdir

A text file containing the absolute path back to the .git file that points to here. This is used to check if the linked repository has been manually removed and there is no need to keep this directory any more. The mtime of this file should be updated every time the linked repository is accessed.

worktrees/<id>/locked

If this file exists, the linked working tree may be on a portable device and not available. The presence of this file prevents worktrees/<id> from being pruned either automatically or manually by git worktree prune. The file may contain a string explaining why the repository is locked.

worktrees/<id>/config.worktree

Working directory specific configuration file.

GIT REPOSITORY FORMAT VERSIONS

Every git repository is marked with a numeric version in the core.repositoryformatversion key of its config file. This version specifies the rules for operating on the on-disk repository data. An implementation of git which does not understand a particular version advertised by an on-disk repository MUST NOT operate on that repository; doing so risks not only producing wrong results, but actually losing data.

Because of this rule, version bumps should be kept to an absolute minimum. Instead, we generally prefer these strategies:

·
bumping format version numbers of individual data files (e.g., index, packfiles, etc). This restricts the incompatibilities only to those files.

·
introducing new data that gracefully degrades when used by older clients (e.g., pack bitmap files are ignored by older clients, which simply do not take advantage of the optimization they provide).

A whole-repository format version bump should only be part of a change that cannot be independently versioned. For instance, if one were to change the reachability rules for objects, or the rules for locking refs, that would require a bump of the repository format version.

Note that this applies only to accessing the repository’s disk contents directly. An older client which understands only format 0 may still connect via git:// to a repository using format 1, as long as the server process understands format 1.

The preferred strategy for rolling out a version bump (whether whole repository or for a single file) is to teach git to read the new format, and allow writing the new format with a config switch or command line option (for experimentation or for those who do not care about backwards compatibility with older gits). Then after a long period to allow the reading capability to become common, we may switch to writing the new format by default.

The currently defined format versions are:

Version 0

This is the format defined by the initial version of git, including but not limited to the format of the repository directory, the repository configuration file, and the object and ref storage. Specifying the complete behavior of git is beyond the scope of this document.

Version 1

This format is identical to version 0, with the following exceptions:

1.
When reading the core.repositoryformatversion variable, a git implementation which supports version 1 MUST also read any configuration keys found in the extensions section of the configuration file.

2.
If a version-1 repository specifies any extensions.* keys that the running git has not implemented, the operation MUST NOT proceed. Similarly, if the value of any known key is not understood by the implementation, the operation MUST NOT proceed.

Note that if no extensions are specified in the config file, then core.repositoryformatversion SHOULD be set to 0 (setting it to 1 provides no benefit, and makes the repository incompatible with older implementations of git).

This document will serve as the master list for extensions. Any implementation wishing to define a new extension should make a note of it here, in order to claim the name.

The defined extensions are:

noop

This extension does not change git’s behavior at all. It is useful only for testing format-1 compatibility.

preciousObjects

When the config key extensions.preciousObjects is set to true, objects in the repository MUST NOT be deleted (e.g., by git-prune or git repack -d).

partialClone

When the config key extensions.partialClone is set, it indicates that the repo was created with a partial clone (or later performed a partial fetch) and that the remote may have omitted sending certain unwanted objects. Such a remote is called a “promisor remote” and it promises that all such omitted objects can be fetched from it in the future.
The value of this key is the name of the promisor remote.

worktreeConfig

If set, by default “git config” reads from both “config” and “config.worktree” files from GIT_DIR in that order. In multiple working directory mode, “config” file is shared while “config.worktree” is per-working directory (i.e., it’s in GIT_COMMON_DIR/worktrees/<id>/config.worktree)

GIT

Part of the git(1) suite

NOTES

The Git User’s Manual

file:///usr/share/doc/git/html/user-manual.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

146 - Linux cli command intro

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command intro and provides detailed information about the command intro, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the intro.

NAME 🖥️ intro 🖥️

introduction to file formats and filesystems

DESCRIPTION

Section 5 of the manual describes various file formats, as well as the corresponding C structures, if any.

In addition, this section contains a number of pages that document various filesystems.

NOTES

Authors and copyright conditions

Look at the header of the manual page source for the author(s) and copyright conditions. Note that these can be different from page to page!

147 - Linux cli command etc-aliases

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command etc-aliases and provides detailed information about the command etc-aliases, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the etc-aliases.

NAME 🖥️ etc-aliases 🖥️

config_files - Files in use by the Debian exim4 packages

SYNOPSIS

DESCRIPTION

This manual page describes the files that are in use by the Debian exim4 packages and which are not part of an exim installation done from source.

/etc/aliases

You should at least set up an alias for postmaster in the /etc/aliases file.

/etc/email-addresses

is used to rewrite the email addresses of users. This is particularly useful for users who use their ISP’s domain for email.

The file should contain lines of the form

user: [email protected]
otheruser: [email protected]

/etc/exim4/local_host_blacklist

In the blacklist, the trick is to read a line break as “or” if it follows a positive item, and as “and” if it follows a negative item.

For example, a /etc/exim4/local_host_blacklist

192.168.10.0/24
!172.16.10.128/26
172.16.10.0/24
10.0.0.0/8

Exim just evaluates left to right (or up-down in the file listing context), so you don’t get the same kind of operator binding as in a programming language.

/etc/exim4/host_local_deny_exceptions

/etc/exim4/local_sender_blacklist

In the blacklist, the trick is to read a line break as “or” if it follows a positive item, and as “and” if it follows a negative item.

For example, a /etc/exim4/local_sender_blacklist

domain1.example
[email protected]
domain2.example
domain3.example

Exim just evaluates left to right (or up-down in the file listing context), so you don’t get the same kind of operator binding as in a programming language.

/etc/exim4/sender_local_deny_exceptions

/etc/exim4/local_sender_callout

/etc/exim4/local_rcpt_callout

/etc/exim4/local_domain_dnsbl_whitelist

/etc/exim4/hubbed_hosts

The file should contain key-value pairs of domain pattern and route data of the form

domain: host-list options
dict.ref.example: mail-1.ref.example:mail-2.ref.example
foo.example: internal.mail.example.com
bar.example: 192.168.183.3

which will cause mail for foo.example to be sent to the host internal.mail.example (IP address derived from A record only), and mail to bar.example to be sent to 192.168.183.3.

See spec.txt chapter 20.3 through 20.7 for a more detailed explanation of host list format and available options.

/etc/exim4/passwd

contains account and password data for SMTP authentication when the local exim is SMTP server and clients authenticate to the local exim.

The file should contain lines of the form

username:crypted-password:clear-password

clear-password is only necessary if you want to offer CRAM-MD5 authentication. If you don’t plan on doing so, the third column can be omitted completely.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim 640.

/etc/exim4/passwd.client

contains account and password data for SMTP authentication when exim is authenticating as a client to some remote server.

The file should contain lines of the form

target.mail.server.example:login-user-name:password

This goes inevitably wrong if the host name of the mail server is a CNAME (a DNS alias), or the reverse lookup does not fit the forward one.

password is your SMTP password in clear text. If you do not know about your SMTP password, you can try using your POP3 password as a first guess.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim 640.

/etc/exim4/exim.crt

/etc/exim4/exim.key

/etc/mailname

The “mail name” of the system. See Debian policy Chapter Customized programs and exim4-base’s README.Debian for further details.

BUGS

Plenty. Please report them through the Debian BTS

This manual page needs a major re-work. If somebody knows better groff than us and has more experience in writing manual pages, any patches would be greatly appreciated.

NOTES

Unresolvable items in host lists

Adding or keeping items in the abovementioned host lists which are not resolvable by DNS has severe consequences.

notresolvable.example.com:rejectme.example.com

Starting the list with the special pattern +ignore_unknown as a safeguard against this behavior is strongly recommended if hostnames are used in hostlists.

AUTHOR

Marc Haber <[email protected]> with help from Ross Boylan.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

148 - Linux cli command org.bluez.MediaFolder

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.MediaFolder and provides detailed information about the command org.bluez.MediaFolder, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.MediaFolder.

NAME 🖥️ org.bluez.MediaFolder 🖥️

BlueZ D-Bus MediaFolder API documentation

INTERFACE

Service
unique name (Target role) org.bluez (Controller role)
Interface
org.bluez.MediaFolder1
Object path
freely definable (Target role) [variable prefix]/{hci0,hci1,…}/dev_XX_XX_XX_XX_XX_XX/playerX (Controller role)

Methods

object Search(string value, dict filter)

Return a folder object containing the search result.
To list the items found use the folder object returned and pass to ChangeFolder.
Possible Errors:
org.bluez.Error.NotSupported
org.bluez.Error.Failed

array{objects, properties} ListItems(dict filter)

Return a list of items found
Possible Errors:
org.bluez.Error.InvalidArguments
org.bluez.Error.NotSupported
org.bluez.Error.Failed

void ChangeFolder(object folder)

Change current folder.
Note: By changing folder the items of previous folder might be destroyed and have to be listed again, the exception is NowPlaying folder which should be always present while the player is active.
Possible Errors:
org.bluez.Error.InvalidArguments
org.bluez.Error.NotSupported
org.bluez.Error.Failed

Properties

uint32 NumberOfItems [readonly]

Number of items in the folder

string Name [readonly]

Folder name:
Possible values:
"/Filesystem/…"
Filesystem scope
"/NowPlaying/…"
NowPlaying scope
Note: /NowPlaying folder might not be listed if player is stopped, folders created by Search are virtual so once another Search is perform or the folder is changed using ChangeFolder it will no longer be listed.

Filters

uint32 Start
Offset of the first item.
Default value: 0
uint32 End
Offset of the last item.
Default value: NumbeOfItems
array{string} Attributes
Item properties that should be included in the list.
Possible Values:
“title”, “artist”, “album”, “genre”, “number-of-tracks”, “number”, “duration”
Default Value: All

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

149 - Linux cli command crontab

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command crontab and provides detailed information about the command crontab, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the crontab.

NAME 🖥️ crontab 🖥️

tables for driving cron

DESCRIPTION

A crontab file contains instructions to the cron(8) daemon of the general form: “run this command at this time on this date”. Each user has their own crontab, and commands in any given crontab will be executed as the user who owns the crontab. Uucp and News will usually have their own crontabs, eliminating the need for explicitly running su(1) as part of a cron command.

Note that comments on the same line as cron commands are not interpreted as comments in the cron sense, but are considered part of the command and passed to the shell. This is similarly true for comments on the same line as environment variable settings.

An active line in a crontab will be either an environment setting or a cron command. An environment setting is of the form,

name = value

where the spaces around the equal-sign (=) are optional, and any subsequent non-leading spaces in value will be part of the value assigned to name. The value string may be placed in quotes (single or double, but matching) to preserve leading or trailing blanks. To define an empty variable, quotes can be used.

The value string is not parsed for environmental substitutions or replacement of variables or tilde(~) expansion, thus lines like

PATH=$HOME/bin:$PATH PATH=~/bin:/usr/bin

will not work as you might expect. And neither will this work

A=1 B=2 C=$A $B

There will not be any substitution for the defined variables in the last value. However, with most shells you can also try e.g.,:

P=PATH=/a/b/c:$PATH 33 22 1 2 3 eval $P && some commands

Several environment variables are set up automatically by the cron(8) daemon. SHELL is set to /usr/bin/sh, and LOGNAME and HOME are set from the /etc/passwd line of the crontabs owner. HOME and SHELL may be overridden by settings in the crontab; LOGNAME may not.

(Another note: the LOGNAME variable is sometimes called USER on BSD systems… on these systems, USER will be set also.)

In addition to LOGNAME, HOME, and SHELL, cron(8) will look at MAILTO if it has any reason to send mail as a result of running commands in “this” crontab. If MAILTO is defined (and non-empty), mail is sent to the user so named. If MAILTO is defined but empty (MAILTO=""), no mail will be sent. Otherwise mail is sent to the owner of the crontab. This option is useful if you decide on /usr/bin/mail instead of /usr/lib/sendmail as your mailer when you install cron – /usr/bin/mail doesnt do aliasing, and UUCP usually doesnt read its mail.

The format of a cron command is very much the V7 standard, with a number of upward-compatible extensions. Each line has five time and date fields, followed by a command, followed by a newline character ( ). The system crontab (/etc/crontab) uses the same format, except that the username for the command is specified after the time and date fields and before the command. The fields may be separated by spaces or tabs. The maximum permitted length for the command field is 998 characters.

Commands are executed by cron(8) when the minute, hour, and month of year fields match the current time, and when at least one of the two day fields (day of month, or day of week) match the current time (see “Note” below). cron(8) examines cron entries once every minute. The time and date fields are:

field	allowed values
minute	0-59
hour	0-23
day of month	0-31
month	0-12 (or names, see below)
day of week	0-7 (0 or 7 is Sun, or use names)

A field may be an asterisk (*), which always stands for “first-last”.

Ranges of numbers are allowed. Ranges are two numbers separated with a hyphen. The specified range is inclusive. For example, 8-11 for an “hours” entry specifies execution at hours 8, 9, 10 and 11.

Lists are allowed. A list is a set of numbers (or ranges) separated by commas. Examples: “1,2,5,9”, “0-4,8-12”.

Step values can be used in conjunction with ranges. Following a range with “/<number>” specifies skips of the numbers value through the range. For example, “0-23/2” can be used in the hours field to specify command execution every other hour (the alternative in the V7 standard is “0,2,4,6,8,10,12,14,16,18,20,22”). Steps are also permitted after an asterisk, so if you want to say “every two hours”, just use “*/2”.

Names can also be used for the “month” and “day of week” fields. Use the first three letters of the particular day or month (case doesnt matter). Ranges or lists of names are not allowed.

The “sixth” field (the rest of the line) specifies the command to be run. The entire command portion of the line, up to a newline or % character, will be executed by /usr/bin/sh or by the shell specified in the SHELL variable of the cronfile. Percent-signs (%) in the command, unless escaped with backslash (, will be changed into newline charac‐ ters, and all data after the first % will be sent to the command as standard input.

Note: The day of a commands execution can be specified by two fields — day of month, and day of week. If both fields are restricted (i.e., arent *), the command will be run when either field matches the current time. For example, “30 4 1,15 * 5” would cause a command to be run at 4:30 am on the 1st and 15th of each month, plus every Friday. One can, however, achieve the desired result by adding a test to the command (see the last example in EXAMPLE CRON FILE below).

Instead of the first five fields, one of eight special strings may appear:

string	meaning
@reboot	Run once, at startup.
@yearly	Run once a year, "0 0 1 1 *".
@annually	(same as @yearly)
@monthly	Run once a month, "0 0 1 * *".
@weekly	Run once a week, "0 0 * * 0".
@daily	Run once a day, "0 0 * * *".
@midnight	(same as @daily)
@hourly	Run once an hour, "0 * * * *".

Please note that startup, as far as @reboot is concerned, is the time when the cron(8) daemon startup. In particular, it may be before some system daemons, or other facilities, were startup. This is due to the boot order sequence of the machine.

EXAMPLE CRON FILE

use /usr/bin/sh to run commands, no matter what /etc/passwd says

SHELL=/usr/bin/sh
# mail any output to `paul, no matter whose crontab this is
MAILTO=paul
#
# run five minutes after midnight, every day
5 0 * * *       $HOME/bin/daily.job >> $HOME/tmp/out 2>&1
# run at 2:15pm on the first of every month -- output mailed to paul
15 14 1 * *     $HOME/bin/monthly
# run at 10 pm on weekdays, annoy Joe
0 22 * * 1-5    mail -s "Its 10pm" joe%Joe,%%Where are your kids?%
23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday"
5 4 * * sun     echo "run at 5 after 4 every Sunday"
0 */4 1 * mon   echo "run every 4th hour on the 1st and on every Monday"
0 0 */2 * sun   echo "run at midn on every Sunday thats an uneven date"
# Run on every second Saturday of the month
0 4 8-14 * *    test $(date +\%u) -eq 6 && echo "2nd Saturday"
# Same thing, efficient too:
0 4 * * * Sat   d=$(date +e) && test $d -ge 8 -a $d -le 14 && echo "2nd Saturday"
#Execute early the next morning following the first
#Thursday of each month
57 2 * * 5 case $(date +d) in 0[2-8]) echo "After 1st Thursday"; esac

All the above examples run non-interactive programs. If you wish to run a program that interacts with the users desktop you have to make sure the proper environment variable DISPLAY is set.

Execute a program and run a notification every day at 10:00 am
0 10 * * *  $HOME/bin/program | DISPLAY=:0 notify-send "Program run" "$(cat)"

EXAMPLE SYSTEM CRON FILE

The following lists the content of a regular system-wide crontab file. Unlike a users crontab, this file has the username field, as used by /etc/crontab.

/etc/crontab: system-wide crontab

# Unlike any other crontab you dont have to run the `crontab
# command to install the new version when you edit this file
# and files in /etc/cron.d.  These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# m h dom mon dow usercommand
17 * * * *  root  cd / && run-parts --report /etc/cron.hourly
25 6 * * *  root  test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7  root  test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * *  root  test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#

Note that all the system-wide tasks will run, by default, from 6 am to 7 am. In the case of systems that are not powered on during that period of time, only the hourly tasks will be executed unless the defaults above are changed.

YET ANOTHER EXAMPLE

In that example one can see that numbers can be prepended some 0, in order to line up columns.

17 * * * * root cd / && run-parts –report /etc/cron.hourly 25 16 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts –report /etc/cron.daily ) 47 06 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts –report /etc/cron.weekly ) 52 06 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts –report /etc/cron.monthly )

EXTENSIONS

When specifying day of week, both day 0 and day 7 will be considered Sunday. BSD and AT&T seem to disagree about this.

Lists and ranges are allowed to co-exist in the same field. “1-3,7-9” would be rejected by AT&T or BSD cron – they want to see “1-3” or “7,8,9” ONLY.

Ranges can include “steps”, so “1-9/2” is the same as “1,3,5,7,9”.

Names of months or days of the week can be specified by name.

Environment variables can be set in the crontab. In BSD or AT&T, the environment handed to child processes is basically the one from /etc/rc.

Command output is mailed to the crontab owner (BSD cant do this), can be mailed to a person other than the crontab owner (SysV cant do this), or the feature can be turned off and no mail will be sent at all (SysV cant do this either).

All of the “@” commands that can appear in place of the first five fields are extensions.

LIMITATIONS

The cron daemon runs with a defined timezone. It currently does not support per-user timezones. All the tasks: systems and users will be run based on the configured timezone. Even if a user specifies the TZ environment variable in his crontab this will affect only the commands executed in the crontab, not the execution of the crontab tasks them‐ selves. If one wants to specify a particular timezone for crontab tasks, one may check the date in the child script, for example:

m h dom mon dow command

TZ=UTC
0 * * * * [ "$(date +\%R)" = 00:00 ] && run_some_script

POSIX specifies that the day of month and the day of week fields both need to match the current time if either of them is a *. However, this implementation only checks if the first character is a *. This is why “0 0 */2 * sun” runs every Sunday thats an uneven date while the POSIX standard would have it run every Sunday and on every uneven date.

The crontab syntax does not make it possible to define all possible periods one can imagine. For example, it is not straightforward to define the last weekday of a month. To have a task run in a time period that cannot be defined using crontab syntax, the best approach would be to have the program itself check the date and time information and continue execution only if the period matches the desired one.

If the program itself cannot do the checks then a wrapper script would be required. Useful tools that could be used for date analysis are ncal or calendar. For example, to run a program the last Saturday of every month you could use the following wrapper code:

0 4 * * Sat [ “$(date +%e)” = “$(LANG=C ncal | sed -n s/^Sa .* ([0-9]+) *$/\1/p)” ] && echo “Last Saturday” && program_to_run

USING EVAL TO WRAP MISC ENVIRONMENT SETTINGS

The following tip is kindly provided by 積丹尼 Dan Jacobson:

CONTENT_TYPE=“text/plain; charset=UTF-8” d=eval LANG=zh_TW.UTF-8 w3m -dump 26 22 16 1-12 * $d https://www.ptt.cc/bbs/transgender/index.html

it wont work without the eval. Saying

d=LANG=zh_TW.UTF-8 w3m -dump

will get

/bin/sh: LANG=zh_TW.UTF-8: command not found

DIAGNOSTICS

cron requires that each entry in a crontab end in a newline character. If the last entry in a crontab is missing a newline (i.e. terminated by EOF), cron will consider the crontab (at least partially) broken. A warning will be written to syslog.

AUTHORS

Paul Vixie <[email protected]>

Wrote this manpage (1994).

Steve Greenland <[email protected]>

Maintained the package (1996-2005).

Javier Fernández-Sanguino Peña <[email protected]>

Maintained the package (2005-2014).

Christian Kastner <[email protected]>

Maintained the package (2010-2016).

Georges Khaznadar <[email protected]>

Maintained the package (2022-2024).

COPYRIGHT

Distribute freely, except: dont remove my name from the source or documentation (dont take credit for my work), mark your changes (dont get me blamed for your possible bugs), dont alter or remove this notice. May be sold if buildable source is provided to buyer. No warranty of any kind, express or implied, is included with this software; use at your own risk, responsibility for damages (if any) to anyone resulting from the use of this software rests entirely with the user.

Since year 1994, many modifications were made in this manpage, authored by Debian Developers which maintained cron; above is a short list, more information can be found in the file /usr/share/doc/cron/copyright.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

150 - Linux cli command modules.dep

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command modules.dep and provides detailed information about the command modules.dep, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the modules.dep.

NAME 🖥️ modules.dep 🖥️

Module dependency information

SYNOPSIS

/lib/modules/modules.dep

/lib/modules/modules.dep.bin

DESCRIPTION

modules.dep.bin is a binary file generated by depmod listing the dependencies for every module in the directories under /lib/modules/version. It is used by kmod tools such as modprobe and libkmod.

Its text counterpart is located in the same directory with the name modules.dep. The text version is maintained only for easy of reading by humans and is in no way used by any kmod tool.

These files are not intended for editing or use by any additional utilities as their format is subject to change in the future. You should use the modinfo(8) command to obtain information about modules in a future proof and compatible fashion rather than touching these files.

COPYRIGHT

AUTHORS

Jon Masters <[email protected]>

Developer

Lucas De Marchi <[email protected]>

Developer

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

151 - Linux cli command limits.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command limits.conf and provides detailed information about the command limits.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the limits.conf.

NAME 🖥️ limits.conf 🖥️

configuration file for the pam_limits module

DESCRIPTION

The pam_limits.so module applies ulimit limits, nice priority and number of simultaneous login sessions limit to user login sessions. This description of the configuration file syntax applies to the /etc/security/limits.conf file and *.conf files in the /etc/security/limits.d directory.

The syntax of the lines is as follows:

<domain> <type> <item> <value>

The fields listed above should be filled as follows:

·
a username
·
a groupname, with @group syntax. This should not be confused with netgroups.
·
the wildcard *, for default entry.
·
the wildcard %, for maxlogins limit only, can also be used with %group syntax. If the % wildcard is used alone it is identical to using * with maxsyslogins limit. With a group specified after % it limits the total number of logins of all users that are member of the group.
·
an uid range specified as <min_uid>:<max_uid>. If min_uid is omitted, the match is exact for the max_uid. If max_uid is omitted, all uids greater than or equal min_uid match.
·
a gid range specified as @<min_gid>:<max_gid>. If min_gid is omitted, the match is exact for the max_gid. If max_gid is omitted, all gids greater than or equal min_gid match. For the exact match all groups including the users supplementary groups are examined. For the range matches only the users primary group is examined.
·
a gid specified as %:<gid> applicable to maxlogins limit only. It limits the total number of logins of all users that are member of the group with the specified gid.
NOTE: group and wildcard limits are not applied to the root user. To set a limit for the root user, this field must contain the literal username root.

<type>

hard
for enforcing hard resource limits. These limits are set by the superuser and enforced by the Kernel. The user cannot raise his requirement of system resources above such values.
soft
for enforcing soft resource limits. These limits are ones that the user can move up or down within the permitted range by any pre-existing hard limits. The values specified with this token can be thought of as default values, for normal system usage.
-
for enforcing both soft and hard resource limits together.
Note, if you specify a type of - but neglect to supply the item and value fields then the module will never enforce any limits on the specified user/group etc. .

<item>

core
limits the core file size (KB)
data
maximum data size (KB)
fsize
maximum filesize (KB)
memlock
maximum locked-in-memory address space (KB)
nofile
maximum number of open file descriptors
rss
maximum resident set size (KB) (Ignored in Linux 2.4.30 and higher)
stack
maximum stack size (KB)
cpu
maximum CPU time (minutes)
nproc
maximum number of processes
as
address space limit (KB)
maxlogins
maximum number of logins for this user (this limit does not apply to user with uid=0)
maxsyslogins
maximum number of all logins on system; user is not allowed to log-in if total number of all user logins is greater than specified number (this limit does not apply to user with uid=0)
nonewprivs
value of 0 or 1; if set to 1 disables acquiring new privileges by invoking prctl(PR_SET_NO_NEW_PRIVS)
priority
the priority to run user process with (negative values boost process priority)
locks
maximum locked files (Linux 2.4 and higher)
sigpending
maximum number of pending signals (Linux 2.6 and higher)
msgqueue
maximum memory used by POSIX message queues (bytes) (Linux 2.6 and higher)
nice
maximum nice priority allowed to raise to (Linux 2.6.12 and higher) values: [-20,19]
rtprio
maximum realtime priority allowed for non-privileged processes (Linux 2.6.12 and higher)
chroot
the directory to chroot the user to

All items support the values -1, unlimited or infinity indicating no limit, except for priority, nice, and nonewprivs. If nofile is to be set to one of these values, it will be set to the contents of /proc/sys/fs/nr_open instead (see setrlimit(3)).

If a hard limit or soft limit of a resource is set to a valid value, but outside of the supported range of the local system, the system may reject the new limit or unexpected behavior may occur. If the control value required is used, the module will reject the login if a limit could not be set.

In general, individual limits have priority over group limits, so if you impose no limits for admin group, but one of the members in this group have a limits line, the user will have its limits set according to this line.

Also, please note that all limit settings are set per login. They are not global, nor are they permanent; existing only for the duration of the session. One exception is the maxlogin option, this one is system wide. But there is a race, concurrent logins at the same time will not always be detect as such but only counted as one.

In the limits configuration file, the # character introduces a comment - after which the rest of the line is ignored.

The pam_limits module does report configuration problems found in its configuration file and errors via syslog(3).

EXAMPLES

These are some example lines which might be specified in /etc/security/limits.conf.

          soft    core            0
root hard core 100000
          hard    nofile          512
@student hard nproc 20 @faculty soft nproc 20 @faculty hard nproc 50 ftp hard nproc 0 @student - maxlogins 4 @student - nonewprivs 1 :123 hard cpu 5000 @500: soft cpu 10000 600:700 hard locks 10

AUTHOR

pam_limits was initially written by Cristian Gafton <[email protected]>

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

152 - Linux cli command proc_pid_stat

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_stat and provides detailed information about the command proc_pid_stat, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_stat.

NAME 🖥️ proc_pid_stat 🖥️

status information

DESCRIPTION

/proc/pid/stat
Status information about the process. This is used by ps(1). It is defined in the kernel source file fs/proc/array.c.

The fields, in order, with their proper scanf(3) format specifiers, are listed below. Whether or not certain of these fields display valid information is governed by a ptrace access mode PTRACE_MODE_READ_FSCREDS | PTRACE_MODE_NOAUDIT check (refer to ptrace(2)). If the check denies access, then the field value is displayed as 0. The affected fields are indicated with the marking [PT].

(1) pid %d

The process ID.

(2) comm %s
The filename of the executable, in parentheses. Strings longer than TASK_COMM_LEN (16) characters (including the terminating null byte) are silently truncated. This is visible whether or not the executable is swapped out.

(3) state %c
One of the following characters, indicating process state:

R
Running

S
Sleeping in an interruptible wait

D
Waiting in uninterruptible disk sleep

Z
Zombie

T
Stopped (on a signal) or (before Linux 2.6.33) trace stopped

t
Tracing stop (Linux 2.6.33 onward)

W
Paging (only before Linux 2.6.0)

X
Dead (from Linux 2.6.0 onward)

x
Dead (Linux 2.6.33 to 3.13 only)

K
Wakekill (Linux 2.6.33 to 3.13 only)

W
Waking (Linux 2.6.33 to 3.13 only)

P
Parked (Linux 3.9 to 3.13 only)

I
Idle (Linux 4.14 onward)

(4) ppid %d
The PID of the parent of this process.

(5) pgrp %d
The process group ID of the process.

(6) session %d
The session ID of the process.

(7) tty_nr %d
The controlling terminal of the process. (The minor device number is contained in the combination of bits 31 to 20 and 7 to 0; the major device number is in bits 15 to 8.)

(8) tpgid %d
The ID of the foreground process group of the controlling terminal of the process.

(9) flags %u
The kernel flags word of the process. For bit meanings, see the PF_* defines in the Linux kernel source file include/linux/sched.h. Details depend on the kernel version.

The format for this field was %lu before Linux 2.6.

(10) minflt %lu
The number of minor faults the process has made which have not required loading a memory page from disk.

(11) cminflt %lu
The number of minor faults that the process’s waited-for children have made.

(12) majflt %lu
The number of major faults the process has made which have required loading a memory page from disk.

(13) cmajflt %lu
The number of major faults that the process’s waited-for children have made.

(14) utime %lu
Amount of time that this process has been scheduled in user mode, measured in clock ticks (divide by sysconf(_SC_CLK_TCK)). This includes guest time, guest_time (time spent running a virtual CPU, see below), so that applications that are not aware of the guest time field do not lose that time from their calculations.

(15) stime %lu
Amount of time that this process has been scheduled in kernel mode, measured in clock ticks (divide by sysconf(_SC_CLK_TCK)).

(16) cutime %ld
Amount of time that this process’s waited-for children have been scheduled in user mode, measured in clock ticks (divide by sysconf(_SC_CLK_TCK)). (See also times(2).) This includes guest time, cguest_time (time spent running a virtual CPU, see below).

(17) cstime %ld
Amount of time that this process’s waited-for children have been scheduled in kernel mode, measured in clock ticks (divide by sysconf(_SC_CLK_TCK)).

(18) priority %ld
(Explanation for Linux 2.6) For processes running a real-time scheduling policy (policy below; see sched_setscheduler(2)), this is the negated scheduling priority, minus one; that is, a number in the range -2 to -100, corresponding to real-time priorities 1 to 99. For processes running under a non-real-time scheduling policy, this is the raw nice value (setpriority(2)) as represented in the kernel. The kernel stores nice values as numbers in the range 0 (high) to 39 (low), corresponding to the user-visible nice range of -20 to 19.

Before Linux 2.6, this was a scaled value based on the scheduler weighting given to this process.

(19) nice %ld
The nice value (see setpriority(2)), a value in the range 19 (low priority) to -20 (high priority).

(20) num_threads %ld
Number of threads in this process (since Linux 2.6). Before Linux 2.6, this field was hard coded to 0 as a placeholder for an earlier removed field.

(21) itrealvalue %ld
The time in jiffies before the next SIGALRM is sent to the process due to an interval timer. Since Linux 2.6.17, this field is no longer maintained, and is hard coded as 0.

(22) starttime %llu
The time the process started after system boot. Before Linux 2.6, this value was expressed in jiffies. Since Linux 2.6, the value is expressed in clock ticks (divide by sysconf(_SC_CLK_TCK)).

The format for this field was %lu before Linux 2.6.

(23) vsize %lu
Virtual memory size in bytes.

(24) rss %ld
Resident Set Size: number of pages the process has in real memory. This is just the pages which count toward text, data, or stack space. This does not include pages which have not been demand-loaded in, or which are swapped out. This value is inaccurate; see /proc/pid/statm below.

(25) rsslim %lu
Current soft limit in bytes on the rss of the process; see the description of RLIMIT_RSS in getrlimit(2).

(26) startcode %lu [PT]
The address above which program text can run.

(27) endcode %lu [PT]
The address below which program text can run.

(28) startstack %lu [PT]
The address of the start (i.e., bottom) of the stack.

(29) kstkesp %lu [PT]
The current value of ESP (stack pointer), as found in the kernel stack page for the process.

(30) kstkeip %lu [PT]
The current EIP (instruction pointer).

(31) signal %lu
The bitmap of pending signals, displayed as a decimal number. Obsolete, because it does not provide information on real-time signals; use /proc/pid/status instead.

(32) blocked %lu
The bitmap of blocked signals, displayed as a decimal number. Obsolete, because it does not provide information on real-time signals; use /proc/pid/status instead.

(33) sigignore %lu
The bitmap of ignored signals, displayed as a decimal number. Obsolete, because it does not provide information on real-time signals; use /proc/pid/status instead.

(34) sigcatch %lu
The bitmap of caught signals, displayed as a decimal number. Obsolete, because it does not provide information on real-time signals; use /proc/pid/status instead.

(35) wchan %lu [PT]
This is the “channel” in which the process is waiting. It is the address of a location in the kernel where the process is sleeping. The corresponding symbolic name can be found in /proc/pid/wchan.

(36) nswap %lu
Number of pages swapped (not maintained).

(37) cnswap %lu
Cumulative nswap for child processes (not maintained).

(38) exit_signal %d (since Linux 2.1.22)
Signal to be sent to parent when we die.

(39) processor %d (since Linux 2.2.8)
CPU number last executed on.

(40) rt_priority %u (since Linux 2.5.19)
Real-time scheduling priority, a number in the range 1 to 99 for processes scheduled under a real-time policy, or 0, for non-real-time processes (see sched_setscheduler(2)).

(41) policy %u (since Linux 2.5.19)
Scheduling policy (see sched_setscheduler(2)). Decode using the SCHED_* constants in linux/sched.h.

The format for this field was %lu before Linux 2.6.22.

(42) delayacct_blkio_ticks %llu (since Linux 2.6.18)
Aggregated block I/O delays, measured in clock ticks (centiseconds).

(43) guest_time %lu (since Linux 2.6.24)
Guest time of the process (time spent running a virtual CPU for a guest operating system), measured in clock ticks (divide by sysconf(_SC_CLK_TCK)).

(44) cguest_time %ld (since Linux 2.6.24)
Guest time of the process’s children, measured in clock ticks (divide by sysconf(_SC_CLK_TCK)).

(45) start_data %lu (since Linux 3.3) [PT]
Address above which program initialized and uninitialized (BSS) data are placed.

(46) end_data %lu (since Linux 3.3) [PT]
Address below which program initialized and uninitialized (BSS) data are placed.

(47) start_brk %lu (since Linux 3.3) [PT]
Address above which program heap can be expanded with brk(2).

(48) arg_start %lu (since Linux 3.5) [PT]
Address above which program command-line arguments (argv) are placed.

(49) arg_end %lu (since Linux 3.5) [PT]
Address below program command-line arguments (argv) are placed.

(50) env_start %lu (since Linux 3.5) [PT]
Address above which program environment is placed.

(51) env_end %lu (since Linux 3.5) [PT]
Address below which program environment is placed.

(52) exit_code %d (since Linux 3.5) [PT]
The thread’s exit status in the form reported by waitpid(2).

153 - Linux cli command deb-src-files

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command deb-src-files and provides detailed information about the command deb-src-files, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the deb-src-files.

NAME 🖥️ deb-src-files 🖥️

src-files - Debian distribute files format

SYNOPSIS

debian/files

DESCRIPTION

This file contains the list of artifacts that are to be distributed via the .changes control file.

The debian/files file has a simple whitespace-delimited format.

filename section priority [ keyword=value… ]

filename is the name of the artifact to distribute.

section and priority correspond to the respective control fields available in the .deb. The allowed values are specific to each distribution archive.

keyword=value… corresponds to an optional whitespace-delimited list of attributes for this entry. The only currently supported keyword is automatic with value yes, to mark automatically generated files.

NOTES

This file is not intended to be modified directly, please use one of dpkg-gencontrol or dpkg-distaddfile to add entries to it.

154 - Linux cli command shadow

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command shadow and provides detailed information about the command shadow, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the shadow.

NAME 🖥️ shadow 🖥️

shadowed password file

DESCRIPTION

shadow is a file which contains the password information for the systems accounts and optional aging information.

This file must not be readable by regular users if password security is to be maintained.

Each line of this file contains 9 fields, separated by colons (“:”), in the following order:

login name

It must be a valid account name, which exist on the system.

encrypted password

This field may be empty, in which case no passwords are required to authenticate as the specified login name. However, some applications which read the /etc/shadow file may decide not to permit any access at all if the password field is empty.
A password field which starts with an exclamation mark means that the password is locked. The remaining characters on the line represent the password field before the password was locked.
Refer to crypt(3) for details on how this string is interpreted.
If the password field contains some string that is not a valid result of crypt(3), for instance ! or *, the user will not be able to use a unix password to log in (but the user may log in the system by other means).

date of last password change

The date of the last password change, expressed as the number of days since Jan 1, 1970 00:00 UTC.
The value 0 has a special meaning, which is that the user should change her password the next time she will log in the system.
An empty field means that password aging features are disabled.

minimum password age

The minimum password age is the number of days the user will have to wait before she will be allowed to change her password again.
An empty field and value 0 mean that there is no minimum password age.

maximum password age

The maximum password age is the number of days after which the user will have to change her password.
After this number of days is elapsed, the password may still be valid. The user should be asked to change her password the next time she will log in.
An empty field means that there are no maximum password age, no password warning period, and no password inactivity period (see below).
If the maximum password age is lower than the minimum password age, the user cannot change her password.

password warning period

The number of days before a password is going to expire (see the maximum password age above) during which the user should be warned.
An empty field and value 0 mean that there are no password warning period.

password inactivity period

The number of days after a password has expired (see the maximum password age above) during which the password should still be accepted (and the user should update her password during the next login).
After expiration of the password and this expiration period is elapsed, no login is possible for the user. The user should contact her administrator.
An empty field means that there are no enforcement of an inactivity period.

account expiration date

The date of expiration of the account, expressed as the number of days since Jan 1, 1970 00:00 UTC.
Note that an account expiration differs from a password expiration. In case of an account expiration, the user shall not be allowed to login. In case of a password expiration, the user is not allowed to login using her password.
An empty field means that the account will never expire.
The value 0 should not be used as it is interpreted as either an account with no expiration, or as an expiration on Jan 1, 1970.

reserved field

This field is reserved for future use.

FILES

/etc/passwd

User account information.

/etc/shadow

Secure user account information.

/etc/shadow-

Backup file for /etc/shadow.
Note that this file is used by the tools of the shadow toolsuite, but not by all user and password management tools.

155 - Linux cli command exim4_local_host_blacklist

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command exim4_local_host_blacklist and provides detailed information about the command exim4_local_host_blacklist, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the exim4_local_host_blacklist.

NAME 🖥️ exim4_local_host_blacklist 🖥️

config_files - Files in use by the Debian exim4 packages

SYNOPSIS

DESCRIPTION

This manual page describes the files that are in use by the Debian exim4 packages and which are not part of an exim installation done from source.

/etc/aliases

You should at least set up an alias for postmaster in the /etc/aliases file.

/etc/email-addresses

is used to rewrite the email addresses of users. This is particularly useful for users who use their ISP’s domain for email.

The file should contain lines of the form

user: [email protected]
otheruser: [email protected]

/etc/exim4/local_host_blacklist

In the blacklist, the trick is to read a line break as “or” if it follows a positive item, and as “and” if it follows a negative item.

For example, a /etc/exim4/local_host_blacklist

192.168.10.0/24
!172.16.10.128/26
172.16.10.0/24
10.0.0.0/8

Exim just evaluates left to right (or up-down in the file listing context), so you don’t get the same kind of operator binding as in a programming language.

/etc/exim4/host_local_deny_exceptions

/etc/exim4/local_sender_blacklist

In the blacklist, the trick is to read a line break as “or” if it follows a positive item, and as “and” if it follows a negative item.

For example, a /etc/exim4/local_sender_blacklist

domain1.example
[email protected]
domain2.example
domain3.example

Exim just evaluates left to right (or up-down in the file listing context), so you don’t get the same kind of operator binding as in a programming language.

/etc/exim4/sender_local_deny_exceptions

/etc/exim4/local_sender_callout

/etc/exim4/local_rcpt_callout

/etc/exim4/local_domain_dnsbl_whitelist

/etc/exim4/hubbed_hosts

The file should contain key-value pairs of domain pattern and route data of the form

domain: host-list options
dict.ref.example: mail-1.ref.example:mail-2.ref.example
foo.example: internal.mail.example.com
bar.example: 192.168.183.3

which will cause mail for foo.example to be sent to the host internal.mail.example (IP address derived from A record only), and mail to bar.example to be sent to 192.168.183.3.

See spec.txt chapter 20.3 through 20.7 for a more detailed explanation of host list format and available options.

/etc/exim4/passwd

contains account and password data for SMTP authentication when the local exim is SMTP server and clients authenticate to the local exim.

The file should contain lines of the form

username:crypted-password:clear-password

clear-password is only necessary if you want to offer CRAM-MD5 authentication. If you don’t plan on doing so, the third column can be omitted completely.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim 640.

/etc/exim4/passwd.client

contains account and password data for SMTP authentication when exim is authenticating as a client to some remote server.

The file should contain lines of the form

target.mail.server.example:login-user-name:password

This goes inevitably wrong if the host name of the mail server is a CNAME (a DNS alias), or the reverse lookup does not fit the forward one.

password is your SMTP password in clear text. If you do not know about your SMTP password, you can try using your POP3 password as a first guess.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim 640.

/etc/exim4/exim.crt

/etc/exim4/exim.key

/etc/mailname

The “mail name” of the system. See Debian policy Chapter Customized programs and exim4-base’s README.Debian for further details.

BUGS

Plenty. Please report them through the Debian BTS

This manual page needs a major re-work. If somebody knows better groff than us and has more experience in writing manual pages, any patches would be greatly appreciated.

NOTES

Unresolvable items in host lists

Adding or keeping items in the abovementioned host lists which are not resolvable by DNS has severe consequences.

notresolvable.example.com:rejectme.example.com

Starting the list with the special pattern +ignore_unknown as a safeguard against this behavior is strongly recommended if hostnames are used in hostlists.

AUTHOR

Marc Haber <[email protected]> with help from Ross Boylan.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

156 - Linux cli command proc_version

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_version and provides detailed information about the command proc_version, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_version.

NAME 🖥️ proc_version 🖥️

kernel version

DESCRIPTION

/proc/version
This string identifies the kernel version that is currently running. It includes the contents of /proc/sys/kernel/ostype, /proc/sys/kernel/osrelease, and /proc/sys/kernel/version. For example:

Linux version 1.0.9 (quinlan@phaze) #1 Sat May 14 01:51:54 EDT 1994

157 - Linux cli command proc_pid_autogroup

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_autogroup and provides detailed information about the command proc_pid_autogroup, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_autogroup.

NAME 🖥️ proc_pid_autogroup 🖥️

group tasks for the scheduler

DESCRIPTION

/proc/pid/autogroup (since Linux 2.6.38)
See sched(7).

158 - Linux cli command proc_self

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_self and provides detailed information about the command proc_self, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_self.

NAME 🖥️ proc_self 🖥️

process information

DESCRIPTION

The process’s “dumpable” attribute may change for the following reasons:

The attribute was explicitly set via the prctl(2) PR_SET_DUMPABLE operation.
The attribute was reset to the value in the file /proc/sys/fs/suid_dumpable (described below), for the reasons described in prctl(2).

/proc/self/
This directory refers to the process accessing the /proc filesystem, and is identical to the /proc directory named by the process ID of the same process.

159 - Linux cli command dnssec-trust-anchors.d

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command dnssec-trust-anchors.d and provides detailed information about the command dnssec-trust-anchors.d, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the dnssec-trust-anchors.d.

NAME 🖥️ dnssec-trust-anchors.d 🖥️

trust-anchors.d, systemd.positive, systemd.negative - DNSSEC trust anchor configuration files

SYNOPSIS

/etc/dnssec-trust-anchors.d/*.positive

/run/dnssec-trust-anchors.d/*.positive

/usr/local/lib/dnssec-trust-anchors.d/*.positive

/usr/lib/dnssec-trust-anchors.d/*.positive

/etc/dnssec-trust-anchors.d/*.negative

/run/dnssec-trust-anchors.d/*.negative

/usr/local/lib/dnssec-trust-anchors.d/*.negative

/usr/lib/dnssec-trust-anchors.d/*.negative

DESCRIPTION

The DNSSEC trust anchor configuration files define positive and negative trust anchors systemd-resolved.service(8) bases DNSSEC integrity proofs on.

POSITIVE TRUST ANCHORS

. IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5

Alternatively, DNSKEY resource records may be used to define trust anchors, like in the following example:

. IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=

If multiple DS or DNSKEY records are defined for the same domain (possibly even in different trust anchor files), all keys are used and are considered equivalent as base for DNSSEC proofs.

It is generally recommended to encode trust anchors in DS resource records, rather than DNSKEY resource records.

The current DNSSEC trust anchor for the Internets root domain is available at the IANA Trust Anchor and Keys[6] page.

NEGATIVE TRUST ANCHORS

Reverse IPv4 mappings

10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
...
# Some custom domains
prod
stag

Negative trust anchors are useful to support private DNS subtrees that are not referenced from the Internet DNS hierarchy, and not signed.

RFC 7646[7] for details on negative trust anchors.

If no negative trust anchor files are configured a built-in set of well-known private DNS zone domains is used as negative trust anchors.

It is also possibly to define per-interface negative trust anchors using the DNSSECNegativeTrustAnchors= setting in systemd.network(5) files.

NOTES

RFC 4035, Section 4.4

https://tools.ietf.org/html/rfc4035#section-4.4

RFC 1035, Section 5

https://tools.ietf.org/html/rfc1035#section-5

RFC 4034, Section 5

https://tools.ietf.org/html/rfc4034#section-5

RFC 4034, Section 2

https://tools.ietf.org/html/rfc4034#section-2

RFC 5011

https://tools.ietf.org/html/rfc5011

IANA Trust Anchor and Keys

https://data.iana.org/root-anchors/root-anchors.xml

RFC 7646

https://tools.ietf.org/html/rfc7646

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

160 - Linux cli command gitprotocol-capabilities

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitprotocol-capabilities and provides detailed information about the command gitprotocol-capabilities, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitprotocol-capabilities.

NAME 🖥️ gitprotocol-capabilities 🖥️

capabilities - Protocol v0 and v1 capabilities

SYNOPSIS

<over-the-wire-protocol>

DESCRIPTION

Note
this document describes capabilities for versions 0 and 1 of the pack protocol. For version 2, please refer to the gitprotocol-v2(5) doc.

Servers SHOULD support all capabilities defined in this document.

On the very first line of the initial server response of either receive-pack and upload-pack the first reference is followed by a NUL byte and then a list of space delimited server capabilities. These allow the server to declare what it can and cannot support to the client.

Client will then send a space separated list of capabilities it wants to be in effect. The client MUST NOT ask for capabilities the server did not say it supports.

Server MUST diagnose and abort if capabilities it does not understand were sent. Server MUST NOT ignore capabilities that client requested and server advertised. As a consequence of these rules, server MUST NOT advertise capabilities it does not understand.

The atomic, report-status, report-status-v2, delete-refs, quiet, and push-cert capabilities are sent and recognized by the receive-pack (push to server) process.

The ofs-delta and side-band-64k capabilities are sent and recognized by both upload-pack and receive-pack protocols. The agent and session-id capabilities may optionally be sent in both protocols.

All other capabilities are only recognized by the upload-pack (fetch from server) process.

MULTI_ACK

The multi_ack capability allows the server to return “ACK obj-id continue” as soon as it finds a commit that it can use as a common base, between the client’s wants and the client’s have set.

By sending this early, the server can potentially head off the client from walking any further down that particular branch of the client’s repository history. The client may still need to walk down other branches, sending have lines for those, until the server has a complete cut across the DAG, or the client has said “done”.

Without multi_ack, a client sends have lines in –date-order until the server has found a common base. That means the client will send have lines that are already known by the server to be common, because they overlap in time with another branch on which the server hasn’t found a common base yet.

For example suppose the client has commits in caps that the server doesn’t and the server has commits in lower case that the client doesn’t, as in the following diagram:

+—- u ———————- x / +—– y / / a – b – c – d – E – F
+— Q – R – S

If the client wants x,y and starts out by saying have F,S, the server doesn’t know what F,S is. Eventually the client says “have d” and the server sends “ACK d continue” to let the client know to stop walking down that line (so don’t send c-b-a), but it’s not done yet, it needs a base for x. The client keeps going with S-R-Q, until a gets reached, at which point the server has a clear base and it all ends.

Without multi_ack the client would have sent that c-b-a chain anyway, interleaved with S-R-Q.

MULTI_ACK_DETAILED

This is an extension of multi_ack that permits the client to better understand the server’s in-memory state. See gitprotocol-pack(5), section “Packfile Negotiation” for more information.

NO-DONE

This capability should only be used with the smart HTTP protocol. If multi_ack_detailed and no-done are both present, then the sender is free to immediately send a pack following its first “ACK obj-id ready” message.

Without no-done in the smart HTTP protocol, the server session would end and the client has to make another trip to send “done” before the server can send the pack. no-done removes the last round and thus slightly reduces latency.

THIN-PACK

A thin pack is one with deltas which reference base objects not contained within the pack (but are known to exist at the receiving end). This can reduce the network traffic significantly, but it requires the receiving end to know how to “thicken” these packs by adding the missing bases to the pack.

The upload-pack server advertises thin-pack when it can generate and send a thin pack. A client requests the thin-pack capability when it understands how to “thicken” it, notifying the server that it can receive such a pack. A client MUST NOT request the thin-pack capability if it cannot turn a thin pack into a self-contained pack.

Receive-pack, on the other hand, is assumed by default to be able to handle thin packs, but can ask the client not to use the feature by advertising the no-thin capability. A client MUST NOT send a thin pack if the server advertises the no-thin capability.

The reasons for this asymmetry are historical. The receive-pack program did not exist until after the invention of thin packs, so historically the reference implementation of receive-pack always understood thin packs. Adding no-thin later allowed receive-pack to disable the feature in a backwards-compatible manner.

SIDE-BAND, SIDE-BAND-64K

This capability means that the server can send, and the client can understand, multiplexed progress reports and error info interleaved with the packfile itself.

These two options are mutually exclusive. A modern client always favors side-band-64k.

Either mode indicates that the packfile data will be streamed broken up into packets of up to either 1000 bytes in the case of side_band, or 65520 bytes in the case of side_band_64k. Each packet is made up of a leading 4-byte pkt-line length of how much data is in the packet, followed by a 1-byte stream code, followed by the actual data.

The stream code can be one of:

1 - pack data 2 - progress messages 3 - fatal error message just before stream aborts

The “side-band-64k” capability came about as a way for newer clients that can handle much larger packets to request packets that are actually crammed nearly full, while maintaining backward compatibility for the older clients.

Further, with side-band and its up to 1000-byte messages, it’s actually 999 bytes of payload and 1 byte for the stream code. With side-band-64k, same deal, you have up to 65519 bytes of data and 1 byte for the stream code.

The client MUST send only one of “side-band” and “side- band-64k”. The server MUST diagnose it as an error if client requests both.

OFS-DELTA

The server can send, and the client can understand, PACKv2 with delta referring to its base by position in pack rather than by an obj-id. That is, they can send/read OBJ_OFS_DELTA (aka type 6) in a packfile.

AGENT

The server may optionally send a capability of the form agent=X to notify the client that the server is running version X. The client may optionally return its own agent string by responding with an agent=Y capability (but it MUST NOT do so if the server did not mention the agent capability). The X and Y strings may contain any printable ASCII characters except space (i.e., the byte range 32 < x < 127), and are typically of the form “package/version” (e.g., “git/1.8.3.1”). The agent strings are purely informative for statistics and debugging purposes, and MUST NOT be used to programmatically assume the presence or absence of particular features.

OBJECT-FORMAT

This capability, which takes a hash algorithm as an argument, indicates that the server supports the given hash algorithms. It may be sent multiple times; if so, the first one given is the one used in the ref advertisement.

When provided by the client, this indicates that it intends to use the given hash algorithm to communicate. The algorithm provided must be one that the server supports.

If this capability is not provided, it is assumed that the only supported algorithm is SHA-1.

SYMREF

This parameterized capability is used to inform the receiver which symbolic ref points to which ref; for example, “symref=HEAD:refs/heads/master” tells the receiver that HEAD points to master. This capability can be repeated to represent multiple symrefs.

Servers SHOULD include this capability for the HEAD symref if it is one of the refs being sent.

Clients MAY use the parameters from this capability to select the proper initial branch when cloning a repository.

SHALLOW

This capability adds “deepen”, “shallow” and “unshallow” commands to the fetch-pack/upload-pack protocol so clients can request shallow clones.

DEEPEN-SINCE

This capability adds “deepen-since” command to fetch-pack/upload-pack protocol so the client can request shallow clones that are cut at a specific time, instead of depth. Internally it’s equivalent of doing “rev-list –max-age=<timestamp>” on the server side. “deepen-since” cannot be used with “deepen”.

DEEPEN-NOT

This capability adds “deepen-not” command to fetch-pack/upload-pack protocol so the client can request shallow clones that are cut at a specific revision, instead of depth. Internally it’s equivalent of doing “rev-list –not <rev>” on the server side. “deepen-not” cannot be used with “deepen”, but can be used with “deepen-since”.

DEEPEN-RELATIVE

If this capability is requested by the client, the semantics of “deepen” command is changed. The “depth” argument is the depth from the current shallow boundary, instead of the depth from remote refs.

NO-PROGRESS

The client was started with “git clone -q” or something similar, and doesn’t want that side band 2. Basically the client just says “I do not wish to receive stream 2 on sideband, so do not send it to me, and if you did, I will drop it on the floor anyway”. However, the sideband channel 3 is still used for error responses.

INCLUDE-TAG

The include-tag capability is about sending annotated tags if we are sending objects they point to. If we pack an object to the client, and a tag object points exactly at that object, we pack the tag object too. In general this allows a client to get all new annotated tags when it fetches a branch, in a single network connection.

Clients MAY always send include-tag, hardcoding it into a request when the server advertises this capability. The decision for a client to request include-tag only has to do with the client’s desires for tag data, whether or not a server had advertised objects in the refs/tags/* namespace.

Servers MUST pack the tags if their referent is packed and the client has requested include-tags.

Clients MUST be prepared for the case where a server has ignored include-tag and has not actually sent tags in the pack. In such cases the client SHOULD issue a subsequent fetch to acquire the tags that include-tag would have otherwise given the client.

The server SHOULD send include-tag, if it supports it, regardless of whether or not there are tags available.

REPORT-STATUS

The receive-pack process can receive a report-status capability, which tells it that the client wants a report of what happened after a packfile upload and reference update. If the pushing client requests this capability, after unpacking and updating references the server will respond with whether the packfile unpacked successfully and if each reference was updated successfully. If any of those were not successful, it will send back an error message. See gitprotocol-pack(5) for example messages.

REPORT-STATUS-V2

Capability report-status-v2 extends capability report-status by adding new “option” directives in order to support reference rewritten by the “proc-receive” hook. The “proc-receive” hook may handle a command for a pseudo-reference which may create or update a reference with different name, new-oid, and old-oid. While the capability report-status cannot report for such case. See gitprotocol-pack(5) for details.

DELETE-REFS

If the server sends back the delete-refs capability, it means that it is capable of accepting a zero-id value as the target value of a reference update. It is not sent back by the client, it simply informs the client that it can be sent zero-id values to delete references.

QUIET

If the receive-pack server advertises the quiet capability, it is capable of silencing human-readable progress output which otherwise may be shown when processing the received pack. A send-pack client should respond with the quiet capability to suppress server-side progress reporting if the local progress reporting is also being suppressed (e.g., via push -q, or if stderr does not go to a tty).

ATOMIC

If the server sends the atomic capability it is capable of accepting atomic pushes. If the pushing client requests this capability, the server will update the refs in one atomic transaction. Either all refs are updated or none.

PUSH-OPTIONS

If the server sends the push-options capability it is able to accept push options after the update commands have been sent, but before the packfile is streamed. If the pushing client requests this capability, the server will pass the options to the pre- and post- receive hooks that process this push request.

ALLOW-TIP-SHA1-IN-WANT

If the upload-pack server advertises this capability, fetch-pack may send “want” lines with object names that exist at the server but are not advertised by upload-pack. For historical reasons, the name of this capability contains “sha1”. Object names are always given using the object format negotiated through the object-format capability.

ALLOW-REACHABLE-SHA1-IN-WANT

PUSH-CERT=<NONCE>

The receive-pack server that advertises this capability is willing to accept a signed push certificate, and asks the <nonce> to be included in the push certificate. A send-pack client MUST NOT send a push-cert packet unless the receive-pack server advertises this capability.

FILTER

If the upload-pack server advertises the filter capability, fetch-pack may send “filter” commands to request a partial clone or partial fetch and request that the server omit various objects from the packfile.

SESSION-ID=<SESSION ID>

The server may advertise a session ID that can be used to identify this process across multiple requests. The client may advertise its own session ID back to the server as well.

Session IDs should be unique to a given process. They must fit within a packet-line, and must not contain non-printable or whitespace characters. The current implementation uses trace2 session IDs (see api-trace2[1] for details), but this may change and users of the session ID should not rely on this fact.

GIT

Part of the git(1) suite

NOTES

api-trace2

file:///usr/share/doc/git/html/technical/api-trace2.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

161 - Linux cli command terminal-colors.d

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command terminal-colors.d and provides detailed information about the command terminal-colors.d, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the terminal-colors.d.

NAME 🖥️ terminal-colors.d 🖥️

colors.d - configure output colorization for various utilities

SYNOPSIS

/etc/terminal-colors.d/[[name][@term].][type]

DESCRIPTION

Files in this directory determine the default behavior for utilities when coloring output.

The name is a utility name. The name is optional and when none is specified then the file is used for all unspecified utilities.

The term is a terminal identifier (the TERM environment variable). The terminal identifier is optional and when none is specified then the file is used for all unspecified terminals.

The type is a file type. Supported file types are:

disable

Turns off output colorization for all compatible utilities.

enable

Turns on output colorization; any matching disable files are ignored.

scheme

Specifies colors used for output. The file format may be specific to the utility, the default format is described below.

If there are more files that match for a utility, then the file with the more specific filename wins. For example, the filename “@xterm.scheme” has less priority than “[email protected]”. The lowest priority are those files without a utility name and terminal identifier (e.g., “disable”).

The user-specific $XDG_CONFIG_HOME/terminal-colors.d or $HOME/.config/terminal-colors.d overrides the global setting.

DEFAULT SCHEME FILES FORMAT

The following statement is recognized:

name color-sequence

The name is a logical name of color sequence (for example “error”). The names are specific to the utilities. For more details always see the COLORS section in the man page for the utility.

The color-sequence is a color name, ASCII color sequences or escape sequences.

Color names

black, blink, blue, bold, brown, cyan, darkgray, gray, green, halfbright, lightblue, lightcyan, lightgray, lightgreen, lightmagenta, lightred, magenta, red, reset, reverse, and yellow.

ANSI color sequences

The color sequences are composed of sequences of numbers separated by semicolons. The most common codes are:

0 to restore default color
1 for brighter colors
4 for underlined text
5 for flashing text
30 for black foreground
31 for red foreground
32 for green foreground
33 for yellow (or brown) foreground
34 for blue foreground
35 for purple foreground
36 for cyan foreground
37 for white (or gray) foreground
40 for black background
41 for red background
42 for green background
43 for yellow (or brown) background
44 for blue background
45 for purple background
46 for cyan background
47 for white (or gray) background

Escape sequences

To specify control or blank characters in the color sequences, C-style \escaped notation can be used:

Bell (ASCII 7)
Backspace (ASCII 8)
Escape (ASCII 27)
Form feed (ASCII 12)
Newline (ASCII 10)
Carriage Return (ASCII 13)
Tab (ASCII 9)
Vertical Tab (ASCII 11)
\? Delete (ASCII 127)
\_ Space
\ Backslash (\)
\^ Caret (^)
\# Hash mark (#)

Please note that escapes are necessary to enter a space, backslash, caret, or any control character anywhere in the string, as well as a hash mark as the first character.

For example, to use a red background for alert messages in the output of dmesg(1), use:

echo alert 37;41 >> /etc/terminal-colors.d/dmesg.scheme

Comments

Lines where the first non-blank character is a # (hash) are ignored. Any other use of the hash character is not interpreted as introducing a comment.

ENVIRONMENT

TERMINAL_COLORS_DEBUG=all

enables debug output.

FILES

$XDG_CONFIG_HOME/terminal-colors.d

$HOME/.config/terminal-colors.d

/etc/terminal-colors.d

EXAMPLE

Disable colors for all compatible utilities:

touch /etc/terminal-colors.d/disable

Disable colors for all compatible utils on a vt100 terminal:

touch /etc/terminal-colors.d/@vt100.disable

Disable colors for all compatible utils except dmesg(1):

touch /etc/terminal-colors.d/disable
touch /etc/terminal-colors.d/dmesg.enable

COMPATIBILITY

The terminal-colors.d functionality is currently supported by all util-linux utilities which provides colorized output. For more details always see the COLORS section in the man page for the utility.

REPORTING BUGS

For bug reports, use the issue tracker at <https://github.com/util-linux/util-linux/issues>.

AVAILABILITY

terminal-colors.d is part of the util-linux package which can be downloaded from Linux Kernel Archive <https://www.kernel.org/pub/linux/utils/util-linux/>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

162 - Linux cli command deluser.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command deluser.conf and provides detailed information about the command deluser.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the deluser.conf.

NAME 🖥️ deluser.conf 🖥️

configuration file for deluser(8) and delgroup(8).

DESCRIPTION

The file /etc/deluser.conf contains defaults for the programs deluser(8) and delgroup(8). Each line holds a single value pair in the form option = value. Double or single quotes are allowed around the value, as is whitespace around the equals sign. Comment lines must have a hash sign (#) in the first column.

deluser(8) and delgroup(8) also read /etc/adduser.conf, see adduser.conf(5); settings in deluser.conf may overwrite settings made in adduser.conf.

The valid configuration options are:

BACKUP
If REMOVE_HOME or REMOVE_ALL_FILES is activated, all files are backed up before they are removed. The backup file that is created defaults to username.tar(.gz|.bz2) in the directory specified by the BACKUP_TO option. The compression method is chosen to the best that is available. Values may be 0 or 1. Defaults to 0.

BACKUP_SUFFIX
Select compression algorithm for a home directory backup. Can be set to any suffix recognized by tar –auto-compress. Defaults to .gz.

BACKUP_TO
If BACKUP is activated, BACKUP_TO specifies the directory the backup is written to. Defaults to the current directory.

NO_DEL_PATHS
A list of regular expressions, space separated. All files to be deleted in course of deleting the home directory or user-owned files elsewhere are checked against each of these regular expressions. If a match is detected, the file is not deleted. Defaults to a list of system directories, leaving only /home. Therefore only files below /home belonging to that specific user are going to be deleted.

ONLY_IF_EMPTY
Only delete a group if there are no users belonging to this group. Defaults to 0.

REMOVE_ALL_FILES
Removes all files on the system owned by the user to be removed. If this option is activated REMOVE_HOME has no effect. Values may be 0 or 1. Defaults to 0.

REMOVE_HOME
Removes the home directory and mail spool of the user to be removed. Value may be 0 (don’t delete) or 1 (do delete). Defaults to 0.

FILES

/etc/deluser.conf

163 - Linux cli command proc_pid_numa_maps

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_numa_maps and provides detailed information about the command proc_pid_numa_maps, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_numa_maps.

NAME 🖥️ proc_pid_numa_maps 🖥️

NUMA memory policy and allocation

DESCRIPTION

/proc/pid/numa_maps (since Linux 2.6.14)
See numa(7).

164 - Linux cli command proc_locks

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_locks and provides detailed information about the command proc_locks, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_locks.

NAME 🖥️ proc_locks 🖥️

current file locks and leases

DESCRIPTION

/proc/locks
This file shows current file locks ( flock(2) and fcntl(2)) and leases ( fcntl(2)).

An example of the content shown in this file is the following:

1: POSIX  ADVISORY  READ  5433 08:01:7864448 128 128
2: FLOCK  ADVISORY  WRITE 2001 08:01:7864554 0 EOF
3: FLOCK  ADVISORY  WRITE 1568 00:2f:32388 0 EOF
4: POSIX  ADVISORY  WRITE 699 00:16:28457 0 EOF
5: POSIX  ADVISORY  WRITE 764 00:16:21448 0 0
6: POSIX  ADVISORY  READ  3548 08:01:7867240 1 1
7: POSIX  ADVISORY  READ  3548 08:01:7865567 1826 2335
8: OFDLCK ADVISORY  WRITE -1 08:01:8713209 128 191

The fields shown in each line are as follows:

[1]
The ordinal position of the lock in the list.

[2]
The lock type. Values that may appear here include:

FLOCK
This is a BSD file lock created using flock(2).

OFDLCK
This is an open file description (OFD) lock created using fcntl(2).

POSIX
This is a POSIX byte-range lock created using fcntl(2).

[3]
Among the strings that can appear here are the following:

ADVISORY
This is an advisory lock.

MANDATORY
This is a mandatory lock.

[4]
The type of lock. Values that can appear here are:

READ
This is a POSIX or OFD read lock, or a BSD shared lock.

WRITE
This is a POSIX or OFD write lock, or a BSD exclusive lock.

[5]
The PID of the process that owns the lock.

Because OFD locks are not owned by a single process (since multiple processes may have file descriptors that refer to the same open file description), the value -1 is displayed in this field for OFD locks. (Before Linux 4.14, a bug meant that the PID of the process that initially acquired the lock was displayed instead of the value -1.)

[6]
Three colon-separated subfields that identify the major and minor device ID of the device containing the filesystem where the locked file resides, followed by the inode number of the locked file.

[7]
The byte offset of the first byte of the lock. For BSD locks, this value is always 0.

[8]
The byte offset of the last byte of the lock. EOF in this field means that the lock extends to the end of the file. For BSD locks, the value shown is always EOF.

Since Linux 4.9, the list of locks shown in /proc/locks is filtered to show just the locks for the processes in the PID namespace (see pid_namespaces(7)) for which the /proc filesystem was mounted. (In the initial PID namespace, there is no filtering of the records shown in this file.)

The lslocks(8) command provides a bit more information about each lock.

165 - Linux cli command systemd.swap

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.swap and provides detailed information about the command systemd.swap, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.swap.

NAME 🖥️ systemd.swap 🖥️

Swap unit configuration

SYNOPSIS

swap.swap

DESCRIPTION

A unit configuration file whose name ends in “.swap” encodes information about a swap device or file for memory paging controlled and supervised by systemd.

This man page lists the configuration options specific to this unit type. See systemd.unit(5) for the common options of all unit configuration files. The common configuration items are configured in the generic [Unit] and [Install] sections. The swap specific configuration options are configured in the [Swap] section.

Additional options are listed in systemd.exec(5), which define the execution environment the swapon(8) program is executed in, in systemd.kill(5), which define the way these processes are terminated, and in systemd.resource-control(5), which configure resource control settings for these processes of the unit.

Swap units must be named after the devices or files they control. Example: the swap device /dev/sda5 must be configured in a unit file dev-sda5.swap. For details about the escaping logic used to convert a file system path to a unit name, see systemd.unit(5). Note that swap units cannot be templated, nor is possible to add multiple names to a swap unit by creating additional symlinks to it.

Note that swap support on Linux is privileged, swap units are hence only available in the system service manager (and roots user service manager), but not in unprivileged users service manager.

AUTOMATIC DEPENDENCIES

Implicit Dependencies

The following dependencies are implicitly added:

·
All swap units automatically get the BindsTo= and After= dependencies on the device units or the mount units of the files they are activated from.

Additional implicit dependencies may be added as result of execution and resource control parameters as documented in systemd.exec(5) and systemd.resource-control(5).

Default Dependencies

The following dependencies are added unless DefaultDependencies=no is set:

·
Swap units automatically acquire a Conflicts= and a Before= dependency on umount.target so that they are deactivated at shutdown as well as a Before=swap.target dependency.

FSTAB

Swap units may either be configured via unit files, or via /etc/fstab (see fstab(5) for details). Swaps listed in /etc/fstab will be converted into native units dynamically at boot and when the configuration of the system manager is reloaded. See systemd-fstab-generator(8) for details about the conversion.

If a swap device or file is configured in both /etc/fstab and a unit file, the configuration in the latter takes precedence.

When reading /etc/fstab, a few special options are understood by systemd which influence how dependencies are created for swap units.

noauto, auto

With noauto, the swap unit will not be added as a dependency for swap.target. This means that it will not be activated automatically during boot, unless it is pulled in by some other unit. The auto option has the opposite meaning and is the default.
Added in version 218.

nofail

With nofail, the swap unit will be only wanted, not required by swap.target. This means that the boot will continue even if this swap device is not activated successfully.
Added in version 218.

x-systemd.device-timeout=

Configure how long systemd should wait for a device to show up before giving up on an entry from /etc/fstab. Specify a time in seconds or explicitly append a unit such as “s”, “min”, “h”, “ms”.
Note that this option can only be used in /etc/fstab, and will be ignored when part of the Options= setting in a unit file.
Added in version 215.

x-systemd.makefs

The swap structure will be initialized on the device. If the device is not “empty”, i.e. it contains any signature, the operation will be skipped. It is hence expected that this option remains set even after the device has been initialized.
Note that this option can only be used in /etc/fstab, and will be ignored when part of the Options= setting in a unit file.
See [email protected](8) and the discussion of wipefs(8) in systemd.mount(5).
Added in version 240.

OPTIONS

Swap unit files may include [Unit] and [Install] sections, which are described in systemd.unit(5).

Swap unit files must include a [Swap] section, which carries information about the swap device it supervises. A number of options that may be used in this section are shared with other unit types. These options are documented in systemd.exec(5), systemd.kill(5) and systemd.resource-control(5). The options specific to the [Swap] section of swap units are the following:

What=

Takes an absolute path or a fstab-style identifier of a device node or file to use for paging. See swapon(8) for details. If this refers to a device node, a dependency on the respective device unit is automatically created. (See systemd.device(5) for more information.) If this refers to a file, a dependency on the respective mount unit is automatically created. (See systemd.mount(5) for more information.) This option is mandatory. Note that the usual specifier expansion is applied to this setting, literal percent characters should hence be written as “%%”.

Priority=

Swap priority to use when activating the swap device or file. This takes an integer. This setting is optional and ignored when the priority is set by pri= in the Options= key.

Options=

May contain an option string for the swap device. This may be used for controlling discard options among other functionality, if the swap backing device supports the discard or trim operation. (See swapon(8) for more information.) Note that the usual specifier expansion is applied to this setting, literal percent characters should hence be written as “%%”.
Added in version 217.

TimeoutSec=

Configures the time to wait for the swapon command to finish. If a command does not exit within the configured time, the swap will be considered failed and be shut down again. All commands still running will be terminated forcibly via SIGTERM, and after another delay of this time with SIGKILL. (See KillMode= in systemd.kill(5).) Takes a unit-less value in seconds, or a time span value such as “5min 20s”. Pass “0” to disable the timeout logic. Defaults to DefaultTimeoutStartSec= from the manager configuration file (see systemd-system.conf(5)).

Check systemd.unit(5), systemd.exec(5), and systemd.kill(5) for more settings.

166 - Linux cli command filesystems

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command filesystems and provides detailed information about the command filesystems, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the filesystems.

NAME 🖥️ filesystems 🖥️

Linux filesystem types: ext, ext2, ext3, ext4, hpfs, iso9660, JFS, minix, msdos, ncpfs nfs, ntfs, proc, Reiserfs, smb, sysv, umsdos, vfat, XFS, xiafs

DESCRIPTION

When, as is customary, the proc filesystem is mounted on /proc, you can find in the file /proc/filesystems which filesystems your kernel currently supports; see proc(5) for more details. There is also a legacy sysfs(2) system call (whose availability is controlled by the CONFIG_SYSFS_SYSCALL kernel build configuration option since Linux 3.15) that enables enumeration of the currently available filesystem types regardless of /proc availability and/or sanity.

If you need a currently unsupported filesystem, insert the corresponding kernel module or recompile the kernel.

In order to use a filesystem, you have to mount it; see mount(2) and mount(8).

The following list provides a short description of the available or historically available filesystems in the Linux kernel. See the kernel documentation for a comprehensive description of all options and limitations.

erofs
is the Enhanced Read-Only File System, stable since Linux 5.4. See erofs(5).

ext
is an elaborate extension of the minix filesystem. It has been completely superseded by the second version of the extended filesystem (ext2) and has been removed from the kernel (in Linux 2.1.21).

ext2
is a disk filesystem that was used by Linux for fixed disks as well as removable media. The second extended filesystem was designed as an extension of the extended filesystem (ext). See ext2(5).

ext3
is a journaling version of the ext2 filesystem. It is easy to switch back and forth between ext2 and ext3. See ext3(5).

ext4
is a set of upgrades to ext3 including substantial performance and reliability enhancements, plus large increases in volume, file, and directory size limits. See ext4(5).

hpfs
is the High Performance Filesystem, used in OS/2. This filesystem is read-only under Linux due to the lack of available documentation.

iso9660
is a CD-ROM filesystem type conforming to the ISO/IEC 9660 standard.

High Sierra
Linux supports High Sierra, the precursor to the ISO/IEC 9660 standard for CD-ROM filesystems. It is automatically recognized within the iso9660 filesystem support under Linux.

Rock Ridge
Linux also supports the System Use Sharing Protocol records specified by the Rock Ridge Interchange Protocol. They are used to further describe the files in the iso9660 filesystem to a UNIX host, and provide information such as long filenames, UID/GID, POSIX permissions, and devices. It is automatically recognized within the iso9660 filesystem support under Linux.

JFS
is a journaling filesystem, developed by IBM, that was integrated into Linux 2.4.24.

minix
is the filesystem used in the Minix operating system, the first to run under Linux. It has a number of shortcomings, including a 64 MB partition size limit, short filenames, and a single timestamp. It remains useful for floppies and RAM disks.

msdos
is the filesystem used by DOS, Windows, and some OS/2 computers. msdos filenames can be no longer than 8 characters, followed by an optional period and 3 character extension.

ncpfs
is a network filesystem that supports the NCP protocol, used by Novell NetWare. It was removed from the kernel in Linux 4.17.

To use ncpfs, you need special programs, which can be found at .

nfs
is the network filesystem used to access disks located on remote computers.

ntfs
is the filesystem native to Microsoft Windows NT, supporting features like ACLs, journaling, encryption, and so on.

proc
is a pseudo filesystem which is used as an interface to kernel data structures rather than reading and interpreting /dev/kmem. In particular, its files do not take disk space. See proc(5).

Reiserfs
is a journaling filesystem, designed by Hans Reiser, that was integrated into Linux 2.4.1.

smb
is a network filesystem that supports the SMB protocol, used by Windows. See .

sysv
is an implementation of the System V/Coherent filesystem for Linux. It implements all of Xenix FS, System V/386 FS, and Coherent FS.

umsdos
is an extended DOS filesystem used by Linux. It adds capability for long filenames, UID/GID, POSIX permissions, and special files (devices, named pipes, etc.) under the DOS filesystem, without sacrificing compatibility with DOS.

tmpfs
is a filesystem whose contents reside in virtual memory. Since the files on such filesystems typically reside in RAM, file access is extremely fast. See tmpfs(5).

vfat
is an extended FAT filesystem used by Microsoft Windows95 and Windows NT. vfat adds the capability to use long filenames under the MSDOS filesystem.

XFS
is a journaling filesystem, developed by SGI, that was integrated into Linux 2.4.20.

xiafs
was designed and implemented to be a stable, safe filesystem by extending the Minix filesystem code. It provides the basic most requested features without undue complexity. The xiafs filesystem is no longer actively developed or maintained. It was removed from the kernel in Linux 2.1.21.

167 - Linux cli command mac-vendor

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command mac-vendor and provides detailed information about the command mac-vendor, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the mac-vendor.

NAME 🖥️ mac-vendor 🖥️

vendor - Ethernet vendor file for arp-scan

SYNOPSIS

mac-vendor.txt

DESCRIPTION

The mac-vendor.txt contains Ethernet MAC to vendor string mappings for arp-scan. It is used in addition to the IEEE OUI listings in ieee-oui.txt. It is for MAC-vendor mappings that are not covered by the IEEE manufacturer listings.

Each line in the mac-vendor.txt file contains a MAC-vendor mapping in the form:

<MAC-Prefix><TAB><Vendor>

Where <MAC-Prefix> is the prefix of the MAC address in hex, and <Vendor> is the name of the vendor. The prefix can be of any length from two hex digits (one octet) to twelve hex digits (six octets, the entire Ethernet hardware address).

Alphabetic hex characters [A-F] may use either upper or lower case, and seperator symbols such as “:”, “-” and “.” are ignored. This permits the use of standard format MAC addresses in this file.

For example:

01:23:45 matches 01:23:45:xx:xx:xx, where xx represents any value;
01:23:45:6 matches 01:23:45:6x:xx:xx; and
01:23:45:67 matches 01:23:45:67:xx:xx.

Do not include entries from the IEEE OUI listings, as these are already in the file ieee-oui.txt, which is automatically used by arp-scan. See get-oui(1) for details of how to update the OUI listings.

The order of entries in the file is not important.

Blank lines and lines beginning with “#” are ignored. arp-scan will attempt to match larger prefixes before trying to match smaller ones, and will stop at the first match.

FILES

/usr/local/share/arp-scan/mac-vendor.txt

EXAMPLE

# From nmap Debian bug report #369681 dated 31 May 2006
52:54:00        QEMU
b0:c4:20        Bochs

# From RFC 2338: 00-00-5E-00-01-{VRID}
00:00:5e:00:01  VRRP (last octet is VRID)

# Microsoft WLBS (Windows NT Load Balancing Service)
# http://www.microsoft.com/technet/prodtechnol/acs/reskit/acrkappb.mspx
02:bf   Microsoft WLBS (last four octets are IP address)

# Cisco HSRP (Hot Standby Routing Protocol)
# 00-00-0c-07-ac-XX, where XX is the HSRP group number (0 to 255)
00:00:0c:07:ac  HSRP (last octet is group number)

168 - Linux cli command org.bluez.AdminPolicySet

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.AdminPolicySet and provides detailed information about the command org.bluez.AdminPolicySet, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.AdminPolicySet.

NAME 🖥️ org.bluez.AdminPolicySet 🖥️

BlueZ D-Bus AdminPolicySet API documentation

DESCRIPTION

This API provides methods to control the behavior of bluetoothd(8) as an administrator.

Interface AdminPolicySet1 provides methods to set policies. Once the policy is set successfully, it will affect all clients and stay persistently even after restarting bluetoothd(8). The only way to clear it is to overwrite the policy with the same method.

INTERFACE

Service
org.bluez
Interface
org.bluez.AdminPolicySet1 [experimental]
Object path
[variable prefix]/{hci0,hci1,…}

Methods

void SetServiceAllowList(array{string} UUIDs)

Sets the service allowlist by specifying service UUIDs.
When called, bluetoothd(8) will block incoming and outgoing connections to the service not in UUIDs for all of the clients.
Any subsequent calls to this method will supersede any previously set allowlist values. Calling this method with an empty array will allow any service UUIDs to be used.
The default value is an empty array.
Possible errors:
org.bluez.Error.InvalidArguments
org.bluez.Error.Failed

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

169 - Linux cli command deb-prerm

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command deb-prerm and provides detailed information about the command deb-prerm, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the deb-prerm.

NAME 🖥️ deb-prerm 🖥️

prerm - package pre-removal maintainer script

SYNOPSIS

DEBIAN/prerm

DESCRIPTION

A package can perform several pre-removal actions via maintainer scripts, by including an executable prerm file in its control archive (i.e. DEBIAN/prerm during package creation).

The script can be called in the following ways:

prerm remove
Before the package is removed.

old-prerm upgrade new-version
Before an upgrade.

new-prerm failed-upgrade old-version new-version
If the above upgrade fails. The new-version is passed only since dpkg 1.18.5.

prerm deconfigure in-favour new-package new-version

[ removing old-package old-version ]

Before package is deconfigured while dependency is replaced due to conflict.

prerm remove in-favour new-package new-version
Before the package is replaced due to conflict.

170 - Linux cli command modprobe.d

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command modprobe.d and provides detailed information about the command modprobe.d, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the modprobe.d.

NAME 🖥️ modprobe.d 🖥️

Configuration directory for modprobe

SYNOPSIS

/lib/modprobe.d/*.conf

/usr/lib/modprobe.d/*.conf

/usr/local/lib/modprobe.d/*.conf

/run/modprobe.d/*.conf

/etc/modprobe.d/*.conf

DESCRIPTION

Because the modprobe command can add or remove more than one module, due to modules having dependencies, we need a method of specifying what options are to be used with those modules. All files underneath the /etc/modprobe.d directory which end with the .conf extension specify those options as required. They can also be used to create convenient aliases: alternate names for a module, or they can override the normal modprobe behavior altogether for those with special requirements (such as inserting more than one module).

Note that module and alias names (like other module names) can have - or _ in them: both are interchangeable throughout all the module commands as underscore conversion happens automatically.

The format of files under modprobe.d is simple: one command per line, with blank lines and lines starting with # ignored (useful for adding comments). A \ at the end of a line causes it to continue on the next line, which makes the file a bit neater.

COMMANDS

alias wildcard modulename

This allows you to give alternate names for a module. For example: “alias my-mod really_long_modulename” means you can use “modprobe my-mod” instead of “modprobe really_long_modulename”. You can also use shell-style wildcards, so “alias my-mod* really_long_modulename” means that “modprobe my-mod-something” has the same effect. You cant have aliases to other aliases (that way lies madness), but aliases can have options, which will be added to any other options.
Note that modules can also contain their own aliases, which you can see using modinfo. These aliases are used as a last resort (ie. if there is no real module, install, remove, or alias command in the configuration).

blacklist modulename

Modules can contain their own aliases: usually these are aliases describing the devices they support, such as “pci:123…”. These “internal” aliases can be overridden by normal “alias” keywords, but there are cases where two or more modules both support the same devices, or a module invalidly claims to support a device that it does not: the blacklist keyword indicates that all of that particular modules internal aliases are to be ignored.

install modulename command…

This command instructs modprobe to run your command instead of inserting the module in the kernel as normal. The command can be any shell command: this allows you to do any kind of complex processing you might wish. For example, if the module “fred” works better with the module “barney” already installed (but it doesnt depend on it, so modprobe wont automatically load it), you could say “install fred /sbin/modprobe barney; /sbin/modprobe –ignore-install fred”, which would do what you wanted. Note the –ignore-install, which stops the second modprobe from running the same install command again. See also remove below.
The long term future of this command as a solution to the problem of providing additional module dependencies is not assured and it is intended to replace this command with a warning about its eventual removal or deprecation at some point in a future release. Its use complicates the automated determination of module dependencies by distribution utilities, such as mkinitrd (because these now need to somehow interpret what the install commands might be doing. In a perfect world, modules would provide all dependency information without the use of this command and work is underway to implement soft dependency support within the Linux kernel.
If you use the string “$CMDLINE_OPTS” in the command, it will be replaced by any options specified on the modprobe command line. This can be useful because users expect “modprobe fred opt=1” to pass the “opt=1” arg to the module, even if theres an install command in the configuration file. So our above example becomes “install fred /sbin/modprobe barney; /sbin/modprobe –ignore-install fred $CMDLINE_OPTS”

options modulename option…

This command allows you to add options to the module modulename (which might be an alias) every time it is inserted into the kernel: whether directly (using modprobe modulename) or because the module being inserted depends on this module.
All options are added together: they can come from an option for the module itself, for an alias, and on the command line.

remove modulename command…

This is similar to the install command above, except it is invoked when “modprobe -r” is run.

softdep modulename pre: modules… post: modules…

The softdep command allows you to specify soft, or optional, module dependencies. modulename can be used without these optional modules installed, but usually with some features missing. For example, a driver for a storage HBA might require another module be loaded in order to use management features.
pre-deps and post-deps modules are lists of names and/or aliases of other modules that modprobe will attempt to install (or remove) in order before and after the main module given in the modulename argument.
Example: Assume “softdep c pre: a b post: d e” is provided in the configuration. Running “modprobe c” is now equivalent to “modprobe a b c d e” without the softdep. Flags such as –use-blacklist are applied to all the specified modules, while module parameters only apply to module c.
Note: if there are install or remove commands with the same modulename argument, softdep takes precedence.

weakdep modulename modules…

The weakdep command allows you to specify weak module dependencies. Those are similar to pre softdep, with the difference that userspace doesnt attempt to load that dependency before the specified module. Instead the kernel may request one or multiple of them during module probe, depending on the hardware its binding to. The purpose of weak module is to allow a driver to specify that a certain dependency may be needed, so it should be present in the filesystem (e.g. in initramfs) when that module is probed.
Example: Assume “weakdep c a b”. A program creating an initramfs knows it should add a, b, and c to the filesystem since a and b may be required/desired at runtime. When c is loaded and is being probed, it may issue calls to request_module() causing a or b to also be loaded.

COMPATIBILITY

A future version of kmod will come with a strong warning to avoid use of the install as explained above. This will happen once support for soft dependencies in the kernel is complete. That support will complement the existing softdep support within this utility by providing such dependencies directly within the modules.

COPYRIGHT

AUTHORS

Jon Masters <[email protected]>

Developer

Robby Workman <[email protected]>

Developer

Lucas De Marchi <[email protected]>

Developer

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

171 - Linux cli command proc_pid_cgroup

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_cgroup and provides detailed information about the command proc_pid_cgroup, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_cgroup.

NAME 🖥️ proc_pid_cgroup 🖥️

control group

DESCRIPTION

/proc/pid/cgroup (since Linux 2.6.24)
See cgroups(7).

172 - Linux cli command rsyncd.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command rsyncd.conf and provides detailed information about the command rsyncd.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the rsyncd.conf.

NAME 🖥️ rsyncd.conf 🖥️

configuration file for rsync in daemon mode

SYNOPSIS

rsyncd.conf

The online version of this manpage (that includes cross-linking of topics) is available at .

DESCRIPTION

The rsyncd.conf file is the runtime configuration file for rsync when run as an rsync daemon.

The rsyncd.conf file controls authentication, access, logging and available modules.

FILE FORMAT

The file consists of modules and parameters. A module begins with the name of the module in square brackets and continues until the next module begins. Modules contain parameters of the form name = value.

The file is line-based – that is, each newline-terminated line represents either a comment, a module name or a parameter.

Only the first equals sign in a parameter is significant. Whitespace before or after the first equals sign is discarded. Leading, trailing and internal whitespace in module and parameter names is irrelevant. Leading and trailing whitespace in a parameter value is discarded. Internal whitespace within a parameter value is retained verbatim.

Any line beginning with a hash (#) is ignored, as are lines containing only whitespace. (If a hash occurs after anything other than leading whitespace, it is considered a part of the line’s content.)

Any line ending in a ** is “continued” on the next line in the customary UNIX fashion.

The values following the equals sign in parameters are all either a string (no quotes needed) or a boolean, which may be given as yes/no, 0/1 or true/false. Case is not significant in boolean values, but is preserved in string values.

LAUNCHING THE RSYNC DAEMON

The rsync daemon is launched by specifying the –daemon option to rsync.

The daemon must run with root privileges if you wish to use chroot, to bind to a port numbered under 1024 (as is the default 873), or to set file ownership. Otherwise, it must just have permission to read and write the appropriate data, log, and lock files.

You can launch it either via inetd, as a stand-alone daemon, or from an rsync client via a remote shell. If run as a stand-alone daemon then just run the command “rsync –daemon” from a suitable startup script.

When run via inetd you should add a line like this to /etc/services:

rsync 873/tcp

and a single line something like this to /etc/inetd.conf:

rsync stream tcp nowait root /usr/bin/rsync rsyncd –daemon

Replace “/usr/bin/rsync” with the path to where you have rsync installed on your system. You will then need to send inetd a HUP signal to tell it to reread its config file.

Note that you should not send the rsync daemon a HUP signal to force it to reread the rsyncd.conf file. The file is re-read on each client connection.

GLOBAL PARAMETERS

The first parameters in the file (before a [module] header) are the global parameters:

motd file
This parameter allows you to specify a “message of the day” (MOTD) to display to clients on each connect. This usually contains site information and any legal notices. The default is no MOTD file. This can be overridden by the –dparam=motdfile=FILE command-line option when starting the daemon.

pid file
This parameter tells the rsync daemon to write its process ID to that file. The rsync keeps the file locked so that it can know when it is safe to overwrite an existing file.

The filename can be overridden by the –dparam=pidfile=FILE command-line option when starting the daemon.

port
You can override the default port the daemon will listen on by specifying this value (defaults to 873). This is ignored if the daemon is being run by inetd, and is superseded by the –port command-line option.

address
You can override the default IP address the daemon will listen on by specifying this value. This is ignored if the daemon is being run by inetd, and is superseded by the –address command-line option.

socket options
This parameter can provide endless fun for people who like to tune their systems to the utmost degree. You can set all sorts of socket options which may make transfers faster (or slower!). Read the manpage for the setsockopt() system call for details on some of the options you may be able to set. By default no special socket options are set. These settings can also be specified via the –sockopts command-line option.

listen backlog
You can override the default backlog value when the daemon listens for connections. It defaults to 5.

You may also include any MODULE PARAMETERS in the global part of the config file, in which case the supplied value will override the default for that parameter.

You may use references to environment variables in the values of parameters. String parameters will have %VAR% references expanded as late as possible (when the string is first used in the program), allowing for the use of variables that rsync sets at connection time, such as RSYNC_USER_NAME. Non-string parameters (such as true/false settings) are expanded when read from the config file. If a variable does not exist in the environment, or if a sequence of characters is not a valid reference (such as an un-paired percent sign), the raw characters are passed through unchanged. This helps with backward compatibility and safety (e.g. expanding a non-existent %VAR% to an empty string in a path could result in a very unsafe path). The safest way to insert a literal % into a value is to use %%.

MODULE PARAMETERS

After the global parameters you should define a number of modules, each module exports a directory tree as a symbolic name. Modules are exported by specifying a module name in square brackets [module] followed by the parameters for that module. The module name cannot contain a slash or a closing square bracket. If the name contains whitespace, each internal sequence of whitespace will be changed into a single space, while leading or trailing whitespace will be discarded.

There is also a special module name of “[global]” that does not define a module but instead switches back to the global settings context where default parameters can be specified. Because each defined module gets its full set of parameters as a combination of the default values that are set at that position in the config file plus its own parameter list, the use of a “[global]” section can help to maintain shared config values for multiple modules.

As with GLOBAL PARAMETERS, you may use references to environment variables in the values of parameters. See that section for details.

comment
This parameter specifies a description string that is displayed next to the module name when clients obtain a list of available modules. The default is no comment.

path
This parameter specifies the directory in the daemon’s filesystem to make available in this module. You must specify this parameter for each module in rsyncd.conf.

If the value contains a “/./” element then the path will be divided at that point into a chroot dir and an inner-chroot subdir. If use chroot is set to false, though, the extraneous dot dir is just cleaned out of the path. An example of this idiom is:

path = /var/rsync/./module1

This will (when chrooting) chroot to “/var/rsync” and set the inside-chroot path to “/module1”.

You may base the path’s value off of an environment variable by surrounding the variable name with percent signs. You can even reference a variable that is set by rsync when the user connects. For example, this would use the authorizing user’s name in the path:

path = /home/%RSYNC_USER_NAME%

It is fine if the path includes internal spaces – they will be retained verbatim (which means that you shouldn’t try to escape them). If your final directory has a trailing space (and this is somehow not something you wish to fix), append a trailing slash to the path to avoid losing the trailing whitespace.

use chroot
If “use chroot” is true, the rsync daemon will chroot to the “path” before starting the file transfer with the client. This has the advantage of extra protection against possible implementation security holes, but it has the disadvantages of requiring super-user privileges, of not being able to follow symbolic links that are either absolute or outside of the new root path, and of complicating the preservation of users and groups by name (see below).

If use chroot is not set, it defaults to trying to enable a chroot but allows the daemon to continue (after logging a warning) if it fails. The one exception to this is when a module’s path has a “/./” chroot divider in it – this causes an unset value to be treated as true for that module.

Prior to rsync 3.2.7, the default value was “true”. The new “unset” default makes it easier to setup an rsync daemon as a non-root user or to run a daemon on a system where chroot fails. Explicitly setting the value to “true” in rsyncd.conf will always require the chroot to succeed.

It is also possible to specify a dot-dir in the module’s “path” to indicate that you want to chdir to the earlier part of the path and then serve files from inside the latter part of the path (with sanitizing and default symlink munging). This can be useful if you need some library dirs inside the chroot (typically for uid & gid lookups) but don’t want to put the lib dir into the top of the served path (even though they can be hidden with an exclude directive). However, a better choice for a modern rsync setup is to use a name converter" and try to avoid inner lib dirs altogether. See also the daemon chroot parameter, which causes rsync to chroot into its own chroot area before doing any path-related chrooting.

If the daemon is serving the “/” dir (either directly or due to being chrooted to the module’s path), rsync does not do any path sanitizing or (default) munging.

When it has to limit access to a particular subdir (either due to chroot being disabled or having an inside-chroot path set), rsync will munge symlinks (by default) and sanitize paths. Those that dislike munged symlinks (and really, really trust their users to not break out of the subdir) can disable the symlink munging via the “munge symlinks” parameter.

When rsync is sanitizing paths, it trims “..” path elements from args that it believes would escape the module hierarchy. It also substitutes leading slashes in absolute paths with the module’s path (so that options such as –backup-dir & –compare-dest interpret an absolute path as rooted in the module’s “path” dir).

When a chroot is in effect and the “name converter” parameter is not set, the “numeric ids” parameter will default to being enabled (disabling name lookups). This means that if you manually setup name-lookup libraries in your chroot (instead of using a name converter) that you need to explicitly set numeric ids = false for rsync to do name lookups.

If you copy library resources into the module’s chroot area, you should protect them through your OS’s normal user/group or ACL settings (to prevent the rsync module’s user from being able to change them), and then hide them from the user’s view via “exclude” (see how in the discussion of that parameter). However, it’s easier and safer to setup a name converter.

daemon chroot
This parameter specifies a path to which the daemon will chroot before beginning communication with clients. Module paths (and any “use chroot” settings) will then be related to this one. This lets you choose if you want the whole daemon to be chrooted (with this setting), just the transfers to be chrooted (with “use chroot”), or both. Keep in mind that the “daemon chroot” area may need various OS/lib/etc files installed to allow the daemon to function. By default the daemon runs without any chrooting.

proxy protocol
When this parameter is enabled, all incoming connections must start with a V1 or V2 proxy protocol header. If the header is not found, the connection is closed.

Setting this to true requires a proxy server to forward source IP information to rsync, allowing you to log proper IP/host info and make use of client-oriented IP restrictions. The default of false means that the IP information comes directly from the socket’s metadata. If rsync is not behind a proxy, this should be disabled.

CAUTION: using this option can be dangerous if you do not ensure that only the proxy is allowed to connect to the rsync port. If any non-proxied connections are allowed through, the client will be able to use a modified rsync to spoof any remote IP address that they desire. You can lock this down using something like iptables -uid-owner root rules (for strict localhost access), various firewall rules, or you can require password authorization so that any spoofing by users will not grant extra access.

This setting is global. If you need some modules to require this and not others, then you will need to setup multiple rsync daemon processes on different ports.

name converter
This parameter lets you specify a program that will be run by the rsync daemon to do user & group conversions between names & ids. This script is started prior to any chroot being setup, and runs as the daemon user (not the transfer user). You can specify a fully qualified pathname or a program name that is on the $PATH.

The program can be used to do normal user & group lookups without having to put any extra files into the chroot area of the module or you can do customized conversions.

The nameconvert program has access to all of the environment variables that are described in the section on pre-xfer exec. This is useful if you want to customize the conversion using information about the module and/or the copy request.

There is a sample python script in the support dir named “nameconvert” that implements the normal user & group lookups. Feel free to customize it or just use it as documentation to implement your own.

numeric ids
Enabling this parameter disables the mapping of users and groups by name for the current daemon module. This prevents the daemon from trying to load any user/group-related files or libraries. This enabling makes the transfer behave as if the client had passed the –numeric-ids command-line option. By default, this parameter is enabled for chroot modules and disabled for non-chroot modules. Also keep in mind that uid/gid preservation requires the module to be running as root (see “uid”) or for “fake super” to be configured.

A chroot-enabled module should not have this parameter set to false unless you’re using a “name converter” program or you’ve taken steps to ensure that the module has the necessary resources it needs to translate names and that it is not possible for a user to change those resources.

munge symlinks
This parameter tells rsync to modify all symlinks in the same way as the (non-daemon-affecting) –munge-links command-line option (using a method described below). This should help protect your files from user trickery when your daemon module is writable. The default is disabled when “use chroot” is on with an inside-chroot path of “/”, OR if “daemon chroot” is on, otherwise it is enabled.

If you disable this parameter on a daemon that is not read-only, there are tricks that a user can play with uploaded symlinks to access daemon-excluded items (if your module has any), and, if “use chroot” is off, rsync can even be tricked into showing or changing data that is outside the module’s path (as access-permissions allow).

The way rsync disables the use of symlinks is to prefix each one with the string “/rsyncd-munged/”. This prevents the links from being used as long as that directory does not exist. When this parameter is enabled, rsync will refuse to run if that path is a directory or a symlink to a directory. When using the “munge symlinks” parameter in a chroot area that has an inside-chroot path of “/”, you should add “/rsyncd-munged/” to the exclude setting for the module so that a user can’t try to create it.

Note: rsync makes no attempt to verify that any pre-existing symlinks in the module’s hierarchy are as safe as you want them to be (unless, of course, it just copied in the whole hierarchy). If you setup an rsync daemon on a new area or locally add symlinks, you can manually protect your symlinks from being abused by prefixing “/rsyncd-munged/” to the start of every symlink’s value. There is a perl script in the support directory of the source code named “munge-symlinks” that can be used to add or remove this prefix from your symlinks.

When this parameter is disabled on a writable module and “use chroot” is off (or the inside-chroot path is not “/”), incoming symlinks will be modified to drop a leading slash and to remove “..” path elements that rsync believes will allow a symlink to escape the module’s hierarchy. There are tricky ways to work around this, though, so you had better trust your users if you choose this combination of parameters.

charset
This specifies the name of the character set in which the module’s filenames are stored. If the client uses an –iconv option, the daemon will use the value of the “charset” parameter regardless of the character set the client actually passed. This allows the daemon to support charset conversion in a chroot module without extra files in the chroot area, and also ensures that name-translation is done in a consistent manner. If the “charset” parameter is not set, the –iconv option is refused, just as if “iconv” had been specified via “refuse options”.

If you wish to force users to always use –iconv for a particular module, add “no-iconv” to the “refuse options” parameter. Keep in mind that this will restrict access to your module to very new rsync clients.

max connections
This parameter allows you to specify the maximum number of simultaneous connections you will allow. Any clients connecting when the maximum has been reached will receive a message telling them to try later. The default is 0, which means no limit. A negative value disables the module. See also the “lock file” parameter.

log file
When the “log file” parameter is set to a non-empty string, the rsync daemon will log messages to the indicated file rather than using syslog. This is particularly useful on systems (such as AIX) where syslog() doesn’t work for chrooted programs. The file is opened before chroot() is called, allowing it to be placed outside the transfer. If this value is set on a per-module basis instead of globally, the global log will still contain any authorization failures or config-file error messages.

If the daemon fails to open the specified file, it will fall back to using syslog and output an error about the failure. (Note that the failure to open the specified log file used to be a fatal error.)

This setting can be overridden by using the –log-file=FILE or –dparam=logfile=FILE command-line options. The former overrides all the log-file parameters of the daemon and all module settings. The latter sets the daemon’s log file and the default for all the modules, which still allows modules to override the default setting.

syslog facility
This parameter allows you to specify the syslog facility name to use when logging messages from the rsync daemon. You may use any standard syslog facility name which is defined on your system. Common names are auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, security, syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6 and local7. The default is daemon. This setting has no effect if the “log file” setting is a non-empty string (either set in the per-modules settings, or inherited from the global settings).

syslog tag
This parameter allows you to specify the syslog tag to use when logging messages from the rsync daemon. The default is “rsyncd”. This setting has no effect if the “log file” setting is a non-empty string (either set in the per-modules settings, or inherited from the global settings).

For example, if you wanted each authenticated user’s name to be included in the syslog tag, you could do something like this:

syslog tag = rsyncd.%RSYNC_USER_NAME%

max verbosity
This parameter allows you to control the maximum amount of verbose information that you’ll allow the daemon to generate (since the information goes into the log file). The default is 1, which allows the client to request one level of verbosity.

This also affects the user’s ability to request higher levels of –info and –debug logging. If the max value is 2, then no info and/or debug value that is higher than what would be set by -vv will be honored by the daemon in its logging. To see how high of a verbosity level you need to accept for a particular info/debug level, refer to rsync –info=help and rsync –debug=help. For instance, it takes max-verbosity 4 to be able to output debug TIME2 and FLIST3.

lock file
This parameter specifies the file to use to support the “max connections” parameter. The rsync daemon uses record locking on this file to ensure that the max connections limit is not exceeded for the modules sharing the lock file. The default is /var/run/rsyncd.lock.

read only
This parameter determines whether clients will be able to upload files or not. If “read only” is true then any attempted uploads will fail. If “read only” is false then uploads will be possible if file permissions on the daemon side allow them. The default is for all modules to be read only.

Note that “auth users” can override this setting on a per-user basis.

write only
This parameter determines whether clients will be able to download files or not. If “write only” is true then any attempted downloads will fail. If “write only” is false then downloads will be possible if file permissions on the daemon side allow them. The default is for this parameter to be disabled.

Helpful hint: you probably want to specify “refuse options = delete” for a write-only module.

open noatime
When set to True, this parameter tells the rsync daemon to open files with the O_NOATIME flag (on systems that support it) to avoid changing the access time of the files that are being transferred. If your OS does not support the O_NOATIME flag then rsync will silently ignore this option. Note also that some filesystems are mounted to avoid updating the atime on read access even without the O_NOATIME flag being set.

When set to False, this parameters ensures that files on the server are not opened with O_NOATIME.

When set to Unset (the default) the user controls the setting via –open-noatime.

list
This parameter determines whether this module is listed when the client asks for a listing of available modules. In addition, if this is false, the daemon will pretend the module does not exist when a client denied by “hosts allow” or “hosts deny” attempts to access it. Realize that if “reverse lookup” is disabled globally but enabled for the module, the resulting reverse lookup to a potentially client-controlled DNS server may still reveal to the client that it hit an existing module. The default is for modules to be listable.

uid
This parameter specifies the user name or user ID that file transfers to and from that module should take place as when the daemon was run as root. In combination with the “gid” parameter this determines what file permissions are available. The default when run by a super-user is to switch to the system’s “nobody” user. The default for a non-super-user is to not try to change the user. See also the “gid” parameter.

The RSYNC_USER_NAME environment variable may be used to request that rsync run as the authorizing user. For example, if you want a rsync to run as the same user that was received for the rsync authentication, this setup is useful:

uid = %RSYNC_USER_NAME%
gid = *

gid
This parameter specifies one or more group names/IDs that will be used when accessing the module. The first one will be the default group, and any extra ones be set as supplemental groups. You may also specify a “*” as the first gid in the list, which will be replaced by all the normal groups for the transfer’s user (see “uid”). The default when run by a super-user is to switch to your OS’s “nobody” (or perhaps “nogroup”) group with no other supplementary groups. The default for a non-super-user is to not change any group attributes (and indeed, your OS may not allow a non-super-user to try to change their group settings).

The specified list is normally split into tokens based on spaces and commas. However, if the list starts with a comma, then the list is only split on commas, which allows a group name to contain a space. In either case any leading and/or trailing whitespace is removed from the tokens and empty tokens are ignored.

daemon uid
This parameter specifies a uid under which the daemon will run. The daemon usually runs as user root, and when this is left unset the user is left unchanged. See also the “uid” parameter.

daemon gid
This parameter specifies a gid under which the daemon will run. The daemon usually runs as group root, and when this is left unset, the group is left unchanged. See also the “gid” parameter.

fake super
Setting “fake super = yes” for a module causes the daemon side to behave as if the –fake-super command-line option had been specified. This allows the full attributes of a file to be stored without having to have the daemon actually running as root.

filter
The daemon has its own filter chain that determines what files it will let the client access. This chain is not sent to the client and is independent of any filters the client may have specified. Files excluded by the daemon filter chain (daemon-excluded files) are treated as non-existent if the client tries to pull them, are skipped with an error message if the client tries to push them (triggering exit code 23), and are never deleted from the module. You can use daemon filters to prevent clients from downloading or tampering with private administrative files, such as files you may add to support uid/gid name translations.

The daemon filter chain is built from the “filter”, “include from”, “include”, “exclude from”, and “exclude” parameters, in that order of priority. Anchored patterns are anchored at the root of the module. To prevent access to an entire subtree, for example, “/secret”, you must exclude everything in the subtree; the easiest way to do this is with a triple-star pattern like “/secret/***”.

The “filter” parameter takes a space-separated list of daemon filter rules, though it is smart enough to know not to split a token at an internal space in a rule (e.g. “- /foo - /bar” is parsed as two rules). You may specify one or more merge-file rules using the normal syntax. Only one “filter” parameter can apply to a given module in the config file, so put all the rules you want in a single parameter. Note that per-directory merge-file rules do not provide as much protection as global rules, but they can be used to make –delete work better during a client download operation if the per-dir merge files are included in the transfer and the client requests that they be used.

exclude
This parameter takes a space-separated list of daemon exclude patterns. As with the client –exclude option, patterns can be qualified with “- " or “+ " to explicitly indicate exclude/include. Only one “exclude” parameter can apply to a given module. See the “filter” parameter for a description of how excluded files affect the daemon.

include
Use an “include” to override the effects of the “exclude” parameter. Only one “include” parameter can apply to a given module. See the “filter” parameter for a description of how excluded files affect the daemon.

exclude from
This parameter specifies the name of a file on the daemon that contains daemon exclude patterns, one per line. Only one “exclude from” parameter can apply to a given module; if you have multiple exclude-from files, you can specify them as a merge file in the “filter” parameter. See the “filter” parameter for a description of how excluded files affect the daemon.

include from
Analogue of “exclude from” for a file of daemon include patterns. Only one “include from” parameter can apply to a given module. See the “filter” parameter for a description of how excluded files affect the daemon.

incoming chmod
This parameter allows you to specify a set of comma-separated chmod strings that will affect the permissions of all incoming files (files that are being received by the daemon). These changes happen after all other permission calculations, and this will even override destination-default and/or existing permissions when the client does not specify –perms. See the description of the –chmod rsync option and the chmod(1) manpage for information on the format of this string.

outgoing chmod
This parameter allows you to specify a set of comma-separated chmod strings that will affect the permissions of all outgoing files (files that are being sent out from the daemon). These changes happen first, making the sent permissions appear to be different than those stored in the filesystem itself. For instance, you could disable group write permissions on the server while having it appear to be on to the clients. See the description of the –chmod rsync option and the chmod(1) manpage for information on the format of this string.

auth users
This parameter specifies a comma and/or space-separated list of authorization rules. In its simplest form, you list the usernames that will be allowed to connect to this module. The usernames do not need to exist on the local system. The rules may contain shell wildcard characters that will be matched against the username provided by the client for authentication. If “auth users” is set then the client will be challenged to supply a username and password to connect to the module. A challenge response authentication protocol is used for this exchange. The plain text usernames and passwords are stored in the file specified by the “secrets file” parameter. The default is for all users to be able to connect without a password (this is called “anonymous rsync”).

In addition to username matching, you can specify groupname matching via a ‘@’ prefix. When using groupname matching, the authenticating username must be a real user on the system, or it will be assumed to be a member of no groups. For example, specifying “@rsync” will match the authenticating user if the named user is a member of the rsync group.

Finally, options may be specified after a colon (:). The options allow you to “deny” a user or a group, set the access to “ro” (read-only), or set the access to “rw” (read/write). Setting an auth-rule-specific ro/rw setting overrides the module’s “read only” setting.

Be sure to put the rules in the order you want them to be matched, because the checking stops at the first matching user or group, and that is the only auth that is checked. For example:

auth users = joe:deny @guest:deny admin:rw @rsync:ro susan joe sam

In the above rule, user joe will be denied access no matter what. Any user that is in the group “guest” is also denied access. The user “admin” gets access in read/write mode, but only if the admin user is not in group “guest” (because the admin user-matching rule would never be reached if the user is in group “guest”). Any other user who is in group “rsync” will get read-only access. Finally, users susan, joe, and sam get the ro/rw setting of the module, but only if the user didn’t match an earlier group-matching rule.

If you need to specify a user or group name with a space in it, start your list with a comma to indicate that the list should only be split on commas (though leading and trailing whitespace will also be removed, and empty entries are just ignored). For example:

auth users = , joe:deny, @Some Group:deny, admin:rw, @RO Group:ro

See the description of the secrets file for how you can have per-user passwords as well as per-group passwords. It also explains how a user can authenticate using their user password or (when applicable) a group password, depending on what rule is being authenticated.

See also the section entitled “USING RSYNC-DAEMON FEATURES VIA A REMOTE SHELL CONNECTION” in rsync(1) for information on how handle an rsyncd.conf-level username that differs from the remote-shell-level username when using a remote shell to connect to an rsync daemon.

secrets file
This parameter specifies the name of a file that contains the username:password and/or @groupname:password pairs used for authenticating this module. This file is only consulted if the “auth users” parameter is specified. The file is line-based and contains one name:password pair per line. Any line has a hash (#) as the very first character on the line is considered a comment and is skipped. The passwords can contain any characters but be warned that many operating systems limit the length of passwords that can be typed at the client end, so you may find that passwords longer than 8 characters don’t work.

The use of group-specific lines are only relevant when the module is being authorized using a matching “@groupname” rule. When that happens, the user can be authorized via either their “username:password” line or the “@groupname:password” line for the group that triggered the authentication.

It is up to you what kind of password entries you want to include, either users, groups, or both. The use of group rules in “auth users” does not require that you specify a group password if you do not want to use shared passwords.

There is no default for the “secrets file” parameter, you must choose a name (such as /etc/rsyncd.secrets). The file must normally not be readable by “other”; see “strict modes”. If the file is not found or is rejected, no logins for an “auth users” module will be possible.

strict modes
This parameter determines whether or not the permissions on the secrets file will be checked. If “strict modes” is true, then the secrets file must not be readable by any user ID other than the one that the rsync daemon is running under. If “strict modes” is false, the check is not performed. The default is true. This parameter was added to accommodate rsync running on the Windows operating system.

hosts allow
This parameter allows you to specify a list of comma- and/or whitespace-separated patterns that are matched against a connecting client’s hostname and IP address. If none of the patterns match, then the connection is rejected.

Each pattern can be in one of six forms:

a dotted decimal IPv4 address of the form a.b.c.d, or an IPv6 address of the form a:b:c::d:e:f. In this case the incoming machine’s IP address must match exactly.
an address/mask in the form ipaddr/n where ipaddr is the IP address and n is the number of one bits in the netmask. All IP addresses which match the masked IP address will be allowed in.
an address/mask in the form ipaddr/maskaddr where ipaddr is the IP address and maskaddr is the netmask in dotted decimal notation for IPv4, or similar for IPv6, e.g. ffff:ffff:ffff:ffff:: instead of /64. All IP addresses which match the masked IP address will be allowed in.
a hostname pattern using wildcards. If the hostname of the connecting IP (as determined by a reverse lookup) matches the wildcarded name (using the same rules as normal Unix filename matching), the client is allowed in. This only works if “reverse lookup” is enabled (the default).
a hostname. A plain hostname is matched against the reverse DNS of the connecting IP (if “reverse lookup” is enabled), and/or the IP of the given hostname is matched against the connecting IP (if “forward lookup” is enabled, as it is by default). Any match will be allowed in.
an ‘@’ followed by a netgroup name, which will match if the reverse DNS of the connecting IP is in the specified netgroup.

Note IPv6 link-local addresses can have a scope in the address specification:

fe80::1%link1 fe80::%link1/64 fe80::%link1/ffff:ffff:ffff:ffff::

You can also combine “hosts allow” with “hosts deny” as a way to add exceptions to your deny list. When both parameters are specified, the “hosts allow” parameter is checked first and a match results in the client being able to connect. A non-allowed host is then matched against the “hosts deny” list to see if it should be rejected. A host that does not match either list is allowed to connect.

The default is no “hosts allow” parameter, which means all hosts can connect.

hosts deny
This parameter allows you to specify a list of comma- and/or whitespace-separated patterns that are matched against a connecting clients hostname and IP address. If the pattern matches then the connection is rejected. See the “hosts allow” parameter for more information.

The default is no “hosts deny” parameter, which means all hosts can connect.

reverse lookup
Controls whether the daemon performs a reverse lookup on the client’s IP address to determine its hostname, which is used for “hosts allow” & “hosts deny” checks and the “%h” log escape. This is enabled by default, but you may wish to disable it to save time if you know the lookup will not return a useful result, in which case the daemon will use the name “UNDETERMINED” instead.

If this parameter is enabled globally (even by default), rsync performs the lookup as soon as a client connects, so disabling it for a module will not avoid the lookup. Thus, you probably want to disable it globally and then enable it for modules that need the information.

forward lookup
Controls whether the daemon performs a forward lookup on any hostname specified in an hosts allow/deny setting. By default this is enabled, allowing the use of an explicit hostname that would not be returned by reverse DNS of the connecting IP.

ignore errors
This parameter tells rsyncd to ignore I/O errors on the daemon when deciding whether to run the delete phase of the transfer. Normally rsync skips the –delete step if any I/O errors have occurred in order to prevent disastrous deletion due to a temporary resource shortage or other I/O error. In some cases this test is counter productive so you can use this parameter to turn off this behavior.

ignore nonreadable
This tells the rsync daemon to completely ignore files that are not readable by the user. This is useful for public archives that may have some non-readable files among the directories, and the sysadmin doesn’t want those files to be seen at all.

transfer logging
This parameter enables per-file logging of downloads and uploads in a format somewhat similar to that used by ftp daemons. The daemon always logs the transfer at the end, so if a transfer is aborted, no mention will be made in the log file.

If you want to customize the log lines, see the “log format” parameter.

log format
This parameter allows you to specify the format used for logging file transfers when transfer logging is enabled. The format is a text string containing embedded single-character escape sequences prefixed with a percent (%) character. An optional numeric field width may also be specified between the percent and the escape letter (e.g. “%-50n %8l %07p”). In addition, one or more apostrophes may be specified prior to a numerical escape to indicate that the numerical value should be made more human-readable. The 3 supported levels are the same as for the –human-readable command-line option, though the default is for human-readability to be off. Each added apostrophe increases the level (e.g. “%‘’l %‘b %f”).

The default log format is “%o %h [%a] %m (%u) %f %l”, and a “%t [%p] " is always prefixed when using the “log file” parameter. (A perl script that will summarize this default log format is included in the rsync source code distribution in the “support” subdirectory: rsyncstats.)

The single-character escapes that are understood are as follows:

%a the remote IP address (only available for a daemon)
%b the number of bytes actually transferred
%B the permission bits of the file (e.g. rwxrwxrwt)
%c the total size of the block checksums received for the basis file (only when sending)
%C the full-file checksum if it is known for the file. For older rsync protocols/versions, the checksum was salted, and is thus not a useful value (and is not displayed when that is the case). For the checksum to output for a file, either the –checksum option must be in-effect or the file must have been transferred without a salted checksum being used. See the –checksum-choice option for a way to choose the algorithm.
%f the filename (long form on sender; no trailing “/”)
%G the gid of the file (decimal) or “DEFAULT”
%h the remote host name (only available for a daemon)
%i an itemized list of what is being updated
%l the length of the file in bytes
%L the string " -> SYMLINK”, " => HARDLINK”, or "” (where SYMLINK or HARDLINK is a filename)
%m the module name
%M the last-modified time of the file
%n the filename (short form; trailing “/” on dir)
%o the operation, which is “send”, “recv”, or “del.” (the latter includes the trailing period)
%p the process ID of this rsync session
%P the module path
%t the current date time
%u the authenticated username or an empty string
%U the uid of the file (decimal)

For a list of what the characters mean that are output by “%i”, see the –itemize-changes option in the rsync manpage.

Note that some of the logged output changes when talking with older rsync versions. For instance, deleted files were only output as verbose messages prior to rsync 2.6.4.

timeout
This parameter allows you to override the clients choice for I/O timeout for this module. Using this parameter you can ensure that rsync won’t wait on a dead client forever. The timeout is specified in seconds. A value of zero means no timeout and is the default. A good choice for anonymous rsync daemons may be 600 (giving a 10 minute timeout).

refuse options
This parameter allows you to specify a space-separated list of rsync command-line options that will be refused by your rsync daemon. You may specify the full option name, its one-letter abbreviation, or a wild-card string that matches multiple options. Beginning in 3.2.0, you can also negate a match term by starting it with a “!”.

When an option is refused, the daemon prints an error message and exits.

For example, this would refuse –checksum (-c) and all the various delete options:

refuse options = c delete

The reason the above refuses all delete options is that the options imply –delete, and implied options are refused just like explicit options.

The use of a negated match allows you to fine-tune your refusals after a wild-card, such as this:

refuse options = delete-* !delete-during

Negated matching can also turn your list of refused options into a list of accepted options. To do this, begin the list with a “*” (to refuse all options) and then specify one or more negated matches to accept. For example:

refuse options = * !a !v !compress*

Don’t worry that the “*” will refuse certain vital options such as –dry-run, –server, –no-iconv, –seclude-args, etc. These important options are not matched by wild-card, so they must be overridden by their exact name. For instance, if you’re forcing iconv transfers you could use something like this:

refuse options = * no-iconv !a !v

As an additional aid (beginning in 3.2.0), refusing (or “!refusing”) the “a” or “archive” option also affects all the options that the –archive option implies (-rdlptgoD), but only if the option is matched explicitly (not using a wildcard). If you want to do something tricky, you can use “archive*” to avoid this side-effect, but keep in mind that no normal rsync client ever sends the actual archive option to the server.

As an additional safety feature, the refusal of “delete” also refuses remove-source-files when the daemon is the sender; if you want the latter without the former, instead refuse “delete-*” as that refuses all the delete modes without affecting –remove-source-files. (Keep in mind that the client’s –delete option typically results in –delete-during.)

When un-refusing delete options, you should either specify “!delete*” (to accept all delete options) or specify a limited set that includes “delete”, such as:

refuse options = * !a !delete !delete-during

… whereas this accepts any delete option except –delete-after:

refuse options = * !a !delete* delete-after

A note on refusing “compress”: it may be better to set the “dont compress” daemon parameter to “*” and ensure that RSYNC_COMPRESS_LIST=zlib is set in the environment of the daemon in order to disable compression silently instead of returning an error that forces the client to remove the -z option.

If you are un-refusing the compress option, you may want to match “!compress*” if you also want to allow the –compress-level option.

Note that the “copy-devices” & “write-devices” options are refused by default, but they can be explicitly accepted with “!copy-devices” and/or “!write-devices”. The options “log-file” and “log-file-format” are forcibly refused and cannot be accepted.

Here are all the options that are not matched by wild-cards:

–server: Required for rsync to even work.
–rsh, -e: Required to convey compatibility flags to the server.
–out-format: This is required to convey output behavior to a remote receiver. While rsync passes the older alias –log-format for compatibility reasons, this options should not be confused with –log-file-format.
–sender: Use “write only” parameter instead of refusing this.
–dry-run, -n: Who would want to disable this?
–seclude-args, -s: Is the oldest arg-protection method.
–from0, -0: Makes it easier to accept/refuse –files-from without affecting this helpful modifier.
–iconv: This is auto-disabled based on “charset” parameter.
–no-iconv: Most transfers use this option.
–checksum-seed: Is a fairly rare, safe option.
–write-devices: Is non-wild but also auto-disabled.

dont compress
NOTE: This parameter currently has no effect except in one instance: if it is set to “*” then it minimizes or disables compression for all files (for those that don’t want to refuse the –compress option completely).

This parameter allows you to select filenames based on wildcard patterns that should not be compressed when pulling files from the daemon (no analogous parameter exists to govern the pushing of files to a daemon). Compression can be expensive in terms of CPU usage, so it is usually good to not try to compress files that won’t compress well, such as already compressed files.

The “dont compress” parameter takes a space-separated list of case-insensitive wildcard patterns. Any source filename matching one of the patterns will be compressed as little as possible during the transfer. If the compression algorithm has an “off” level, then no compression occurs for those files. If an algorithms has the ability to change the level in mid-stream, it will be minimized to reduce the CPU usage as much as possible.

See the –skip-compress parameter in the rsync(1) manpage for the list of file suffixes that are skipped by default if this parameter is not set.

early exec, pre-xfer exec, post-xfer exec
You may specify a command to be run in the early stages of the connection, or right before and/or after the transfer. If the early exec or pre-xfer exec command returns an error code, the transfer is aborted before it begins. Any output from the pre-xfer exec command on stdout (up to several KB) will be displayed to the user when aborting, but is not displayed if the script returns success. The other programs cannot send any text to the user. All output except for the pre-xfer exec stdout goes to the corresponding daemon’s stdout/stderr, which is typically discarded. See the –no-detach option for a way to see the daemon’s output, which can assist with debugging.

Note that the early exec command runs before any part of the transfer request is known except for the module name. This helper script can be used to setup a disk mount or decrypt some data into a module dir, but you may need to use lock file and max connections to avoid concurrency issues. If the client rsync specified the –early-input=FILE option, it can send up to about 5K of data to the stdin of the early script. The stdin will otherwise be empty.

Note that the post-xfer exec command is still run even if one of the other scripts returns an error code. The pre-xfer exec command will not be run, however, if the early exec command fails.

The following environment variables will be set, though some are specific to the pre-xfer or the post-xfer environment:

RSYNC_MODULE_NAME: The name of the module being accessed.
RSYNC_MODULE_PATH: The path configured for the module.
RSYNC_HOST_ADDR: The accessing host’s IP address.
RSYNC_HOST_NAME: The accessing host’s name.
RSYNC_USER_NAME: The accessing user’s name (empty if no user).
RSYNC_PID: A unique number for this transfer.
RSYNC_REQUEST: (pre-xfer only) The module/path info specified by the user. Note that the user can specify multiple source files, so the request can be something like “mod/path1 mod/path2”, etc.
RSYNC_ARG#: (pre-xfer only) The pre-request arguments are set in these numbered values. RSYNC_ARG0 is always “rsyncd”, followed by the options that were used in RSYNC_ARG1, and so on. There will be a value of “.” indicating that the options are done and the path args are beginning – these contain similar information to RSYNC_REQUEST, but with values separated and the module name stripped off.
RSYNC_EXIT_STATUS: (post-xfer only) the server side’s exit value. This will be 0 for a successful run, a positive value for an error that the server generated, or a -1 if rsync failed to exit properly. Note that an error that occurs on the client side does not currently get sent to the server side, so this is not the final exit status for the whole transfer.
RSYNC_RAW_STATUS: (post-xfer only) the raw exit value from waitpid().

Even though the commands can be associated with a particular module, they are run using the permissions of the user that started the daemon (not the module’s uid/gid setting) without any chroot restrictions.

These settings honor 2 environment variables: use RSYNC_SHELL to set a shell to use when running the command (which otherwise uses your system() call’s default shell), and use RSYNC_NO_XFER_EXEC to disable both options completely.

CONFIG DIRECTIVES

There are currently two config directives available that allow a config file to incorporate the contents of other files: &include and &merge. Both allow a reference to either a file or a directory. They differ in how segregated the file’s contents are considered to be.

The &include directive treats each file as more distinct, with each one inheriting the defaults of the parent file, starting the parameter parsing as globals/defaults, and leaving the defaults unchanged for the parsing of the rest of the parent file.

The &merge directive, on the other hand, treats the file’s contents as if it were simply inserted in place of the directive, and thus it can set parameters in a module started in another file, can affect the defaults for other files, etc.

When an &include or &merge directive refers to a directory, it will read in all the *.conf or *.inc files (respectively) that are contained inside that directory (without any recursive scanning), with the files sorted into alpha order. So, if you have a directory named “rsyncd.d” with the files “foo.conf”, “bar.conf”, and “baz.conf” inside it, this directive:

&include /path/rsyncd.d

would be the same as this set of directives:

&include /path/rsyncd.d/bar.conf &include /path/rsyncd.d/baz.conf &include /path/rsyncd.d/foo.conf

except that it adjusts as files are added and removed from the directory.

The advantage of the &include directive is that you can define one or more modules in a separate file without worrying about unintended side-effects between the self-contained module files.

The advantage of the &merge directive is that you can load config snippets that can be included into multiple module definitions, and you can also set global values that will affect connections (such as motd file), or globals that will affect other include files.

For example, this is a useful /etc/rsyncd.conf file:

port = 873 log file = /var/log/rsync.log pid file = /var/lock/rsync.lock
&merge /etc/rsyncd.d
&include /etc/rsyncd.d

This would merge any /etc/rsyncd.d/*.inc files (for global values that should stay in effect), and then include any /etc/rsyncd.d/*.conf files (defining modules without any global-value cross-talk).

AUTHENTICATION STRENGTH

The authentication protocol used in rsync is a 128 bit MD4 based challenge response system. This is fairly weak protection, though (with at least one brute-force hash-finding algorithm publicly available), so if you want really top-quality security, then I recommend that you run rsync over ssh. (Yes, a future version of rsync will switch over to a stronger hashing method.)

Also note that the rsync daemon protocol does not currently provide any encryption of the data that is transferred over the connection. Only authentication is provided. Use ssh as the transport if you want encryption.

You can also make use of SSL/TLS encryption if you put rsync behind an SSL proxy.

SSL/TLS Daemon Setup

When setting up an rsync daemon for access via SSL/TLS, you will need to configure a TCP proxy (such as haproxy or nginx) as the front-end that handles the encryption.

You should limit the access to the backend-rsyncd port to only allow the proxy to connect. If it is on the same host as the proxy, then configuring it to only listen on localhost is a good idea.
You should consider turning on the proxy protocol rsync-daemon parameter if your proxy supports sending that information. The examples below assume that this is enabled.

An example haproxy setup is as follows:

frontend fe_rsync-ssl bind :::874 ssl crt /etc/letsencrypt/example.com/combined.pem mode tcp use_backend be_rsync
backend be_rsync
   mode tcp
   server local-rsync 127.0.0.1:873 check send-proxy

An example nginx proxy setup is as follows:

stream { server { listen 874 ssl; listen [::]:874 ssl;

       ssl_certificate /etc/letsencrypt/example.com/fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/example.com/privkey.pem;

       proxy_pass localhost:873;
       proxy_protocol on; # Requires rsyncd.conf "proxy protocol = true"
       proxy_timeout 1m;
       proxy_connect_timeout 5s;
   }
}

DAEMON CONFIG EXAMPLES

A simple rsyncd.conf file that allow anonymous rsync to a ftp area at /home/ftp would be:

[ftp] path = /home/ftp comment = ftp export area

A more sophisticated example would be:

uid = nobody gid = nobody use chroot = yes max connections = 4 syslog facility = local5 pid file = /var/run/rsyncd.pid

[ftp]
        path = /var/ftp/./pub
        comment = whole ftp area (approx 6.1 GB)

[sambaftp]
        path = /var/ftp/./pub/samba
        comment = Samba ftp area (approx 300 MB)

[rsyncftp]
        path = /var/ftp/./pub/rsync
        comment = rsync ftp area (approx 6 MB)

[sambawww]
        path = /public_html/samba
        comment = Samba WWW pages (approx 240 MB)

[cvs]
        path = /data/cvs
        comment = CVS repository (requires authentication)
        auth users = tridge, susan
        secrets file = /etc/rsyncd.secrets

The /etc/rsyncd.secrets file would look something like this:

tridge:mypass susan:herpass

FILES

/etc/rsyncd.conf or rsyncd.conf

BUGS

Please report bugs! The rsync bug tracking system is online at .

VERSION

This manpage is current for version 3.3.0 of rsync.

CREDITS

Rsync is distributed under the GNU General Public License. See the file COPYING for details.

An rsync web site is available at and its github project is .

THANKS

Thanks to Warren Stanley for his original idea and patch for the rsync daemon. Thanks to Karsten Thygesen for his many suggestions and documentation!

AUTHOR

Rsync was originally written by Andrew Tridgell and Paul Mackerras. Many people have later contributed to it. It is currently maintained by Wayne Davison.

Mailing lists for support and development are available at .

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

173 - Linux cli command modules.dep.bin

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command modules.dep.bin and provides detailed information about the command modules.dep.bin, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the modules.dep.bin.

NAME 🖥️ modules.dep.bin 🖥️

Module dependency information

SYNOPSIS

/lib/modules/modules.dep

/lib/modules/modules.dep.bin

DESCRIPTION

Its text counterpart is located in the same directory with the name modules.dep. The text version is maintained only for easy of reading by humans and is in no way used by any kmod tool.

COPYRIGHT

AUTHORS

Jon Masters <[email protected]>

Developer

Lucas De Marchi <[email protected]>

Developer

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

174 - Linux cli command initrd-release

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command initrd-release and provides detailed information about the command initrd-release, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the initrd-release.

NAME 🖥️ initrd-release 🖥️

release, initrd-release, extension-release - Operating system identification

SYNOPSIS

/etc/os-release

/usr/lib/os-release

/etc/initrd-release

/usr/lib/extension-release.d/extension-release.IMAGE

DESCRIPTION

The /etc/os-release and /usr/lib/os-release files contain operating system identification data.

os-release contains data that is defined by the operating system vendor and should generally not be changed by the administrator.

As this file only encodes names and identifiers it should not be localized.

For a longer rationale for os-release please refer to the Announcement of /etc/os-release[1].

/etc/initrd-release

The rest of this document that talks about os-release should be understood to apply to initrd-release too.

/usr/lib/extension-release.d/extension-release.IMAGE

The rest of this document that talks about os-release should be understood to apply to extension-release too.

OPTIONS

The following OS identifications parameters may be set using os-release:

General information identifying the operating system

NAME=

A string identifying the operating system, without a version component, and suitable for presentation to the user. If not set, a default of “NAME=Linux” may be used.
Examples: “NAME=Fedora”, “NAME=“Debian GNU/Linux””.

ID=

A lower-case string (no spaces or other characters outside of 0–9, a–z, “.”, “_” and “-”) identifying the operating system, excluding any version information and suitable for processing by scripts or usage in generated filenames. If not set, a default of “ID=linux” may be used. Note that even though this string may not include characters that require shell quoting, quoting may nevertheless be used.
Examples: “ID=fedora”, “ID=debian”.

ID_LIKE=

A space-separated list of operating system identifiers in the same syntax as the ID= setting. It should list identifiers of operating systems that are closely related to the local operating system in regards to packaging and programming interfaces, for example listing one or more OS identifiers the local OS is a derivative from. An OS should generally only list other OS identifiers it itself is a derivative of, and not any OSes that are derived from it, though symmetric relationships are possible. Build scripts and similar should check this variable if they need to identify the local operating system and the value of ID= is not recognized. Operating systems should be listed in order of how closely the local operating system relates to the listed ones, starting with the closest. This field is optional.
Examples: for an operating system with “ID=centos”, an assignment of “ID_LIKE=“rhel fedora”” would be appropriate. For an operating system with “ID=ubuntu”, an assignment of “ID_LIKE=debian” is appropriate.

PRETTY_NAME=

A pretty operating system name in a format suitable for presentation to the user. May or may not contain a release code name or OS version of some kind, as suitable. If not set, a default of “PRETTY_NAME=“Linux”” may be used
Example: “PRETTY_NAME=“Fedora 17 (Beefy Miracle)””.

CPE_NAME=

A CPE name for the operating system, in URI binding syntax, following the Common Platform Enumeration Specification[4] as proposed by the NIST. This field is optional.
Example: “CPE_NAME=“cpe:/o:fedoraproject:fedora:17"”

VARIANT=

A string identifying a specific variant or edition of the operating system suitable for presentation to the user. This field may be used to inform the user that the configuration of this system is subject to a specific divergent set of rules or default configuration settings. This field is optional and may not be implemented on all systems.
Examples: “VARIANT=“Server Edition””, “VARIANT=“Smart Refrigerator Edition””.
Note: this field is for display purposes only. The VARIANT_ID field should be used for making programmatic decisions.
Added in version 220.

VARIANT_ID=

A lower-case string (no spaces or other characters outside of 0–9, a–z, “.”, “_” and “-”), identifying a specific variant or edition of the operating system. This may be interpreted by other packages in order to determine a divergent default configuration. This field is optional and may not be implemented on all systems.
Examples: “VARIANT_ID=server”, “VARIANT_ID=embedded”.
Added in version 220.

Information about the version of the operating system

VERSION=

A string identifying the operating system version, excluding any OS name information, possibly including a release code name, and suitable for presentation to the user. This field is optional.
Examples: “VERSION=17”, “VERSION=“17 (Beefy Miracle)””.

VERSION_ID=

A lower-case string (mostly numeric, no spaces or other characters outside of 0–9, a–z, “.”, “_” and “-”) identifying the operating system version, excluding any OS name information or release code name, and suitable for processing by scripts or usage in generated filenames. This field is optional.
Examples: “VERSION_ID=17”, “VERSION_ID=11.04”.

VERSION_CODENAME=

A lower-case string (no spaces or other characters outside of 0–9, a–z, “.”, “_” and “-”) identifying the operating system release code name, excluding any OS name information or release version, and suitable for processing by scripts or usage in generated filenames. This field is optional and may not be implemented on all systems.
Examples: “VERSION_CODENAME=buster”, “VERSION_CODENAME=xenial”.
Added in version 231.

BUILD_ID=

A string uniquely identifying the system image originally used as the installation base. In most cases, VERSION_ID or IMAGE_ID+IMAGE_VERSION are updated when the entire system image is replaced during an update. BUILD_ID may be used in distributions where the original installation image version is important: VERSION_ID would change during incremental system updates, but BUILD_ID would not. This field is optional.
Examples: “BUILD_ID=“2013-03-20.3"”, “BUILD_ID=201303203”.
Added in version 200.

IMAGE_ID=

A lower-case string (no spaces or other characters outside of 0–9, a–z, “.”, “_” and “-”), identifying a specific image of the operating system. This is supposed to be used for environments where OS images are prepared, built, shipped and updated as comprehensive, consistent OS images. This field is optional and may not be implemented on all systems, in particularly not on those that are not managed via images but put together and updated from individual packages and on the local system.
Examples: “IMAGE_ID=vendorx-cashier-system”, “IMAGE_ID=netbook-image”.
Added in version 249.

IMAGE_VERSION=

A lower-case string (mostly numeric, no spaces or other characters outside of 0–9, a–z, “.”, “_” and “-”) identifying the OS image version. This is supposed to be used together with IMAGE_ID described above, to discern different versions of the same image.
Examples: “IMAGE_VERSION=33”, “IMAGE_VERSION=47.1rc1”.
Added in version 249.

Presentation information and links

HOME_URL=, DOCUMENTATION_URL=, SUPPORT_URL=, BUG_REPORT_URL=, PRIVACY_POLICY_URL=

Links to resources on the Internet related to the operating system. HOME_URL= should refer to the homepage of the operating system, or alternatively some homepage of the specific version of the operating system. DOCUMENTATION_URL= should refer to the main documentation page for this operating system. SUPPORT_URL= should refer to the main support page for the operating system, if there is any. This is primarily intended for operating systems which vendors provide support for. BUG_REPORT_URL= should refer to the main bug reporting page for the operating system, if there is any. This is primarily intended for operating systems that rely on community QA. PRIVACY_POLICY_URL= should refer to the main privacy policy page for the operating system, if there is any. These settings are optional, and providing only some of these settings is common. These URLs are intended to be exposed in “About this system” UIs behind links with captions such as “About this Operating System”, “Obtain Support”, “Report a Bug”, or “Privacy Policy”. The values should be in RFC3986 format[5], and should be “http:” or “https:” URLs, and possibly “mailto:” or “tel:”. Only one URL shall be listed in each setting. If multiple resources need to be referenced, it is recommended to provide an online landing page linking all available resources.
Examples: “HOME_URL=“https://fedoraproject.org/"", “BUG_REPORT_URL=“https://bugzilla.redhat.com/"".

SUPPORT_END=

The date at which support for this version of the OS ends. (What exactly “lack of support” means varies between vendors, but generally users should assume that updates, including security fixes, will not be provided.) The value is a date in the ISO 8601 format “YYYY-MM-DD”, and specifies the first day on which support is not provided.
For example, “SUPPORT_END=2001-01-01” means that the system was supported until the end of the last day of the previous millennium.
Added in version 252.

LOGO=

A string, specifying the name of an icon as defined by freedesktop.org Icon Theme Specification[6]. This can be used by graphical applications to display an operating systems or distributors logo. This field is optional and may not necessarily be implemented on all systems.
Examples: “LOGO=fedora-logo”, “LOGO=distributor-logo-opensuse”
Added in version 240.

ANSI_COLOR=

A suggested presentation color when showing the OS name on the console. This should be specified as string suitable for inclusion in the ESC [ m ANSI/ECMA-48 escape code for setting graphical rendition. This field is optional.
Examples: “ANSI_COLOR=“0;31"” for red, “ANSI_COLOR=“1;34"” for light blue, or “ANSI_COLOR=“0;38;2;60;110;180"” for Fedora blue.

VENDOR_NAME=

The name of the OS vendor. This is the name of the organization or company which produces the OS. This field is optional.
This name is intended to be exposed in “About this system” UIs or software update UIs when needed to distinguish the OS vendor from the OS itself. It is intended to be human readable.
Examples: “VENDOR_NAME=“Fedora Project”” for Fedora Linux, “VENDOR_NAME=“Canonical”” for Ubuntu.
Added in version 254.

VENDOR_URL=

The homepage of the OS vendor. This field is optional. The VENDOR_NAME= field should be set if this one is, although clients must be robust against either field not being set.
The value should be in RFC3986 format[5], and should be “http:” or “https:” URLs. Only one URL shall be listed in the setting.
Examples: “VENDOR_URL=“https://fedoraproject.org/"", “VENDOR_URL=“https://canonical.com/"".
Added in version 254.

Distribution-level defaults and metadata

DEFAULT_HOSTNAME=

A string specifying the hostname if hostname(5) is not present and no other configuration source specifies the hostname. Must be either a single DNS label (a string composed of 7-bit ASCII lower-case characters and no spaces or dots, limited to the format allowed for DNS domain name labels), or a sequence of such labels separated by single dots that forms a valid DNS FQDN. The hostname must be at most 64 characters, which is a Linux limitation (DNS allows longer names).
See org.freedesktop.hostname1(5) for a description of how systemd-hostnamed.service(8) determines the fallback hostname.
Added in version 248.

ARCHITECTURE=

A string that specifies which CPU architecture the userspace binaries require. The architecture identifiers are the same as for ConditionArchitecture= described in systemd.unit(5). The field is optional and should only be used when just single architecture is supported. It may provide redundant information when used in a GPT partition with a GUID type that already encodes the architecture. If this is not the case, the architecture should be specified in e.g., an extension image, to prevent an incompatible host from loading it.
Added in version 252.

SYSEXT_LEVEL=

A lower-case string (mostly numeric, no spaces or other characters outside of 0–9, a–z, “.”, “_” and “-”) identifying the operating system extensions support level, to indicate which extension images are supported. See /usr/lib/extension-release.d/extension-release.IMAGE, initrd[2] and systemd-sysext(8)) for more information.
Examples: “SYSEXT_LEVEL=2”, “SYSEXT_LEVEL=15.14”.
Added in version 248.

CONFEXT_LEVEL=

Semantically the same as SYSEXT_LEVEL= but for confext images. See /etc/extension-release.d/extension-release.IMAGE for more information.
Examples: “CONFEXT_LEVEL=2”, “CONFEXT_LEVEL=15.14”.
Added in version 254.

SYSEXT_SCOPE=

Takes a space-separated list of one or more of the strings “system”, “initrd” and “portable”. This field is only supported in extension-release.d/ files and indicates what environments the system extension is applicable to: i.e. to regular systems, to initrds, or to portable service images. If unspecified, “SYSEXT_SCOPE=system portable” is implied, i.e. any system extension without this field is applicable to regular systems and to portable service environments, but not to initrd environments.
Added in version 250.

CONFEXT_SCOPE=

Semantically the same as SYSEXT_SCOPE= but for confext images.
Added in version 254.

PORTABLE_PREFIXES=

Takes a space-separated list of one or more valid prefix match strings for the Portable Services[3] logic. This field serves two purposes: it is informational, identifying portable service images as such (and thus allowing them to be distinguished from other OS images, such as bootable system images). It is also used when a portable service image is attached: the specified or implied portable service prefix is checked against the list specified here, to enforce restrictions how images may be attached to a system.
Added in version 250.

Notes

Example: “DEBIAN_BTS=“debbugs://bugs.debian.org/””.

EXAMPLES

Example 1. os-release file for Fedora Workstation

NAME=Fedora VERSION=“32 (Workstation Edition)” ID=fedora VERSION_ID=32 PRETTY_NAME=“Fedora 32 (Workstation Edition)” ANSI_COLOR=“0;38;2;60;110;180” LOGO=fedora-logo-icon CPE_NAME=“cpe:/o:fedoraproject:fedora:32” HOME_URL=“https://fedoraproject.org/" DOCUMENTATION_URL=“https://docs.fedoraproject.org/en-US/fedora/f32/system-administrators-guide/" SUPPORT_URL=“https://fedoraproject.org/wiki/Communicating_and_getting_help" BUG_REPORT_URL=“https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT=“Fedora” REDHAT_BUGZILLA_PRODUCT_VERSION=32 REDHAT_SUPPORT_PRODUCT=“Fedora” REDHAT_SUPPORT_PRODUCT_VERSION=32 PRIVACY_POLICY_URL=“https://fedoraproject.org/wiki/Legal:PrivacyPolicy" VARIANT=“Workstation Edition” VARIANT_ID=workstation

Example 2. extension-release file for an extension for Fedora Workstation 32

ID=fedora VERSION_ID=32

Example 3. Reading os-release in sh(1)

#!/bin/sh -eu # SPDX-License-Identifier: MIT-0

test -e /etc/os-release && os_release=/etc/os-release || os_release=/usr/lib/os-release
. "${os_release}"

echo "Running on ${PRETTY_NAME:-Linux}"

if [ "${ID:-linux}" = "debian" ] || [ "${ID_LIKE#*debian*}" != "${ID_LIKE}" ]; then
    echo "Looks like Debian!"
fi

Example 4. Reading os-release in python(1) (versions >= 3.10)

#!/usr/bin/python # SPDX-License-Identifier: MIT-0

import platform
os_release = platform.freedesktop_os_release()

pretty_name = os_release.get(PRETTY_NAME, Linux)
print(fRunning on {pretty_name!r})

if fedora in [os_release.get(ID, linux),
                *os_release.get(ID_LIKE, ).split()]:
    print(Looks like Fedora!)

See docs for platform.freedesktop_os_release[7] for more details.

Example 5. Reading os-release in python(1) (any version)

#!/usr/bin/python # SPDX-License-Identifier: MIT-0

import ast
import re
import sys

def read_os_release():
    try:
        filename = /etc/os-release
        f = open(filename)
    except FileNotFoundError:
        filename = /usr/lib/os-release
        f = open(filename)

    for line_number, line in enumerate(f, start=1):
        line = line.rstrip()
        if not line or line.startswith(#):
            continue
        m = re.match(r([A-Z][A-Z_0-9]+)=(.*), line)
        if m:
            name, val = m.groups()
            if val and val[0] in "\:
                val = ast.literal_eval(val)
            yield name, val
        else:
            print(f{filename}:{line_number}: bad line {line!r},
                  file=sys.stderr)

os_release = dict(read_os_release())

pretty_name = os_release.get(PRETTY_NAME, Linux)
print(fRunning on {pretty_name!r})

if debian in [os_release.get(ID, linux),
                *os_release.get(ID_LIKE, ).split()]:
    print(Looks like Debian!)

Note that the above version that uses the built-in implementation is preferred in most cases, and the open-coded version here is provided for reference.

NOTES

Announcement of /etc/os-release

https://0pointer.de/blog/projects/os-release

initrd

https://docs.kernel.org/admin-guide/initrd.html

Portable Services

https://systemd.io/PORTABLE_SERVICES

Common Platform Enumeration Specification

http://scap.nist.gov/specifications/cpe/

RFC3986 format

https://tools.ietf.org/html/rfc3986

freedesktop.org Icon Theme Specification

https://standards.freedesktop.org/icon-theme-spec/latest

platform.freedesktop_os_release

https://docs.python.org/3/library/platform.html#platform.freedesktop_os_release

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

175 - Linux cli command proc_driver

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_driver and provides detailed information about the command proc_driver, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_driver.

NAME 🖥️ proc_driver 🖥️

empty dir

DESCRIPTION

/proc/driver/
Empty subdirectory.

176 - Linux cli command exim4_local_sender_callout

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command exim4_local_sender_callout and provides detailed information about the command exim4_local_sender_callout, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the exim4_local_sender_callout.

NAME 🖥️ exim4_local_sender_callout 🖥️

config_files - Files in use by the Debian exim4 packages

SYNOPSIS

DESCRIPTION

This manual page describes the files that are in use by the Debian exim4 packages and which are not part of an exim installation done from source.

/etc/aliases

You should at least set up an alias for postmaster in the /etc/aliases file.

/etc/email-addresses

is used to rewrite the email addresses of users. This is particularly useful for users who use their ISP’s domain for email.

The file should contain lines of the form

user: [email protected]
otheruser: [email protected]

/etc/exim4/local_host_blacklist

In the blacklist, the trick is to read a line break as “or” if it follows a positive item, and as “and” if it follows a negative item.

For example, a /etc/exim4/local_host_blacklist

192.168.10.0/24
!172.16.10.128/26
172.16.10.0/24
10.0.0.0/8

Exim just evaluates left to right (or up-down in the file listing context), so you don’t get the same kind of operator binding as in a programming language.

/etc/exim4/host_local_deny_exceptions

/etc/exim4/local_sender_blacklist

In the blacklist, the trick is to read a line break as “or” if it follows a positive item, and as “and” if it follows a negative item.

For example, a /etc/exim4/local_sender_blacklist

domain1.example
[email protected]
domain2.example
domain3.example

Exim just evaluates left to right (or up-down in the file listing context), so you don’t get the same kind of operator binding as in a programming language.

/etc/exim4/sender_local_deny_exceptions

/etc/exim4/local_sender_callout

/etc/exim4/local_rcpt_callout

/etc/exim4/local_domain_dnsbl_whitelist

/etc/exim4/hubbed_hosts

The file should contain key-value pairs of domain pattern and route data of the form

domain: host-list options
dict.ref.example: mail-1.ref.example:mail-2.ref.example
foo.example: internal.mail.example.com
bar.example: 192.168.183.3

which will cause mail for foo.example to be sent to the host internal.mail.example (IP address derived from A record only), and mail to bar.example to be sent to 192.168.183.3.

See spec.txt chapter 20.3 through 20.7 for a more detailed explanation of host list format and available options.

/etc/exim4/passwd

contains account and password data for SMTP authentication when the local exim is SMTP server and clients authenticate to the local exim.

The file should contain lines of the form

username:crypted-password:clear-password

clear-password is only necessary if you want to offer CRAM-MD5 authentication. If you don’t plan on doing so, the third column can be omitted completely.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim 640.

/etc/exim4/passwd.client

contains account and password data for SMTP authentication when exim is authenticating as a client to some remote server.

The file should contain lines of the form

target.mail.server.example:login-user-name:password

This goes inevitably wrong if the host name of the mail server is a CNAME (a DNS alias), or the reverse lookup does not fit the forward one.

password is your SMTP password in clear text. If you do not know about your SMTP password, you can try using your POP3 password as a first guess.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim 640.

/etc/exim4/exim.crt

/etc/exim4/exim.key

/etc/mailname

The “mail name” of the system. See Debian policy Chapter Customized programs and exim4-base’s README.Debian for further details.

BUGS

Plenty. Please report them through the Debian BTS

This manual page needs a major re-work. If somebody knows better groff than us and has more experience in writing manual pages, any patches would be greatly appreciated.

NOTES

Unresolvable items in host lists

Adding or keeping items in the abovementioned host lists which are not resolvable by DNS has severe consequences.

notresolvable.example.com:rejectme.example.com

Starting the list with the special pattern +ignore_unknown as a safeguard against this behavior is strongly recommended if hostnames are used in hostlists.

AUTHOR

Marc Haber <[email protected]> with help from Ross Boylan.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

177 - Linux cli command pkcs15-profile

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command pkcs15-profile and provides detailed information about the command pkcs15-profile, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the pkcs15-profile.

NAME 🖥️ pkcs15-profile 🖥️

profile - format of profile for pkcs15-init

DESCRIPTION

The pkcs15-init utility for PKCS #15 smart card personalization is controlled via profiles. When starting, it will read two such profiles at the moment, a generic application profile, and a card specific profile. The generic profile must be specified on the command line, while the card-specific file is selected based on the type of card detected.

The generic application profile defines general information about the card layout, such as the path of the application DF, various PKCS #15 files within that directory, and the access conditions on these files. It also defines general information about PIN, key and certificate objects. Currently, there is only one such generic profile, pkcs15.profile.

The card specific profile contains additional information required during card initialization, such as location of PIN files, key references etc. Profiles currently reside in /usr/share/opensc

SYNTAX

This section should contain information about the profile syntax. Will add this soonishly.

178 - Linux cli command proc_modules

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_modules and provides detailed information about the command proc_modules, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_modules.

NAME 🖥️ proc_modules 🖥️

loaded modules

DESCRIPTION

/proc/modules
A text list of the modules that have been loaded by the system. See also lsmod(8).

179 - Linux cli command pc

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command pc and provides detailed information about the command pc, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the pc.

pkg-config files provide a useful mechanism for storing various information about libraries and packages on a given system. Information stored by

files include compiler and linker flags necessary to use a given library, as well as any other relevant metadata.

These

files are processed by a utility called

of which

is an implementation.

The

file follows a format inspired by RFC822. Comments are prefixed by a pound sign, hash sign or octothorpe (#), and variable assignment is similar to POSIX shell. Properties are defined using RFC822-style stanzas.

Variable definitions start with an alphanumeric string, followed by an equal sign, and then the value the variable should contain.

Variable references are always written as “${variable}”. It is possible to escape literal “${” as “$${”.

Properties are set using RFC822-style stanzas which consist of a keyword, followed by a colon (:) and then the value the property should be set to. Variable substitution is always performed regardless of property type.

There are three types of property:

The property will be set to the text of the value.

The property will be set to a list of dependencies parsed from the text. Dependency lists are defined by this ABNF syntax:

package-list = *WSP *( package-spec *( package-sep ) ) package-sep = WSP / “,” package-spec = package-key [ ver-op package-version ] ver-op = “<” / “<=” / “=” / “!=” / “>=” / “>”

The property will be set to a list of fragments parsed from the text. The input text must be in a format that is suitable for passing to a POSIX shell without any shell expansions after variable substitution has been done.

The displayed name of the package. (mandatory; literal)

The version of the package. (mandatory; literal)

A description of the package. (mandatory; literal)

A URL to a webpage for the package. This is used to recommend where newer versions of the package can be acquired. (mandatory; literal)

Required compiler flags. These flags are always used, regardless of whether static compilation is requested. (optional; fragment list)

Required compiler flags for static compilation. (optional; fragment list; pkgconf extension)

Required linking flags for this package. Libraries this package depends on for linking against it, which are not described as dependencies should be specified here. (optional; fragment list)

Required linking flags for this package that are only required when linking statically. Libraries this package depends on for linking against it statically, which are not described as dependencies should be specified here. (optional; fragment list)

Required dependencies that must be met for the package to be usable. All dependencies must be satisfied or the pkg-config implementation must not use the package. (optional; dependency list)

Required dependencies that must be met for the package to be usable for static linking. All dependencies must be satisfied or the pkg-config implementation must not use the package for static linking. (optional; dependency list)

Dependencies that must not be met for the package to be usable. If any package in the proposed dependency solution match any dependency in the Conflicts list, the package being considered is not usable. (optional; dependency list)

Dependencies that may be provided by an alternate package. If a package cannot be found, the entire package collection is scanned for providers which can match the requested dependency. (optional; dependency list; pkgconf extension)

Features that have been marked as a pkgconf extension are only guaranteed to work with the pkgconf implementation of pkg-config. Other implementations may or may not support the extensions.

Accordingly, it is suggested that

files which absolutely depend on these extensions declare a requirement on the pkgconf virtual.

An example .pc file:

# This is a comment prefix=/home/kaniini/pkg # this defines a variable exec_prefix=${prefix} # defining another variable with a substitution libdir=${exec_prefix}/lib includedir=${prefix}/include

Name: libfoo # human-readable name Description: an example library called libfoo # human-readable description Version: 1.0 URL: http://www.pkgconf.org Requires: libbar > 2.0.0 Conflicts: libbaz <= 3.0.0 Libs: -L${libdir} -lfoo Libs.private: -lm Cflags: -I${includedir}/libfoo

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

180 - Linux cli command systemd-user.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd-user.conf and provides detailed information about the command systemd-user.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd-user.conf.

NAME 🖥️ systemd-user.conf 🖥️

system.conf, system.conf.d, systemd-user.conf, user.conf.d - System and session service manager configuration files

SYNOPSIS

/etc/systemd/system.conf, /run/systemd/system.conf, /usr/lib/systemd/system.conf, /etc/systemd/system.conf.d/*.conf, /run/systemd/system.conf.d/*.conf, /usr/lib/systemd/system.conf.d/*.conf

~/.config/systemd/user.conf, /etc/systemd/user.conf, /run/systemd/user.conf, /usr/lib/systemd/user.conf, /etc/systemd/user.conf.d/*.conf, /run/systemd/user.conf.d/*.conf, /usr/lib/systemd/user.conf.d/*.conf

DESCRIPTION

When run as a system instance, systemd interprets the configuration file system.conf and the files in system.conf.d directories; when run as a user instance, it interprets the configuration file user.conf (in order of priority, in the home directory of the user and under /etc/systemd/, /run/systemd/, and /usr/lib/systemd/) and the files in user.conf.d directories. These configuration files contain a few settings controlling basic manager operations.

See systemd.syntax(7) for a general description of the syntax.

CONFIGURATION DIRECTORIES AND PRECEDENCE

OPTIONS

All options are configured in the [Manager] section:

LogColor=, LogLevel=, LogLocation=, LogTarget=, LogTime=, DumpCore=yes, CrashChangeVT=no, CrashShell=no, CrashAction=freeze, ShowStatus=yes, DefaultStandardOutput=journal, DefaultStandardError=inherit

Configures various parameters of basic manager operation. These options may be overridden by the respective process and kernel command line arguments. See systemd(1) for details.
Added in version 198.

CtrlAltDelBurstAction=

Defines what action will be performed if user presses Ctrl-Alt-Delete more than 7 times in 2s. Can be set to “reboot-force”, “poweroff-force”, “reboot-immediate”, “poweroff-immediate” or disabled with “none”. Defaults to “reboot-force”.
Added in version 232.

CPUAffinity=

Configures the CPU affinity for the service manager as well as the default CPU affinity for all forked off processes. Takes a list of CPU indices or ranges separated by either whitespace or commas. CPU ranges are specified by the lower and upper CPU indices separated by a dash. This option may be specified more than once, in which case the specified CPU affinity masks are merged. If the empty string is assigned, the mask is reset, all assignments prior to this will have no effect. Individual services may override the CPU affinity for their processes with the CPUAffinity= setting in unit files, see systemd.exec(5).
Added in version 198.

NUMAPolicy=

Configures the NUMA memory policy for the service manager and the default NUMA memory policy for all forked off processes. Individual services may override the default policy with the NUMAPolicy= setting in unit files, see systemd.exec(5).
Added in version 243.

NUMAMask=

Configures the NUMA node mask that will be associated with the selected NUMA policy. Note that default and local NUMA policies dont require explicit NUMA node mask and value of the option can be empty. Similarly to NUMAPolicy=, value can be overridden by individual services in unit files, see systemd.exec(5).
Added in version 243.

RuntimeWatchdogSec=, RebootWatchdogSec=, KExecWatchdogSec=

Configure the hardware watchdog at runtime and at reboot. Takes a timeout value in seconds (or in other time units if suffixed with “ms”, “min”, “h”, “d”, “w”), or the special strings “off” or “default”. If set to “off” (alternatively: “0”) the watchdog logic is disabled: no watchdog device is opened, configured, or pinged. If set to the special string “default” the watchdog is opened and pinged in regular intervals, but the timeout is not changed from the default. If set to any other time value the watchdog timeout is configured to the specified value (or a value close to it, depending on hardware capabilities).
If RuntimeWatchdogSec= is set to a non-zero value, the watchdog hardware (/dev/watchdog0 or the path specified with WatchdogDevice= or the kernel option systemd.watchdog-device=) will be programmed to automatically reboot the system if it is not contacted within the specified timeout interval. The system manager will ensure to contact it at least once in half the specified timeout interval. This feature requires a hardware watchdog device to be present, as it is commonly the case in embedded and server systems. Not all hardware watchdogs allow configuration of all possible reboot timeout values, in which case the closest available timeout is picked.
RebootWatchdogSec= may be used to configure the hardware watchdog when the system is asked to reboot. It works as a safety net to ensure that the reboot takes place even if a clean reboot attempt times out. Note that the RebootWatchdogSec= timeout applies only to the second phase of the reboot, i.e. after all regular services are already terminated, and after the system and service manager process (PID 1) got replaced by the systemd-shutdown binary, see system bootup(7) for details. During the first phase of the shutdown operation the system and service manager remains running and hence RuntimeWatchdogSec= is still honoured. In order to define a timeout on this first phase of system shutdown, configure JobTimeoutSec= and JobTimeoutAction= in the [Unit] section of the shutdown.target unit. By default RuntimeWatchdogSec= defaults to 0 (off), and RebootWatchdogSec= to 10min.
KExecWatchdogSec= may be used to additionally enable the watchdog when kexec is being executed rather than when rebooting. Note that if the kernel does not reset the watchdog on kexec (depending on the specific hardware and/or driver), in this case the watchdog might not get disabled after kexec succeeds and thus the system might get rebooted, unless RuntimeWatchdogSec= is also enabled at the same time. For this reason it is recommended to enable KExecWatchdogSec= only if RuntimeWatchdogSec= is also enabled.
These settings have no effect if a hardware watchdog is not available.
Added in version 198.

RuntimeWatchdogPreSec=

Configure the hardware watchdog device pre-timeout value. Takes a timeout value in seconds (or in other time units similar to RuntimeWatchdogSec=). A watchdog pre-timeout is a notification generated by the watchdog before the watchdog reset might occur in the event the watchdog has not been serviced. This notification is handled by the kernel and can be configured to take an action (i.e. generate a kernel panic) using RuntimeWatchdogPreGovernor=. Not all watchdog hardware or drivers support generating a pre-timeout and depending on the state of the system, the kernel may be unable to take the configured action before the watchdog reboot. The watchdog will be configured to generate the pre-timeout event at the amount of time specified by RuntimeWatchdogPreSec= before the runtime watchdog timeout (set by RuntimeWatchdogSec=). For example, if the we have RuntimeWatchdogSec=30 and RuntimeWatchdogPreSec=10, then the pre-timeout event will occur if the watchdog has not pinged for 20s (10s before the watchdog would fire). By default, RuntimeWatchdogPreSec= defaults to 0 (off). The value set for RuntimeWatchdogPreSec= must be smaller than the timeout value for RuntimeWatchdogSec=. This setting has no effect if a hardware watchdog is not available or the hardware watchdog does not support a pre-timeout and will be ignored by the kernel if the setting is greater than the actual watchdog timeout.
Added in version 251.

RuntimeWatchdogPreGovernor=

Configure the action taken by the hardware watchdog device when the pre-timeout expires. The default action for the pre-timeout event depends on the kernel configuration, but it is usually to log a kernel message. For a list of valid actions available for a given watchdog device, check the content of the /sys/class/watchdog/watchdogX/pretimeout_available_governors file. Typically, available governor types are noop and panic. Availability, names and functionality might vary depending on the specific device driver in use. If the pretimeout_available_governors sysfs file is empty, the governor might be built as a kernel module and might need to be manually loaded (e.g. pretimeout_noop.ko), or the watchdog device might not support pre-timeouts.
Added in version 251.

WatchdogDevice=

Configure the hardware watchdog device that the runtime and shutdown watchdog timers will open and use. Defaults to /dev/watchdog0. This setting has no effect if a hardware watchdog is not available.
Added in version 236.

CapabilityBoundingSet=

Controls which capabilities to include in the capability bounding set for PID 1 and its children. See capabilities(7) for details. Takes a whitespace-separated list of capability names as read by cap_from_name(3). Capabilities listed will be included in the bounding set, all others are removed. If the list of capabilities is prefixed with ~, all but the listed capabilities will be included, the effect of the assignment inverted. Note that this option also affects the respective capabilities in the effective, permitted and inheritable capability sets. The capability bounding set may also be individually configured for units using the CapabilityBoundingSet= directive for units, but note that capabilities dropped for PID 1 cannot be regained in individual units, they are lost for good.
Added in version 198.

NoNewPrivileges=

Takes a boolean argument. If true, ensures that PID 1 and all its children can never gain new privileges through execve(2) (e.g. via setuid or setgid bits, or filesystem capabilities). Defaults to false. General purpose distributions commonly rely on executables with setuid or setgid bits and will thus not function properly with this option enabled. Individual units cannot disable this option. Also see No New Privileges Flag[2].
Added in version 239.

ProtectSystem=

Takes a boolean argument or the string “auto”. If set to true this will remount /usr/ read-only. If set to “auto” (the default) and running in an initrd equivalent to true, otherwise false. This implements a restricted subset of the per-unit setting of the same name, see systemd.exec(5) for details: currently, the “full” or “struct” values are not supported.
Added in version 256.

SystemCallArchitectures=

Takes a space-separated list of architecture identifiers. Selects from which architectures system calls may be invoked on this system. This may be used as an effective way to disable invocation of non-native binaries system-wide, for example to prohibit execution of 32-bit x86 binaries on 64-bit x86-64 systems. This option operates system-wide, and acts similar to the SystemCallArchitectures= setting of unit files, see systemd.exec(5) for details. This setting defaults to the empty list, in which case no filtering of system calls based on architecture is applied. Known architecture identifiers are “x86”, “x86-64”, “x32”, “arm” and the special identifier “native”. The latter implicitly maps to the native architecture of the system (or more specifically, the architecture the system manager was compiled for). Set this setting to “native” to prohibit execution of any non-native binaries. When a binary executes a system call of an architecture that is not listed in this setting, it will be immediately terminated with the SIGSYS signal.
Added in version 209.

TimerSlackNSec=

Sets the timer slack in nanoseconds for PID 1, which is inherited by all executed processes, unless overridden individually, for example with the TimerSlackNSec= setting in service units (for details see systemd.exec(5)). The timer slack controls the accuracy of wake-ups triggered by system timers. See prctl(2) for more information. Note that in contrast to most other time span definitions this parameter takes an integer value in nano-seconds if no unit is specified. The usual time units are understood too.
Added in version 198.

StatusUnitFormat=

Takes name, description or combined as the value. If name, the system manager will use unit names in status messages (e.g. “systemd-journald.service”), instead of the longer and more informative descriptions set with Description= (e.g. “Journal Logging Service”). If combined, the system manager will use both unit names and descriptions in status messages (e.g. “systemd-journald.service - Journal Logging Service”).
See systemd.unit(5) for details about unit names and Description=.
Added in version 243.

DefaultTimerAccuracySec=

Sets the default accuracy of timer units. This controls the global default for the AccuracySec= setting of timer units, see systemd.timer(5) for details. AccuracySec= set in individual units override the global default for the specific unit. Defaults to 1min. Note that the accuracy of timer units is also affected by the configured timer slack for PID 1, see TimerSlackNSec= above.
Added in version 212.

DefaultTimeoutStartSec=, DefaultTimeoutStopSec=, DefaultTimeoutAbortSec=, DefaultRestartSec=

Configures the default timeouts for starting, stopping and aborting of units, as well as the default time to sleep between automatic restarts of units, as configured per-unit in TimeoutStartSec=, TimeoutStopSec=, TimeoutAbortSec= and RestartSec= (for services, see systemd.service(5) for details on the per-unit settings). For non-service units, DefaultTimeoutStartSec= sets the default TimeoutSec= value.
DefaultTimeoutStartSec= and DefaultTimeoutStopSec= default to 90 s in the system manager and 90 s in the user manager. DefaultTimeoutAbortSec= is not set by default so that all units fall back to TimeoutStopSec=. DefaultRestartSec= defaults to 100 ms.
Added in version 209.

DefaultDeviceTimeoutSec=

Configures the default timeout for waiting for devices. It can be changed per device via the x-systemd.device-timeout= option in /etc/fstab and /etc/crypttab (see systemd.mount(5), crypttab(5)). Defaults to 90 s in the system manager and 90 s in the user manager.
Added in version 252.

DefaultStartLimitIntervalSec=, DefaultStartLimitBurst=

Configure the default unit start rate limiting, as configured per-service by StartLimitIntervalSec= and StartLimitBurst=. See systemd.service(5) for details on the per-service settings. DefaultStartLimitIntervalSec= defaults to 10s. DefaultStartLimitBurst= defaults to 5.
Added in version 209.

DefaultEnvironment=

Configures environment variables passed to all executed processes. Takes a space-separated list of variable assignments. See environ(7) for details about environment variables.
Simple “%"-specifier expansion is supported, see below for a list of supported specifiers.
Example:
DefaultEnvironment=“VAR1=word1 word2” VAR2=word3 “VAR3=word 5 6”
Sets three variables “VAR1”, “VAR2”, “VAR3”.
Added in version 205.

ManagerEnvironment=

Takes the same arguments as DefaultEnvironment=, see above. Sets environment variables just for the manager process itself. In contrast to user managers, these variables are not inherited by processes spawned by the system manager, use DefaultEnvironment= for that. Note that these variables are merged into the existing environment block. In particular, in case of the system manager, this includes variables set by the kernel based on the kernel command line.
Setting environment variables for the manager process may be useful to modify its behaviour. See Known Environment Variables[3] for a descriptions of some variables understood by systemd.
Simple “%"-specifier expansion is supported, see below for a list of supported specifiers.
Added in version 248.

DefaultCPUAccounting=, DefaultMemoryAccounting=, DefaultTasksAccounting=, DefaultIOAccounting=, DefaultIPAccounting=

Configure the default resource accounting settings, as configured per-unit by CPUAccounting=, MemoryAccounting=, TasksAccounting=, IOAccounting= and IPAccounting=. See systemd.resource-control(5) for details on the per-unit settings.
DefaultCPUAccounting= defaults to yes when running on kernel ≥4.15, and no on older versions. DefaultMemoryAccounting= defaults to yes. DefaultTasksAccounting= defaults to yes. The other settings default to no.
Added in version 211.

DefaultTasksMax=

Configure the default value for the per-unit TasksMax= setting. See systemd.resource-control(5) for details. This setting applies to all unit types that support resource control settings, with the exception of slice units. Defaults to 15% of the minimum of kernel.pid_max=, kernel.threads-max= and root cgroup pids.max. Kernel has a default value for kernel.pid_max= and an algorithm of counting in case of more than 32 cores. For example, with the default kernel.pid_max=, DefaultTasksMax= defaults to 4915, but might be greater in other systems or smaller in OS containers.
Added in version 228.

DefaultLimitCPU=, DefaultLimitFSIZE=, DefaultLimitDATA=, DefaultLimitSTACK=, DefaultLimitCORE=, DefaultLimitRSS=, DefaultLimitNOFILE=, DefaultLimitAS=, DefaultLimitNPROC=, DefaultLimitMEMLOCK=, DefaultLimitLOCKS=, DefaultLimitSIGPENDING=, DefaultLimitMSGQUEUE=, DefaultLimitNICE=, DefaultLimitRTPRIO=, DefaultLimitRTTIME=

These settings control various default resource limits for processes executed by units. See setrlimit(2) for details. These settings may be overridden in individual units using the corresponding LimitXXX= directives and they accept the same parameter syntax, see systemd.exec(5) for details. Note that these resource limits are only defaults for units, they are not applied to the service manager process (i.e. PID 1) itself.
Most of these settings are unset, which means the resource limits are inherited from the kernel or, if invoked in a container, from the container manager. However, the following have defaults:
·
DefaultLimitNOFILE= defaults to 1024:524288.
·
DefaultLimitMEMLOCK= defaults to 8M.
·
DefaultLimitCORE= does not have a default but it is worth mentioning that RLIMIT_CORE is set to “infinity” by PID 1 which is inherited by its children.
Note that the service manager internally in PID 1 bumps RLIMIT_NOFILE and RLIMIT_MEMLOCK to higher values, however the limit is reverted to the mentioned defaults for all child processes forked off.
Added in version 198.

DefaultOOMPolicy=

Configure the default policy for reacting to processes being killed by the Linux Out-Of-Memory (OOM) killer or systemd-oomd. This may be used to pick a global default for the per-unit OOMPolicy= setting. See systemd.service(5) for details. Note that this default is not used for services that have Delegate= turned on.
Added in version 243.

DefaultOOMScoreAdjust=

Configures the default OOM score adjustments of processes run by the service manager. This defaults to unset (meaning the forked off processes inherit the service managers OOM score adjustment value), except if the service manager is run for an unprivileged user, in which case this defaults to the service managers OOM adjustment value plus 100 (this makes service processes slightly more likely to be killed under memory pressure than the manager itself). This may be used to pick a global default for the per-unit OOMScoreAdjust= setting. See systemd.exec(5) for details. Note that this setting has no effect on the OOM score adjustment value of the service manager process itself, it retains the original value set during its invocation.
Added in version 250.

DefaultSmackProcessLabel=

Takes a SMACK64 security label as the argument. The process executed by a unit will be started under this label if SmackProcessLabel= is not set in the unit. See systemd.exec(5) for the details.
If the value is “/”, only labels specified with SmackProcessLabel= are assigned and the compile-time default is ignored.
Added in version 252.

ReloadLimitIntervalSec=, ReloadLimitBurst=

Rate limiting for daemon-reload and (since v256) daemon-reexec requests. The setting applies to both operations, but the rate limits are tracked separately. Defaults to unset, and any number of operations can be requested at any time. ReloadLimitIntervalSec= takes a value in seconds to configure the rate limit window, and ReloadLimitBurst= takes a positive integer to configure the maximum allowed number of operations within the configured time window.
Added in version 253.

DefaultMemoryPressureWatch=, DefaultMemoryPressureThresholdSec=

Configures the default settings for the per-unit MemoryPressureWatch= and MemoryPressureThresholdSec= settings. See systemd.resource-control(5) for details. Defaults to “auto” and “200ms”, respectively. This also sets the memory pressure monitoring threshold for the service manager itself.
Added in version 254.

SPECIFIERS

Specifiers may be used in the DefaultEnvironment= and ManagerEnvironment= settings. The following expansions are understood:

Table 1. Specifiers available

Specifier	Meaning	Details
"%a"	Architecture	A short string identifying the architecture of the local system. A string such as x86, x86-64 or arm64. See the architectures defined for ConditionArchitecture= in systemd.unit(5) for a full list.
"%A"	Operating system image version	The operating system image version identifier of the running system, as read from the IMAGE_VERSION= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.
"%b"	Boot ID	The boot ID of the running system, formatted as string. See random(4) for more information.
"%B"	Operating system build ID	The operating system build identifier of the running system, as read from the BUILD_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.
"%H"	Host name	The hostname of the running system.
"%l"	Short host name	The hostname of the running system, truncated at the first dot to remove any domain component.
"%m"	Machine ID	The machine ID of the running system, formatted as string. See machine-id(5) for more information.
"%M"	Operating system image identifier	The operating system image identifier of the running system, as read from the IMAGE_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.
"%o"	Operating system ID	The operating system identifier of the running system, as read from the ID= field of /etc/os-release. See os-release(5) for more information.
"%v"	Kernel release	Identical to uname -r output.
"%w"	Operating system version ID	The operating system version identifier of the running system, as read from the VERSION_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.
"%W"	Operating system variant ID	The operating system variant identifier of the running system, as read from the VARIANT_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.
"%T"	Directory for temporary files	This is either /tmp or the path "$TMPDIR", "$TEMP" or "$TMP" are set to. (Note that the directory may be specified without a trailing slash.)
"%V"	Directory for larger and persistent temporary files	This is either /var/tmp or the path "$TMPDIR", "$TEMP" or "$TMP" are set to. (Note that the directory may be specified without a trailing slash.)
"%h"	User home directory	This is the home directory of the user running the service manager instance.
"%u"	Username	This is the username of the user running the service manager instance.
"%U"	User id	This is the user id of the user running the service manager instance.
"%g"	Primary group	This is the primary group of the user running the service manager instance.
"%G"	Primary group id	This is the primary group id of the user running the service manager instance.
"%s"	User shell	This is the shell of the user running the service manager instance.
"%%"	Single percent sign	Use "%%" in place of "%" to specify a single percent sign.

HISTORY

systemd 252

Option DefaultBlockIOAccounting= was deprecated. Please switch to the unified cgroup hierarchy.
Added in version 252.

NOTES

No New Privileges Flag

https://docs.kernel.org/userspace-api/no_new_privs.html

Known Environment Variables

https://systemd.io/ENVIRONMENT

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

181 - Linux cli command proc_kpageflags

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_kpageflags and provides detailed information about the command proc_kpageflags, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_kpageflags.

NAME 🖥️ proc_kpageflags 🖥️

physical pages frame masks

DESCRIPTION

/proc/kpageflags (since Linux 2.6.25)
This file contains 64-bit masks corresponding to each physical page frame; it is indexed by page frame number (see the discussion of /proc/pid/pagemap). The bits are as follows:

0	-	KPF_LOCKED
1	-	KPF_ERROR
2	-	KPF_REFERENCED
3	-	KPF_UPTODATE
4	-	KPF_DIRTY
5	-	KPF_LRU
6	-	KPF_ACTIVE
7	-	KPF_SLAB
8	-	KPF_WRITEBACK
9	-	KPF_RECLAIM
10	-	KPF_BUDDY
11	-	KPF_MMAP	(since Linux 2.6.31)
12	-	KPF_ANON	(since Linux 2.6.31)
13	-	KPF_SWAPCACHE	(since Linux 2.6.31)
14	-	KPF_SWAPBACKED	(since Linux 2.6.31)
15	-	KPF_COMPOUND_HEAD	(since Linux 2.6.31)
16	-	KPF_COMPOUND_TAIL	(since Linux 2.6.31)
17	-	KPF_HUGE	(since Linux 2.6.31)
18	-	KPF_UNEVICTABLE	(since Linux 2.6.31)
19	-	KPF_HWPOISON	(since Linux 2.6.31)
20	-	KPF_NOPAGE	(since Linux 2.6.31)
21	-	KPF_KSM	(since Linux 2.6.32)
22	-	KPF_THP	(since Linux 3.4)
23	-	KPF_BALLOON	(since Linux 3.18)
24	-	KPF_ZERO_PAGE	(since Linux 4.0)
25	-	KPF_IDLE	(since Linux 4.3)
26	-	KPF_PGTABLE	(since Linux 4.18)

For further details on the meanings of these bits, see the kernel source file Documentation/admin-guide/mm/pagemap.rst. Before Linux 2.6.29, KPF_WRITEBACK, KPF_RECLAIM, KPF_BUDDY, and KPF_LOCKED did not report correctly.

The /proc/kpageflags file is present only if the CONFIG_PROC_PAGE_MONITOR kernel configuration option is enabled.

182 - Linux cli command proc_pid_environ

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_environ and provides detailed information about the command proc_pid_environ, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_environ.

NAME 🖥️ proc_pid_environ 🖥️

initial environment

DESCRIPTION

/proc/pid/environ
This file contains the initial environment that was set when the currently executing program was started via execve(2). The entries are separated by null bytes (‘�’), and there may be a null byte at the end. Thus, to print out the environment of process 1, you would do:

$ cat /proc/1/environ | tr '' '

If, after an execve(2), the process modifies its environment (e.g., by calling functions such as putenv(3) or modifying the environ(7) variable directly), this file will not reflect those changes.

Furthermore, a process may change the memory location that this file refers via prctl(2) operations such as PR_SET_MM_ENV_START.

Permission to access this file is governed by a ptrace access mode PTRACE_MODE_READ_FSCREDS check; see ptrace(2).

183 - Linux cli command updatedb.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command updatedb.conf and provides detailed information about the command updatedb.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the updatedb.conf.

NAME 🖥️ updatedb.conf 🖥️

a configuration file for updatedb(8)

DESCRIPTION

/etc/updatedb.conf is a text file. Blank lines are ignored. A # character outside of a quoted string starts a comment extending until end of line.

Other lines must be of the following form:

VARIABLE = "VALUE"

White space between tokens is ignored. VARIABLE is an alphanumeric string which does not start with a digit. VALUE can contain any character except for ". No escape mechanism is supported within VALUE and there is no way to write VALUE spanning more than one line.

Unknown VARIABLE values are considered an error. The defined variables are:

PRUNEFS
A whitespace-separated list of file system types (as used in /etc/mtab) which should not be scanned by updatedb(8). The file system type matching is case-insensitive. By default, no file system types are skipped.

When scanning a file system is skipped, all file systems mounted in the subtree are skipped too, even if their type does not match any entry in PRUNEFS.

PRUNENAMES
A whitespace-separated list of directory names (without paths) which should not be scanned by updatedb(8). By default, no directory names are skipped.

Note that only directories can be specified, and no pattern mechanism (e.g. globbing) is used.

PRUNEPATHS
A whitespace-separated list of path names of directories which should not be scanned by updatedb(8). Each path name must be exactly in the form in which the directory would be reported by locate(1).

By default, no paths are skipped.

PRUNE_BIND_MOUNTS
One of the strings 0, no, 1 or yes. If PRUNE_BIND_MOUNTS is 1 or yes, bind mounts are not scanned by updatedb(8). All file systems mounted in the subtree of a bind mount are skipped as well, even if they are not bind mounts. As an exception, bind mounts of a directory on itself are not skipped. Note that Btrfs subvolume mounts are handled internally in the kernel as bind mounts (see btrfs-subvolume(8)), and thus, may get skipped if you have also mounted the filesystem root itself. To counteract this, make your root directory a Btrfs subvolume, too.

By default, bind mounts are not skipped.

NOTES

When a directory is matched by PRUNEFS, PRUNENAMES or PRUNEPATHS, updatedb(8) does not scan the contents of the directory. The path of the directory itself is, however, entered in the created database. For example, if /tmp is in PRUNEPATHS, locate(1) will not show any files stored in /tmp, but it can show the /tmp directory. This behavior differs from traditional locate implementations.

In some updatedb(8) implementations PRUNEPATHS can be used to exclude non-directory files. This is not the case in this implementation.

/etc/updatedb.conf is a shell script in some implementations, which allows much more flexibility in defining the variables. Equivalent functionality can be achieved by using the command-line options to updatedb(8).

AUTHOR

Miloslav Trmac <[email protected]>

184 - Linux cli command deb-control

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command deb-control and provides detailed information about the command deb-control, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the deb-control.

NAME 🖥️ deb-control 🖥️

control - Debian binary package control file format

SYNOPSIS

DEBIAN/control

DESCRIPTION

Each Debian binary package contains a control file in its control member, and its deb822 (5) format is a subset of the debian/control template source control file in Debian source packages, see deb-src-control (5).

This file contains a number of fields. Each field begins with a tag, such as Package or Version (case insensitive), followed by a colon, and the body of the field (case sensitive unless stated otherwise). Fields are delimited only by field tags. In other words, field text may be multiple lines in length, but the installation tools will generally join lines when processing the body of the field (except in the case of the Description field, see below).

FIELDS

Package: package-name (required)
The value of this field determines the package name, and is used to generate file names by most installation tools.

Package-Type: deb|udeb|type
This field defines the type of the package. udeb is for size-constrained packages used by the debian installer. deb is the default value, it is assumed if the field is absent. More types might be added in the future.

Version: version-string (required)
Typically, this is the original package’s version number in whatever form the program’s author uses. It may also include a Debian revision number (for non-native packages). The exact format and sorting algorithm are described in deb-version (7).

Maintainer: fullname-email (recommended)
Should be in the format “Joe Bloggs <[email protected]>”, and is typically the person who created the package, as opposed to the author of the software that was packaged.

Description: short-description (recommended)

long-description

The format for the package description is a short brief summary on the first line (after the Description field). The following lines should be used as a longer, more detailed description. Each line of the long description must be preceded by a space, and blank lines in the long description must contain a single ‘.’ following the preceding space.

Section: section
This is a general field that gives the package a category based on the software that it installs. Some common sections are utils, net, mail, text, x11, etc.

Priority: priority
Sets the importance of this package in relation to the system as a whole. Common priorities are required, standard, optional, extra, etc.

The Section and Priority fields usually have a defined set of accepted values based on the specific distribution policy.

Installed-Size: size
The approximate total size of the package’s installed files, in KiB units. The algorithm to compute the size is described in deb-substvars (5).

Protected: yes|no
This field is usually only needed when the answer is yes. It denotes a package that is required mostly for proper booting of the system or used for custom system-local meta-packages. dpkg (1) or any other installation tool will not allow a Protected package to be removed (at least not without using one of the force options). Supported since dpkg 1.20.1.

Essential: yes|no
This field is usually only needed when the answer is yes. It denotes a package that is required for the packaging system, for proper operation of the system in general or during boot (although the latter should be converted to Protected field instead). dpkg (1) or any other installation tool will not allow an Essential package to be removed (at least not without using one of the force options).

Build-Essential: yes|no
This field is usually only needed when the answer is yes, and is commonly injected by the archive software. It denotes a package that is required when building other packages.

Architecture: arch|all (required)
The architecture specifies which type of hardware this package was compiled for. Common architectures are amd64, armel, i386, powerpc, etc. Note that the all value is meant for packages that are architecture independent. Some examples of this are shell and Perl scripts, and documentation.

Origin: name
The name of the distribution this package is originating from.

Bugs: url
The url of the bug tracking system for this package. The current used format is bts-type**://**bts-address, like debbugs://bugs.debian.org.

Homepage: url
The upstream project home page url.

Tag: tag-list
List of tags describing the qualities of the package. The description and list of supported tags can be found in the debtags package.

Multi-Arch: no|same|foreign|allowed
This field is used to indicate how this package should behave on a multi-arch installations.

no
This value is the default when the field is omitted, in which case adding the field with an explicit no value is generally not needed.

same
This package is co-installable with itself, but it must not be used to satisfy the dependency of any package of a different architecture from itself.

foreign
This package is not co-installable with itself, but should be allowed to satisfy a non-arch-qualified dependency of a package of a different arch from itself (if a dependency has an explicit arch-qualifier then the value foreign is ignored).

allowed
This allows reverse-dependencies to indicate in their Depends field that they accept this package from a foreign architecture by qualifying the package name with :any, but has no effect otherwise.

Source: source-name [(source-version)]
The name of the source package that this binary package came from, if it is different than the name of the package itself. If the source version differs from the binary version, then the source-name will be followed by a source-version in parenthesis. This can happen for example on a binary-only non-maintainer upload, or when setting a different binary version via «dpkg-gencontrol -v».

Subarchitecture: value

Kernel-Version: value

Installer-Menu-Item: value

These fields are used by the debian-installer and are usually not needed. For more details about them, see <https://salsa.debian.org/installer-team/debian-installer/-/raw/master/doc/devel/modules.txt>.

Depends: package-list
List of packages that are required for this package to provide a non-trivial amount of functionality. The package maintenance software will not allow a package to be installed if the packages listed in its Depends field aren’t installed (at least not without using the force options). In an installation, the postinst scripts of packages listed in Depends fields are run before those of the packages which depend on them. On the opposite, in a removal, the prerm script of a package is run before those of the packages listed in its Depends field.

Pre-Depends: package-list
List of packages that must be installed and configured before this one can be installed. This is usually used in the case where this package requires another package for running its preinst script.

Recommends: package-list
Lists packages that would be found together with this one in all but unusual installations. The package maintenance software will warn the user if they install a package without those listed in its Recommends field.

Suggests: package-list
Lists packages that are related to this one and can perhaps enhance its usefulness, but without which installing this package is perfectly reasonable.

The syntax of Depends, Pre-Depends, Recommends and Suggests fields is a list of groups of alternative packages. Each group is a list of packages separated by vertical bar (or “pipe”) symbols, ‘|’. The groups are separated by commas. Commas are to be read as “AND”, and pipes as “OR”, with pipes binding more tightly. Each package name is optionally followed by an architecture qualifier appended after a colon ‘:’, optionally followed by a version number specification in parentheses.

An architecture qualifier name can be a real Debian architecture name (since dpkg 1.16.5) or any (since dpkg 1.16.2). If omitted, the default is the current binary package architecture. A real Debian architecture name will match exactly that architecture for that package name, any will match any architecture for that package name if the package has been marked as Multi-Arch: allowed.

A version number may start with a ‘>>’, in which case any later version will match, and may specify or omit the Debian packaging revision (separated by a hyphen). Accepted version relationships are ‘>>’ for greater than, ‘<<’ for less than, ‘>=’ for greater than or equal to, ‘<=’ for less than or equal to, and ‘=’ for equal to.

Breaks: package-list
Lists packages that this one breaks, for example by exposing bugs when the named packages rely on this one. The package maintenance software will not allow broken packages to be configured; generally the resolution is to upgrade the packages named in a Breaks field.

Conflicts: package-list
Lists packages that conflict with this one, for example by containing files with the same names. The package maintenance software will not allow conflicting packages to be installed at the same time. Two conflicting packages should each include a Conflicts line mentioning the other.

Replaces: package-list
List of packages files from which this one replaces. This is used for allowing this package to overwrite the files of another package and is usually used with the Conflicts field to force removal of the other package, if this one also has the same files as the conflicted package.

The syntax of Breaks, Conflicts and Replaces is a list of package names, separated by commas (and optional whitespace). In the Breaks and Conflicts fields, the comma should be read as “OR”. An optional architecture qualifier can also be appended to the package name with the same syntax as above, but the default is any instead of the binary package architecture. An optional version can also be given with the same syntax as above for the Breaks, Conflicts and Replaces fields.

Enhances: package-list
This is a list of packages that this one enhances. It is similar to Suggests but in the opposite direction.

Provides: package-list
This is a list of virtual packages that this one provides. Usually this is used in the case of several packages all providing the same service. For example, sendmail and exim can serve as a mail server, so they provide a common package (“mail-transport-agent”) on which other packages can depend. This will allow sendmail or exim to serve as a valid option to satisfy the dependency. This prevents the packages that depend on a mail server from having to know the package names for all of them, and using ‘|’ to separate the list.

The syntax of Provides is a list of package names, separated by commas (and optional whitespace). An optional architecture qualifier can also be appended to the package name with the same syntax as above. If omitted, the default is the current binary package architecture. An optional exact (equal to) version can also be given with the same syntax as above (honored since dpkg 1.17.11).

Built-Using: package-list
This dependency field lists extra source packages that were used during the build of this binary package, for license compliance purposes. This is an indication to the archive maintenance software that these extra source packages must be kept whilst this binary package is maintained. This field must be a comma-separated list of source package names with strict ‘=’ version relationships enclosed within parenthesis. Note that the archive maintenance software is likely to refuse to accept an upload which declares a Built-Using relationship which cannot be satisfied within the archive.

Static-Built-Using: package-list
This dependency field lists extra source packages that were used during the build of this binary package, for static building purposes (for example linking against static libraries, builds for source-centered languages such as Go or Rust, usage of header-only C/C++ libraries, injecting data blobs into code, etc.). This is useful to track whether this package might need to be rebuilt when source packages listed here have been updated, for example due to security updates. This field must be a comma-separated list of source package names with strict ‘=’ version relationships enclosed within parenthesis. Supported since dpkg 1.21.3.

Built-For-Profiles: profile-list (obsolete)
This field used to specify a whitespace separated list of build profiles that this binary packages was built with (since dpkg 1.17.2 until 1.18.18). The information previously found in this field can now be found in the .buildinfo file, which supersedes it.

Auto-Built-Package: reason-list
This field specifies a whitespace separated list of reasons why this package was auto-generated. Binary packages marked with this field will not appear in the debian/control template source control file. The only currently used reason is debug-symbols.

Build-Ids: elf-build-id-list
This field specifies a whitespace separated list of ELF build-ids. These are unique identifiers for semantically identical ELF objects, for each of these within the package. The format or the way to compute each build-id is not defined by design.

EXAMPLE

Package: grep Essential: yes Priority: required Section: base Maintainer: Wichert Akkerman <[email protected]> Architecture: sparc Version: 2.4-1 Pre-Depends: libc6 (>= 2.0.105) Provides: rgrep Conflicts: rgrep Description: GNU grep, egrep and fgrep. The GNU family of grep utilities may be the “fastest grep in the west”. GNU grep is based on a fast lazy-state deterministic matcher (about twice as fast as stock Unix egrep) hybridized with a Boyer-Moore-Gosper search for a fixed string that eliminates impossible text from being considered by the full regexp matcher without necessarily having to look at every character. The result is typically many times faster than Unix grep or egrep. (Regular expressions containing backreferencing will run more slowly, however).

BUGS

The Build-Ids field uses a rather generic name out of its original context within an ELF object, which serves a very specific purpose and executable format.

185 - Linux cli command ext4

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ext4 and provides detailed information about the command ext4, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ext4.

NAME 🖥️ ext4 🖥️

the second extended file system
ext3 - the third extended file system
ext4 - the fourth extended file system

DESCRIPTION

FILE SYSTEM FEATURES

64bit

bigalloc

This feature requires that the extent feature be enabled.

casefold

dir_index

Use hashed b-trees to speed up name lookups in large directories. This feature is supported by ext3 and ext4 file systems, and is ignored by ext2 file systems.

dir_nlink

ea_inode

encrypt

Enables support for file-system level encryption of data blocks and file names. The inode metadata (timestamps, file size, user/group ownership, etc.) is not encrypted.

ext_attr

This feature enables the use of extended attributes. This feature is supported by ext2, ext3, and ext4.

extent

extra_isize

For this feature to be useful the inode size must be 256 bytes in size or larger.

filetype

This feature enables the storage of file type information in directory entries. This feature is supported by ext2, ext3, and ext4.

flex_bg

has_journal

huge_file

This ext4 feature allows files to be larger than 2 terabytes in size.

inline_data
Allow data to be stored in the inode and extended attribute area.

journal_dev

This feature is enabled on the superblock found on an external journal device. The block size for the external journal must be the same as the file system which uses it.

The external journal device can be used by a file system by specifying the -J device=<external-device> option to mke2fs(8) or tune2fs(8).

large_dir

large_file

metadata_csum

metadata_csum_seed

meta_bg

mmp

This ext4 feature provides multiple mount protection (MMP). MMP helps to protect the file system from being multiply mounted and is useful in shared storage environments.

project

This ext4 feature provides project quota support. With this feature, the project ID of inode will be managed when the file system is mounted.

quota

Create quota inodes (inode #3 for userquota and inode #4 for group quota) and set them in the superblock. With this feature, the quotas will be enabled automatically when the file system is mounted.

Causes the quota files (i.e., user.quota and group.quota which existed in the older quota design) to be hidden inodes.

resize_inode

This feature requires that the sparse_super or sparse_super2 feature be enabled.

sparse_super

sparse_super2

stable_inodes

uninit_bg

verity

MOUNT OPTIONS

This section describes mount options which are specific to ext2, ext3, and ext4. Other generic mount options may be used as well; see mount(8) for details.

Mount options for ext2

The `ext2’ file system is the standard Linux file system. Since Linux 2.5.46, for most mount options the default is determined by the file system superblock. Set them with tune2fs(8).

acl|noacl
Support POSIX Access Control Lists (or not). See the acl(5) manual page.

% mount /k -o minixdf; df /k; umount /k

File System	1024-blocks	Used	Available	Capacity	Mounted on
/dev/sda6	2630655	86954	2412169	3%	/k

% mount /k -o bsddf; df /k; umount /k

File System	1024-blocks	Used	Available	Capacity	Mounted on
/dev/sda6	2543714	13	2412169	0%	/k

(Note that this example shows that one can add command line options to the options given in /etc/fstab.)

debug
Print debugging info upon each (re)mount.

nouid32
Disables 32-bit UIDs and GIDs. This is for interoperability with older kernels which only store and expect 16-bit values.

oldalloc or orlov
Use old allocator or Orlov allocator for new inodes. Orlov is default.

The block number here uses 1 k units. Thus, if you want to use logical block 32768 on a file system with 4 k blocks, use “sb=131072”.

user_xattr|nouser_xattr
Support “user.” extended attributes (or not).

Mount options for ext3

The ext3 file system is a version of the ext2 file system which has been enhanced with journaling. It supports the same options as ext2 as well as the following additions:

journal
All data is committed into the journal prior to being written into the main file system.

ordered
This is the default mode. All data is forced directly out to the main file system prior to its metadata being committed to the journal.

data_err=ignore
Just print an error message if an error occurs in a file data buffer in ordered mode.

data_err=abort
Abort the journal if an error occurs in a file data buffer in ordered mode.

**commit=**nrsec
Start a journal commit every nrsec seconds. The default value is 5 seconds. Zero means default.

user_xattr
Enable Extended User Attributes. See the attr(5) manual page.

Mount options for ext4

The ext4 file system is an advanced level of the ext3 file system which incorporates scalability and reliability enhancements for supporting large file system.

The ext4 file system enables write barriers by default.

delalloc
Deferring block allocation until write-out time.

nodelalloc
Disable delayed allocation. Blocks are allocated when data is copied from user to page cache.

abort
Simulate the effects of calling ext4_abort() for debugging purposes. This is normally used while remounting a file system which is already mounted.

auto_da_alloc|noauto_da_alloc
Many broken applications don’t use fsync() when replacing existing files via patterns such as

fd = open(“foo.new”)/write(fd,…)/close(fd)/ rename(“foo.new”, “foo”)

or worse yet

fd = open(“foo”, O_TRUNC)/write(fd,…)/close(fd).

i_version
Enable 64-bit inode version support. This option is off by default.

FILE ATTRIBUTES

The ext2, ext3, and ext4 file systems support setting the following file attributes on Linux systems using the chattr(1) utility:

a - append only

A - no atime updates

d - no dump

D - synchronous directory updates

i - immutable

S - synchronous updates

u - undeletable

In addition, the ext3 and ext4 file systems support the following flag:

j - data journaling

Finally, the ext4 file system also supports the following flag:

e - extents format

For descriptions of these attribute flags, please refer to the chattr(1) man page.

KERNEL SUPPORT

filetype
ext2, 2.2.0

sparse_super
ext2, 2.2.0

large_file
ext2, 2.2.0

has_journal
ext3, 2.4.15

ext_attr
ext2/ext3, 2.6.0

dir_index
ext3, 2.6.0

resize_inode
ext3, 2.6.10 (online resizing)

64bit
ext4, 2.6.28

dir_nlink
ext4, 2.6.28

extent
ext4, 2.6.28

extra_isize
ext4, 2.6.28

flex_bg
ext4, 2.6.28

huge_file
ext4, 2.6.28

meta_bg
ext4, 2.6.28

uninit_bg
ext4, 2.6.28

mmp
ext4, 3.0

bigalloc
ext4, 3.2

quota
ext4, 3.6

inline_data
ext4, 3.8

sparse_super2
ext4, 3.16

metadata_csum
ext4, 3.18

encrypt
ext4, 4.1

metadata_csum_seed
ext4, 4.4

project
ext4, 4.5

ea_inode
ext4, 4.13

large_dir
ext4, 4.13

casefold
ext4, 5.2

verity
ext4, 5.4

stable_inodes
ext4, 5.5

186 - Linux cli command proc_malloc

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_malloc and provides detailed information about the command proc_malloc, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_malloc.

NAME 🖥️ proc_malloc 🖥️

debug malloc (obsolete)

DESCRIPTION

/proc/malloc (only up to and including Linux 2.2)
This file is present only if CONFIG_DEBUG_MALLOC was defined during compilation.

187 - Linux cli command mailcap.order

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command mailcap.order and provides detailed information about the command mailcap.order, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the mailcap.order.

NAME 🖥️ mailcap.order 🖥️

the mailcap ordering specifications

DESCRIPTION

The order of entries in the /etc/mailcap file can be altered by editing the /etc/mailcap.order file. Each line of that file specifies a package and an optional mime type. Mailcap entries that match will be placed in the order of this file. Entries that don’t match will be placed later.

Example

mime-support:*/* gv:application/postscript netscape:text/html less:text/* emacs:text/*

The above would make any entries provided by the mime-support package (as found in the /usr/lib/mime/packages directory) take priority over everything else. The gv package will be used over anything else when it comes to postscript documents. Netscape will be used for any html documents and less will be used for any remaining text documents. However, since neither netscape or less provide for editing documents, any edit or compose actions will fall through to the emacs rules.

After modifying this file, be sure to run /usr/sbin/update-mime (as root) to propagate the changes into the /etc/mailcap file.

Remember that this files takes package names and not executable names. If you want to define rules that reference specific programs, the best way is to include them in ~/.mailcap or the user section of the /etc/mailcap file.

LIMITATIONS

There is currently no way to break out a certain type from a wildcard rule. If, for example, both xv and gimp were to specify “image/*” rules, it isn’t possible to use xv for gif images but use gimp for jpeg images.

Also, I would like to add the ability to specify certain actions in the rules. For example, if netscape were to have an edit rule but I wanted to use emacs for editing/creating html documents, I could place a line like

emacs:text/* action=edit|compose

before the netscape entry. The update-mime program would then spit out entries such that netscape view rule comes before the emacs view rule but have the netscape edit rule comes after the emacs edit rule.

AUTHOR

The mailcap.order specification was written by Brian White <[email protected]>

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

188 - Linux cli command XCompose

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command XCompose and provides detailed information about the command XCompose, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the XCompose.

NAME 🖥️ XCompose 🖥️

X client mappings for multi-key input sequences

DESCRIPTION

The X library, libX11, provides a simple input method for characters beyond those represented on typical keyboards using sequences of key strokes that are combined to enter a single character.

The compose file is searched for in the following order:

If the environment variable $XCOMPOSEFILE is set, its value is used as the name of the Compose file.
If the user’s home directory has a file named .XCompose, it is used as the Compose file.
The system provided compose file is used by mapping the locale to a compose file from the list in /usr/share/X11/locale/compose.dir.

Compose files can use an include instruction. This allows local modifications to be made to existing compose files without including all of the content directly. For example, the system’s iso8859-1 compose file can be included with a line like this:

**include **%S/iso8859-1/Compose

There are several substitutions that can be made in the file name of the include instruction:

%H
expands to the user’s home directory (the $HOME environment variable)

%L
expands to the name of the locale specific Compose file (i.e., /usr/share/X11/locale/<localename>/Compose)

%S
expands to the name of the system directory for Compose files (i.e., /usr/share/X11/locale)

For example, you can include in your compose file the default Compose file by using:

include %L

and then rewrite only the few rules that you need to change. New compose rules can be added, and previous ones replaced.

FILE FORMAT

Compose files are plain text files, with a separate line for each compose sequence. Comments begin with # characters. Each compose sequence specifies one or more events and a resulting input sequence, with an optional comment at the end of the line:

EVENT [EVENT…] : RESULT [# COMMENT]

Each event consists of a specified input keysym, and optional modifier states:

[([!] ([~] MODIFIER)…) | None] <keysym>

If the modifier list is preceded by ! it must match exactly. MODIFIER may be one of Ctrl, Lock, Caps, Shift, Alt or Meta. Each modifier may be preceded by a ~ character to indicate that the modifier must not be present. If None is specified, no modifier may be present.

The result specifies a string, keysym, or both, that the X client receives as input when the sequence of events is input:

STRING | keysym | STRING keysym

Keysyms are specified without the XK_ prefix.

Strings may be direct text encoded in the locale for which the compose file is to be used, or an escaped octal or hexadecimal character code. Octal codes are specified as \123 and hexadecimal codes as :. It is not necessary to specify in the right part of a rule a locale encoded string in addition to the keysym name. If the string is omitted, Xlib figures it out from the keysym according to the current locale. I.e., if a rule looks like:

<dead_grave> <A> : \300 Agrave

the result of the composition is always the letter with the “\300” code. But if the rule is:

<dead_grave> <A> : Agrave

the result depends on how Agrave is mapped in the current locale.

ENVIRONMENT

XCOMPOSEFILE
File to use for compose sequences.

XCOMPOSECACHE
Directory to use for caching compiled compose files.

FILES

$HOME/.XCompose
User default compose file if XCOMPOSEFILE is not set.

/usr/share/X11/locale/compose.dir
File listing the compose file path to use for each locale.

/usr/share/X11/locale/<localemapping>/Compose
System default compose file for the locale, mapped via compose.dir.

/var/cache/libx11/compose/
System-wide cache directory for compiled compose files.

$HOME/.compose-cache/
Per-user cache directory for compiled compose files.

189 - Linux cli command [email protected]

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command [email protected] and provides detailed information about the command [email protected], system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the [email protected].

NAME 🖥️ [email protected] 🖥️

System unit for the capsule service manager

SYNOPSIS

capsule@NAME.service

DESCRIPTION

Service managers for capsules run in capsule@NAME.service system units, with the capsule name as the instance identifier. Capsules are way to run additional instances of the service manager, under dynamic user IDs, i.e. UIDs that are allocated when the capsule service manager is started, and released when it is stopped.

In many ways [email protected] is similar to the per-user [email protected] service manager, but there are a few important distinctions:

·
The capsule service manager utilizes DynamicUser= (see systemd.exec(5)) to allocate a new UID dynamically on invocation. The user name is automatically generated from the capsule name, by prefixing “c-”. The UID is released when the service is terminated. The user service manager on the other hand operates under a statically allocated user ID that must be pre-existing, before the user service manager is invoked.

·
User service managers register themselves with pam(8), capsule service managers do not.

·
User service managers typically read their configuration from a $HOME directory below /home/, capsule service managers from a $HOME directory below /var/lib/capsules/.

·
User service managers are collectively contained in the user.slice unit, capsule service managers in capsule.slice. Also see systemd.special(7).

·
User service managers start the user unit default.target initially. Capsule service managers invoke the user unit [email protected] instead.

The capsule service manager and the capsules bus broker can be reached via the –capsule= switch to systemctl(1), systemd-run(1) and busctl(1).

New capsules can be started via a simple systemctl start capsule@NAME.service command, and stopped via systemctl stop capsule@NAME.service. Starting a capsule will implicitly create a home directory /var/lib/capsules/NAME/, if missing. A runtime directory is created as /run/capsules/NAME/. To remove these resources use systemctl clean capsule@NAME.service, for example with the –what=all switch.

The [email protected] unit invokes a systemd –user service manager process. This means unit files are looked for according to the sames rules as for regular user service managers, for example in /var/lib/capsules/NAME/.config/systemd/user/.

Capsule names may be chosen freely by the user, however, they must be suitable as UNIX filenames (i.e. 255 characters max, and contain no “/”), and when prefixed with “p-” be suitable as a user name matching strict POSIX rules, see User/Group Name Syntax[1] for details.

Added in version 256.

EXAMPLES

Example 1. Create a new capsule, invoke two programs in it (one interactively), terminate it, and clean everything up

systemctl start [email protected]

# systemd-run --capsule=tatze --unit=sleeptest.service sleep 999
# systemctl --capsule=tatze status sleeptest.service
# systemd-run -t --capsule=tatze bash
# systemctl --capsule=tatze stop sleeptest.service
# systemctl stop [email protected]
# systemctl clean --all [email protected]

NOTES

User/Group Name Syntax

https://systemd.io/USER_NAMES

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

190 - Linux cli command proc_filesystems

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_filesystems and provides detailed information about the command proc_filesystems, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_filesystems.

NAME 🖥️ proc_filesystems 🖥️

supported filesystems

DESCRIPTION

/proc/filesystems
A text listing of the filesystems which are supported by the kernel, namely filesystems which were compiled into the kernel or whose kernel modules are currently loaded. (See also filesystems(5).) If a filesystem is marked with “nodev”, this means that it does not require a block device to be mounted (e.g., virtual filesystem, network filesystem).

Incidentally, this file may be used by mount(8) when no filesystem is specified and it didn’t manage to determine the filesystem type. Then filesystems contained in this file are tried (excepted those that are marked with “nodev”).

191 - Linux cli command systemd.pcrlock

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.pcrlock and provides detailed information about the command systemd.pcrlock, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.pcrlock.

NAME 🖥️ systemd.pcrlock 🖥️

PCR measurement prediction files

SYNOPSIS

/etc/pcrlock.d/*.pcrlock

/etc/pcrlock.d/*.pcrlock.d/*.pcrlock

/run/pcrlock.d/*.pcrlock

/run/pcrlock.d/*.pcrlock.d/*.pcrlock

/var/lib/pcrlock.d/*.pcrlock

/var/lib/pcrlock.d/*.pcrlock.d/*.pcrlock

/usr/local/pcrlock.d/*.pcrlock

/usr/local/pcrlock.d/*.pcrlock.d/*.pcrlock

/usr/lib/pcrlock.d/*.pcrlock

/usr/lib/pcrlock.d/*.pcrlock.d/*.pcrlock

DESCRIPTION

*.pcrlock files define expected TPM2 PCR measurements of components involved in the boot process. systemd-pcrlock(1) uses such pcrlock files to analyze and predict TPM2 PCR measurements. The pcrlock files are JSON arrays that follow a subset of the TCG Canonical Event Log Format (CEL-JSON)[1] specification. Specifically the “recnum”, “content”, and “content_type” record fields are not used and ignored if present. Each pcrlock file defines one set of expected, ordered PCR measurements of a specific component of the boot.

*.pcrlock files may be placed in various .d/ drop-in directories (see above for a full list). All matching files discovered in these directories are sorted alphabetically by their file name (without taking the actual directory they were found in into account): pcrlock files with alphabetically earlier names are expected to cover measurements done before those with alphabetically later names. In order to make positioning pcrlock files in the boot process convenient the files are expected (by convention, this is not enforced) to be named “NNN-component.pcrlock” (where NNN is a three-digit decimal number), for example 750-enter-initrd.pcrlock.

For various components of the boot process more than one alternative pcrlock file shall be supported (i.e. “variants”). For example to cover multiple kernels installed in parallel in the access policy, or multiple versions of the boot loader. This can be done by placing *.pcrlock.d/*.pcrlock in the drop-in dirs, i.e. a common directory for a specific component, that contains one or more pcrlock files each covering one variant of the component. Example: 650-kernel.pcrlock.d/6.5.5-200.fc38.x86_64.pcrlock and 650-kernel.pcrlock.d/6.5.7-100.fc38.x86_64.pcrlock

Use systemd-pcrlock list-components to list all pcrlock files currently installed.

Use the various lock-* commands of systemd-pcrlock to automatically generate suitable pcrlock files for various types of resources.

WELL-KNOWN COMPONENTS

Components of the boot process may be defined freely by the administrator or OS vendor. The following components are well-known however, and are defined by systemd. The list below is useful for ordering local pcrlock files properly against these components of the boot.

240-secureboot-policy.pcrlock

The SecureBoot policy, as recorded to PCR 7. May be generated via systemd-pcrlock lock-secureboot-policy.
Added in version 255.

250-firmware-code-early.pcrlock

Firmware code measurements, as recorded to PCR 0 and 2, up to the separator measurement (see 400-secureboot-separator.pcrlock below). May be generated via systemd-pcrlock lock-firmware-code.
Added in version 255.

250-firmware-config-early.pcrlock

Firmware configuration measurements, as recorded to PCR 1 and 3, up to the separator measurement (see 400-secureboot-separator.pcrlock below). May be generated via systemd-pcrlock lock-firmware-config.
Added in version 255.

350-action-efi-application.pcrlock

The EFI “Application” measurement done once by the firmware. Statically defined.
Added in version 255.

400-secureboot-separator.pcrlock

The EFI “separator” measurement on PCR 7 done once by the firmware to indicate where firmware control transitions into boot loader/OS control. Statically defined.
Added in version 255.

500-separator.pcrlock

The EFI “separator” measurements on PCRs 0-6 done once by the firmware to indicate where firmware control transitions into boot loader/OS control. Statically defined.
Added in version 255.

550-firmware-code-late.pcrlock

Firmware code measurements, as recorded to PCR 0 and 2, after the separator measurement (see 400-secureboot-separator.pcrlock above). May be generated via systemd-pcrlock lock-firmware-code.
Added in version 255.

550-firmware-config-late.pcrlock

Firmware configuration measurements, as recorded to PCR 1 and 3, after the separator measurement (see 400-secureboot-separator.pcrlock above). May be generated via systemd-pcrlock lock-firmware-config.
Added in version 255.

600-gpt.pcrlock

The GPT partition table of the booted medium, as recorded to PCR 5 by the firmware. May be generated via systemd-pcrlock lock-gpt.
Added in version 255.

620-secureboot-authority.pcrlock

The SecureBoot authority, as recorded to PCR 7. May be generated via systemd-pcrlock lock-secureboot-authority.
Added in version 255.

700-action-efi-exit-boot-services.pcrlock

The EFI action generated when ExitBootServices() is generated, i.e. when the UEFI environment is left and the OS takes over. Covers the PCR 5 measurement. Statically defined.
Added in version 255.

710-kernel-cmdline.pcrlock

The kernel command line, as measured by the Linux kernel to PCR 9. May be generated via systemd-pcrlock lock-kernel-cmdline.
Added in version 255.

720-kernel-initrd.pcrlock

The kernel initrd, as measured by the Linux kernel to PCR 9. May be generated via systemd-pcrlock lock-kernel-initrd.
Added in version 255.

750-enter-initrd.pcrlock

The measurement to PCR 11 systemd-pcrphase-initrd.service(8) makes when the initrd initializes. Statically defined.
Added in version 255.

800-leave-initrd.pcrlock

The measurement to PCR 11 systemd-pcrphase-initrd.service(8) makes when the initrd finishes. Statically defined.
Added in version 255.

820-machine-id.pcrlock

The measurement to PCR 15 systemd-pcrmachine.service(8) makes at boot, covering /etc/machine-id contents. May be generated via systemd-pcrlock lock-machine-id.
Added in version 255.

830-root-file-system.pcrlock

The measurement to PCR 15 systemd-pcrfs-root.service(8) makes at boot, covering the root file system identity. May be generated via systemd-pcrlock lock-file-system.
Added in version 255.

850-sysinit.pcrlock

The measurement to PCR 11 systemd-pcrphase-sysinit.service(8) makes when the main userspace did basic initialization and will now proceed to start regular system services. Statically defined.
Added in version 255.

900-ready.pcrlock

The measurement to PCR 11 systemd-pcrphase.service(8) makes when the system fully booted up. Statically defined.
Added in version 255.

950-shutdown.pcrlock

The measurement to PCR 11 systemd-pcrphase.service(8) makes when the system begins shutdown. Statically defined.
Added in version 255.

990-final.pcrlock

The measurement to PCR 11 systemd-pcrphase-sysinit.service(8) makes when the system is close to finishing shutdown. Statically defined.
Added in version 255.

NOTES

TCG Canonical Event Log Format (CEL-JSON)

https://trustedcomputinggroup.org/resource/canonical-event-log-format/

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

192 - Linux cli command proc_sys

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_sys and provides detailed information about the command proc_sys, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_sys.

NAME 🖥️ proc_sys 🖥️

system information, and sysctl pseudo-filesystem

DESCRIPTION

/proc/sys/
This directory (present since Linux 1.3.57) contains a number of files and subdirectories corresponding to kernel variables. These variables can be read and in some cases modified using the /proc filesystem, and the (deprecated) sysctl(2) system call.

String values may be terminated by either ‘�’ or ' ‘.

Integer and long values may be written either in decimal or in hexadecimal notation (e.g., 0x3FFF). When writing multiple integer or long values, these may be separated by any of the following whitespace characters: ’ ‘, ’ ‘, or ' ‘. Using other separators leads to the error EINVAL.

193 - Linux cli command GeoIP.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command GeoIP.conf and provides detailed information about the command GeoIP.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the GeoIP.conf.

NAME 🖥️ GeoIP.conf 🖥️

Configuration file for geoipupdate

SYNOPSIS

This file allows you to configure your geoipupdate program to download GeoIP2 and GeoLite2 databases.

DESCRIPTION

The file consists of one setting per line. Lines starting with # are comments and will not be processed. All setting keywords are case sensitive.

Required settings:

AccountID
Your MaxMind account ID. This was formerly known as UserId. This can be overridden at run time by either the GEOIPUPDATE_ACCOUNT_ID or the GEOIPUPDATE_ACCOUNT_ID_FILE environment variables.

LicenseKey
Your case-sensitive MaxMind license key. This can be overridden at run time by either the GEOIPUPDATE_LICENSE_KEY or GEOIPUPDATE_LICENSE_KEY_FILE environment variables.

EditionIDs
List of space-separated database edition IDs. Edition IDs may consist of letters, digits, and dashes. For example, GeoIP2-City would download the GeoIP2 City database (GeoIP2-City). This can be overridden at run time by the GEOIPUPDATE_EDITION_IDS environment variable. Note: this was formerly called ProductIds.

Optional settings:

DatabaseDirectory
The directory to store the database files. If not set, the default is /var/lib/GeoIP. This can be overridden at run time by the GEOIPUPDATE_DB_DIR environment variable or the -d command line argument.

Host
The host name of the server to use. The default is updates.maxmind.com. This can be overridden at run time by the GEOIPUPDATE_HOST environment variable.

Proxy
The proxy host name or IP address. You may optionally specify a port number, e.g., 127.0.0.1:8888. If no port number is specified, 1080 will be used. This can be overridden at run time by the GEOIPUPDATE_PROXY environment variable.

ProxyUserPassword
The proxy user name and password, separated by a colon. For instance, username:password. This can be overridden at run time by the GEOIPUPDATE_PROXY_USER_PASSWORD environment variable.

PreserveFileTimes
Whether to preserve modification times of files downloaded from the server. This option is either 0 or 1. The default is 0. This can be overridden at run time by the GEOIPUPDATE_PRESERVE_FILE_TIMES environment variable.

LockFile
The lock file to use. This ensures only one geoipupdate process can run at a time. Note: Once created, this lockfile is not removed from the filesystem. The default is .geoipupdate.lock under the DatabaseDirectory. This can be overridden at run time by the GEOIPUPDATE_LOCK_FILE environment variable.

RetryFor
The amount of time to retry for when errors during HTTP transactions are encountered. It can be specified as a (possibly fractional) decimal number followed by a unit suffix. Valid time units are ns, us (or µs), ms, s, m, h. The default is 5m (5 minutes). This can be overridden at run time by the GEOIPUPDATE_RETRY_FOR environment variable.

Parallelism
The maximum number of parallel database downloads. The default is 1, which means that databases will be downloaded sequentially. This can be overridden at run time by the GEOIPUPDATE_PARALLELISM environment variable or the –parallelism command line argument.

Deprecated settings:

The following are deprecated and will be ignored if present:

Protocol

SkipPeerVerification

SkipHostnameVerification

194 - Linux cli command Xsession.options

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command Xsession.options and provides detailed information about the command Xsession.options, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the Xsession.options.

NAME 🖥️ Xsession.options 🖥️

configuration options for Xsession(5)

DESCRIPTION

Available options are:

allow-user-resources
If users have a file called .Xresources in their home directories, these resources will be merged with the default X resources when they log in.

use-session-dbus
If the dbus package is installed, the session bus will be activated at X session launch.

All of the above options are enabled by default. Additional options may be supported by the local administrator. Xsession(5) describes how this is accomplished.

AUTHORS

Stephen Early, Mark Eichin, and Branden Robinson developed Debian’s X session handling scripts. Branden Robinson wrote this manual page.

195 - Linux cli command terminfo

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command terminfo and provides detailed information about the command terminfo, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the terminfo.

NAME 🖥️ terminfo 🖥️

terminal capability database

SYNOPSIS

/etc/terminfo/*/*

DESCRIPTION

Terminfo is a database describing terminals, used by screen-oriented programs such as nvi(1), lynx(1), mutt(1), and other curses applications, using high-level calls to libraries such as ncurses(3NCURSES). It is also used via low-level calls by non-curses applications which may be screen-oriented (such as clear(1)) or non-screen (such as tabs(1)).

Terminfo describes terminals by giving a set of capabilities which they have, by specifying how to perform screen operations, and by specifying padding requirements and initialization sequences.

This document describes ncurses version 6.5 (patch 20240427).

terminfo Entry Syntax

Entries in terminfo consist of a sequence of fields:

Each field ends with a comma , (embedded commas may be escaped with a backslash or written as ,).
White space between fields is ignored.
The first field in a terminfo entry begins in the first column.
Newlines and leading whitespace (spaces or tabs) may be used for formatting entries for readability. These are removed from parsed entries.
The infocmp -f and -W options rely on this to format if-then-else expressions, or to enforce maximum line-width. The resulting formatted terminal description can be read by tic.
The first field for each terminal gives the names which are known for the terminal, separated by | characters.
The first name given is the most common abbreviation for the terminal (its primary name), the last name given should be a long name fully identifying the terminal (see longname(3NCURSES)), and all others are treated as synonyms (aliases) for the primary terminal name.
X/Open Curses advises that all names but the last should be in lower case and contain no blanks; the last name may well contain upper case and blanks for readability.
This implementation is not so strict; it allows mixed case in the primary name and aliases. If the last name has no embedded blanks, it allows that to be both an alias and a verbose name (but will warn about this ambiguity).
Lines beginning with a # in the first column are treated as comments.
While comment lines are valid at any point, the output of captoinfo and infotocap (aliases for tic) will move comments so they occur only between entries.

Terminal names (except for the last, verbose entry) should be chosen using the following conventions. The particular piece of hardware making up the terminal should have a root name, thus hp2621. This name should not contain hyphens. Modes that the hardware can be in, or user preferences, should be indicated by appending a hyphen and a mode suffix. Thus, a vt100 in 132-column mode would be vt100-w. The following suffixes should be used where possible:

Suffix	Example	Meaning
-nn	aaa-60	Number of lines on the screen
-np	c100-4p	Number of pages of memory
-am	vt100-am	With automargins (usually the default)
-m	ansi-m	Mono mode; suppress color
-mc	wy30-mc	Magic cookie; spaces when highlighting
-na	c100-na	No arrow keys (leave them in local)
-nam	vt100-nam	Without automatic margins
-nl	hp2621-nl	No status line
-ns	hp2626-ns	No status line
-rv	c100-rv	Reverse video
-s	vt100-s	Enable status line
-vb	wy370-vb	Use visible bell instead of beep
-w	vt100-w	Wide mode (> 80 columns, usually 132)

For more on terminal naming conventions, see the term(7) manual page.

terminfo Capabilities Syntax

The terminfo entry consists of several capabilities, i.e., features that the terminal has, or methods for exercising the terminal’s features.

After the first field (giving the name(s) of the terminal entry), there should be one or more capability fields. These are Boolean, numeric or string names with corresponding values:

Boolean capabilities are true when present, false when absent. There is no explicit value for Boolean capabilities.
Numeric capabilities have a # following the name, then an unsigned decimal integer value.
String capabilities have a = following the name, then an string of characters making up the capability value.
String capabilities can be split into multiple lines, just as the fields comprising a terminal entry can be split into multiple lines. While blanks between fields are ignored, blanks embedded within a string value are retained, except for leading blanks on a line.

Any capability can be canceled, i.e., suppressed from the terminal entry, by following its name with @ rather than a capability value.

Similar Terminals

If there are two very similar terminals, one (the variant) can be defined as being just like the other (the base) with certain exceptions. In the definition of the variant, the string capability use can be given with the name of the base terminal:

The capabilities given before use override those in the base type named by use.
If there are multiple use capabilities, they are merged in reverse order. That is, the rightmost use reference is processed first, then the one to its left, and so forth.
Capabilities given explicitly in the entry override those brought in by use references.

A capability can be canceled by placing xx@ to the left of the use reference that imports it, where xx is the capability. For example, the entry

2621-nl, smkx@, rmkx@, use=2621,

defines a 2621-nl that does not have the smkx or rmkx capabilities, and hence does not turn on the function key labels when in visual mode. This is useful for different modes for a terminal, or for different user preferences.

An entry included via use can contain canceled capabilities, which have the same effect as if those cancels were inline in the using terminal entry.

Predefined Capabilities

Tables of capabilities ncurses recognizes in a terminfo terminal type description and available to terminfo-using code follow.

The capability name identifies the symbol by which the programmer using the terminfo API accesses the capability.
The TI (terminfo) code is the short name used by a person composing or updating a terminal type entry.
Whenever possible, these codes are the same as or similar to those of the ANSI X3.64-1979 standard (now superseded by ECMA-48, which uses identical or very similar names). Semantics are also intended to match those of the specification.
terminfo codes have no hard length limit, but ncurses maintains an informal one of 5 characters to keep them short and to allow the tabs in the source file Caps to line up nicely. (Some standard codes exceed this limit regardless.)
The TC (termcap) code is that used by the corresponding API of ncurses. (Some capabilities are new, and have names that BSD termcap did not originate.)
The description field attempts to convey the capability’s semantics.

The description field employs a handful of notations.

(P)
indicates that padding may be specified.

(P*)
indicates that padding may vary in proportion to the number of output lines affected.

**#**i
indicates the ith parameter of a string capability; the programmer should pass the string to tparm(3NCURSES) with the parameters listed.

If the description lists no parameters, passing the string to tparm(3NCURSES) may produce unexpected behavior, for instance if the string contains percent signs.

TABLE

The following numeric capabilities are present in the SVr4.0 term structure, but are not yet documented in the man page. They came in with SVr4’s printer support.

TABLE

key_eic	krmir	kM	sent by rmir or smir in insert mode
key_eol	kel	kE	clear-to-end-of-line key
key_eos	ked	kS	clear-to-end-of-screen key
key_f0	kf0	k0	F0 function key
key_f1	kf1	k1	F1 function key
key_f10	kf10	k;	F10 function key
key_f2	kf2	k2	F2 function key
key_f3	kf3	k3	F3 function key
key_f4	kf4	k4	F4 function key
key_f5	kf5	k5	F5 function key
key_f6	kf6	k6	F6 function key
key_f7	kf7	k7	F7 function key
key_f8	kf8	k8	F8 function key
key_f9	kf9	k9	F9 function key
key_home	khome	kh	home key
key_ic	kich1	kI	insert-character key
key_il	kil1	kA	insert-line key
key_left	kcub1	kl	left-arrow key
key_ll	kll	kH	lower-left key (home down)
key_npage	knp	kN	next-page key
key_ppage	kpp	kP	previous-page key
key_right	kcuf1	kr	right-arrow key
key_sf	kind	kF	scroll-forward key
key_sr	kri	kR	scroll-backward key
key_stab	khts	kT	set-tab key
key_up	kcuu1	ku	up-arrow key
keypad_local	rmkx	ke	leave keyboard transmit mode
keypad_xmit	smkx	ks	enter keyboard transmit mode
lab_f0	lf0	l0	label on function key f0 if not f0
lab_f1	lf1	l1	label on function key f1 if not f1
lab_f10	lf10	la	label on function key f10 if not f10
lab_f2	lf2	l2	label on function key f2 if not f2
lab_f3	lf3	l3	label on function key f3 if not f3
lab_f4	lf4	l4	label on function key f4 if not f4
lab_f5	lf5	l5	label on function key f5 if not f5
lab_f6	lf6	l6	label on function key f6 if not f6
lab_f7	lf7	l7	label on function key f7 if not f7
lab_f8	lf8	l8	label on function key f8 if not f8
lab_f9	lf9	l9	label on function key f9 if not f9
meta_off	rmm	mo	turn off meta mode
meta_on	smm	mm	turn on meta mode (8th-bit on)
newline	nel	nw	newline (behave like cr followed by lf)
pad_char	pad	pc	padding char (instead of null)
parm_dch	dch	DC	delete #1 characters (P*)
parm_delete_line	dl	DL	delete #1 lines (P*)
parm_down_cursor	cud	DO	down #1 lines (P*)
parm_ich	ich	IC	insert #1 characters (P*)
parm_index	indn	SF	scroll forward #1 lines (P)
parm_insert_line	il	AL	insert #1 lines (P*)
parm_left_cursor	cub	LE	move #1 characters to the left (P)
parm_right_cursor	cuf	RI	move #1 characters to the right (P*)
parm_rindex	rin	SR	scroll back #1 lines (P)
parm_up_cursor	cuu	UP	up #1 lines (P*)
pkey_key	pfkey	pk	program function key #1 to type string #2
pkey_local	pfloc	pl	program function key #1 to execute string #2
pkey_xmit	pfx	px	program function key #1 to transmit string #2
print_screen	mc0	ps	print contents of screen
prtr_off	mc4	pf	turn off printer
prtr_on	mc5	po	turn on printer
repeat_char	rep	rp	repeat char #1 #2 times (P*)
reset_1string	rs1	r1	reset string
reset_2string	rs2	r2	reset string

reset_3string	rs3	r3	reset string
reset_file	rf	rf	name of reset file
restore_cursor	rc	rc	restore cursor to position of last save_cursor
row_address	vpa	cv	vertical position #1 absolute (P)
save_cursor	sc	sc	save current cursor position (P)
scroll_forward	ind	sf	scroll text up (P)
scroll_reverse	ri	sr	scroll text down (P)
set_attributes	sgr	sa	define video attributes #1-#9 (PG9)
set_tab	hts	st	set a tab in every row, current columns
set_window	wind	wi	current window is lines #1-#2 cols #3-#4
tab	ht	ta	tab to next 8-space hardware tab stop
to_status_line	tsl	ts	move to status line, column #1
underline_char	uc	uc	underline char and move past it
up_half_line	hu	hu	half a line up
init_prog	iprog	iP	path name of program for initialization
key_a1	ka1	K1	upper left of keypad
key_a3	ka3	K3	upper right of keypad
key_b2	kb2	K2	center of keypad
key_c1	kc1	K4	lower left of keypad
key_c3	kc3	K5	lower right of keypad
prtr_non	mc5p	pO	turn on printer for #1 bytes
char_padding	rmp	rP	like ip but when in insert mode
acs_chars	acsc	ac	graphics charset pairs, based on vt100
plab_norm	pln	pn	program label #1 to show string #2
key_btab	kcbt	kB	back-tab key
enter_xon_mode	smxon	SX	turn on xon/xoff handshaking
exit_xon_mode	rmxon	RX	turn off xon/xoff handshaking
enter_am_mode	smam	SA	turn on automatic margins
exit_am_mode	rmam	RA	turn off automatic margins
xon_character	xonc	XN	XON character
xoff_character	xoffc	XF	XOFF character
ena_acs	enacs	eA	enable alternate char set
label_on	smln	LO	turn on soft labels
label_off	rmln	LF	turn off soft labels
key_beg	kbeg	@1	begin key
key_cancel	kcan	@2	cancel key
key_close	kclo	@3	close key
key_command	kcmd	@4	command key
key_copy	kcpy	@5	copy key
key_create	kcrt	@6	create key
key_end	kend	@7	end key
key_enter	kent	@8	enter/send key
key_exit	kext	@9	exit key
key_find	kfnd	@0	find key
key_help	khlp	%1	help key
key_mark	kmrk	%2	mark key
key_message	kmsg	%3	message key
key_move	kmov	%4	move key
key_next	knxt	%5	next key
key_open	kopn	%6	open key
key_options	kopt	%7	options key
key_previous	kprv	%8	previous key
key_print	kprt	%9	print key
key_redo	krdo	%0	redo key
key_reference	kref	&1	reference key
key_refresh	krfr	&2	refresh key
key_replace	krpl	&3	replace key
key_restart	krst	&4	restart key
key_resume	kres	&5	resume key
key_save	ksav	&6	save key
key_suspend	kspd	&7	suspend key
key_undo	kund	&8	undo key

key_sbeg	kBEG	&9	shifted begin key
key_scancel	kCAN	&0	shifted cancel key
key_scommand	kCMD	*1	shifted command key
key_scopy	kCPY	*2	shifted copy key
key_screate	kCRT	*3	shifted create key
key_sdc	kDC	*4	shifted delete-character key
key_sdl	kDL	*5	shifted delete-line key
key_select	kslt	*6	select key
key_send	kEND	*7	shifted end key
key_seol	kEOL	*8	shifted clear-to-end-of-line key
key_sexit	kEXT	*9	shifted exit key
key_sfind	kFND	*0	shifted find key
key_shelp	kHLP	#1	shifted help key
key_shome	kHOM	#2	shifted home key
key_sic	kIC	#3	shifted insert-character key
key_sleft	kLFT	#4	shifted left-arrow key
key_smessage	kMSG	%a	shifted message key
key_smove	kMOV	%b	shifted move key
key_snext	kNXT	%c	shifted next key
key_soptions	kOPT	%d	shifted options key
key_sprevious	kPRV	%e	shifted previous key
key_sprint	kPRT	%f	shifted print key
key_sredo	kRDO	%g	shifted redo key
key_sreplace	kRPL	%h	shifted replace key
key_sright	kRIT	%i	shifted right-arrow key
key_srsume	kRES	%j	shifted resume key
key_ssave	kSAV	!1	shifted save key
key_ssuspend	kSPD	!2	shifted suspend key
key_sundo	kUND	!3	shifted undo key
req_for_input	rfi	RF	send next input char (for ptys)
key_f11	kf11	F1	F11 function key
key_f12	kf12	F2	F12 function key
key_f13	kf13	F3	F13 function key
key_f14	kf14	F4	F14 function key
key_f15	kf15	F5	F15 function key
key_f16	kf16	F6	F16 function key
key_f17	kf17	F7	F17 function key
key_f18	kf18	F8	F18 function key
key_f19	kf19	F9	F19 function key
key_f20	kf20	FA	F20 function key
key_f21	kf21	FB	F21 function key
key_f22	kf22	FC	F22 function key
key_f23	kf23	FD	F23 function key
key_f24	kf24	FE	F24 function key
key_f25	kf25	FF	F25 function key
key_f26	kf26	FG	F26 function key
key_f27	kf27	FH	F27 function key
key_f28	kf28	FI	F28 function key
key_f29	kf29	FJ	F29 function key
key_f30	kf30	FK	F30 function key
key_f31	kf31	FL	F31 function key
key_f32	kf32	FM	F32 function key
key_f33	kf33	FN	F33 function key
key_f34	kf34	FO	F34 function key
key_f35	kf35	FP	F35 function key
key_f36	kf36	FQ	F36 function key
key_f37	kf37	FR	F37 function key
key_f38	kf38	FS	F38 function key
key_f39	kf39	FT	F39 function key
key_f40	kf40	FU	F40 function key
key_f41	kf41	FV	F41 function key
key_f42	kf42	FW	F42 function key

key_f43	kf43	FX	F43 function key
key_f44	kf44	FY	F44 function key
key_f45	kf45	FZ	F45 function key
key_f46	kf46	Fa	F46 function key
key_f47	kf47	Fb	F47 function key
key_f48	kf48	Fc	F48 function key
key_f49	kf49	Fd	F49 function key
key_f50	kf50	Fe	F50 function key
key_f51	kf51	Ff	F51 function key
key_f52	kf52	Fg	F52 function key
key_f53	kf53	Fh	F53 function key
key_f54	kf54	Fi	F54 function key
key_f55	kf55	Fj	F55 function key
key_f56	kf56	Fk	F56 function key
key_f57	kf57	Fl	F57 function key
key_f58	kf58	Fm	F58 function key
key_f59	kf59	Fn	F59 function key
key_f60	kf60	Fo	F60 function key
key_f61	kf61	Fp	F61 function key
key_f62	kf62	Fq	F62 function key
key_f63	kf63	Fr	F63 function key
clr_bol	el1	cb	Clear to beginning of line
clear_margins	mgc	MC	clear right and left soft margins
set_left_margin	smgl	ML	set left soft margin at current column (not in BSD termcap)
set_right_margin	smgr	MR	set right soft margin at current column
label_format	fln	Lf	label format
set_clock	sclk	SC	set clock, #1 hrs #2 mins #3 secs
display_clock	dclk	DK	display clock
remove_clock	rmclk	RC	remove clock
create_window	cwin	CW	define a window #1 from #2,#3 to #4,#5
goto_window	wingo	WG	go to window #1
hangup	hup	HU	hang-up phone
dial_phone	dial	DI	dial number #1
quick_dial	qdial	QD	dial number #1 without checking
tone	tone	TO	select touch tone dialing
pulse	pulse	PU	select pulse dialing
flash_hook	hook	fh	flash switch hook
fixed_pause	pause	PA	pause for 2-3 seconds
wait_tone	wait	WA	wait for dial-tone
user0	u0	u0	User string #0
user1	u1	u1	User string #1
user2	u2	u2	User string #2
user3	u3	u3	User string #3
user4	u4	u4	User string #4
user5	u5	u5	User string #5
user6	u6	u6	User string #6
user7	u7	u7	User string #7
user8	u8	u8	User string #8
user9	u9	u9	User string #9
orig_pair	op	op	Set default pair to its original value
orig_colors	oc	oc	Set all color pairs to the original ones
initialize_color	initc	Ic	initialize color #1 to (#2,#3,#4)
initialize_pair	initp	Ip	Initialize color pair #1 to fg=(#2,#3,#4), bg=(#5,#6,#7)
set_color_pair	scp	sp	Set current color pair to #1
set_foreground	setf	Sf	Set foreground color #1
set_background	setb	Sb	Set background color #1
change_char_pitch	cpi	ZA	Change number of characters per inch to #1
change_line_pitch	lpi	ZB	Change number of lines per inch to #1
change_res_horz	chr	ZC	Change horizontal resolution to #1
change_res_vert	cvr	ZD	Change vertical resolution to #1
define_char	defc	ZE	Define a character #1, #2 dots wide, descender #3
enter_doublewide_mode	swidm	ZF	Enter double-wide mode

enter_draft_quality	sdrfq	ZG	Enter draft-quality mode
enter_italics_mode	sitm	ZH	Enter italic mode
enter_leftward_mode	slm	ZI	Start leftward carriage motion
enter_micro_mode	smicm	ZJ	Start micro-motion mode
enter_near_letter_quality	snlq	ZK	Enter NLQ mode
enter_normal_quality	snrmq	ZL	Enter normal-quality mode
enter_shadow_mode	sshm	ZM	Enter shadow-print mode
enter_subscript_mode	ssubm	ZN	Enter subscript mode
enter_superscript_mode	ssupm	ZO	Enter superscript mode
enter_upward_mode	sum	ZP	Start upward carriage motion
exit_doublewide_mode	rwidm	ZQ	End double-wide mode
exit_italics_mode	ritm	ZR	End italic mode
exit_leftward_mode	rlm	ZS	End left-motion mode
exit_micro_mode	rmicm	ZT	End micro-motion mode
exit_shadow_mode	rshm	ZU	End shadow-print mode
exit_subscript_mode	rsubm	ZV	End subscript mode
exit_superscript_mode	rsupm	ZW	End superscript mode
exit_upward_mode	rum	ZX	End reverse character motion
micro_column_address	mhpa	ZY	Like column_address in micro mode
micro_down	mcud1	ZZ	Like cursor_down in micro mode
micro_left	mcub1	Za	Like cursor_left in micro mode
micro_right	mcuf1	Zb	Like cursor_right in micro mode
micro_row_address	mvpa	Zc	Like row_address #1 in micro mode
micro_up	mcuu1	Zd	Like cursor_up in micro mode
order_of_pins	porder	Ze	Match software bits to print-head pins
parm_down_micro	mcud	Zf	Like parm_down_cursor in micro mode
parm_left_micro	mcub	Zg	Like parm_left_cursor in micro mode
parm_right_micro	mcuf	Zh	Like parm_right_cursor in micro mode
parm_up_micro	mcuu	Zi	Like parm_up_cursor in micro mode
select_char_set	scs	Zj	Select character set, #1
set_bottom_margin	smgb	Zk	Set bottom margin at current line
set_bottom_margin_parm	smgbp	Zl	Set bottom margin at line #1 or (if smgtp is not given) #2 lines from bottom
set_left_margin_parm	smglp	Zm	Set left (right) margin at column #1
set_right_margin_parm	smgrp	Zn	Set right margin at column #1
set_top_margin	smgt	Zo	Set top margin at current line
set_top_margin_parm	smgtp	Zp	Set top (bottom) margin at row #1
start_bit_image	sbim	Zq	Start printing bit image graphics
start_char_set_def	scsd	Zr	Start character set definition #1, with #2 characters in the set
stop_bit_image	rbim	Zs	Stop printing bit image graphics
stop_char_set_def	rcsd	Zt	End definition of character set #1
subscript_characters	subcs	Zu	List of subscriptable characters
superscript_characters	supcs	Zv	List of superscriptable characters
these_cause_cr	docr	Zw	Printing any of these characters causes CR
zero_motion	zerom	Zx	No motion for subsequent character

The following string capabilities are present in the SVr4.0 term structure, but were originally not documented in the man page.

TABLE

The XSI Curses standard added these hardcopy capabilities. They were used in some post-4.1 versions of System V curses, e.g., Solaris 2.5 and IRIX 6.x. Except for YI, the ncurses termcap names for them are invented. According to the XSI Curses standard, they have no termcap names. If your compiled terminfo entries use these, they may not be binary-compatible with System V terminfo entries after SVr4.1; beware!

TABLE

User-Defined Capabilities

The preceding section listed the predefined capabilities. They deal with some special features for terminals no longer (or possibly never) produced. Occasionally there are special features of newer terminals which are awkward or impossible to represent by reusing the predefined capabilities.

ncurses addresses this limitation by allowing user-defined capabilities. The tic and infocmp programs provide the -x option for this purpose. When -x is set, tic treats unknown capabilities as user-defined. That is, if tic encounters a capability name which it does not recognize, it infers its type (Boolean, number or string) from the syntax and makes an extended table entry for that capability. The use_extended_names(3NCURSES) function makes this information conditionally available to applications. The ncurses library provides the data leaving most of the behavior to applications:

User-defined capability strings whose name begins with k are treated as function keys.
The types (Boolean, number, string) determined by tic can be inferred by successful calls on tigetflag, etc.
If the capability name happens to be two characters, the capability is also available through the termcap interface.

While termcap is said to be extensible because it does not use a predefined set of capabilities, in practice it has been limited to the capabilities defined by terminfo implementations. As a rule, user-defined capabilities intended for use by termcap applications should be limited to Booleans and numbers to avoid running past the 1023 byte limit assumed by termcap implementations and their applications. In particular, providing extended sets of function keys (past the 60 numbered keys and the handful of special named keys) is best done using the longer names available using terminfo.

The ncurses library uses a few of these user-defined capabilities, as described in user_caps(5). Other user-defined capabilities (including function keys) are described in the terminal database, in the section on NCURSES USER-DEFINABLE CAPABILITIES

A Sample Entry

The following entry, describing an ANSI-standard terminal, is representative of what a terminfo entry for a modern terminal typically looks like.

ansi|ansi/pc-term compatible with color,
        am, mc5i, mir, msgr,
        colors#8, cols#80, it#8, lines#24, ncv#3, pairs#64,
        acsc=+\,-.Y0\333`a\261f\370g\361h\260
             j\331k\277l\332m\300n\305op\304q\304r\304s_t\303
             u\264v\301w\302x\263y\363z\362{\343|\330}\234\376,
        bel=G, blink=[5m, bold=[1m, cbt=[Z, clear=[H[J,
        cr=M, cub=[%p1%dD, cub1=[D, cud=[%p1%dB, cud1=[B,
        cuf=[%p1%dC, cuf1=[C, cup=[%i%p1%d;%p2%dH,
        cuu=[%p1%dA, cuu1=[A, dch=[%p1%dP, dch1=[P,
        dl=[%p1%dM, dl1=[M, ech=[%p1%dX, ed=[J, el=[K,
        el1=[1K, home=[H, hpa=[%i%p1%dG, ht=[I, hts=H,
        ich=[%p1%d@, il=[%p1%dL, il1=[L, ind=J,
        indn=[%p1%dS, invis=[8m, kbs=H, kcbt=[Z, kcub1=[D,
        kcud1=[B, kcuf1=[C, kcuu1=[A, khome=[H, kich1=[L,
        mc4=[4i, mc5=[5i, nel=
[S, op=[39;49m,
        rep=%p1%c[%p2%{1}%-%db, rev=[7m, rin=[%p1%dT,
        rmacs=[10m, rmpch=[10m, rmso=[m, rmul=[m,
        s0ds=(B, s1ds=)B, s2ds=*B, s3ds=+B,
        setab=[4%p1%dm, setaf=[3%p1%dm,
        sgr=[0;10%?%p1%t;7%;
                   %?%p2%t;4%;
                   %?%p3%t;7%;
                   %?%p4%t;5%;
                   %?%p6%t;1%;
                   %?%p7%t;8%;
                   %?%p9%t;11%;m,
        sgr0=[0;10m, smacs=[11m, smpch=[11m, smso=[7m,
        smul=[4m, tbc=[3g, u6=[%i%d;%dR, u7=[6n,
        u8=[?%[;0123456789]c, u9=[c, vpa=[%i%p1%dd,

Entries may continue onto multiple lines by placing white space at the beginning of each line except the first. Comments may be included on lines beginning with #. Capabilities in terminfo are of three types:

Boolean capabilities which indicate that the terminal has some particular feature,
numeric capabilities giving the size of the terminal or the size of particular delays, and
string capabilities, which give a sequence which can be used to perform particular terminal operations.

Types of Capabilities

All capabilities have names. For instance, the fact that ANSI-standard terminals have automatic margins (i.e., an automatic return and line-feed when the end of a line is reached) is indicated by the capability am. Hence the description of ansi includes am. Numeric capabilities are followed by the character # and then a positive value. Thus cols, which indicates the number of columns the terminal has, gives the value 80 for ansi. Values for numeric capabilities may be specified in decimal, octal, or hexadecimal, using the C programming language conventions (e.g., 255, 0377 and 0xff or 0xFF).

Finally, string valued capabilities, such as el (clear to end of line sequence) are given by the two-character code, an =, and then a string ending at the next following ,.

A number of escape sequences are provided in the string valued capabilities for easy encoding of characters there:

Both and map to an ESCAPE character,
x maps to a control-x for any appropriate x, and
the sequences
** **, \l, ** **, ** **, , ** **, and \s
produce
newline, line-feed, return, tab, backspace, form-feed, and space,
respectively.

X/Open Curses does not say what appropriate x might be. In practice, that is a printable ASCII graphic character. The special case ? is interpreted as DEL (127). In all other cases, the character value is AND’d with 0x1f, mapping to ASCII control codes in the range 0 through 31.

Other escapes include

** for ,
** for ****,
****, for comma,
** for :,
and � for null.
� will produce \200, which does not terminate a string but behaves as a null character on most terminals, providing CS7 is specified. See stty(1).
The reason for this quirk is to maintain binary compatibility of the compiled terminfo files with other implementations, e.g., the SVr4 systems, which document this. Compiled terminfo files use null-terminated strings, with no lengths. Modifying this would require a new binary format, which would not work with other implementations.

Finally, characters may be given as three octal digits after a ****.

A delay in milliseconds may appear anywhere in a string capability, enclosed in $<..> brackets, as in el=K$<5>, and padding characters are supplied by tputs(3NCURSES) to provide this delay.

The delay must be a number with at most one decimal place of precision; it may be followed by suffixes * or / or both.
A * indicates that the padding required is proportional to the number of lines affected by the operation, and the amount given is the per-affected-unit padding required. (In the case of insert character, the factor is still the number of lines affected.)
Normally, padding is advisory if the device has the xon capability; it is used for cost computation but does not trigger delays.
A / suffix indicates that the padding is mandatory and forces a delay of the given number of milliseconds even on devices for which xon is present to indicate flow control.

Sometimes individual capabilities must be commented out. To do this, put a period before the capability name. For example, see the second ind in the example above.

Fetching Compiled Descriptions

Terminal descriptions in ncurses are stored in terminal databases. These databases, which are found by their pathname, may be configured either as directory trees or hashed databases (see term(5)),

The library uses a compiled-in list of pathnames, which can be overridden by environment variables. Before starting to search, ncurses checks the search list, eliminating duplicates and pathnames where no terminal database is found. The ncurses library reads the first description which passes its consistency checks.

The environment variable TERMINFO is checked first, for a terminal database containing the terminal description.
Next, ncurses looks in $HOME/.terminfo for a compiled description.
This is an optional feature which may be omitted entirely from the library, or limited to prevent accidental use by privileged applications.
Next, if the environment variable TERMINFO_DIRS is set, ncurses interprets the contents of that variable as a list of colon-separated pathnames of terminal databases to be searched.
An empty pathname (i.e., if the variable begins or ends with a colon, or contains adjacent colons) is interpreted as the system location /etc/terminfo.
Finally, ncurses searches these compiled-in locations:
- a list of directories (/etc/terminfo:/lib/terminfo:/usr/share/terminfo), and
- the system terminfo directory, /etc/terminfo

The TERMINFO variable can contain a terminal description instead of the pathname of a terminal database. If this variable begins with hex: or b64: then ncurses reads a terminal description from hexadecimal- or base64-encoded data, and if that description matches the name sought, will use that. This encoded data can be set using the -Q option of tic or infocmp.

The preceding addresses the usual configuration of ncurses, which uses terminal descriptions prepared in terminfo format. While termcap is less expressive, ncurses can also be configured to read termcap descriptions. In that configuration, it checks the TERMCAP and TERMPATH variables (for content and search path, respectively) after the system terminal database.

Preparing Descriptions

We now outline how to prepare descriptions of terminals. The most effective way to prepare a terminal description is by imitating the description of a similar terminal in terminfo and to build up a description gradually, using partial descriptions with vi or some other screen-oriented program to check that they are correct. Be aware that a very unusual terminal may expose deficiencies in the ability of the terminfo file to describe it or bugs in the screen-handling code of the test program.

To get the padding for insert line right (if the terminal manufacturer did not document it) a severe test is to edit a large file at 9600 baud, delete 16 or so lines from the middle of the screen, then hit the u key several times quickly. If the terminal messes up, more padding is usually needed. A similar test can be used for insert character.

Basic Capabilities

The number of columns on each line for the terminal is given by the cols numeric capability. If the terminal is a CRT, then the number of lines on the screen is given by the lines capability. If the terminal wraps around to the beginning of the next line when it reaches the right margin, then it should have the am capability. If the terminal can clear its screen, leaving the cursor in the home position, then this is given by the clear string capability. If the terminal overstrikes (rather than clearing a position when a character is struck over) then it should have the os capability. If the terminal is a printing terminal, with no soft copy unit, give it both hc and os. (os applies to storage scope terminals, such as TEKTRONIX 4010 series, as well as hard copy and APL terminals.) If there is a code to move the cursor to the left edge of the current row, give this as cr. (Normally this will be carriage return, control/M.) If there is a code to produce an audible signal (bell, beep, etc) give this as bel.

If there is a code to move the cursor one position to the left (such as backspace) that capability should be given as cub1. Similarly, codes to move to the right, up, and down should be given as cuf1, cuu1, and cud1. These local cursor motions should not alter the text they pass over, for example, you would not normally use cuf1= because the space would erase the character moved over.

A very important point here is that the local cursor motions encoded in terminfo are undefined at the left and top edges of a CRT terminal. Programs should never attempt to backspace around the left edge, unless bw is given, and never attempt to go up locally off the top. In order to scroll text up, a program will go to the bottom left corner of the screen and send the ind (index) string.

To scroll text down, a program goes to the top left corner of the screen and sends the ri (reverse index) string. The strings ind and ri are undefined when not on their respective corners of the screen.

Parameterized versions of the scrolling sequences are indn and rin which have the same semantics as ind and ri except that they take one parameter, and scroll that many lines. They are also undefined except at the appropriate edge of the screen.

The am capability tells whether the cursor sticks at the right edge of the screen when text is output, but this does not necessarily apply to a cuf1 from the last column. The only local motion which is defined from the left edge is if bw is given, then a cub1 from the left edge will move to the right edge of the previous row. If bw is not given, the effect is undefined. This is useful for drawing a box around the edge of the screen, for example. If the terminal has switch selectable automatic margins, the terminfo file usually assumes that this is on; i.e., am. If the terminal has a command which moves to the first column of the next line, that command can be given as nel (newline). It does not matter if the command clears the remainder of the current line, so if the terminal has no cr and lf it may still be possible to craft a working nel out of one or both of them.

These capabilities suffice to describe hard-copy and glass-tty terminals. Thus the model 33 teletype is described as

 | tty33 | tty | model 33 teletype,
        bel=G, cols#72, cr=M, cud1=J, hc, ind=J, os,

while the Lear Siegler ADM-3 is described as

adm3 | 3 | lsi adm3,
        am, bel=G, clear=Z, cols#80, cr=M, cub1=H, cud1=J,
        ind=J, lines#24,

Parameterized Strings

Cursor addressing and other strings requiring parameters in the terminal are described by a parameterized string capability, with printf-like escapes such as %x in it. For example, to address the cursor, the cup capability is given, using two parameters: the row and column to address to. (Rows and columns are numbered from zero and refer to the physical screen visible to the user, not to any unseen memory.) If the terminal has memory relative cursor addressing, that can be indicated by mrcup.

The parameter mechanism uses a stack and special % codes to manipulate it. Typically a sequence will push one of the parameters onto the stack and then print it in some format. Print (e.g., %d) is a special case. Other operations, including %t pop their operand from the stack. It is noted that more complex operations are often necessary, e.g., in the sgr string.

The % encodings have the following meanings:

%%
outputs %

%[[:]flags][width[.precision]][doxXs]
as in printf(3), flags are [-+#] and space. Use a : to allow the next character to be a - flag, avoiding interpreting %- as an operator.

%c
print pop() like %c in printf

%s
print pop() like %s in printf

%p*[1-9]*
push i’th parameter

%P*[a-z]*
set dynamic variable [a-z] to pop()

%g*[a-z]*
get dynamic variable [a-z] and push it

%P*[A-Z]*
set static variable [a-z] to pop()

%g*[A-Z]*
get static variable [a-z] and push it

The terms static and dynamic are misleading. Historically, these are simply two different sets of variables, whose values are not reset between calls to tparm(3NCURSES). However, that fact is not documented in other implementations. Relying on it will adversely impact portability to other implementations:

SVr2 curses supported dynamic variables. Those are set only by a %P operator. A %g for a given variable without first setting it with %P will give unpredictable results, because dynamic variables are an uninitialized local array on the stack in the tparm function.
SVr3.2 curses supported static variables. Those are an array in the TERMINAL structure (declared in term.h), and are zeroed automatically when the setupterm function allocates the data.
SVr4 curses made no further improvements to the dynamic/static variable feature.
Solaris XPG4 curses does not distinguish between dynamic and static variables. They are the same. Like SVr4 curses, XPG4 curses does not initialize these explicitly.
Before version 6.3, ncurses stores both dynamic and static variables in persistent storage, initialized to zeros.
Beginning with version 6.3, ncurses stores static and dynamic variables in the same manner as SVr4.
- Unlike other implementations, ncurses zeros dynamic variables before the first %g or %P operator.
- Like SVr2, the scope of dynamic variables in ncurses is within the current call to tparm. Use static variables if persistent storage is needed.

**%**c
char constant c

%{nn}
integer constant nn

%l
push strlen(pop)

%+, %-, %*, %/, %m
arithmetic (%m is mod): push(pop() op pop())

%&, %|, %
bit operations (AND, OR and exclusive-OR): push(pop() op pop())

%=, %>, %<
logical operations: push(pop() op pop())

%A, %O
logical AND and OR operations (for conditionals)

%!, %
unary operations (logical and bit complement): push(op pop())

%i
add 1 to first two parameters (for ANSI terminals)

%? expr %t thenpart %e elsepart %;
This forms an if-then-else. The %e elsepart is optional. Usually the %? expr part pushes a value onto the stack, and %t pops it from the stack, testing if it is nonzero (true). If it is zero (false), control passes to the %e (else) part.

It is possible to form else-if’s a la Algol 68:

%? c1 %t b1 %e c2 %t b2 %e c3 %t b3 %e c4 %t b4 %e %;

where ci are conditions, bi are bodies.

Use the -f option of tic or infocmp to see the structure of if-then-else’s. Some strings, e.g., sgr can be very complicated when written on one line. The -f option splits the string into lines with the parts indented.

Binary operations are in postfix form with the operands in the usual order. That is, to get x-5 one would use %gx%{5}%-. %P and %g variables are persistent across escape-string evaluations.

Consider the HP2645, which, to get to row 3 and column 12, needs to be sent &a12c03Y padded for 6 milliseconds. The order of the rows and columns is inverted here, and the row and column are printed as two digits. The corresponding terminal description is expressed thus:

cup=&a%p2%dc%p1%dY$<6>,

The Microterm ACT-IV needs the current row and column sent preceded by a T, with the row and column simply encoded in binary,

cup=T%p1%c%p2%c

Terminals which use %c need to be able to backspace the cursor (cub1), and to move the cursor up one line on the screen (cuu1). This is necessary because it is not always safe to transmit ** ** D and ** **, as the system may change or discard them. (The library routines dealing with terminfo set tty modes so that tabs are never expanded, so is safe to send. This turns out to be essential for the Ann Arbor 4080.)

A final example is the LSI ADM-3a, which uses row and column offset by a blank character, thus

cup==%p1% %+%c%p2% %+%c

After sending =, this pushes the first parameter, pushes the ASCII value for a space (32), adds them (pushing the sum on the stack in place of the two previous values) and outputs that value as a character. Then the same is done for the second parameter. More complex arithmetic is possible using the stack.

Cursor Motions

If the terminal has a fast way to home the cursor (to very upper left corner of screen) then this can be given as home; similarly a fast way of getting to the lower left-hand corner can be given as ll; this may involve going up with cuu1 from the home position, but a program should never do this itself (unless ll does) because it can make no assumption about the effect of moving up from the home position. Note that the home position is the same as addressing to (0,0): to the top left corner of the screen, not of memory. (Thus, the H sequence on HP terminals cannot be used for home.)

If the terminal has row or column absolute cursor addressing, these can be given as single parameter capabilities hpa (horizontal position absolute) and vpa (vertical position absolute). Sometimes these are shorter than the more general two parameter sequence (as with the hp2645) and can be used in preference to cup. If there are parameterized local motions (e.g., move n spaces to the right) these can be given as cud, cub, cuf, and cuu with a single parameter indicating how many spaces to move. These are primarily useful if the terminal does not have cup, such as the TEKTRONIX 4025.

If the terminal needs to be in a special mode when running a program that uses these capabilities, the codes to enter and exit this mode can be given as smcup and rmcup. This arises, for example, from terminals like the Concept with more than one page of memory. If the terminal has only memory relative cursor addressing and not screen relative cursor addressing, a one screen-sized window must be fixed into the terminal for cursor addressing to work properly. This is also used for the TEKTRONIX 4025, where smcup sets the command character to be the one used by terminfo. If the smcup sequence will not restore the screen after an rmcup sequence is output (to the state prior to outputting rmcup), specify nrrmc.

Margins

SVr4 (and X/Open Curses) list several string capabilities for setting margins. Two were intended for use with terminals, and another six were intended for use with printers.

The two terminal capabilities assume that the terminal may have the capability of setting the left and/or right margin at the current cursor column position.
The printer capabilities assume that the printer may have two types of capability:
- the ability to set a top and/or bottom margin using the current line position, and
- parameterized capabilities for setting the top, bottom, left, right margins given the number of rows or columns.

In practice, the categorization into terminal and printer is not suitable:

The AT&T SVr4 terminal database uses smgl four times, for AT&T hardware.
Three of the four are printers. They lack the ability to set left/right margins by specifying the column.
Other (non-AT&T) terminals may support margins but using different assumptions from AT&T.
For instance, the DEC VT420 supports left/right margins, but only using a column parameter. As an added complication, the VT420 uses two settings to fully enable left/right margins (left/right margin mode, and origin mode). The former enables the margins, which causes printed text to wrap within margins, but the latter is needed to prevent cursor-addressing outside those margins.
Both DEC VT420 left/right margins are set with a single control sequence. If either is omitted, the corresponding margin is set to the left or right edge of the display (rather than leaving the margin unmodified).

These are the margin-related capabilities:

Name	Description
smgl	Set left margin at current column
smgr	Set right margin at current column
smgb	Set bottom margin at current line
smgt	Set top margin at current line
smgbp	Set bottom margin at line N
smglp	Set left margin at column N
smgrp	Set right margin at column N
smgtp	Set top margin at line N
smglr	Set both left and right margins to L and R
smgtb	Set both top and bottom margins to T and B

When writing an application that uses these string capabilities, the pairs should be first checked to see if each capability in the pair is set or only one is set:

If both smglp and smgrp are set, each is used with a single argument, N, that gives the column number of the left and right margin, respectively.
If both smgtp and smgbp are set, each is used to set the top and bottom margin, respectively:
- smgtp is used with a single argument, N, the line number of the top margin.
- smgbp is used with two arguments, N and M, that give the line number of the bottom margin, the first counting from the top of the page and the second counting from the bottom. This accommodates the two styles of specifying the bottom margin in different manufacturers’ printers.
When designing a terminfo entry for a printer that has a settable bottom margin, only the first or second argument should be used, depending on the printer. When developing an application that uses smgbp to set the bottom margin, both arguments must be given.

Conversely, when only one capability in the pair is set:

If only one of smglp and smgrp is set, then it is used with two arguments, the column number of the left and right margins, in that order.
Likewise, if only one of smgtp and smgbp is set, then it is used with two arguments that give the top and bottom margins, in that order, counting from the top of the page.
When designing a terminfo entry for a printer that requires setting both left and right or top and bottom margins simultaneously, only one capability in the pairs smglp and smgrp or smgtp and smgbp should be defined, leaving the other unset.

Except for very old terminal descriptions, e.g., those developed for SVr4, the scheme just described should be considered obsolete. An improved set of capabilities was added late in the SVr4 releases (smglr and smgtb), which explicitly use two parameters for setting the left/right or top/bottom margins.

When setting margins, the line- and column-values are zero-based.

The mgc string capability should be defined. Applications such as tabs(1) rely upon this to reset all margins.

Area Clears

If the terminal can clear from the current position to the end of the line, leaving the cursor where it is, this should be given as el. If the terminal can clear from the beginning of the line to the current position inclusive, leaving the cursor where it is, this should be given as el1. If the terminal can clear from the current position to the end of the display, then this should be given as ed. Ed is only defined from the first column of a line. (Thus, it can be simulated by a request to delete a large number of lines, if a true ed is not available.)

Insert/Delete Line and Vertical Motions

If the terminal can open a new blank line before the line where the cursor is, this should be given as il1; this is done only from the first position of a line. The cursor must then appear on the newly blank line. If the terminal can delete the line which the cursor is on, then this should be given as dl1; this is done only from the first position on the line to be deleted. Versions of il1 and dl1 which take a single parameter and insert or delete that many lines can be given as il and dl.

If the terminal has a settable scrolling region (like the vt100) the command to set this can be described with the csr capability, which takes two parameters: the top and bottom lines of the scrolling region. The cursor position is, alas, undefined after using this command.

It is possible to get the effect of insert or delete line using csr on a properly chosen region; the sc and rc (save and restore cursor) commands may be useful for ensuring that your synthesized insert/delete string does not move the cursor. (Note that the ncurses(3NCURSES) library does this synthesis automatically, so you need not compose insert/delete strings for an entry with csr).

Yet another way to construct insert and delete might be to use a combination of index with the memory-lock feature found on some terminals (like the HP-700/90 series, which however also has insert/delete).

Inserting lines at the top or bottom of the screen can also be done using ri or ind on many terminals without a true insert/delete line, and is often faster even on terminals with those features.

The Boolean non_dest_scroll_region should be set if each scrolling window is effectively a view port on a screen-sized canvas. To test for this capability, create a scrolling region in the middle of the screen, write something to the bottom line, move the cursor to the top of the region, and do ri followed by dl1 or ind. If the data scrolled off the bottom of the region by the ri re-appears, then scrolling is non-destructive. System V and X/Open Curses expect that ind, ri, indn, and rin will simulate destructive scrolling; their documentation cautions you not to define csr unless this is true. This curses implementation is more liberal and will do explicit erases after scrolling if ndsrc is defined.

If the terminal has the ability to define a window as part of memory, which all commands affect, it should be given as the parameterized string wind. The four parameters are the starting and ending lines in memory and the starting and ending columns in memory, in that order.

If the terminal can retain display memory above, then the da capability should be given; if display memory can be retained below, then db should be given. These indicate that deleting a line or scrolling may bring non-blank lines up from below or that scrolling back with ri may bring down non-blank lines.

Insert/Delete Character

There are two basic kinds of intelligent terminals with respect to insert/delete character which can be described using terminfo. The most common insert/delete character operations affect only the characters on the current line and shift characters off the end of the line rigidly. Other terminals, such as the Concept 100 and the Perkin Elmer Owl, make a distinction between typed and untyped blanks on the screen, shifting upon an insert or delete only to an untyped blank on the screen which is either eliminated, or expanded to two untyped blanks.

You can determine the kind of terminal you have by clearing the screen and then typing text separated by cursor motions. Type abc def using local cursor motions (not spaces) between the abc and the def. Then position the cursor before the abc and put the terminal in insert mode. If typing characters causes the rest of the line to shift rigidly and characters to fall off the end, then your terminal does not distinguish between blanks and untyped positions. If the abc shifts over to the def which then move together around the end of the current line and onto the next as you insert, you have the second type of terminal, and should give the capability in, which stands for insert null.

While these are two logically separate attributes (one line versus multi-line insert mode, and special treatment of untyped spaces) we have seen no terminals whose insert mode cannot be described with the single attribute.

Terminfo can describe both terminals which have an insert mode, and terminals which send a simple sequence to open a blank position on the current line. Give as smir the sequence to get into insert mode. Give as rmir the sequence to leave insert mode. Now give as ich1 any sequence needed to be sent just before sending the character to be inserted. Most terminals with a true insert mode will not give ich1; terminals which send a sequence to open a screen position should give it here.

If your terminal has both, insert mode is usually preferable to ich1. Technically, you should not give both unless the terminal actually requires both to be used in combination. Accordingly, some non-curses applications get confused if both are present; the symptom is doubled characters in an update using insert. This requirement is now rare; most ich sequences do not require previous smir, and most smir insert modes do not require ich1 before each character. Therefore, the new curses actually assumes this is the case and uses either rmir/smir or ich/ich1 as appropriate (but not both). If you have to write an entry to be used under new curses for a terminal old enough to need both, include the rmir/smir sequences in ich1.

If post insert padding is needed, give this as a number of milliseconds in ip (a string option). Any other sequence which may need to be sent after an insert of a single character may also be given in ip. If your terminal needs both to be placed into an insert mode and a special code to precede each inserted character, then both smir/rmir and ich1 can be given, and both will be used. The ich capability, with one parameter, n, will repeat the effects of ich1 n times.

If padding is necessary between characters typed while not in insert mode, give this as a number of milliseconds padding in rmp.

It is occasionally necessary to move around while in insert mode to delete characters on the same line (e.g., if there is a tab after the insertion position). If your terminal allows motion while in insert mode you can give the capability mir to speed up inserting in this case. Omitting mir will affect only speed. Some terminals (notably Datamedia’s) must not have mir because of the way their insert mode works.

Finally, you can specify dch1 to delete a single character, dch with one parameter, n, to delete ncharacters, and delete mode by giving smdc and rmdc to enter and exit delete mode (any mode the terminal needs to be placed in for dch1 to work).

A command to erase n characters (equivalent to outputting n blanks without moving the cursor) can be given as ech with one parameter.

Highlighting, Underlining, and Visible Bells

If your terminal has one or more kinds of display attributes, these can be represented in a number of different ways. You should choose one display form as standout mode, representing a good, high contrast, easy-on-the-eyes, format for highlighting error messages and other attention getters. (If you have a choice, reverse video plus half-bright is good, or reverse video alone.) The sequences to enter and exit standout mode are given as smso and rmso, respectively. If the code to change into or out of standout mode leaves one or even two blank spaces on the screen, as the TVI 912 and Teleray 1061 do, then xmc should be given to tell how many spaces are left.

Codes to begin underlining and end underlining can be given as smul and rmul respectively. If the terminal has a code to underline the current character and move the cursor one space to the right, such as the Microterm Mime, this can be given as uc.

Other capabilities to enter various highlighting modes include blink (blinking) bold (bold or extra bright) dim (dim or half-bright) invis (blanking or invisible text) prot (protected) rev (reverse video) sgr0 (turn off all attribute modes) smacs (enter alternate character set mode) and rmacs (exit alternate character set mode). Turning on any of these modes singly may or may not turn off other modes.

If there is a sequence to set arbitrary combinations of modes, this should be given as sgr (set attributes), taking 9 parameters. Each parameter is either zero (0) or nonzero, as the corresponding attribute is on or off. The 9 parameters are, in order: standout, underline, reverse, blink, dim, bold, blank, protect, alternate character set. Not all modes need be supported by sgr, only those for which corresponding separate attribute commands exist.

For example, the DEC vt220 supports most of the modes:

tparm Parameter	Attribute	Escape Sequence
none	none	[0m
p1	standout	[0;1;7m
p2	underline	[0;4m
p3	reverse	[0;7m
p4	blink	[0;5m
p5	dim	not available
p6	bold	[0;1m
p7	invis	[0;8m
p8	protect	not used
p9	altcharset	O (off) N (on)

We begin each escape sequence by turning off any existing modes, since there is no quick way to determine whether they are active. Standout is set up to be the combination of reverse and bold. The vt220 terminal has a protect mode, though it is not commonly used in sgr because it protects characters on the screen from the host’s erasures. The altcharset mode also is different in that it is either O or N, depending on whether it is off or on. If all modes are turned on, the resulting sequence is [0;1;4;5;7;8mN.

Some sequences are common to different modes. For example, ;7 is output when either p1 or p3 is true, that is, if either standout or reverse modes are turned on.

Writing out the above sequences, along with their dependencies yields

Sequence	When to Output	terminfo Translation
[0	always	[0
;1	if p1 or p6	%?%p1%p6%\|%t;1%;
;4	if p2	%?%p2%\|%t;4%;
;5	if p4	%?%p4%\|%t;5%;
;7	if p1 or p3	%?%p1%p3%\|%t;7%;
;8	if p7	%?%p7%\|%t;8%;
m	always	m
N or O	if p9 N, else O	%?%p9%tN%eO%;

Putting this all together into the sgr sequence gives:

    sgr=[0%?%p1%p6%|%t;1%;%?%p2%t;4%;%?%p4%t;5%;
        %?%p1%p3%|%t;7%;%?%p7%t;8%;m%?%p9%t%e%;,

Remember that if you specify sgr, you must also specify sgr0. Also, some implementations rely on sgr being given if sgr0 is, Not all terminfo entries necessarily have an sgr string, however. Many terminfo entries are derived from termcap entries which have no sgr string. The only drawback to adding an sgr string is that termcap also assumes that sgr0 does not exit alternate character set mode.

Terminals with the magic cookie glitch (xmc) deposit special cookies when they receive mode-setting sequences, which affect the display algorithm rather than having extra bits for each character. Some terminals, such as the HP 2621, automatically leave standout mode when they move to a new line or the cursor is addressed. Programs using standout mode should exit standout mode before moving the cursor or sending a newline, unless the msgr capability, asserting that it is safe to move in standout mode, is present.

If the terminal has a way of flashing the screen to indicate an error quietly (a bell replacement) then this can be given as flash; it must not move the cursor.

If the cursor needs to be made more visible than normal when it is not on the bottom line (to make, for example, a non-blinking underline into an easier to find block or blinking underline) give this sequence as cvvis. If there is a way to make the cursor completely invisible, give that as civis. The capability cnorm should be given which undoes the effects of both of these modes.

If your terminal correctly generates underlined characters (with no special codes needed) even though it does not overstrike, then you should give the capability ul. If a character overstriking another leaves both characters on the screen, specify the capability os. If overstrikes are erasable with a blank, then this should be indicated by giving eo.

Keypad and Function Keys

If the terminal has a keypad that transmits codes when the keys are pressed, this information can be given. Note that it is not possible to handle terminals where the keypad only works in local (this applies, for example, to the unshifted HP 2621 keys). If the keypad can be set to transmit or not transmit, give these codes as smkx and rmkx. Otherwise the keypad is assumed to always transmit.

The codes sent by the left arrow, right arrow, up arrow, down arrow, and home keys can be given as kcub1, kcuf1, kcuu1, kcud1, and khome respectively. If there are function keys such as f0, f1, …, f10, the codes they send can be given as kf0, kf1, …, kf10. If these keys have labels other than the default f0 through f10, the labels can be given as lf0, lf1, …, lf10.

The codes transmitted by certain other special keys can be given:

kll (home down),
kbs (backspace),
ktbc (clear all tabs),
kctab (clear the tab stop in this column),
kclr (clear screen or erase key),
kdch1 (delete character),
kdl1 (delete line),
krmir (exit insert mode),
kel (clear to end of line),
ked (clear to end of screen),
kich1 (insert character or enter insert mode),
kil1 (insert line),
knp (next page),
kpp (previous page),
kind (scroll forward/down),
kri (scroll backward/up),
khts (set a tab stop in this column).

In addition, if the keypad has a 3 by 3 array of keys including the four arrow keys, the other five keys can be given as ka1, ka3, kb2, kc1, and kc3. These keys are useful when the effects of a 3 by 3 directional pad are needed.

Strings to program function keys can be given as pfkey, pfloc, and pfx. A string to program screen labels should be specified as pln. Each of these strings takes two parameters: the function key number to program (from 0 to 10) and the string to program it with. Function key numbers out of this range may program undefined keys in a terminal dependent manner. The difference between the capabilities is that pfkey causes pressing the given key to be the same as the user typing the given string; pfloc causes the string to be executed by the terminal in local; and pfx causes the string to be transmitted to the computer.

The capabilities nlab, lw and lh define the number of programmable screen labels and their width and height. If there are commands to turn the labels on and off, give them in smln and rmln. smln is normally output after one or more pln sequences to make sure that the change becomes visible.

Tabs and Initialization

A few capabilities are used only for tabs:

If the terminal has hardware tabs, the command to advance to the next tab stop can be given as ht (usually control/I).
A back-tab command which moves leftward to the preceding tab stop can be given as cbt.
By convention, if the teletype modes indicate that tabs are being expanded by the computer rather than being sent to the terminal, programs should not use ht or cbt even if they are present, since the user may not have the tab stops properly set.
If the terminal has hardware tabs which are initially set every n spaces when the terminal is powered up, the numeric parameter it is given, showing the number of spaces the tabs are set to.
The it capability is normally used by the tset command to determine whether to set the mode for hardware tab expansion, and whether to set the tab stops. If the terminal has tab stops that can be saved in non-volatile memory, the terminfo description can assume that they are properly set.

Other capabilities include

is1, is2, and is3, initialization strings for the terminal,
iprog, the path name of a program to be run to initialize the terminal,
and if, the name of a file containing long initialization strings.

These strings are expected to set the terminal into modes consistent with the rest of the terminfo description. They are normally sent to the terminal, by the init option of the tput program, each time the user logs in. They will be printed in the following order:

run the program
iprog
output
is1 and
is2
set the margins using
mgc or
smglp and smgrp or
smgl and smgr
set tabs using
tbc and hts
print the file
if
and finally output
is3.

Most initialization is done with is2. Special terminal modes can be set up without duplicating strings by putting the common sequences in is2 and special cases in is1 and is3.

A set of sequences that does a harder reset from a totally unknown state can be given as rs1, rs2, rf and rs3, analogous to is1 , is2 , if and is3 respectively. These strings are output by reset option of tput, or by the reset program (an alias of tset), which is used when the terminal gets into a wedged state. Commands are normally placed in rs1, rs2 rs3 and rf only if they produce annoying effects on the screen and are not necessary when logging in. For example, the command to set the vt100 into 80-column mode would normally be part of is2, but it causes an annoying glitch of the screen and is not normally needed since the terminal is usually already in 80-column mode.

The reset program writes strings including iprog, etc., in the same order as the init program, using rs1, etc., instead of is1, etc. If any of rs1, rs2, rs3, or rf reset capability strings are missing, the reset program falls back upon the corresponding initialization capability string.

If there are commands to set and clear tab stops, they can be given as tbc (clear all tab stops) and hts (set a tab stop in the current column of every row). If a more complex sequence is needed to set the tabs than can be described by this, the sequence can be placed in is2 or if.

The tput reset command uses the same capability strings as the reset command, although the two programs (tput and reset) provide different command-line options.

In practice, these terminfo capabilities are not often used in initialization of tabs (though they are required for the tabs program):

Almost all hardware terminals (at least those which supported tabs) initialized those to every eight columns:
The only exception was the AT&T 2300 series, which set tabs to every five columns.
In particular, developers of the hardware terminals which are commonly used as models for modern terminal emulators provided documentation demonstrating that eight columns were the standard.
Because of this, the terminal initialization programs tput and tset use the tbc (clear_all_tabs) and hts (set_tab) capabilities directly only when the it (init_tabs) capability is set to a value other than eight.

Delays and Padding

Many older and slower terminals do not support either XON/XOFF or DTR handshaking, including hard copy terminals and some very archaic CRTs (including, for example, DEC VT100s). These may require padding characters after certain cursor motions and screen changes.

If the terminal uses xon/xoff handshaking for flow control (that is, it automatically emits S back to the host when its input buffers are close to full), set xon. This capability suppresses the emission of padding. You can also set it for memory-mapped console devices effectively that do not have a speed limit. Padding information should still be included so that routines can make better decisions about relative costs, but actual pad characters will not be transmitted.

If pb (padding baud rate) is given, padding is suppressed at baud rates below the value of pb. If the entry has no padding baud rate, then whether padding is emitted or not is completely controlled by xon.

If the terminal requires other than a null (zero) character as a pad, then this can be given as pad. Only the first character of the pad string is used.

Status Lines

Some terminals have an extra status line which is not normally used by software (and thus not counted in the terminal’s lines capability).

The simplest case is a status line which is cursor-addressable but not part of the main scrolling region on the screen; the Heathkit H19 has a status line of this kind, as would a 24-line VT100 with a 23-line scrolling region set up on initialization. This situation is indicated by the hs capability.

Some terminals with status lines need special sequences to access the status line. These may be expressed as a string with single parameter tsl which takes the cursor to a given zero-origin column on the status line. The capability fsl must return to the main-screen cursor positions before the last tsl. You may need to embed the string values of sc (save cursor) and rc (restore cursor) in tsl and fsl to accomplish this.

The status line is normally assumed to be the same width as the width of the terminal. If this is untrue, you can specify it with the numeric capability wsl.

A command to erase or blank the status line may be specified as dsl.

The Boolean capability eslok specifies that escape sequences, tabs, etc., work ordinarily in the status line.

The ncurses implementation does not yet use any of these capabilities. They are documented here in case they ever become important.

Line Graphics

Many terminals have alternate character sets useful for forms-drawing. Terminfo and curses have built-in support for most of the drawing characters supported by the VT100, with some characters from the AT&T 4410v1 added. This alternate character set may be specified by the acsc capability.

TABLE

A few notes apply to the table itself:

X/Open Curses incorrectly states that the mapping for lantern is uppercase I although Unix implementations use the lowercase i mapping.
The DEC VT100 implemented graphics using the alternate character set feature, temporarily switching modes and sending characters in the range 0x60 (96) to 0x7e (126) (the acsc Value column in the table).
The AT&T terminal added graphics characters outside that range.
Some of the characters within the range do not match the VT100; presumably they were used in the AT&T terminal: board of squares replaces the VT100 newline symbol, while lantern symbol replaces the VT100 vertical tab symbol. The other VT100 symbols for control characters (horizontal tab, carriage return and line-feed) are not (re)used in curses.

The best way to define a new device’s graphics set is to add a column to a copy of this table for your terminal, giving the character which (when emitted between smacs/rmacs switches) will be rendered as the corresponding graphic. Then read off the VT100/your terminal character pairs right to left in sequence; these become the ACSC string.

Color Handling

The curses library functions init_pair and init_color manipulate the color pairs and color values discussed in this section (see color(3NCURSES) for details on these and related functions).

Most color terminals are either Tektronix-like or HP-like:

Tektronix-like terminals have a predefined set of N colors (where N is usually 8), and can set character-cell foreground and background characters independently, mixing them into N * N color pairs.
On HP-like terminals, the user must set each color pair up separately (foreground and background are not independently settable). Up to M color pairs may be set up from 2*M different colors. ANSI-compatible terminals are Tektronix-like.

Some basic color capabilities are independent of the color method. The numeric capabilities colors and pairs specify the maximum numbers of colors and color pairs that can be displayed simultaneously. The op (original pair) string resets foreground and background colors to their default values for the terminal. The oc string resets all colors or color pairs to their default values for the terminal. Some terminals (including many PC terminal emulators) erase screen areas with the current background color rather than the power-up default background; these should have the Boolean capability bce.

While the curses library works with color pairs (reflecting the inability of some devices to set foreground and background colors independently), there are separate capabilities for setting these features:

To change the current foreground or background color on a Tektronix-type terminal, use setaf (set ANSI foreground) and setab (set ANSI background) or setf (set foreground) and setb (set background). These take one parameter, the color number. The SVr4 documentation describes only setaf/setab; the XPG4 draft says that “If the terminal supports ANSI escape sequences to set background and foreground, they should be coded as setaf and setab, respectively.
If the terminal supports other escape sequences to set background and foreground, they should be coded as setf and setb, respectively. The vidputs and the refresh(3NCURSES) functions use the setaf and setab capabilities if they are defined.

The setaf/setab and setf/setb capabilities take a single numeric argument each. Argument values 0-7 of setaf/setab are portably defined as follows (the middle column is the symbolic #define available in the header for the curses or ncurses libraries). The terminal hardware is free to map these as it likes, but the RGB values indicate normal locations in color space.

TABLE

The argument values of setf/setb historically correspond to a different mapping, i.e.,

TABLE

It is important to not confuse the two sets of color capabilities; otherwise red/blue will be interchanged on the display.

On an HP-like terminal, use scp with a color pair number parameter to set which color pair is current.

Some terminals allow the color values to be modified:

On a Tektronix-like terminal, the capability ccc may be present to indicate that colors can be modified. If so, the initc capability will take a color number (0 to colors - 1)and three more parameters which describe the color. These three parameters default to being interpreted as RGB (Red, Green, Blue) values. If the Boolean capability hls is present, they are instead as HLS (Hue, Lightness, Saturation) indices. The ranges are terminal-dependent.
On an HP-like terminal, initp may give a capability for changing a color pair value. It will take seven parameters; a color pair number (0 to max_pairs - 1), and two triples describing first background and then foreground colors. These parameters must be (Red, Green, Blue) or (Hue, Lightness, Saturation) depending on hls.

On some color terminals, colors collide with highlights. You can register these collisions with the ncv capability. This is a bit mask of attributes not to be used when colors are enabled. The correspondence with the attributes understood by curses is as follows:

Attribute	Bit	Decimal	Set by
A_STANDOUT	0	1	sgr
A_UNDERLINE	1	2	sgr
A_REVERSE	2	4	sgr
A_BLINK	3	8	sgr
A_DIM	4	16	sgr
A_BOLD	5	32	sgr
A_INVIS	6	64	sgr
A_PROTECT	7	128	sgr
A_ALTCHARSET	8	256	sgr
A_HORIZONTAL	9	512	sgr1
A_LEFT	10	1024	sgr1
A_LOW	11	2048	sgr1
A_RIGHT	12	4096	sgr1
A_TOP	13	8192	sgr1
A_VERTICAL	14	16384	sgr1
A_ITALIC	15	32768	sitm

For example, on many IBM PC consoles, the underline attribute collides with the foreground color blue and is not available in color mode. These should have an ncv capability of 2.

SVr4 curses does nothing with ncv, ncurses recognizes it and optimizes the output in favor of colors.

Miscellaneous

If the terminal requires other than a null (zero) character as a pad, then this can be given as pad. Only the first character of the pad string is used. If the terminal does not have a pad character, specify npc. Note that ncurses implements the termcap-compatible PC variable; though the application may set this value to something other than a null, ncurses will test npc first and use napms if the terminal has no pad character.

If the terminal can move up or down half a line, this can be indicated with hu (half-line up) and hd (half-line down). This is primarily useful for superscripts and subscripts on hard-copy terminals. If a hard-copy terminal can eject to the next page (form feed), give this as ff (usually control/L).

If there is a command to repeat a given character a given number of times (to save time transmitting a large number of identical characters) this can be indicated with the parameterized string rep. The first parameter is the character to be repeated and the second is the number of times to repeat it. Thus, tparm(repeat_char, x, 10) is the same as xxxxxxxxxx.

If the terminal has a settable command character, such as the TEKTRONIX 4025, this can be indicated with cmdch. A prototype command character is chosen which is used in all capabilities. This character is given in the cmdch capability to identify it. The following convention is supported on some Unix systems: The environment is to be searched for a CC variable, and if found, all occurrences of the prototype character are replaced with the character in the environment variable.

Terminal descriptions that do not represent a specific kind of known terminal, such as switch, dialup, patch, and network, should include the gn (generic) capability so that programs can complain that they do not know how to talk to the terminal. (This capability does not apply to virtual terminal descriptions for which the escape sequences are known.)

If the terminal has a meta key which acts as a shift key, setting the 8th bit of any character transmitted, this fact can be indicated with km. Otherwise, software will assume that the 8th bit is parity and it will usually be cleared. If strings exist to turn this meta mode on and off, they can be given as smm and rmm.

If the terminal has more lines of memory than will fit on the screen at once, the number of lines of memory can be indicated with lm. A value of lm#0 indicates that the number of lines is not fixed, but that there is still more memory than fits on the screen.

If the terminal is one of those supported by the Unix virtual terminal protocol, the terminal number can be given as vt.

Media copy strings which control an auxiliary printer connected to the terminal can be given as mc0: print the contents of the screen, mc4: turn off the printer, and mc5: turn on the printer. When the printer is on, all text sent to the terminal will be sent to the printer. It is undefined whether the text is also displayed on the terminal screen when the printer is on. A variation mc5p takes one parameter, and leaves the printer on for as many characters as the value of the parameter, then turns the printer off. The parameter should not exceed 255. All text, including mc4, is transparently passed to the printer while an mc5p is in effect.

Glitches and Brain Damage

Hazeltine terminals, which do not allow characters to be displayed should indicate hz.

Terminals which ignore a line-feed immediately after an am wrap, such as the Concept and vt100, should indicate xenl.

If el is required to get rid of standout (instead of merely writing normal text on top of it), xhp should be given.

Teleray terminals, where tabs turn all characters moved over to blanks, should indicate xt (destructive tabs). Note: the variable indicating this is now dest_tabs_magic_smso; in older versions, it was teleray_glitch. This glitch is also taken to mean that it is not possible to position the cursor on top of a magic cookie, that to erase standout mode it is instead necessary to use delete and insert line. The ncurses implementation ignores this glitch.

The Beehive Superbee, which is unable to correctly transmit the escape or control/C characters, has xsb, indicating that the f1 key is used for escape and f2 for control/C. (Only certain Superbees have this problem, depending on the ROM.) Note that in older terminfo versions, this capability was called beehive_glitch; it is now no_esc_ctl_c.

Other specific terminal problems may be corrected by adding more capabilities of the form xx.

Pitfalls of Long Entries

Long terminfo entries are unlikely to be a problem; to date, no entry has even approached terminfo’s 4096-byte string-table maximum. Unfortunately, the termcap translations are much more strictly limited (to 1023 bytes), thus termcap translations of long terminfo entries can cause problems.

The man pages for 4.3BSD and older versions of tgetent instruct the user to allocate a 1024-byte buffer for the termcap entry. The entry gets null-terminated by the termcap library, so that makes the maximum safe length for a termcap entry 1k-1 (1023) bytes. Depending on what the application and the termcap library being used does, and where in the termcap file the terminal type that tgetent is searching for is, several bad things can happen:

some termcap libraries print a warning message,
some exit if they find an entry that’s longer than 1023 bytes,
some neither exit nor warn, doing nothing useful, and
some simply truncate the entries to 1023 bytes.

Some application programs allocate more than the recommended 1K for the termcap entry; others do not.

Each termcap entry has two important sizes associated with it: before tc expansion, and after tc expansion. tc is the capability that tacks on another termcap entry to the end of the current one, to add on its capabilities. If a termcap entry does not use the tc capability, then of course the two lengths are the same.

The before tc expansion length is the most important one, because it affects more than just users of that particular terminal. This is the length of the entry as it exists in /etc/termcap, minus the backslash-newline pairs, which tgetent strips out while reading it. Some termcap libraries strip off the final newline, too (GNU termcap does not). Now suppose:

a termcap entry before expansion is more than 1023 bytes long,
and the application has only allocated a 1k buffer,
and the termcap library (like the one in BSD/OS 1.1 and GNU) reads the whole entry into the buffer, no matter what its length, to see if it is the entry it wants,
and tgetent is searching for a terminal type that either is the long entry, appears in the termcap file after the long entry, or does not appear in the file at all (so that tgetent has to search the whole termcap file).

Then tgetent will overwrite memory, perhaps its stack, and probably core dump the program. Programs like telnet are particularly vulnerable; modern telnets pass along values like the terminal type automatically. The results are almost as undesirable with a termcap library, like SunOS 4.1.3 and Ultrix 4.4, that prints warning messages when it reads an overly long termcap entry. If a termcap library truncates long entries, like OSF/1 3.0, it is immune to dying here but will return incorrect data for the terminal.

The after tc expansion length will have a similar effect to the above, but only for people who actually set TERM to that terminal type, since tgetent only does tc expansion once it is found the terminal type it was looking for, not while searching.

In summary, a termcap entry that is longer than 1023 bytes can cause, on various combinations of termcap libraries and applications, a core dump, warnings, or incorrect operation. If it is too long even before tc expansion, it will have this effect even for users of some other terminal types and users whose TERM variable does not have a termcap entry.

When in -C (translate to termcap) mode, the ncurses implementation of tic(1) issues warning messages when the pre-tc length of a termcap translation is too long. The -c (check) option also checks resolved (after tc expansion) lengths.

FILES

/etc/terminfo
compiled terminal description database directory

EXTENSIONS

Searching for terminal descriptions in $HOME/.terminfo and TERMINFO_DIRS is not supported by older implementations.

Some SVr4 curses implementations, and all previous to SVr4, do not interpret the %A and %O operators in parameter strings.

SVr4/XPG4 do not specify whether msgr licenses movement while in an alternate-character-set mode (such modes may, among other things, map CR and NL to characters that do not trigger local motions). The ncurses implementation ignores msgr in ALTCHARSET mode. This raises the possibility that an XPG4 implementation making the opposite interpretation may need terminfo entries made for ncurses to have msgr turned off.

The ncurses library handles insert-character and insert-character modes in a slightly non-standard way to get better update efficiency. See the Insert/Delete Character subsection above.

The parameter substitutions for set_clock and display_clock are not documented in SVr4 or X/Open Curses. They are deduced from the documentation for the AT&T 505 terminal.

Be careful assigning the kmous capability. The ncurses library wants to interpret it as KEY_MOUSE, for use by terminals and emulators like xterm that can return mouse-tracking information in the keyboard-input stream.

X/Open Curses does not mention italics. Portable applications must assume that numeric capabilities are signed 16-bit values. This includes the no_color_video (ncv) capability. The 32768 mask value used for italics with ncv can be confused with an absent or cancelled ncv. If italics should work with colors, then the ncv value must be specified, even if it is zero.

Different commercial ports of terminfo and curses support different subsets of X/Open Curses and (in some cases) different extensions. Here is a summary, accurate as of October 1995, after which the commercial Unix market contracted and lost diversity.

SVr4, Solaris, and ncurses support all SVr4 capabilities.
IRIX supports the SVr4 set and adds one undocumented extended string capability (set_pglen).
SVr1 and Ultrix support a restricted subset of terminfo capabilities. The Booleans end with xon_xoff; the numerics with width_status_line; and the strings with prtr_non.
HP/UX supports the SVr1 subset, plus the SVr[234] numerics num_labels, label_height, label_width, plus function keys 11 through 63, plus plab_norm, label_on, and label_off, plus a number of incompatible string table extensions.
AIX supports the SVr1 subset, plus function keys 11 through 63, plus a number of incompatible string table extensions.
OSF/1 supports both the SVr4 set and the AIX extensions.

PORTABILITY

Do not count on compiled (binary) terminfo entries being portable between commercial Unix systems. At least two implementations of terminfo (those of HP-UX and AIX) diverged from those of other System V Unices after SVr1, adding extension capabilities to the string table that (in the binary format) collide with subsequent System V and X/Open Curses extensions.

AUTHORS

Zeyd M. Ben-Halim, Eric S. Raymond, Thomas E. Dickey. Based on pcurses by Pavel Curtis.

196 - Linux cli command proc_sysrq-trigger

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_sysrq-trigger and provides detailed information about the command proc_sysrq-trigger, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_sysrq-trigger.

NAME 🖥️ proc_sysrq-trigger 🖥️

trigger - SysRq function

DESCRIPTION

/proc/sysrq-trigger (since Linux 2.4.21)
Writing a character to this file triggers the same SysRq function as typing ALT-SysRq-<character> (see the description of /proc/sys/kernel/sysrq). This file is normally writable only by root. For further details see the Linux kernel source file Documentation/admin-guide/sysrq.rst (or Documentation/sysrq.txt before Linux 4.10).

197 - Linux cli command proc_scsi

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_scsi and provides detailed information about the command proc_scsi, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_scsi.

NAME 🖥️ proc_scsi 🖥️

SCSI

DESCRIPTION

/proc/scsi/
A directory with the scsi mid-level pseudo-file and various SCSI low-level driver directories, which contain a file for each SCSI host in this system, all of which give the status of some part of the SCSI IO subsystem. These files contain ASCII structures and are, therefore, readable with cat(1).

You can also write to some of the files to reconfigure the subsystem or switch certain features on or off.

/proc/scsi/scsi
This is a listing of all SCSI devices known to the kernel. The listing is similar to the one seen during bootup. scsi currently supports only the add-single-device command which allows root to add a hotplugged device to the list of known devices.

The command

echo 'scsi add-single-device 1 0 5 0' > /proc/scsi/scsi

will cause host scsi1 to scan on SCSI channel 0 for a device on ID 5 LUN 0. If there is already a device known on this address or the address is invalid, an error will be returned.

/proc/scsi/drivername/
drivername can currently be NCR53c7xx, aha152x, aha1542, aha1740, aic7xxx, buslogic, eata_dma, eata_pio, fdomain, in2000, pas16, qlogic, scsi_debug, seagate, t128, u15-24f, ultrastore, or wd7000. These directories show up for all drivers that registered at least one SCSI HBA. Every directory contains one file per registered host. Every host-file is named after the number the host was assigned during initialization.

Reading these files will usually show driver and host configuration, statistics, and so on.

Writing to these files allows different things on different hosts. For example, with the latency and nolatency commands, root can switch on and off command latency measurement code in the eata_dma driver. With the lockup and unlock commands, root can control bus lockups simulated by the scsi_debug driver.

198 - Linux cli command systemd.negative

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.negative and provides detailed information about the command systemd.negative, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.negative.

NAME 🖥️ systemd.negative 🖥️

trust-anchors.d, systemd.positive, systemd.negative - DNSSEC trust anchor configuration files

SYNOPSIS

/etc/dnssec-trust-anchors.d/*.positive

/run/dnssec-trust-anchors.d/*.positive

/usr/local/lib/dnssec-trust-anchors.d/*.positive

/usr/lib/dnssec-trust-anchors.d/*.positive

/etc/dnssec-trust-anchors.d/*.negative

/run/dnssec-trust-anchors.d/*.negative

/usr/local/lib/dnssec-trust-anchors.d/*.negative

/usr/lib/dnssec-trust-anchors.d/*.negative

DESCRIPTION

The DNSSEC trust anchor configuration files define positive and negative trust anchors systemd-resolved.service(8) bases DNSSEC integrity proofs on.

POSITIVE TRUST ANCHORS

. IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5

Alternatively, DNSKEY resource records may be used to define trust anchors, like in the following example:

. IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=

If multiple DS or DNSKEY records are defined for the same domain (possibly even in different trust anchor files), all keys are used and are considered equivalent as base for DNSSEC proofs.

It is generally recommended to encode trust anchors in DS resource records, rather than DNSKEY resource records.

The current DNSSEC trust anchor for the Internets root domain is available at the IANA Trust Anchor and Keys[6] page.

NEGATIVE TRUST ANCHORS

Reverse IPv4 mappings

10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
...
# Some custom domains
prod
stag

Negative trust anchors are useful to support private DNS subtrees that are not referenced from the Internet DNS hierarchy, and not signed.

RFC 7646[7] for details on negative trust anchors.

If no negative trust anchor files are configured a built-in set of well-known private DNS zone domains is used as negative trust anchors.

It is also possibly to define per-interface negative trust anchors using the DNSSECNegativeTrustAnchors= setting in systemd.network(5) files.

NOTES

RFC 4035, Section 4.4

https://tools.ietf.org/html/rfc4035#section-4.4

RFC 1035, Section 5

https://tools.ietf.org/html/rfc1035#section-5

RFC 4034, Section 5

https://tools.ietf.org/html/rfc4034#section-5

RFC 4034, Section 2

https://tools.ietf.org/html/rfc4034#section-2

RFC 5011

https://tools.ietf.org/html/rfc5011

IANA Trust Anchor and Keys

https://data.iana.org/root-anchors/root-anchors.xml

RFC 7646

https://tools.ietf.org/html/rfc7646

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

199 - Linux cli command geoclue

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command geoclue and provides detailed information about the command geoclue, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the geoclue.

NAME 🖥️ geoclue 🖥️

geoclue configuration parameters

SYNOPSIS

Main configuration file: /etc/geoclue/geoclue.conf
Overwriting parameters files: /etc/geoclue/conf.d

DESCRIPTION

The main GeoClue configuration file ‘geoclue.conf’ specifies parameters that control the operation of geoclue. Parameters can be overwritten by placing configuration files in conf.d directory and applied in alphabetic order. Thus, a configuration file ‘90-config.conf’ will overwrite parameters specified in another configuration file ‘50-config.conf’ in the conf.d directory.

All configurations settings below are mandatory and the defaults are what you see before you edit them in geoclue.conf. If you want to keep the default values around, copy and comment out the appropriate line(s) before changing them.

Missing ’enable’ key for a particular source in the main configuration file causes that source to be enabled by default. Adding ’enable’ key setting to any further config file can overwrite this default.

AGENT CONFIGURATION OPTIONS

[agent] is used to begin the agent configuration.

whitelist

Whitelist of desktop IDs (without .desktop part) of all agents we recognise, separated by a ‘;’.

whitelist=geoclue-demo-agent;gnome-shell;io.elementary.desktop.agent-geoclue2

[network-nmea]

Network NMEA source configuration options

enable=true
Fetch location from NMEA sources on local network?

nmea-socket=/var/run/gps-share.sock
Use a nmea unix socket as the data source. If not set, unix socket will not be used.

[3g]

3G source configuration options

enable=true
Enable 3G source

[cdma]

CDMA source configuration options

enable=true
Enable CDMA source

[modem-gps]

Modem GPS source configuration options

enable=true
Enable Modem-GPS source

[wifi]

WiFi source configuration options

enable=true
Enable WiFi source

url=https://location.services.mozilla.com/v1/geolocate?key=YOUR_KEY
URL to the WiFi geolocation service. If not set, defaults to Mozilla’s Location Service with a hardcoded key. To use a custom key, uncomment this URL while changing YOUR_KEY to your MLS API key.

submit-data=false Submit data to Mozilla Location Service
If set to true, geoclue will automatically submit network data to Mozilla each time it gets a GPS lock.

submission-url=https://location.services.mozilla.com/v2/geosubmit?key=YOUR_KEY
URL to submission API of Mozilla Location Service

submission-nick=geoclue
A nickname to submit network data with. A nickname must be 2-32 characters long.

[compass]

Compass configuration options

enable=true
Enable Compass

[static-source]

Static source configuration options.
This source reads location from “geolocation” file in /etc. While this file is constantly monitored for changes during geoclue operation, and the reported static location is updated accordingly, this source isn’t meant for inputting a dynamically changing location to geoclue (please use the Network NMEA source for that).

enable=true
Enable the static source.
If you make use of this source, you probably should disable other location sources in geoclue.conf so they won’t override the configured static location.

APPLICATION CONFIGURATION OPTIONS

Having an entry here for an application with allowed=true means that geoclue will not ask agent to authorize the application. This is to ensure that applications with built-in authorization mechanism (e.g web browsers) do not have to be bound to agents.

If your application is denied access to location information and your operating system doesn’t provide any mechanism to change that, it is likely a bug in your operation system (or geoclue). The solution is to report the issue with all details, rather than adding your application to this list.

Format:

[random-app]
Desktop ID of application without .desktop part

allowed=true|false
Allowed access to location information?

system=true|false
Is application a system component?

users=
List of UIDs of all users for which this application is allowed location info access, separate by ‘;’. Keep it empty for allowing it for all users.

Examples:

[gnome-datetime-panel]
allowed=true
system=true
users=

[gnome-color-panel]
allowed=true
system=true
users=

[org.gnome.Shell]
allowed=true
system=true
users=

[io.elementary.desktop.agent-geoclue2]
allowed=true
system=true
users=

[epiphany]
allowed=true
system=false
users=

[firefox]
allowed=true
system=false
users=

STATIC LOCATION FILE

Basic format:

The static location file in /etc (used by the static source) is a text file consisting of the following:

Latitude (floating point number; positive values mean north, negative south)

[step]
Longitude (floating point number; positive values mean east, negative west)

[step]
Altitude (floating point number; in meters)

[step]
Accuracy radius (floating point number; in meters)

These values need to be separated by newline characters.

Additional format information:

The ‘#’ character starts a comment, which continues until the end of the current line.
Leading and trailing white-space on each line is ignored.
Empty lines (or containing just white-space or a comment) are ignored.

Example:

# Example static location file for a machine inside Statue of Liberty torch

40.6893129   # latitude
-74.0445531  # longitude
96           # altitude
1.83         # accuracy radius (the diameter of the torch is 12 feet)

Notes:

For extra security, the static location file can be made readable just by the geoclue user:

# chown geoclue /etc/geolocation
# chmod 600 /etc/geolocation

AUTHOR

Sachin Chand

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

200 - Linux cli command [email protected]

NAME 🖥️ [email protected] 🖥️

[email protected], systemd-user-runtime-dir - System units to start the user manager

SYNOPSIS

user@UID.service

user-runtime-dir@UID.service

/usr/lib/systemd/systemd-user-runtime-dir

user-UID.slice

DESCRIPTION

The systemd(1) system manager (PID 1) starts user manager instances as user@UID.service, with the users numerical UID used as the instance identifier. These instances use the same executable as the system manager, but running in a mode where it starts a different set of units. Each systemd –user instance manages a hierarchy of units specific to that user. See systemd(1) for a discussion of units and systemd.special(7) for a list of units that form the basis of the unit hierarchies of system and user units.

user@UID.service is accompanied by the system unit user-runtime-dir@UID.service, which creates the users runtime directory /run/user/UID, and then removes it when this unit is stopped. user-runtime-dir@UID.service executes the systemd-user-runtime-dir binary to do the actual work.

User processes may be started by the [email protected] instance, in which case they will be part of that unit in the system hierarchy. They may also be started elsewhere, for example by sshd(8) or a display manager like gdm, in which case they form a .scope unit (see systemd.scope(5)). Both user@UID.service and the scope units are collected under the user-UID.slice.

Individual user-UID.slice slices are collected under user.slice, see systemd.special(7).

CONTROLLING RESOURCES FOR LOGGED-IN USERS

Options that control resources available to logged-in users can be configured at a few different levels. As described in the previous section, user.slice contains processes of all users, so any resource limits on that slice apply to all users together. The usual way to configure them would be through drop-ins, e.g. /etc/systemd/system/user.slice.d/resources.conf.

The processes of a single user are collected under user-UID.slice. Resource limits for that user can be configured through drop-ins for that unit, e.g. /etc/systemd/system/user-1000.slice.d/resources.conf. If the limits should apply to all users instead, they may be configured through drop-ins for the truncated unit name, user-.slice. For example, configuration in /etc/systemd/system/user-.slice.d/resources.conf is included in all user-UID.slice units, see systemd.unit(5) for a discussion of the drop-in mechanism.

When a user logs in and a .scope unit is created for the session (see previous section), the creation of the scope may be managed through pam_systemd(8). This PAM module communicates with systemd-logind(8) to create the session scope and provide access to hardware resources. Resource limits for the scope may be configured through the PAM module configuration, see pam_systemd(8). Configuring them through the normal unit configuration is also possible, but since the name of the slice unit is generally unpredictable, this is less useful.

In general any resources that apply to units may be set for user@UID.service and the slice units discussed above, see systemd.resource-control(5) for an overview.

EXAMPLES

Example 1. Hierarchy of control groups with two logged in users

$ systemd-cgls Control group /: -.slice ├─user.slice │ ├─user-1000.slice │ │ ├─[email protected] │ │ │ ├─pulseaudio.service │ │ │ │ └─2386 /usr/bin/pulseaudio –daemonize=no │ │ │ └─gnome-terminal-server.service │ │ │ └─init.scope │ │ │ ├─ 4127 /usr/libexec/gnome-terminal-server │ │ │ └─ 4198 zsh │ │ … │ │ └─session-4.scope │ │ ├─ 1264 gdm-session-worker [pam/gdm-password] │ │ ├─ 2339 /usr/bin/gnome-shell │ │ … │ │ ├─session-19.scope │ │ ├─6497 sshd: zbyszek [priv] │ │ ├─6502 sshd: zbyszek@pts/6 │ │ ├─6509 -zsh │ │ └─6602 systemd-cgls –no-pager │ … │ └─user-1001.slice │ ├─session-20.scope │ │ ├─6675 sshd: guest [priv] │ │ ├─6708 sshd: guest@pts/6 │ │ └─6717 -bash │ └─[email protected] │ ├─init.scope │ │ ├─6680 /usr/lib/systemd/systemd –user │ │ └─6688 (sd-pam) │ └─sleep.service │ └─6706 /usr/bin/sleep 30 …

User with UID 1000 is logged in using gdm (session-4.scope) and ssh(1) (session-19.scope), and also has a user manager instance running ([email protected]). User with UID 1001 is logged in using ssh (session-20.scope) and also has a user manager instance running ([email protected]). Those are all (leaf) system units, and form part of the slice hierarchy, with user-1000.slice and user-1001.slice below user.slice. User units are visible below the [email protected] instances (pulseaudio.service, gnome-terminal-server.service, init.scope, sleep.service).

Example 2. Default user resource limits

$ systemctl cat user-1000.slice # /usr/lib/systemd/system/user-.slice.d/10-defaults.conf # … [Unit] Description=User Slice of UID %j After=systemd-user-sessions.service
[Slice]
TasksMax=33%

The user-UID.slice units by default dont have a unit file. The resource limits are set through a drop-in, which can be easily replaced or extended following standard drop-in mechanisms discussed in the first section.

201 - Linux cli command org.bluez.GattCharacteristic

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.GattCharacteristic and provides detailed information about the command org.bluez.GattCharacteristic, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.GattCharacteristic.

NAME 🖥️ org.bluez.GattCharacteristic 🖥️

BlueZ D-Bus GattCharacteristic API documentation

DESCRIPTION

GATT local/server and remote/client characteristic attribute representation share the same high-level D-Bus API.

Local/Server refers to GATT based characteristics exported by a plugin or an external application.

Remote/Client refers to GATT characteristics exported by the peer.

INTERFACE

Client

Service
org.bluez
Interface
org.bluez.GattCharacteristic1
Object path
[variable prefix]/{hci0,hci1,…}/dev_XX_XX_XX_XX_XX_XX/serviceXX/charYYYY

Server

Service
unique name
Interface
org.bluez.GattCharacteristic1
Object path
freely definable

Methods

array{byte} ReadValue(dict options)

Issues a request to read the value of the characteristic and returns the value if the operation was successful.
Possible options:
uint16_t offset
Read start offset in bytes.
uint16_t mtu (server only)
Exchange MTU in bytes.
object device (server only)
Device object.
Possible Errors:
org.bluez.Error.Failed
Possible values: string 0x80 - 0x9f
org.bluez.Error.InProgress
org.bluez.Error.NotPermitted
org.bluez.Error.NotAuthorized
org.bluez.Error.InvalidOffset
org.bluez.Error.NotSupported

void WriteValue(array{byte} value, dict options)

Issues a request to write the value of the characteristic.
Possible options:
uint16 offset
Write start offset in bytes.
string type
Possible values:
“command”
Use Write without response procedure.
“request”
Use Write with response procedure.
“reliable”
Use Reliable Write procedure.
uint16 mtu
Exchanged MTU (Server only).
object device
Device path (Server only).
string link
Link type (Server only).
Possible values:
“BR/EDR”
“LE”
boolean prepare-authorize
True if prepare authorization request.
Possible Errors:
org.bluez.Error.Failed
Possible values: string 0x80 - 0x9f
org.bluez.Error.InProgress
org.bluez.Error.NotPermitted
org.bluez.Error.InvalidValueLength
org.bluez.Error.NotAuthorized
org.bluez.Error.NotSupported

fd, uint16 AcquireWrite(dict options) [optional]

Acquire file descriptor and MTU for writing. Only sockets are supported. Usage of WriteValue will be locked causing it to return NotPermitted error.
For server the MTU returned shall be equal or smaller than the negotiated MTU.
For client it only works with characteristic that has WriteAcquired property which relies on write-without-response Flag.
To release the lock the client shall close the file descriptor, a HUP is generated in case the device is disconnected.
Note: the MTU can only be negotiated once and is symmetric therefore this method may be delayed in order to have the exchange MTU completed, because of that the file descriptor is closed during reconnections as the MTU has to be renegotiated.
Possible options:
object device
Object Device (Server only).
uint16 mtu
Exchanged MTU (Server only).
string link
Link type (Server only).
Possible values:
“BR/EDR”
“LE”
Possible Errors:
org.bluez.Error.Failed
org.bluez.Error.NotSupported

fd, uint16 AcquireNotify(dict options) [optional]

Acquire file descriptor and MTU for notify. Only sockets are support.
Usage of StartNotify will be locked causing it to return org.bluez.Error.NotPermitted.
For server the MTU returned shall be equal or smaller than the negotiated MTU.
Only works with characteristic that has NotifyAcquired property which relies on “notify” Flag and no other client have called StartNotify().
Notification are enabled during this procedure so StartNotify() shall not be called, any notification will be dispatched via file descriptor therefore the Value property is not affected during the time where notify has been acquired.
To release the lock the client shall close the file descriptor, a HUP is generated in case the device is disconnected.
Note: the MTU can only be negotiated once and is symmetric therefore this method may be delayed in order to have the exchange MTU completed, because of that the file descriptor is closed during reconnections as the MTU has to be renegotiated.
Possible options:
object device
Object Device (Server only).
uint16 mtu
Exchanged MTU (Server only).
string link
Link type (Server only).
Possible values:
“BR/EDR”
“LE”
Possible Errors:
org.bluez.Error.Failed
org.bluez.Error.NotSupported
org.bluez.Error.NotPermitted

void StartNotify()

Starts a notification session from this characteristic if it supports value notifications or indications.
Possible Errors:
org.bluez.Error.Failed
org.bluez.Error.NotPermitted
org.bluez.Error.InProgress
org.bluez.Error.NotConnected
org.bluez.Error.NotSupported

void StopNotify()

Stops or cancel session previously created by StartNotify().
Note that notifications from a characteristic are shared between sessions thus calling StopNotify will release a single session.
Possible Errors:
org.bluez.Error.Failed

void Confirm() [noreply, optional] (Server only)

Confirms value was received.
Possible Errors:
org.bluez.Error.Failed

Properties

string UUID [read-only]

128-bit characteristic UUID.

object Service [read-only]

Object path of the GATT service the characteristic belongs to.

array{byte} Value [read-only, optional]

The cached value of the characteristic. This property gets updated only after a successful read request and when a notification or indication is received, upon which a PropertiesChanged signal will be emitted.

boolean WriteAcquired [read-only, optional]

True, if this characteristic has been acquired by any client using AcquireWrite.
For client properties is ommited in case ‘write-without-response’ flag is not set.
For server the presence of this property indicates that AcquireWrite is supported.

boolean NotifyAcquired [read-only, optional]

True, if this characteristic has been acquired by any client using AcquireNotify.
For client this properties is ommited in case ’notify’ flag is not set.
For server the presence of this property indicates that AcquireNotify is supported.

boolean Notifying [read-only, optional]

True, if notifications or indications on this characteristic are currently enabled.

array{string} Flags [read-only]

Defines how the characteristic value can be used. See Core spec “Table 3.5: Characteristic Properties bit field”, and “Table 3.8: Characteristic Extended Properties bit field”.
The “x-notify” and “x-indicate” flags restrict access to notifications and indications by imposing write restrictions on a characteristic’s client characteristic configuration descriptor.
Possible values:
“broadcast”
“read”
“write-without-response”
“write”
“notify”
“indicate”
“authenticated-signed-writes”
“extended-properties”
“reliable-write”
“writable-auxiliaries”
“encrypt-read”
“encrypt-write”
“encrypt-notify” (Server only)
“encrypt-indicate” (Server only)
“encrypt-authenticated-read”
“encrypt-authenticated-write”
“encrypt-authenticated-notify” (Server only)
“encrypt-authenticated-indicate” (Server only)
“secure-read” (Server only)
“secure-write” (Server only)
“secure-notify” (Server only)
“secure-indicate” (Server only)
“authorize”

uint16 Handle [read-only] (Client Only)

Characteristic handle.

uint16 Handle [read-write, optional] (Server Only)

Characteristic handle. When available in the server it would attempt to use to allocate into the database which may fail, to auto allocate the value 0x0000 shall be used which will cause the allocated handle to be set once registered.

uint16 MTU [read-only]

Characteristic MTU, this is valid both for ReadValue() and WriteValue() but either method can use long procedures when supported.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

202 - Linux cli command org.freedesktop.timedate1

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.freedesktop.timedate1 and provides detailed information about the command org.freedesktop.timedate1, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.freedesktop.timedate1.

NAME 🖥️ org.freedesktop.timedate1 🖥️

The D-Bus interface of systemd-timedated

INTRODUCTION

systemd-timedated.service(8) is a system service that can be used to control the system time and related settings. This page describes the D-Bus interface.

THE D-BUS API

The service exposes the following interfaces on the bus:

node /org/freedesktop/timedate1 { interface org.freedesktop.timedate1 { methods: SetTime(in x usec_utc, in b relative, in b interactive); SetTimezone(in s timezone, in b interactive); SetLocalRTC(in b local_rtc, in b fix_system, in b interactive); SetNTP(in b use_ntp, in b interactive); ListTimezones(out as timezones); properties: readonly s Timezone = …; readonly b LocalRTC = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b CanNTP = …; readonly b NTP = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly b NTPSynchronized = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t TimeUSec = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t RTCTimeUSec = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; };

Methods

Use SetTime() to change the system clock. Pass a value of microseconds since the UNIX epoch (1 Jan 1970 UTC). If relative is true, the passed usec value will be added to the current system time. If it is false, the current system time will be set to the passed usec value. If the system time is set with this method, the RTC will be updated as well.

Use SetTimezone() to set the system timezone. Pass a value like “Europe/Berlin” to set the timezone. Valid timezones are listed in /usr/share/zoneinfo/zone.tab. If the RTC is configured to be maintained in local time, it will be updated accordingly.

Use SetLocalRTC() to control whether the RTC is in local time or UTC. It is strongly recommended to maintain the RTC in UTC. However, some OSes (Windows) maintain the RTC in local time, which might make it necessary to enable this feature. Note that this might create various problems as daylight changes could be missed. If fix_system is “true”, the time from the RTC is read again and the system clock is adjusted according to the new setting. If fix_system is “false”, the system time is written to the RTC taking the new setting into account. Use fix_system=true in installers and livecds where the RTC is probably more reliable than the system time. Use fix_system=false in configuration UIs that are run during normal operation and where the system clock is probably more reliable than the RTC.

Use SetNTP() to control whether the system clock is synchronized with the network using systemd-timesyncd. This will enable and start or disable and stop the chosen time synchronization service.

ListTimezones() returns a list of time zones known on the local system as an array of names ("[“Africa/Abidjan”, “Africa/Accra”, …, “UTC”]").

Properties

Timezone shows the currently configured time zone. LocalRTC shows whether the RTC is configured to use UTC (false), or the local time zone (true). CanNTP shows whether a service to perform time synchronization over the network is available, and NTP shows whether such a service is enabled.

NTPSynchronized shows whether the kernel reports the time as synchronized (c.f. adjtimex(3)). TimeUSec and RTCTimeUSec show the current time on the system and in the RTC. The purpose of those three properties is to allow remote clients to access this information over D-Bus. Local clients can access the information directly.

Whenever the Timezone and LocalRTC settings are changed via the daemon, PropertyChanged signals are sent out to which clients can subscribe.

Note that this service will not inform you about system time changes. Use timerfd(3) with CLOCK_REALTIME and TFD_TIMER_CANCEL_ON_SET for that.

Security

The interactive boolean parameters can be used to control whether polkit[1] should interactively ask the user for authentication credentials if required.

The polkit action for SetTimezone() is org.freedesktop.timedate1.set-timezone. For SetLocalRTC() it is org.freedesktop.timedate1.set-local-rtc, for SetTime() it is org.freedesktop.timedate1.set-time and for SetNTP() it is org.freedesktop.timedate1.set-ntp. ListTimezones() does not require any privileges.

EXAMPLES

Example 1. Introspect org.freedesktop.timedate1 on the bus

$ gdbus introspect –system
–dest org.freedesktop.timedate1
–object-path /org/freedesktop/timedate1

VERSIONING

These D-Bus interfaces follow the usual interface versioning guidelines[2].

NOTES

polkit

https://www.freedesktop.org/software/polkit/docs/latest/

the usual interface versioning guidelines

https://0pointer.de/blog/projects/versioning-dbus.html

More information on how the system clock and RTC interact

https://lists.freedesktop.org/archives/systemd-devel/2011-May/002526.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

203 - Linux cli command proc_pid_fd

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_fd and provides detailed information about the command proc_pid_fd, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_fd.

NAME 🖥️ proc_pid_fd 🖥️

file descriptors

DESCRIPTION

/proc/pid/fd/
This is a subdirectory containing one entry for each file which the process has open, named by its file descriptor, and which is a symbolic link to the actual file. Thus, 0 is standard input, 1 standard output, 2 standard error, and so on.

For file descriptors for pipes and sockets, the entries will be symbolic links whose content is the file type with the inode. A readlink(2) call on this file returns a string in the format:

type:[inode]

For example, socket:[2248868] will be a socket and its inode is 2248868. For sockets, that inode can be used to find more information in one of the files under /proc/net/.

For file descriptors that have no corresponding inode (e.g., file descriptors produced by bpf(2), epoll_create(2), eventfd(2), inotify_init(2), perf_event_open(2), signalfd(2), timerfd_create(2), and userfaultfd(2)), the entry will be a symbolic link with contents of the form

anon_inode:file-type

In many cases (but not all), the file-type is surrounded by square brackets.

For example, an epoll file descriptor will have a symbolic link whose content is the string anon_inode:[eventpoll].

In a multithreaded process, the contents of this directory are not available if the main thread has already terminated (typically by calling pthread_exit(3)).

Programs that take a filename as a command-line argument, but don’t take input from standard input if no argument is supplied, and programs that write to a file named as a command-line argument, but don’t send their output to standard output if no argument is supplied, can nevertheless be made to use standard input or standard output by using /proc/pid/fd files as command-line arguments. For example, assuming that -i is the flag designating an input file and -o is the flag designating an output file:

$ foobar -i /proc/self/fd/0 -o /proc/self/fd/1 ...

and you have a working filter.

/proc/self/fd/N is approximately the same as /dev/fd/N in some UNIX and UNIX-like systems. Most Linux MAKEDEV scripts symbolically link /dev/fd to /proc/self/fd, in fact.

Most systems provide symbolic links /dev/stdin, /dev/stdout, and /dev/stderr, which respectively link to the files 0, 1, and 2 in /proc/self/fd. Thus the example command above could be written as:

$ foobar -i /dev/stdin -o /dev/stdout ...

Permission to dereference or read (readlink(2)) the symbolic links in this directory is governed by a ptrace access mode PTRACE_MODE_READ_FSCREDS check; see ptrace(2).

Note that for file descriptors referring to inodes (pipes and sockets, see above), those inodes still have permission bits and ownership information distinct from those of the /proc/pid/fd entry, and that the owner may differ from the user and group IDs of the process. An unprivileged process may lack permissions to open them, as in this example:

$ echo test | sudo -u nobody cat
test
$ echo test | sudo -u nobody cat /proc/self/fd/0
cat: /proc/self/fd/0: Permission denied

File descriptor 0 refers to the pipe created by the shell and owned by that shell’s user, which is not nobody, so cat does not have permission to create a new file descriptor to read from that inode, even though it can still read from its existing file descriptor 0.

204 - Linux cli command proc_pid_cwd

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_cwd and provides detailed information about the command proc_pid_cwd, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_cwd.

NAME 🖥️ proc_pid_cwd 🖥️

symbolic link to current working directory

DESCRIPTION

/proc/pid/cwd
This is a symbolic link to the current working directory of the process. To find out the current working directory of process 20, for instance, you can do this:

$ cd /proc/20/cwd; pwd -P

In a multithreaded process, the contents of this symbolic link are not available if the main thread has already terminated (typically by calling pthread_exit(3)).

Permission to dereference or read (readlink(2)) this symbolic link is governed by a ptrace access mode PTRACE_MODE_READ_FSCREDS check; see ptrace(2).

205 - Linux cli command org.bluez.Media

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.Media and provides detailed information about the command org.bluez.Media, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.Media.

NAME 🖥️ org.bluez.Media 🖥️

BlueZ D-Bus Media API documentation

INTERFACE

Service
org.bluez
Interface
org.bluez.Media1
Object path
[variable prefix]/{hci0,hci1,…}

Methods

void RegisterEndpoint(object endpoint, dict properties)

Register a local end point to sender, the sender can register as many end points as it likes.
Note: If the sender disconnects the end points are automatically unregistered.
possible properties:
string UUID
UUID of the profile which the endpoint is for.
UUID must be in the list of SupportedUUIDS.
byte Codec
Assigned number of codec that the endpoint implements. The values should match the profile specification which is indicated by the UUID.
uint32_t Vendor [Optional]
Vendor-specific Company ID, Codec ID tuple that the endpoint implements.
It shall be set to appropriate value when Vendor Specific Codec (0xff) is used.
array{byte} Capabilities
Capabilities blob, it is used as it is so the size and byte order must match.
array{byte} Metadata [Optional]
Metadata blob, it is used as it is so the size and byte order must match.
Possible Errors:
org.bluez.Error.InvalidArguments
org.bluez.Error.NotSupported
emitted when interface for the end-point is disabled

void UnregisterEndpoint(object endpoint)

Unregister sender end point.

void RegisterPlayer(object player, dict properties)

Register a media player object to sender, the sender can register as many objects as it likes.
Object must implement at least org.mpris.MediaPlayer2.Player as defined in MPRIS 2.2 spec:
http://specifications.freedesktop.org/mpris-spec/latest/
Note: If the sender disconnects its objects are automatically unregistered.
Possible Errors:
org.bluez.Error.InvalidArguments
org.bluez.Error.NotSupported

void UnregisterPlayer(object player)

Unregister sender media player.

void RegisterApplication(object root, dict options)

Register endpoints an player objects within root object which must implement ObjectManager.
The application object path together with the D-Bus system bus connection ID define the identification of the application.
Possible errors:
org.bluez.Error.InvalidArguments
org.bluez.Error.AlreadyExists

void UnregisterApplication(object application)

This unregisters the services that has been previously registered. The object path parameter must match the same value that has been used on registration.
Possible errors:
org.bluez.Error.InvalidArguments
org.bluez.Error.DoesNotExist

Properties

array{string} SupportedUUIDs [readonly]

List of 128-bit UUIDs that represents the supported Endpoint registration.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

206 - Linux cli command procfs

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command procfs and provides detailed information about the command procfs, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the procfs.

NAME 🖥️ procfs 🖥️

process information, system information, and sysctl pseudo-filesystem

DESCRIPTION

The proc filesystem is a pseudo-filesystem which provides an interface to kernel data structures. It is commonly mounted at /proc. Typically, it is mounted automatically by the system, but it can also be mounted manually using a command such as:

mount -t proc proc /proc

Most of the files in the proc filesystem are read-only, but some files are writable, allowing kernel variables to be changed.

Mount options

The proc filesystem supports the following mount options:

hidepid=n (since Linux 3.3)
This option controls who can access the information in */proc/*pid directories. The argument, n, is one of the following values:

0
Everybody may access all */proc/*pid directories. This is the traditional behavior, and the default if this mount option is not specified.

1
Users may not access files and subdirectories inside any */proc/*pid directories but their own (the */proc/*pid directories themselves remain visible). Sensitive files such as /proc/pid/cmdline and /proc/pid/status are now protected against other users. This makes it impossible to learn whether any user is running a specific program (so long as the program doesn’t otherwise reveal itself by its behavior).

2
As for mode 1, but in addition the */proc/*pid directories belonging to other users become invisible. This means that */proc/*pid entries can no longer be used to discover the PIDs on the system. This doesn’t hide the fact that a process with a specific PID value exists (it can be learned by other means, for example, by “kill -0 $PID”), but it hides a process’s UID and GID, which could otherwise be learned by employing stat(2) on a */proc/*pid directory. This greatly complicates an attacker’s task of gathering information about running processes (e.g., discovering whether some daemon is running with elevated privileges, whether another user is running some sensitive program, whether other users are running any program at all, and so on).

gid=gid (since Linux 3.3)
Specifies the ID of a group whose members are authorized to learn process information otherwise prohibited by hidepid (i.e., users in this group behave as though /proc was mounted with hidepid=0). This group should be used instead of approaches such as putting nonroot users into the sudoers(5) file.

subset=pid (since Linux 5.8)
Show only the specified subset of procfs, hiding all top level files and directories in the procfs that are not related to tasks.

Overview

Underneath /proc, there are the following general groups of files and subdirectories:

*/proc/*pid subdirectories
Each one of these subdirectories contains files and subdirectories exposing information about the process with the corresponding process ID.

Underneath each of the */proc/*pid directories, a task subdirectory contains subdirectories of the form *task/*tid, which contain corresponding information about each of the threads in the process, where tid is the kernel thread ID of the thread.

The */proc/*pid subdirectories are visible when iterating through /proc with getdents(2) (and thus are visible when one uses ls(1) to view the contents of /proc).

*/proc/*tid subdirectories
Each one of these subdirectories contains files and subdirectories exposing information about the thread with the corresponding thread ID. The contents of these directories are the same as the corresponding */proc/pid/task/*tid directories.

The */proc/*tid subdirectories are not visible when iterating through /proc with getdents(2) (and thus are not visible when one uses ls(1) to view the contents of /proc).

/proc/self
When a process accesses this magic symbolic link, it resolves to the process’s own */proc/*pid directory.

/proc/thread-self
When a thread accesses this magic symbolic link, it resolves to the process’s own */proc/self/task/*tid directory.

/proc/[a-z]*
Various other files and subdirectories under /proc expose system-wide information.

All of the above are described in more detail in separate manpages whose names start with proc_.

NOTES

Many files contain strings (e.g., the environment and command line) that are in the internal format, with subfields terminated by null bytes (‘�’). When inspecting such files, you may find that the results are more readable if you use a command of the following form to display them:

$ cat file | tr '' '

207 - Linux cli command slabinfo

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command slabinfo and provides detailed information about the command slabinfo, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the slabinfo.

NAME 🖥️ slabinfo 🖥️

kernel slab allocator statistics

SYNOPSIS

cat /proc/slabinfo

DESCRIPTION

Frequently used objects in the Linux kernel (buffer heads, inodes, dentries, etc.) have their own cache. The file /proc/slabinfo gives statistics on these caches. The following (edited) output shows an example of the contents of this file:

$ sudo cat /proc/slabinfo
slabinfo - version: 2.1
# name    <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> ...
sigqueue      100  100  160   25  1 : tunables  0  0  0 : slabdata   4   4  0
sighand_cache 355   405 2112  15  8 : tunables  0  0  0 : slabdata  27  27  0
kmalloc-8192   96   96  8192   4  8 : tunables  0  0  0 : slabdata  24  24  0
...

The first line of output includes a version number, which allows an application that is reading the file to handle changes in the file format. (See VERSIONS, below.) The next line lists the names of the columns in the remaining lines.

Each of the remaining lines displays information about a specified cache. Following the cache name, the output shown in each line shows three components for each cache:

statistics
tunables
slabdata

The statistics are as follows:

active_objs
The number of objects that are currently active (i.e., in use).

num_objs
The total number of allocated objects (i.e., objects that are both in use and not in use).

objsize
The size of objects in this slab, in bytes.

objperslab
The number of objects stored in each slab.

pagesperslab
The number of pages allocated for each slab.

The tunables entries in each line show tunable parameters for the corresponding cache. When using the default SLUB allocator, there are no tunables, the /proc/slabinfo file is not writable, and the value 0 is shown in these fields. When using the older SLAB allocator, the tunables for a particular cache can be set by writing lines of the following form to /proc/slabinfo:

# echo 'name limit batchcount sharedfactor' > /proc/slabinfo

Here, name is the cache name, and limit, batchcount, and sharedfactor are integers defining new values for the corresponding tunables. The limit value should be a positive value, batchcount should be a positive value that is less than or equal to limit, and sharedfactor should be nonnegative. If any of the specified values is invalid, the cache settings are left unchanged.

The tunables entries in each line contain the following fields:

limit
The maximum number of objects that will be cached.

batchcount
On SMP systems, this specifies the number of objects to transfer at one time when refilling the available object list.

sharedfactor
[To be documented]

The slabdata entries in each line contain the following fields:

active_slabs
The number of active slabs.

nums_slabs
The total number of slabs.

sharedavail
[To be documented]

Note that because of object alignment and slab cache overhead, objects are not normally packed tightly into pages. Pages with even one in-use object are considered in-use and cannot be freed.

Kernels configured with CONFIG_DEBUG_SLAB will also have additional statistics fields in each line, and the first line of the file will contain the string “(statistics)”. The statistics field include : the high water mark of active objects; the number of times objects have been allocated; the number of times the cache has grown (new pages added to this cache); the number of times the cache has been reaped (unused pages removed from this cache); and the number of times there was an error allocating new pages to this cache.

VERSIONS

The /proc/slabinfo file first appeared in Linux 2.1.23. The file is versioned, and over time there have been a number of versions with different layouts:

1.0
Present throughout the Linux 2.2.x kernel series.

1.1
Present in the Linux 2.4.x kernel series.

1.2
A format that was briefly present in the Linux 2.5 development series.

2.0
Present in Linux 2.6.x kernels up to and including Linux 2.6.9.

2.1
The current format, which first appeared in Linux 2.6.10.

NOTES

Only root can read and (if the kernel was configured with CONFIG_SLAB) write the /proc/slabinfo file.

The total amount of memory allocated to the SLAB/SLUB cache is shown in the Slab field of /proc/meminfo.

208 - Linux cli command org.bluez.GattDescriptor

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.GattDescriptor and provides detailed information about the command org.bluez.GattDescriptor, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.GattDescriptor.

NAME 🖥️ org.bluez.GattDescriptor 🖥️

BlueZ D-Bus GattDescriptor API documentation

DESCRIPTION

GATT local/server and remote/client descriptor attribute representation share the same high-level D-Bus API.

Local/Server refers to GATT based descriptors exported by a plugin or an external application.

Remote/Client refers to GATT descriptors exported by the peer.

INTERFACE

Client

Service
org.bluez
Interface
org.bluez.GattDescriptor1
Object path
[variable prefix]/{hci0,hci1,…}/dev_XX_XX_XX_XX_XX_XX/serviceXX/charYYYY/descriptorZZZ

Server

Service
unique name
Interface
org.bluez.GattDescriptor1
Object path
freely definable

Methods

array{byte} ReadValue(dict flags)

Issues a request to read the value of the descriptor and returns the value if the operation was successful.
Possible options:
uint16_t offset
Read start offset in bytes.
object device (server only)
Device object.
string link
Link type (Server only).
Possible values:
“BR/EDR”
“LE”
Possible Errors:
org.bluez.Error.Failed
org.bluez.Error.InProgress
org.bluez.Error.NotPermitted
org.bluez.Error.NotAuthorized
org.bluez.Error.NotSupported

void WriteValue(array{byte} value, dict flags)

Issues a request to write the value of the descriptor.
Possible flags:
uint16 offset
Write start offset in bytes.
uint16 mtu
Exchanged MTU (Server only).
object device
Device path (Server only).
string link
Link type (Server only).
Possible values:
“BR/EDR”
“LE”
boolean prepare-authorize
True if prepare authorization request.
Possible Errors:
org.bluez.Error.Failed
org.bluez.Error.InProgress
org.bluez.Error.NotPermitted
org.bluez.Error.InvalidValueLength
org.bluez.Error.NotAuthorized
org.bluez.Error.NotSupported

Properties

string UUID [read-only]

128-bit descriptor UUID.

object Characteristic [read-only]

Object path of the GATT characteristic the descriptor belongs to.

array{byte} Value [read-only, optional]

The cached value of the descriptor. This property gets updated only after a successful read request, upon which a PropertiesChanged signal will be emitted.

array{string} Flags [read-only]

Defines how the descriptor value can be used.
Possible values:
“read”
“write”
“encrypt-read”
“encrypt-write”
“encrypt-authenticated-read”
“encrypt-authenticated-write”
“secure-read” (Server Only)
“secure-write” (Server Only)
“authorize”

uint16 Handle [read-only] (Client Only)

Descriptor handle.

uint16 Handle [read-write, optional] (Server Only)

Descriptor handle. When available in the server it would attempt to use to allocate into the database which may fail, to auto allocate the value 0x0000 shall be used which will cause the allocated handle to be set once registered.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

209 - Linux cli command snmpd.internal

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command snmpd.internal and provides detailed information about the command snmpd.internal, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the snmpd.internal.

NAME 🖥️ snmpd.internal 🖥️

internal configuration of the Net-SNMP agent

DESCRIPTION

The snmpd.conf(5) man page defines the syntax and behaviour of the main configuration directives that can be used to control the operation of the Net-SNMP agent, and the management information it provides.

However there are several other configuration directives (many of which, though not all, start with a leading underscore) that are recognised by the agent. These are typically used to retain configuration across agent restarts, and are not intended for direct user access. This man page list these directives, giving a brief indication of where they are used. For full details - see the relevant source files. If you can’t follow that source, you probably shouldn’t be fiddling with these directives!

AGENT BEHAVIOUR

quit

ACCESS CONTROL

VACM Configuration

vacmView / vacmGroup / vacmAccess
These directives are used to retain dynamically configured access control settings.

SYSTEM INFORMATION

System Group

setSerialNo
This directive is used to implement the advisory lock object snmpSetSerialNo.

psyslocation / psyscontact / psysname
These directives are used to retain dynamically configured system settings. They will be overridden by the corresponding sysLocation, sysContact and sysName directives.

ACTIVE MONITORING

Notification Handling

pauthtrapenable
This directive is used to retain the dynamically configured setting of whether the agent should generate authenticationFailure traps. It will be overridden by the corresponding authtrapenable directive.

snmpNotify*Table

targetAddr / targetParams
These directives are used to retain dynamically configured notification destination settings.

DisMan Event MIB

_mteE*Table, _mteOTable, _mteT*Table
These directives are used to retain dynamically configured event, object and monitor trigger settings.

mteObjectsTable / mteTriggerTable
These directives are for compatibility with the previous disman/event-mib implementation.

DisMan Schedule MIB

_schedTable
This directive is used to retain dynamically configured scheduled events.

EXTENDING AGENT FUNCTIONALITY

Arbitrary Extension Commands

extend-sh

exec2 / sh2 / execFix2
These directives were defined by analogy with equivalent directives in the previous ucd-snmp/extensible implementation. They are deprecated, and should not be used.

FILES

/etc/snmp/snmpd.conf

210 - Linux cli command pwhistory.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command pwhistory.conf and provides detailed information about the command pwhistory.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the pwhistory.conf.

NAME 🖥️ pwhistory.conf 🖥️

pam_pwhistory configuration file

DESCRIPTION

pwhistory.conf provides a way to configure the default settings for saving the last passwords for each user. This file is read by the pam_pwhistory module and is the preferred method over configuring pam_pwhistory directly.

The file has a very simple name = value format with possible comments starting with # character. The whitespace at the beginning of line, end of line, and around the = sign is ignored.

OPTIONS

debug

Turns on debugging via syslog(3).

enforce_for_root

If this option is set, the check is enforced for root, too.

remember=N

The last N passwords for each user are saved. The default is 10. Value of 0 makes the module to keep the existing contents of the opasswd file unchanged.

retry=N

Prompt user at most N times before returning with error. The default is 1.

file=/path/filename

Store password history in file /path/filename rather than the default location. The default location is /etc/security/opasswd.

EXAMPLES

/etc/security/pwhistory.conf file example:

debug remember=5 file=/tmp/opasswd

FILES

/etc/security/pwhistory.conf

the config file for custom options

AUTHOR

pam_pwhistory was written by Thorsten Kukuk. The support for pwhistory.conf was written by Iker Pedrosa.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

211 - Linux cli command gitprotocol-v2

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitprotocol-v2 and provides detailed information about the command gitprotocol-v2, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitprotocol-v2.

NAME 🖥️ gitprotocol-v2 🖥️

v2 - Git Wire Protocol, Version 2

SYNOPSIS

<over-the-wire-protocol>

DESCRIPTION

This document presents a specification for a version 2 of Git’s wire protocol. Protocol v2 will improve upon v1 in the following ways:

·
Instead of multiple service names, multiple commands will be supported by a single service

·
Easily extendable as capabilities are moved into their own section of the protocol, no longer being hidden behind a NUL byte and limited by the size of a pkt-line

·
Separate out other information hidden behind NUL bytes (e.g. agent string as a capability and symrefs can be requested using ls-refs)

·
Reference advertisement will be omitted unless explicitly requested

·
ls-refs command to explicitly request some refs

·
Designed with http and stateless-rpc in mind. With clear flush semantics the http remote helper can simply act as a proxy

In protocol v2 communication is command oriented. When first contacting a server a list of capabilities will be advertised. Some of these capabilities will be commands which a client can request be executed. Once a command has completed, a client can reuse the connection and request that other commands be executed.

PACKET-LINE FRAMING

All communication is done using packet-line framing, just as in v1. See gitprotocol-pack(5) and gitprotocol-common(5) for more information.

In protocol v2 these special packets will have the following semantics:

·
0000 Flush Packet (flush-pkt) - indicates the end of a message

·
0001 Delimiter Packet (delim-pkt) - separates sections of a message

·
0002 Response End Packet (response-end-pkt) - indicates the end of a response for stateless connections

INITIAL CLIENT REQUEST

In general a client can request to speak protocol v2 by sending version=2 through the respective side-channel for the transport being used which inevitably sets GIT_PROTOCOL. More information can be found in gitprotocol-pack(5) and gitprotocol-http(5), as well as the GIT_PROTOCOL definition in git.txt. In all cases the response from the server is the capability advertisement.

Git Transport

When using the git:// transport, you can request to use protocol v2 by sending “version=2” as an extra parameter:

003egit-upload-pack /project.git�host=myserver.com��version=2�

SSH and File Transport

When using either the ssh:// or file:// transport, the GIT_PROTOCOL environment variable must be set explicitly to include “version=2”. The server may need to be configured to allow this environment variable to pass.

HTTP Transport

When using the http:// or https:// transport a client makes a “smart” info/refs request as described in gitprotocol-http(5) and requests that v2 be used by supplying “version=2” in the Git-Protocol header.

C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0 C: Git-Protocol: version=2

A v2 server would reply:

S: 200 OK S: S: … S: S: 000eversion 2

S: <capability-advertisement>

Subsequent requests are then made directly to the service $GIT_URL/git-upload-pack. (This works the same for git-receive-pack).

Uses the –http-backend-info-refs option to git-upload-pack(1).

The server may need to be configured to pass this header’s contents via the GIT_PROTOCOL variable. See the discussion in git-http-backend.txt.

CAPABILITY ADVERTISEMENT

A server which decides to communicate (based on a request from a client) using protocol version 2, notifies the client by sending a version string in its initial response followed by an advertisement of its capabilities. Each capability is a key with an optional value. Clients must ignore all unknown keys. Semantics of unknown values are left to the definition of each key. Some capabilities will describe commands which can be requested to be executed by the client.

capability-advertisement = protocol-version capability-list flush-pkt

protocol-version = PKT-LINE(“version 2” LF) capability-list = *capability capability = PKT-LINE(key[=value] LF)

key = 1*(ALPHA | DIGIT | “-”) value = 1*(ALPHA | DIGIT | " -.,?/{}<>!@#$%^&*+=:;")

COMMAND REQUEST

After receiving the capability advertisement, a client can then issue a request to select the command it wants with any particular capabilities or arguments. There is then an optional section where the client can provide any command specific parameters or queries. Only a single command can be requested at a time.

request = empty-request | command-request empty-request = flush-pkt command-request = command capability-list delim-pkt command-args flush-pkt command = PKT-LINE(“command=” key LF) command-args = *command-specific-arg

command-specific-args are packet line framed arguments defined by each individual command.

The server will then check to ensure that the client’s request is comprised of a valid command as well as valid capabilities which were advertised. If the request is valid the server will then execute the command. A server MUST wait till it has received the client’s entire request before issuing a response. The format of the response is determined by the command being executed, but in all cases a flush-pkt indicates the end of the response.

When a command has finished, and the client has received the entire response from the server, a client can either request that another command be executed or can terminate the connection. A client may optionally send an empty request consisting of just a flush-pkt to indicate that no more requests will be made.

CAPABILITIES

There are two different types of capabilities: normal capabilities, which can be used to convey information or alter the behavior of a request, and commands, which are the core actions that a client wants to perform (fetch, push, etc).

Protocol version 2 is stateless by default. This means that all commands must only last a single round and be stateless from the perspective of the server side, unless the client has requested a capability indicating that state should be maintained by the server. Clients MUST NOT require state management on the server side in order to function correctly. This permits simple round-robin load-balancing on the server side, without needing to worry about state management.

agent

The server can advertise the agent capability with a value X (in the form agent=X) to notify the client that the server is running version X. The client may optionally send its own agent string by including the agent capability with a value Y (in the form agent=Y) in its request to the server (but it MUST NOT do so if the server did not advertise the agent capability). The X and Y strings may contain any printable ASCII characters except space (i.e., the byte range 32 < x < 127), and are typically of the form “package/version” (e.g., “git/1.8.3.1”). The agent strings are purely informative for statistics and debugging purposes, and MUST NOT be used to programmatically assume the presence or absence of particular features.

ls-refs

ls-refs is the command used to request a reference advertisement in v2. Unlike the current reference advertisement, ls-refs takes in arguments which can be used to limit the refs sent from the server.

Additional features not supported in the base command will be advertised as the value of the command in the capability advertisement in the form of a space separated list of features: “<command>=<feature 1> <feature 2>”

ls-refs takes in the following arguments:

symrefs In addition to the object pointed by it, show the underlying ref pointed by it when showing a symbolic ref. peel Show peeled tags. ref-prefix When specified, only references having a prefix matching one of the provided prefixes are displayed. Multiple instances may be given, in which case references matching any prefix will be shown. Note that this is purely for optimization; a server MAY show refs not matching the prefix if it chooses, and clients should filter the result themselves.

If the unborn feature is advertised the following argument can be included in the client’s request.

unborn The server will send information about HEAD even if it is a symref pointing to an unborn branch in the form “unborn HEAD symref-target:”.

The output of ls-refs is as follows:

output = *ref flush-pkt obj-id-or-unborn = (obj-id | “unborn”) ref = PKT-LINE(obj-id-or-unborn SP refname *(SP ref-attribute) LF) ref-attribute = (symref | peeled) symref = “symref-target:” symref-target peeled = “peeled:” obj-id

fetch

fetch is the command used to fetch a packfile in v2. It can be looked at as a modified version of the v1 fetch where the ref-advertisement is stripped out (since the ls-refs command fills that role) and the message format is tweaked to eliminate redundancies and permit easy addition of future extensions.

A fetch request can take the following arguments:

want Indicates to the server an object which the client wants to retrieve. Wants can be anything and are not limited to advertised objects.

have Indicates to the server an object which the client has locally. This allows the server to make a packfile which only contains the objects that the client needs. Multiple have lines can be supplied.

done Indicates to the server that negotiation should terminate (or not even begin if performing a clone) and that the server should use the information supplied in the request to construct the packfile.

thin-pack Request that a thin pack be sent, which is a pack with deltas which reference base objects not contained within the pack (but are known to exist at the receiving end). This can reduce the network traffic significantly, but it requires the receiving end to know how to “thicken” these packs by adding the missing bases to the pack.

no-progress Request that progress information that would normally be sent on side-band channel 2, during the packfile transfer, should not be sent. However, the side-band channel 3 is still used for error responses.

include-tag Request that annotated tags should be sent if the objects they point to are being sent.

ofs-delta Indicate that the client understands PACKv2 with delta referring to its base by position in pack rather than by an oid. That is, they can read OBJ_OFS_DELTA (aka type 6) in a packfile.

If the shallow feature is advertised the following arguments can be included in the clients request as well as the potential addition of the shallow-info section in the server’s response as explained below.

shallow A client must notify the server of all commits for which it only has shallow copies (meaning that it doesnt have the parents of a commit) by supplying a shallow line for each such object so that the server is aware of the limitations of the clients history. This is so that the server is aware that the client may not have all objects reachable from such commits.

deepen Requests that the fetch/clone should be shallow having a commit depth of relative to the remote side.

deepen-relative Requests that the semantics of the “deepen” command be changed to indicate that the depth requested is relative to the clients current shallow boundary, instead of relative to the requested commits.

deepen-since Requests that the shallow clone/fetch should be cut at a specific time, instead of depth. Internally its equivalent to doing “git rev-list –max-age=”. Cannot be used with “deepen”.

deepen-not Requests that the shallow clone/fetch should be cut at a specific revision specified by , instead of a depth. Internally its equivalent of doing “git rev-list –not ”. Cannot be used with “deepen”, but can be used with “deepen-since”.

If the filter feature is advertised, the following argument can be included in the client’s request:

filter Request that various objects from the packfile be omitted using one of several filtering techniques. These are intended for use with partial clone and partial fetch operations. See rev-list for possible “filter-spec” values. When communicating with other processes, senders SHOULD translate scaled integers (e.g. “1k”) into a fully-expanded form (e.g. “1024”) to aid interoperability with older receivers that may not understand newly-invented scaling suffixes. However, receivers SHOULD accept the following suffixes: k, m, and g for 1024, 1048576, and 1073741824, respectively.

If the ref-in-want feature is advertised, the following argument can be included in the client’s request as well as the potential addition of the wanted-refs section in the server’s response as explained below.

want-ref Indicates to the server that the client wants to retrieve a particular ref, where is the full name of a ref on the server.

If the sideband-all feature is advertised, the following argument can be included in the client’s request:

sideband-all Instruct the server to send the whole response multiplexed, not just the packfile section. All non-flush and non-delim PKT-LINE in the response (not only in the packfile section) will then start with a byte indicating its sideband (1, 2, or 3), and the server may send “0005\2” (a PKT-LINE of sideband 2 with no payload) as a keepalive packet.

If the packfile-uris feature is advertised, the following argument can be included in the client’s request as well as the potential addition of the packfile-uris section in the server’s response as explained below.

packfile-uris Indicates to the server that the client is willing to receive URIs of any of the given protocols in place of objects in the sent packfile. Before performing the connectivity check, the client should download from all given URIs. Currently, the protocols supported are “http” and “https”.

If the wait-for-done feature is advertised, the following argument can be included in the client’s request.

wait-for-done Indicates to the server that it should never send “ready”, but should wait for the client to say “done” before sending the packfile.

The response of fetch is broken into a number of sections separated by delimiter packets (0001), with each section beginning with its section header. Most sections are sent only when the packfile is sent.

output = acknowledgements flush-pkt | [acknowledgments delim-pkt] [shallow-info delim-pkt] [wanted-refs delim-pkt] [packfile-uris delim-pkt] packfile flush-pkt

acknowledgments = PKT-LINE(“acknowledgments” LF) (nak | *ack) (ready) ready = PKT-LINE(“ready” LF) nak = PKT-LINE(“NAK” LF) ack = PKT-LINE(“ACK” SP obj-id LF)

shallow-info = PKT-LINE(“shallow-info” LF) *PKT-LINE((shallow | unshallow) LF) shallow = “shallow” SP obj-id unshallow = “unshallow” SP obj-id

wanted-refs = PKT-LINE(“wanted-refs” LF) *PKT-LINE(wanted-ref LF) wanted-ref = obj-id SP refname

packfile-uris = PKT-LINE(“packfile-uris” LF) packfile-uri packfile-uri = PKT-LINE(40(HEXDIGIT) SP *%x20-ff LF)

packfile = PKT-LINE(“packfile” LF) *PKT-LINE(%x01-03 *%x00-ff)

acknowledgments section * If the client determines that it is finished with negotiations by sending a “done” line (thus requiring the server to send a packfile), the acknowledgments sections MUST be omitted from the servers response.

·
Always begins with the section header “acknowledgments”

·
The server will respond with “NAK” if none of the object ids sent as have lines were common.

·
The server will respond with “ACK obj-id” for all of the object ids sent as have lines which are common.

·
A response cannot have both “ACK” lines as well as a “NAK” line.

·
The server will respond with a “ready” line indicating that the server has found an acceptable common base and is ready to make and send a packfile (which will be found in the packfile section of the same response)

·
If the server has found a suitable cut point and has decided to send a “ready” line, then the server can decide to (as an optimization) omit any “ACK” lines it would have sent during its response. This is because the server will have already determined the objects it plans to send to the client and no further negotiation is needed.
shallow-info section * If the client has requested a shallow fetch/clone, a shallow client requests a fetch or the server is shallow then the servers response may include a shallow-info section. The shallow-info section will be included if (due to one of the above conditions) the server needs to inform the client of any shallow boundaries or adjustments to the clients already existing shallow boundaries.

·
Always begins with the section header “shallow-info”

·
If a positive depth is requested, the server will compute the set of commits which are no deeper than the desired depth.

·
The server sends a “shallow obj-id” line for each commit whose parents will not be sent in the following packfile.

·
The server sends an “unshallow obj-id” line for each commit which the client has indicated is shallow, but is no longer shallow as a result of the fetch (due to its parents being sent in the following packfile).

·
The server MUST NOT send any “unshallow” lines for anything which the client has not indicated was shallow as a part of its request.
wanted-refs section * This section is only included if the client has requested a ref using a want-ref line and if a packfile section is also included in the response.

·
Always begins with the section header “wanted-refs”.

·
The server will send a ref listing ("<oid> <refname>") for each reference requested using want-ref lines.

·
The server MUST NOT send any refs which were not requested using want-ref lines.
packfile-uris section * This section is only included if the client sent packfile-uris and the server has at least one such URI to send.

·
Always begins with the section header “packfile-uris”.

·
For each URI the server sends, it sends a hash of the pack’s contents (as output by git index-pack) followed by the URI.

·
The hashes are 40 hex characters long. When Git upgrades to a new hash algorithm, this might need to be updated. (It should match whatever index-pack outputs after “pack " or “keep “.
packfile section * This section is only included if the client has sent want lines in its request and either requested that no more negotiation be done by sending done or if the server has decided it has found a sufficient cut point to produce a packfile.

·
Always begins with the section header “packfile”

·
The transmission of the packfile begins immediately after the section header

·
The data transfer of the packfile is always multiplexed, using the same semantics of the side-band-64k capability from protocol version 1. This means that each packet, during the packfile data stream, is made up of a leading 4-byte pkt-line length (typical of the pkt-line format), followed by a 1-byte stream code, followed by the actual data.
The stream code can be one of: 1 - pack data 2 - progress messages 3 - fatal error message just before stream aborts

server-option

If advertised, indicates that any number of server specific options can be included in a request. This is done by sending each option as a “server-option=<option>” capability line in the capability-list section of a request.

The provided options must not contain a NUL or LF character.

object-format

The server can advertise the object-format capability with a value X (in the form object-format=X) to notify the client that the server is able to deal with objects using hash algorithm X. If not specified, the server is assumed to only handle SHA-1. If the client would like to use a hash algorithm other than SHA-1, it should specify its object-format string.

session-id=<session id>

The server may advertise a session ID that can be used to identify this process across multiple requests. The client may advertise its own session ID back to the server as well.

object-info

object-info is the command to retrieve information about one or more objects. Its main purpose is to allow a client to make decisions based on this information without having to fully fetch objects. Object size is the only information that is currently supported.

An object-info request takes the following arguments:

size Requests size information to be returned for each listed object id.

oid Indicates to the server an object which the client wants to obtain information for.

The response of object-info is a list of the requested object ids and associated requested information, each separated by a single space.

output = info flush-pkt

info = PKT-LINE(attrs) LF) *PKT-LINE(obj-info LF)

attrs = attr | attrs SP attrs

attr = “size”

obj-info = obj-id SP obj-size

bundle-uri

If the bundle-uri capability is advertised, the server supports the ‘bundle-uri’ command.

The capability is currently advertised with no value (i.e. not “bundle-uri=somevalue”), a value may be added in the future for supporting command-wide extensions. Clients MUST ignore any unknown capability values and proceed with the bundle-uri` dialog they support.

The bundle-uri command is intended to be issued before fetch to get URIs to bundle files (see git-bundle(1)) to “seed” and inform the subsequent fetch command.

The client CAN issue bundle-uri before or after any other valid command. To be useful to clients it’s expected that it’ll be issued after an ls-refs and before fetch, but CAN be issued at any time in the dialog.

DISCUSSION of bundle-uri

The intent of the feature is optimize for server resource consumption in the common case by changing the common case of fetching a very large PACK during git-clone(1) into a smaller incremental fetch.
It also allows servers to achieve better caching in combination with an uploadpack.packObjectsHook (see git-config(1)).
By having new clones or fetches be a more predictable and common negotiation against the tips of recently produces *.bundle file(s). Servers might even pre-generate the results of such negotiations for the uploadpack.packObjectsHook as new pushes come in.
One way that servers could take advantage of these bundles is that the server would anticipate that fresh clones will download a known bundle, followed by catching up to the current state of the repository using ref tips found in that bundle (or bundles).

PROTOCOL for bundle-uri

A bundle-uri request takes no arguments, and as noted above does not currently advertise a capability value. Both may be added in the future.
When the client issues a command=bundle-uri request, the response is a list of key-value pairs provided as packet lines with value <key>=<value>. Each <key> should be interpreted as a config key from the bundle.* namespace to construct a list of bundles. These keys are grouped by a bundle.<id>. subsection, where each key corresponding to a given <id> contributes attributes to the bundle defined by that <id>. See git-config(1) for the specific details of these keys and how the Git client will interpret their values.
Clients MUST parse the line according to the above format, lines that do not conform to the format SHOULD be discarded. The user MAY be warned in such a case.

bundle-uri CLIENT AND SERVER EXPECTATIONS

URI CONTENTS
The content at the advertised URIs MUST be one of two types.
The advertised URI may contain a bundle file that git bundle verify would accept. I.e. they MUST contain one or more reference tips for use by the client, MUST indicate prerequisites (in any) with standard “-” prefixes, and MUST indicate their “object-format”, if applicable.
The advertised URI may alternatively contain a plaintext file that git config –list would accept (with the –file option). The key-value pairs in this list are in the bundle.* namespace (see git-config(1)).
bundle-uri CLIENT ERROR RECOVERY
A client MUST above all gracefully degrade on errors, whether that error is because of bad missing/data in the bundle URI(s), because that client is too dumb to e.g. understand and fully parse out bundle headers and their prerequisite relationships, or something else.
Server operators should feel confident in turning on “bundle-uri” and not worry if e.g. their CDN goes down that clones or fetches will run into hard failures. Even if the server bundle(s) are incomplete, or bad in some way the client should still end up with a functioning repository, just as if it had chosen not to use this protocol extension.
All subsequent discussion on client and server interaction MUST keep this in mind.
bundle-uri SERVER TO CLIENT
The ordering of the returned bundle uris is not significant. Clients MUST parse their headers to discover their contained OIDS and prerequisites. A client MUST consider the content of the bundle(s) themselves and their header as the ultimate source of truth.
A server MAY even return bundle(s) that don’t have any direct relationship to the repository being cloned (either through accident, or intentional “clever” configuration), and expect a client to sort out what data they’d like from the bundle(s), if any.
bundle-uri CLIENT TO SERVER
The client SHOULD provide reference tips found in the bundle header(s) as have lines in any subsequent fetch request. A client MAY also ignore the bundle(s) entirely if doing so is deemed worse for some reason, e.g. if the bundles can’t be downloaded, it doesn’t like the tips it finds etc.
WHEN ADVERTISED BUNDLE(S) REQUIRE NO FURTHER NEGOTIATION
If after issuing bundle-uri and ls-refs, and getting the header(s) of the bundle(s) the client finds that the ref tips it wants can be retrieved entirely from advertised bundle(s), the client MAY disconnect from the Git server. The results of such a clone or fetch should be indistinguishable from the state attained without using bundle-uri.
EARLY CLIENT DISCONNECTIONS AND ERROR RECOVERY
A client MAY perform an early disconnect while still downloading the bundle(s) (having streamed and parsed their headers). In such a case the client MUST gracefully recover from any errors related to finishing the download and validation of the bundle(s).
I.e. a client might need to re-connect and issue a fetch command, and possibly fall back to not making use of bundle-uri at all.
This “MAY” behavior is specified as such (and not a “SHOULD”) on the assumption that a server advertising bundle uris is more likely than not to be serving up a relatively large repository, and to be pointing to URIs that have a good chance of being in working order. A client MAY e.g. look at the payload size of the bundles as a heuristic to see if an early disconnect is worth it, should falling back on a full “fetch” dialog be necessary.
WHEN ADVERTISED BUNDLE(S) REQUIRE FURTHER NEGOTIATION
A client SHOULD commence a negotiation of a PACK from the server via the “fetch” command using the OID tips found in advertised bundles, even if’s still in the process of downloading those bundle(s).
This allows for aggressive early disconnects from any interactive server dialog. The client blindly trusts that the advertised OID tips are relevant, and issues them as have lines, it then requests any tips it would like (usually from the “ls-refs” advertisement) via want lines. The server will then compute a (hopefully small) PACK with the expected difference between the tips from the bundle(s) and the data requested.
The only connection the client then needs to keep active is to the concurrently downloading static bundle(s), when those and the incremental PACK are retrieved they should be inflated and validated. Any errors at this point should be gracefully recovered from, see above.

bundle-uri PROTOCOL FEATURES

The client constructs a bundle list from the <key>=<value> pairs provided by the server. These pairs are part of the bundle.* namespace as documented in git-config(1). In this section, we discuss some of these keys and describe the actions the client will do in response to this information.
In particular, the bundle.version key specifies an integer value. The only accepted value at the moment is 1, but if the client sees an unexpected value here then the client MUST ignore the bundle list.
As long as bundle.version is understood, all other unknown keys MAY be ignored by the client. The server will guarantee compatibility with older clients, though newer clients may be better able to use the extra keys to minimize downloads.
Any backwards-incompatible addition of pre-URI key-value will be guarded by a new bundle.version value or values in bundle-uri capability advertisement itself, and/or by new future bundle-uri request arguments.
Some example key-value pairs that are not currently implemented but could be implemented in the future include:
·
Add a “hash=<val>” or “size=<bytes>” advertise the expected hash or size of the bundle file.
·
Advertise that one or more bundle files are the same (to e.g. have clients round-robin or otherwise choose one of N possible files).
·
A “oid=<OID>” shortcut and “prerequisite=<OID>” shortcut. For expressing the common case of a bundle with one tip and no prerequisites, or one tip and one prerequisite.
This would allow for optimizing the common case of servers who’d like to provide one “big bundle” containing only their “main” branch, and/or incremental updates thereof.
A client receiving such a a response MAY assume that they can skip retrieving the header from a bundle at the indicated URI, and thus save themselves and the server(s) the request(s) needed to inspect the headers of that bundle or bundles.

GIT

Part of the git(1) suite

NOTES

api-trace2

file:///usr/share/doc/git/html/technical/api-trace2.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

212 - Linux cli command key.dns_resolver.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command key.dns_resolver.conf and provides detailed information about the command key.dns_resolver.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the key.dns_resolver.conf.

NAME 🖥️ key.dns_resolver.conf 🖥️

Kernel DNS resolver config

DESCRIPTION

This file is used by the key.dns_resolver(5) program to set parameters. Unless otherwise overridden with the -c flag, the program reads:

/etc/key.dns_resolver.conf

Configuration options are given in key[=value] form, where value is optional. If present, the value may be surrounded by a pair of single (’’) or double quotes ("") which will be stripped off. The special characters in the value may be escaped with a backslash to turn them into ordinary characters.

Lines beginning with a ‘#’ are considered comments and ignored. A ‘#’ symbol anywhere after the ‘=’ makes the rest of the line into a comment unless the ‘#’ is inside a quoted section or is escaped.

Leading and trailing spaces and spaces around the ‘=’ symbol will be stripped off.

Available options include:

default_ttl=<number>
The number of seconds to set as the expiration on a cached record. This will be overridden if the program manages to retrieve TTL information along with the addresses (if, for example, it accesses the DNS directly). The default is 5 seconds. The value must be in the range 1 to INT_MAX.

The file can also include comments beginning with a ‘#’ character unless otherwise suppressed by being inside a quoted value or being escaped with a backslash.

FILES

/etc/key.dns_resolver.conf

213 - Linux cli command avahi.service

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command avahi.service and provides detailed information about the command avahi.service, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the avahi.service.

NAME 🖥️ avahi.service 🖥️

avahi-daemon static service file

SYNOPSIS

/etc/avahi/services/*.service

DESCRIPTION

/etc/avahi/services/*.service are XML fragments containing static DNS-SD service data. Every service file can contain multiple service definitions which share the same name. This is useful for publishing service data for services which implement multiple protocols. (i.e. a printer implementing _ipp._tcp and _printer._tcp)

XML TAGS

<service-group> The document tag of avahi service files. Should contain one <name> and one or more <service> elements.
<name replace-wildcards=“yes|no”> The service name. If replace-wildcards is “yes”, any occurence of the string “%h” will be replaced by the local host name. This can be used for service names like “Remote Terminal on %h”. If replace-wildcards is not specified, defaults to “no”.
<service protocol=“ipv4|ipv6|any”> Contains the service information for exactly one service type. Should contain one <type> and one <port> element. Optionally it may contain one <domain-name>, one <host-name>, any number of <subtype> and any number of <txt-record> elements. The attribute protocol specifies the protocol to advertise the service on. If any is used (which is the default), the service will be advertised on both IPv4 and IPv6.
<type> Contains the DNS-SD service type for this service. e.g. “_http._tcp”.
<subtype> Contains an additional DNS-SD service subtype for this service. e.g. “_anon._sub._ftp._tcp”.
<domain-name> The domain name this service should be registered. If omited defaults to the default domain of the avahi daemon. (probably .local)
<host-name> The host name of the host that provides this service. This should be a host that is resolvable by multicast or unicast DNS. Please note that you need to specify a fully-qualified domain name (FQDN) here, i.e. .local is not appended implicitly! The host name doesn’t need to be part of the domain specified in <domain-name>. See avahi.hosts(5) for more information how to publish additional host name mappings.
<port> The IP port number the service listens on.
<txt-record value-format=“text|binary-hex|binary-base64”> DNS-SD TXT record data. If value-format is “text”, the value of the TXT record is taken verbatim. If value-format is “binary-hex” then the value of TXT record is decoded by taking pairs of characters after the “=” char and interpreting them as the textual representation of the two-digit hexadecimal number. Both uppercase and lowercase hexadecimal digits are allowed. The 0x or 0X prefix is not allowed. This requires the length of the value to be even. If value-format is “binary-base64” then the value of TXT record is decoded with a base64 decoder. The character set used is A-Za-z0-9+/. This requires the length of the value to be a multiple of 4, with “=” as padding at the end. If value-format is not specified, defaults to “text”. Examples (all the values are decoded to the string “value” without quotes):
<txt-record>key=value<txt-record>

<txt-record value-format=“text”>key=value<txt-record>

<txt-record value-format=“binary-hex”>key=76616c7565<txt-record>

<txt-record value-format=“binary-base64”>key=dmFsdWU=<txt-record>

AUTHORS

The Avahi Developers <avahi (at) lists (dot) freedesktop (dot) org>; Avahi is available from http://avahi.org/

COMMENTS

This man page was written using xml2man(1) by Oliver Kurth.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

214 - Linux cli command proc_sys_abi

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_sys_abi and provides detailed information about the command proc_sys_abi, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_sys_abi.

NAME 🖥️ proc_sys_abi 🖥️

application binary information

DESCRIPTION

/proc/sys/abi/ (since Linux 2.4.10)
This directory may contain files with application binary information. See the Linux kernel source file Documentation/sysctl/abi.rst (or Documentation/sysctl/abi.txt before Linux 5.3) for more information.

215 - Linux cli command user_caps

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command user_caps and provides detailed information about the command user_caps, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the user_caps.

NAME 🖥️ user_caps 🖥️

user-defined terminfo capability format

SYNOPSIS

infocmp -x

tic -x

DESCRIPTION

Background

Before ncurses 5.0, terminfo databases used a fixed repertoire of terminal capabilities designed for the SVr2 terminal database in 1984, and extended in stages through SVr4 (1989), and standardized in the Single Unix Specification beginning in 1995.

Most of the extensions in this fixed repertoire were additions to the tables of Boolean, numeric and string capabilities. Rather than change the meaning of an existing capability, a new name was added. The terminfo database uses a binary format; binary compatibility was ensured by using a header which gave the number of items in the tables for each type of capability. The standardization was incomplete:

The binary format itself is not described in the X/Open Curses documentation. Only the source format is described.
Library developers rely upon the SVr4 documentation, and reverse-engineering the compiled terminfo files to match the binary format.
Lacking a standard for the binary format, most implementations copy the SVr2 binary format, which uses 16-bit signed integers, and is limited to 4096-byte entries.
The format cannot represent very large numeric capabilities, nor can it represent large numbers of special keyboard definitions.
The tables of capability names differ between implementations.
Although they may provide all of the standard capability names, the position in the tables differs because some features were added as needed, while others were added (out of order) to comply with X/Open Curses.
While ncurses’ repertoire of predefined capabilities is closest to Solaris, Solaris’s terminfo database has a few differences from the list published by X/Open Curses. For example, ncurses can be configured with tables which match the terminal databases for AIX, HP-UX or OSF/1, rather than the default Solaris-like configuration.
In SVr4 curses and ncurses, the terminal database is defined at compile-time using a text file which lists the different terminal capabilities.
In principle, the text-file can be extended, but doing this requires recompiling and reinstalling the library. The text-file used in ncurses for terminal capabilities includes details for various systems past the documented X/Open Curses features. For example, ncurses supports these capabilities in each configuration:
memory_lock
(meml) lock memory above cursor
memory_unlock
(memu) unlock memory
box_chars_1
(box1) box characters primary set
The memory lock/unlock capabilities were included because they were used in the X11R6 terminal description for xterm(1). The box1 capability is used in tic to help with terminal descriptions written for AIX.

During the 1990s, some users were reluctant to use terminfo in spite of its performance advantages over termcap:

The fixed repertoire prevented users from adding features for unanticipated terminal improvements (or required them to reuse existing capabilities as a workaround).
The limitation to 16-bit signed integers was also mentioned. Because termcap stores everything as a string, it could represent larger numbers.

Although termcap’s extensibility was rarely used (it was never the speaker who had actually used the feature), the criticism had a point. ncurses 5.0 provided a way to detect nonstandard capabilities, determine their type and optionally store and retrieve them in a way which did not interfere with other applications. These are referred to as user-defined capabilities because no modifications to the toolset’s predefined capability names are needed.

The ncurses utilities tic and infocmp have a command-line option -x to control whether the nonstandard capabilities are stored or retrieved. A library function use_extended_names is provided for the same purpose.

When compiling a terminal database, if -x is set, tic will store a user-defined capability if the capability name is not one of the predefined names.

Because ncurses provides a termcap library interface, these user-defined capabilities may be visible to termcap applications:

The termcap interface (like all implementations of termcap) requires that the capability names are 2-characters.
When the capability is simple enough for use in a termcap application, it is provided as a 2-character name.
There are other user-defined capabilities which refer to features not usable in termcap, e.g., parameterized strings that use more than two parameters or use more than the trivial expression support provided by termcap. For these, the terminfo database should have only capability names with 3 or more characters.
Some terminals can send distinct strings for special keys (cursor-, keypad- or function-keys) depending on modifier keys (shift, control, etc.). While terminfo and termcap have a set of 60 predefined function-key names, to which a series of keys can be assigned, that is insufficient for more than a dozen keys multiplied by more than a couple of modifier combinations. The ncurses database uses a convention based on xterm(1) to provide extended special-key names.
Fitting that into termcap’s limitation of 2-character names would be pointless. These extended keys are available only with terminfo.

Recognized Capabilities

The ncurses library uses the user-definable capabilities. While the terminfo database may have other extensions, ncurses makes explicit checks for these:

AX
Boolean, asserts that the terminal interprets SGR 39 and SGR 49 by resetting the foreground and background color, respectively, to the default.
This is a feature recognized by the screen program as well.
E3
string, tells how to clear the terminal’s scrollback buffer. When present, the clear(1) program sends this before clearing the terminal.
The command tput clear does the same thing.
NQ
Boolean, used to suppress a consistency check in tic for the ncurses capabilities in user6 through user9 (u6, u7, u8 and u9) which tell how to query the terminal’s cursor position and its device attributes.
RGB
Boolean, number or string, used to assert that the set_a_foreground and set_a_background capabilities correspond to direct colors, using an RGB (red/green/blue) convention. This capability allows the color_content function to return appropriate values without requiring the application to initialize colors using init_color.
The capability type determines the values which ncurses sees:
Boolean
implies that the number of bits for red, green and blue are the same. Using the maximum number of colors, ncurses adds two, divides that sum by three, and assigns the result to red, green and blue in that order.
If the number of bits needed for the number of colors is not a multiple of three, the blue (and green) components lose in comparison to red.
number
tells ncurses what result to add to red, green and blue. If ncurses runs out of bits, blue (and green) lose just as in the Boolean case.
string
explicitly list the number of bits used for red, green and blue components as a slash-separated list of decimal integers.
Because there are several RGB encodings in use, applications which make assumptions about the number of bits per color are unlikely to work reliably. As a trivial case, for example, one could define RGB#1 to represent the standard eight ANSI colors, i.e., one bit per color.
U8
number, asserts that ncurses must use Unicode values for line-drawing characters, and that it should ignore the alternate character set capabilities when the locale uses UTF-8 encoding. For more information, see the discussion of NCURSES_NO_UTF8_ACS in ncurses(3NCURSES).
Set this capability to a nonzero value to enable it.
XM
string, override ncurses’s built-in string which enables/disables xterm(1) mouse mode.
ncurses sends a character sequence to the terminal to initialize mouse mode, and when the user clicks the mouse buttons or (in certain modes) moves the mouse, handles the characters sent back by the terminal to tell it what was done with the mouse.
The mouse protocol is enabled when the mask passed in the mousemask function is nonzero. By default, ncurses handles the responses for the X11 xterm mouse protocol. It also knows about the SGR 1006 xterm mouse protocol, but must to be told to look for this specifically. It will not be able to guess which mode is used, because the responses are enough alike that only confusion would result.
The XM capability has a single parameter. If nonzero, the mouse protocol should be enabled. If zero, the mouse protocol should be disabled. ncurses inspects this capability if it is present, to see whether the 1006 protocol is used. If so, it expects the responses to use the SGR 1006 xterm mouse protocol.
The xterm mouse protocol is used by other terminal emulators. The terminal database uses building-blocks for the various xterm mouse protocols which can be used in customized terminal descriptions.
The terminal database building blocks for this mouse feature also have an experimental capability xm. The xm capability describes the mouse response. Currently there is no interpreter which would use this information to make the mouse support completely data-driven.
xm shows the format of the mouse responses. In this experimental capability, the parameters are
p1
y-ordinate
p2
x-ordinate
p3
button
p4
state, e.g., pressed or released
p5
y-ordinate starting region
p6
x-ordinate starting region
p7
y-ordinate ending region
p8
x-ordinate ending region
Here are examples from the terminal database for the most commonly used xterm mouse protocols:
  xterm+x11mouse|X11 xterm mouse protocol,
          kmous=[M, XM=[?1000%?%p1%{1}%=%th%el%;,
          xm=[M
             %?%p4%t%p3%e%{3}%;%' '%+%c
             %p2%'!'%+%c
             %p1%'!'%+%c,

  xterm+sm+1006|xterm SGR-mouse,
          kmous=[<, XM=[?1006;1000%?%p1%{1}%=%th%el%;,
          xm=[<%i%p3%d;
             %p1%d;
             %p2%d;
             %?%p4%tM%em%;,

Extended Key Definitions

Several terminals provide the ability to send distinct strings for combinations of modified special keys. There is no standard for what those keys can send.

Since 1999, xterm(1) has supported shift, control, alt, and meta modifiers which produce distinct special-key strings. In a terminal description, ncurses has no special knowledge of the modifiers used. Applications can use the naming convention established for xterm to find these special keys in the terminal description.

Starting with the curses convention that capability codes describing the input generated by a terminal’s key caps begin with k, and that shifted special keys use uppercase letters in their names, ncurses’s terminal database defines the following names and codes to which a suffix is added.

Code Description
kDC shifted kdch1 (delete character)
kDN shifted kcud1 (cursor down)
kEND shifted kend (end)
kHOM shifted khome (home)
kLFT shifted kcub1 (cursor back)
kNXT shifted knext (next)
kPRV shifted kprev (previous)
kRIT shifted kcuf1 (cursor forward)
kUP shifted kcuu1 (cursor up)

Keycap nomenclature on the Unix systems for which curses was developed differs from today’s ubiquitous descendants of the IBM PC/AT keyboard layout. In the foregoing, interpret backward as left, forward as right, next as page down, and prev(ious) as page up.

These are the suffixes used to denote the modifiers:

Value Description
2 Shift
3 Alt
4 Shift + Alt
5 Control
6 Shift + Control
7 Alt + Control
8 Shift + Alt + Control
9 Meta
10 Meta + Shift
11 Meta + Alt
12 Meta + Alt + Shift
13 Meta + Ctrl
14 Meta + Ctrl + Shift
15 Meta + Ctrl + Alt
16 Meta + Ctrl + Alt + Shift

None of these are predefined; terminal descriptions can refer to names which ncurses will allocate at runtime to key-codes. To use these keys in an ncurses program, an application could do this:

using a list of extended key names, ask tigetstr(3NCURSES) for their values, and
given the list of values, ask key_defined(3NCURSES) for the key-code which would be returned for those keys by wgetch(3NCURSES).

PORTABILITY

The -x extension feature of tic and infocmp has been adopted in NetBSD curses. That implementation stores user-defined capabilities, but makes no use of these capabilities itself.

AUTHORS

Thomas E. Dickey
beginning with ncurses 5.0 (1999)

216 - Linux cli command org.bluez.obex.FileTransfer

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.obex.FileTransfer and provides detailed information about the command org.bluez.obex.FileTransfer, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.obex.FileTransfer.

NAME 🖥️ org.bluez.obex.FileTransfer 🖥️

BlueZ D-Bus OBEX FileTransfer API documentation

INTERFACE

Service
org.bluez.obex
Interface
org.bluez.obex.FileTransfer1
Object path
[Session object path]

Methods

void ChangeFolder(string folder)

Changes the current folder of the remote device.
Possible errors:
org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Error.Failed

void CreateFolder(string folder)

Creates a new folder in the remote device.
Possible errors:
org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Error.Failed

array{dict} ListFolder()

Returns a dictionary containing information about the current folder content.
Possible return values:
string Name
Object name in UTF-8 format.
string Type
Either “folder” or “file”.
uint64 Size
Object size or number of items in folder.
string Permission
Group, owner and other permission.
uint64 Modified
Last change.
uint64 Accessed
Last access.
uint64 Created
Creation date.
Possible errors:
org.bluez.obex.Error.Failed

object, dict GetFile(string targetfile, string sourcefile)

Copies the contents of the source file (from remote device) to the target file (on local filesystem).
If an empty target file is given, a name will be automatically generated for the temporary file.
The returned path represents the newly created transfer, which should be used to find out if the content has been successfully transferred or if the operation fails.
The properties of this transfer are also returned along with the object path, to avoid a call to GetProperties, see org.bluez.obex.Transfer(5) for the possible list of properties.
Possible errors:
org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Error.Failed

object, dict PutFile(string sourcefile, string targetfile)

Copies the contents of the source file (from local filesystem) to the target file (on remote device).
The returned path represents the newly created transfer, which should be used to find out if the content has been successfully transferred or if the operation fails.
The properties of this transfer are also returned along with the object path, to avoid a call to GetProperties, see org.bluez.obex.Transfer(5) for the possible list of properties.
Possible errors:
org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Error.Failed

void CopyFile(string sourcefile, string targetfile)

Copies the contents from source file to target file on the remote device.
Possible errors:
org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Error.Failed

void MoveFile(string sourcefile, string targetfile)

Moves a file within the remote device from source file to the target file.
Possible errors:
;org.bluez.obex.Error.InvalidArguments: :org.bluez.obex.Error.Failed:

void Delete(string file)

Deletes the specified file/folder.
Possible errors:
org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Error.Failed

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

217 - Linux cli command pbm

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command pbm and provides detailed information about the command pbm, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the pbm.

NAME 🖥️ pbm 🖥️

Netpbm bi-level image format

DESCRIPTION

This program is part of Netpbm(1) .

The PBM format is a lowest common denominator monochrome file format. It serves as the common language of a large family of bitmap image conversion filters. Because the format pays no heed to efficiency, it is simple and general enough that one can easily develop programs to convert to and from just about any other graphics format, or to manipulate the image.

The name “PBM” is an acronym derived from “Portable Bit Map.”

This is not a format that one would normally use to store a file or to transmit it to someone – it’s too expensive and not expressive enough for that. It’s just an intermediary format. In it’s purest use, it lives only in a pipe between two other programs.

THE LAYOUT

The format definition is as follows.

A PBM file consists of a sequence of one or more PBM images. There are no data, delimiters, or padding before, after, or between images.

Each PBM image consists of the following:

A “magic number” for identifying the file type. A pbm image’s magic number is the two characters “P4”.
Whitespace (blanks, TABs, CRs, LFs).
The width in pixels of the image, formatted as ASCII characters in decimal.
Whitespace.
The height in pixels of the image, again in ASCII decimal.
A single whitespace character (usually a newline).
A raster of Height rows, in order from top to bottom. Each row is Width bits, packed 8 to a byte, with don’t care bits to fill out the last byte in the row. Each bit represents a pixel: 1 is black, 0 is white. The order of the pixels is left to right. The order of their storage within each file byte is most significant bit to least significant bit. The order of the file bytes is from the beginning of the file toward the end of the file.

A row of an image is horizontal. A column is vertical. The pixels in the image are square and contiguous.

Before the whitespace character that delimits the raster, any characters from a “#” to but not including the next carriage return or newline character, or end of file, is a comment and is ignored.

(Before June 2024, the carriage return or line feed was specified to be part of the comment and ignored, but in the 22 years that comments had existed in the specification, Netpbm never implemented that).

Plain PBM

There is actually another version of the PBM format, even more simplistic, more lavishly wasteful of space than PBM, called Plain PBM. Plain PBM actually came first, but even its inventor couldn’t stand its recklessly squanderous use of resources after a while and switched to what we now know as the regular PBM format. But Plain PBM is so redundant – so overstated – that it’s virtually impossible to break. You can send it through the most liberal mail system (which was the original purpose of the PBM format) and it will arrive still readable. You can flip a dozen random bits and easily piece back together the original image. And we hardly need to define the format here, because you can decode it by inspection.

Netpbm programs generate Raw PBM format instead of Plain PBM by default, but the common option -plain chooses Plain PBM.

The difference is:

There is exactly one image in a file.
The “magic number” is “P1” instead of “P4”.
Each pixel in the raster is represented by a byte containing ASCII ‘1’ or ‘0’, representing black and white respectively. There are no fill bits at the end of a row.
White space in the raster section is ignored.
You can put any junk you want after the raster, if it starts with a white space character.
No line should be longer than 70 characters.

Here is an example of a small image in the plain PBM format.

P1
# feep.pbm
24 7
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 1 1 1 1 0 0 1 1 1 1 0 0 1 1 1 1 0 0 1 1 1 1 0
0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 1 0
0 1 1 1 0 0 0 1 1 1 0 0 0 1 1 1 0 0 0 1 1 1 1 0
0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0
0 1 0 0 0 0 0 1 1 1 1 0 0 1 1 1 1 0 0 1 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

There is a newline character at the end of each of these lines.

You can generate the Plain PBM format from the regular PBM format (first image in the file only) with the pnmtoplainpnm program.

Programs that read this format should be as lenient as possible, accepting anything that looks remotely like a bitmap.

INTERNET MEDIA TYPE

No Internet Media Type (aka MIME type, content type) for PBM has been registered with IANA, but the value image/x-portable-bitmap is conventional.

Note that the PNM Internet Media Type image/x-portable-anymap also applies.

FILE NAME

There are no requirements on the name of a PBM file, but the convention is to use the suffix “.pbm”. “pnm” is also conventional, for cases where distinguishing between the particular subformats of PNM is not convenient.

COMPATIBILITY

Before July 2000, there could be at most one image in a PBM file. As a result, most tools to process PBM files ignore (and don’t read) any data after the first image.

DOCUMENT SOURCE

This manual page was generated by the Netpbm tool ‘makeman’ from HTML source. The master documentation is at

http://netpbm.sourceforge.net/doc/pbm.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

218 - Linux cli command gshadow

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gshadow and provides detailed information about the command gshadow, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gshadow.

NAME 🖥️ gshadow 🖥️

shadowed group file

DESCRIPTION

/etc/gshadow contains the shadowed information for group accounts.

This file must not be readable by regular users if password security is to be maintained.

Each line of this file contains the following colon-separated fields:

group name

It must be a valid group name, which exist on the system.

encrypted password

Refer to crypt(3) for details on how this string is interpreted.
If the password field contains some string that is not a valid result of crypt(3), for instance ! or *, users will not be able to use a unix password to access the group (but group members do not need the password).
The password is used when a user who is not a member of the group wants to gain the permissions of this group (see newgrp(1)).
This field may be empty, in which case only the group members can gain the group permissions.
A password field which starts with an exclamation mark means that the password is locked. The remaining characters on the line represent the password field before the password was locked.
This password supersedes any password specified in /etc/group.

administrators

It must be a comma-separated list of user names.
Administrators can change the password or the members of the group.
Administrators also have the same permissions as the members (see below).

members

It must be a comma-separated list of user names.
Members can access the group without being prompted for a password.
You should use the same list of users as in /etc/group.

FILES

/etc/group

Group account information.

/etc/gshadow

Secure group account information.

219 - Linux cli command nfsrahead

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command nfsrahead and provides detailed information about the command nfsrahead, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the nfsrahead.

NAME 🖥️ nfsrahead 🖥️

Configure the readahead for NFS mounts

SYNOPSIS

nfsrahead [-F] [-d] <device>

DESCRIPTION

nfsrahead is a tool intended to be used with udev to set the read_ahead_kb parameter of NFS mounts, according to the configuration file (see CONFIGURATION). device is the device number for the NFS backing device as provided by the kernel.

OPTIONS

-F
Send messages to stderr instead of syslog

-d
Increase the debugging level.

CONFIGURATION

nfsrahead is configured in /etc/nfs.conf, in the section titled nfsrahead. It accepts the following configurations.

nfs=<value>
The readahead value applied to NFSv3 mounts.

nfs4=<value>
The readahead value applied to NFSv4 mounts.

default=<value>
The default configuration when none of the configurations above is set.

EXAMPLE CONFIGURATION

[nfsrahead]
nfs=15000 # readahead of 15000 for NFSv3 mounts
nfs4=16000 # readahead of 16000 for NFSv4 mounts
default=128 # default is 128

BUGS

No known bugs.

AUTHOR

Thiago Rafael Becker <[email protected]>

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

220 - Linux cli command org.bluez.LEAdvertisingManager

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.LEAdvertisingManager and provides detailed information about the command org.bluez.LEAdvertisingManager, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.LEAdvertisingManager.

NAME 🖥️ org.bluez.LEAdvertisingManager 🖥️

BlueZ D-Bus LEAvertisingManager API documentation

INTERFACE

The Advertising Manager allows external applications to register Advertisement Data which should be broadcast to devices. Advertisement Data elements must follow the API for LE Advertisement Data described above.

Service
org.bluez
Interface
org.bluez.LEAdvertisingManager1
Object path
/org/bluez/{hci0,hci1,…}

Methods

void RegisterAdvertisement(object advertisement, dict options)

Registers an advertisement object to be sent over the LE Advertising channel. The service must implement org.bluez.LEAdvertisement(5) interface.
Possible errors:
org.bluez.Error.InvalidArguments
Indicates that the object has invalid or conflicting properties.
org.bluez.Error.AlreadyExists
Indicates the object is already registered.
org.bluez.Error.InvalidLength
Indicates that the data provided generates a data packet which is too long
org.bluez.Error.NotPermitted
Indicates the maximum number of advertisement instances has been reached.

void UnregisterAdvertisement(object advertisement)

Unregisters an advertisement that has been previously registered using RegisterAdvertisement(). The object path parameter must match the same value that has been used on registration.
Possible errors:
org.bluez.Error.InvalidArguments
org.bluez.Error.DoesNotExist

Properties

byte ActiveInstances [readonly]

Number of active advertising instances.

byte SupportedInstances [readonly]

Number of available advertising instances.

array{string} SupportedIncludes [readonly]

List of supported system includes.
Possible values:
“tx-power”
“appearance”
“local-name”
“rsi”

array{string} SupportedSecondaryChannels [readonly, Experimental]

List of supported Secondary channels. Secondary channels can be used to advertise with the corresponding PHY.
Possible values:
“1M”
“2M”
“Coded”

dict SupportedCapabilities [readonly, Experimental]

Enumerates Advertising-related controller capabilities useful to the client.
Possible Values:
byte MaxAdvLen
Max advertising data length
byte MaxScnRspLen
Max advertising scan response length
;int16 MinTxPower:
Min advertising tx power (dBm)
int16 MaxTxPower
Max advertising tx power (dBm)

array{string} SupportedFeatures [readonly,optional,Experimental]

List of supported platform features. If no features are available on the platform, the SupportedFeatures array will be empty.
Possible values:
“CanSetTxPower”
Indicates whether platform can specify tx power on each advertising instance.
“HardwareOffload”
Indicates whether multiple advertising will be offloaded to the controller.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

221 - Linux cli command proc_mounts

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_mounts and provides detailed information about the command proc_mounts, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_mounts.

NAME 🖥️ proc_mounts 🖥️

mounted filesystems

DESCRIPTION

/proc/pid/mounts (since Linux 2.4.19)
This file lists all the filesystems currently mounted in the process’s mount namespace (see mount_namespaces(7)). The format of this file is documented in fstab(5).

Since Linux 2.6.15, this file is pollable: after opening the file for reading, a change in this file (i.e., a filesystem mount or unmount) causes select(2) to mark the file descriptor as having an exceptional condition, and poll(2) and epoll_wait(2) mark the file as having a priority event (POLLPRI). (Before Linux 2.6.30, a change in this file was indicated by the file descriptor being marked as readable for select(2), and being marked as having an error condition for poll(2) and epoll_wait(2).)

/proc/mounts
Before Linux 2.4.19, this file was a list of all the filesystems currently mounted on the system. With the introduction of per-process mount namespaces in Linux 2.4.19 (see mount_namespaces(7)), this file became a link to /proc/self/mounts, which lists the mounts of the process’s own mount namespace. The format of this file is documented in fstab(5).

222 - Linux cli command reader.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command reader.conf and provides detailed information about the command reader.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the reader.conf.

NAME 🖥️ reader.conf 🖥️

configuration file for pcscd readers’ drivers

DESCRIPTION

The /etc/reader.conf.d/* files contain configuration information for serial and (some) PCMCIA smart card readers.

USB readers SHALL NOT be configured using these files. pcscd uses another mechanism to automatically load USB drivers.

SYNTAX

The /etc/reader.conf.d/* files are regular text file. Each reader must be defined by four fields:

FRIENDLYNAME TEXT_STRING DEVICENAME FILENAME LIBPATH FILENAME CHANNELID NUMBER

The “FRIENDLYNAME” field is an arbitrary text used to identify the reader. This text is displayed by commands like pcsc_scan(1) that prints the names of all the connected and detected readers.

The “DEVICENAME” field was not used for old drivers (using the IFD handler version 2.0 or earlier). It is now (IFD handler version 3.0) used to identify the physical port on which the reader is connected. This is the device name of this port. It is dependent of the OS kernel. The first serial port device is called /dev/ttyS0 under Linux and /dev/cuaa0 under FreeBSD.

The “LIBPATH” field is the filename of the driver code. The driver is a dynamically loaded piece of code (generally a drivername.so.* file).

The “CHANNELID” is no more used for recent drivers (IFD handler 3.0) and has been superseded by “DEVICENAME”. If you have an old driver this field is used to indicate the port to use. You should read your driver documentation to know what information is needed here. It should be the serial port number for a serial reader.

EXAMPLE

# Gemplus GemPCTwin reader with serial communication # connected to the first serial port FRIENDLYNAME “GemPCTwin serial” DEVICENAME /dev/ttyS0 LIBPATH /usr/lib/pcsc/drivers/serial/libccidtwin.so.0.4.1 CHANNELID 1

DEBUGGING

In order to set up your /etc/reader.conf.d/my_reader.conf file correctly you may want to have debug messages from pcscd. I recommend you to start pscsd in the foreground and debug mode using: # pcscd –foreground –debug

If everything seems OK you can use the pcsc_scan command to print the list of correctly detected readers and try to get the ATR of your smart cards.

AUTHOR

Ludovic Rousseau <[email protected]>

223 - Linux cli command semanage.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command semanage.conf and provides detailed information about the command semanage.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the semanage.conf.

NAME 🖥️ semanage.conf 🖥️

global configuration file for the SELinux Management library

DESCRIPTION

The semanage.conf file is usually located under the directory /etc/selinux and it is used for run-time configuration of the behavior of the SELinux Management library.

Each line should contain a configuration parameter followed by the equal sign ("=") and then followed by the configuration value for that parameter. Anything after the “#” symbol is ignored similarly to empty lines.

The following parameters are allowed:

module-store
Specify how the SELinux Management library should interact with the SELinux policy store. When set to “direct”, the SELinux Management library writes to the SELinux policy module store directly (this is the default setting). Otherwise a socket path or a server name can be used for the argument. If the argument begins with “/” (as in “/foo/bar”), it represents the path to a named socket that should be used to connect the policy management server. If the argument does not begin with a “/” (as in “example.com:4242”), it should be interpreted as the name of a remote policy management server to be used through a TCP connection (default port is 4242 unless a different one is specified after the server name using the colon to separate the two fields).
root
Specify an alternative root path to use for the store. The default is “/”
store-root
Specify an alternative store_root path to use. The default is “/var/lib/selinux”
compiler-directory
Specify an alternative directory that contains HLL to CIL compilers. The default value is “/usr/libexec/selinux/hll”.
ignore-module-cache
Whether or not to ignore the cache of CIL modules compiled from HLL. It can be set to either “true” or “false” and is set to “false” by default. If the cache is ignored, then all CIL modules are recompiled from their HLL modules.
policy-version
When generating the policy, by default semanage will set the policy version to POLICYDB_VERSION_MAX, as defined in <sepol/policydb/policydb.h>. Change this setting if a different version needs to be set for the policy.
target-platform
The target platform to generate policies for. Valid values are “selinux” and “xen”, and is set to “selinux” by default.
expand-check
Whether or not to check “neverallow” rules when executing all semanage command. It can be set to either “0” (disabled) or “1” (enabled) and by default it is enabled. There might be a large penalty in execution time if this option is enabled.
file-mode
By default the permission mode for the run-time policy files is set to 0644.
save-previous
It controls whether the previous module directory is saved after a successful commit to the policy store and it can be set to either “true” or “false”. By default it is set to “false” (the previous version is deleted).
save-linked
It controls whether the previously linked module is saved (with name “base.linked”) after a successful commit to the policy store. It can be set to either “true” or “false” and by default it is set to “false” (the previous module is deleted).
ignoredirs
List, separated by “;”, of directories to ignore when setting up users homedirs. Some distributions use this to stop labeling /root as a homedir.
usepasswd
Whether or not to enable the use getpwent() to obtain a list of home directories to label. It can be set to either “true” or “false”. By default it is set to “true”.
disable-genhomedircon
It controls whether or not the genhomedircon function is executed when using the semanage command and it can be set to either “false” or “true”. By default the genhomedircon functionality is enabled (equivalent to this option set to “false”).
handle-unknown
This option overrides the kernel behavior for handling permissions defined in the kernel but missing from the actual policy. It can be set to “deny”, “reject” or “allow”. By default the setting from the policy is taken.
bzip-blocksize
It should be in the range 0-9. A value of 0 means no compression. By default the bzip block size is set to 9 (actual block size value is obtained after multiplication by 100000).
bzip-small
When set to “true”, the bzip algorithm shall try to reduce its system memory usage. It can be set to either “true” or “false” and by default it is set to “false”.
remove-hll
When set to “true”, HLL files will be removed after compilation into CIL. In order to delete HLL files already compiled into CIL, modules will need to be recompiled with the ignore-module-cache option set to ’true’ or using the ignore-module-cache option with semodule. The remove-hll option can be set to either “true” or “false” and by default it is set to “false”.
Please note that since this option deletes all HLL files, an updated HLL compiler will not be able to recompile the original HLL file into CIL. In order to compile the original HLL file into CIL, the same HLL file will need to be reinstalled.
optimize-policy
When set to “true”, the kernel policy will be optimized upon rebuilds. It can be set to either “true” or “false” and by default it is set to “false”.

AUTHOR

This manual page was written by Guido Trentalancia <[email protected]>.

The SELinux management library was written by Tresys Technology LLC and Red Hat Inc.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

224 - Linux cli command sudoers_timestamp

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command sudoers_timestamp and provides detailed information about the command sudoers_timestamp, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the sudoers_timestamp.

The

plugin uses per-user-ID time stamp files for credential caching. Once a user has been authenticated, they may use

without a password for a short period of time

minutes unless overridden by the

option

By default,

uses a separate record for each terminal, which means that a user’s login sessions are authenticated separately. The

option can be used to select the type of time stamp record

will use.

A multi-record time stamp file format was introduced in

1.8.10 that uses a single file per user. Previously, a separate file was used for each user and terminal combination unless tty-based time stamps were disabled. The new format is extensible and records of multiple types and versions may coexist within the same file.

All records, regardless of type or version, begin with a 16-bit version number and a 16-bit record size.

Time stamp records have the following structure:

/* Time stamp entry types */ #define TS_GLOBAL 0x01 /* not restricted by tty or ppid */ #define TS_TTY 0x02 /* restricted by tty */ #define TS_PPID 0x03 /* restricted by ppid */ #define TS_LOCKEXCL 0x04 /* special lock record */

/* Time stamp flags */ #define TS_DISABLED 0x01 /* entry disabled */ #define TS_ANYUID 0x02 /* ignore uid, only valid in key */

struct timestamp_entry { unsigned short version; /* version number */ unsigned short size; /* entry size */ unsigned short type; /* TS_GLOBAL, TS_TTY, TS_PPID */ unsigned short flags; /* TS_DISABLED, TS_ANYUID */ uid_t auth_uid; /* uid to authenticate as */ pid_t sid; /* session ID associated with tty/ppid */ struct timespec start_time; /* session/ppid start time */ struct timespec ts; /* time stamp (CLOCK_MONOTONIC) */ union { dev_t ttydev; /* tty device number */ pid_t ppid; /* parent pid */ } u; };

The timestamp_entry struct fields are as follows:

The version number of the timestamp_entry struct. New entries are created with a version number of 2. Records with different version numbers may coexist in the same file but are not inter-operable.

The size of the record in bytes.

The record type, currently

Zero or more record flags which can be bit-wise ORed together. Supported flags are

for records disabled via

and

which is used only when matching records.

The user-ID that was used for authentication. Depending on the value of the

and

options, the user-ID may be that of the invoking user, the root user, the default runas user or the target user.

The ID of the user’s terminal session, if present. The session ID is only used when matching records of type

The start time of the session leader for records of type

or of the parent process for records of type

The

is used to help prevent re-use of a time stamp record after a user has logged out. Not all systems support a method to easily retrieve a process’s start time. The

field was added in

version 1.8.22 for the second revision of the timestamp_entry struct.

The actual time stamp. A monotonic time source (which does not move backward) is used if the system supports it. Where possible,

uses a monotonic timer that increments even while the system is suspended. The value of

is updated each time a command is run via

If the difference between

and the current time is less than the value of the

option, no password is required.

The device number of the terminal associated with the session for records of type

The ID of the parent process for records of type

versions 1.8.10 through 1.8.14, the entire time stamp file was locked for exclusive access when reading or writing to the file. Starting in

1.8.15, individual records are locked in the time stamp file instead of the entire file and the lock is held for a longer period of time. This scheme is described below.

The first record in the time stamp file is of type

and is used as a

record to prevent more than one

process from adding a new record at the same time. Once the desired time stamp record has been located or created (and locked), the

record is unlocked. The lock on the individual time stamp record, however, is held until authentication is complete. This allows

to avoid prompting for a password multiple times when it is used more than once in a pipeline.

Records of type

cannot be locked for a long period of time since doing so would interfere with other

processes. Instead, a separate lock record is used to prevent multiple

processes using the same terminal (or parent process ID) from prompting for a password as the same time.

Originally,

used a single zero-length file per user and the file’s modification time was used as the time stamp. Later versions of

added restrictions on the ownership of the time stamp files and directory as well as checks on the validity of the time stamp itself. Notable changes were introduced in the following

versions:

Support for tty-based time stamp file was added by appending the terminal name to the time stamp file name.

The time stamp file was replaced by a per-user directory which contained any tty-based time stamp files.

The target user name was added to the time stamp file name when the

option was set.

Information about the terminal device was stored in tty-based time stamp files for validity checks. This included the terminal device numbers, inode number and, on systems where it was not updated when the device was written to, the inode change time. This helped prevent re-use of the time stamp file after logout.

The terminal session ID was added to tty-based time stamp files to prevent re-use of the time stamp by the same user in a different terminal session. It also helped prevent re-use of the time stamp file on systems where the terminal device’s inode change time was updated by writing.

A new, multi-record time stamp file format was introduced that uses a single file per user. The terminal device’s change time was not included since most systems now update the change time after a write is performed as required by POSIX.

Individual records are locked in the time stamp file instead of the entire file and the lock is held until authentication is complete.

The start time of the terminal session leader or parent process is now stored in non-global time stamp records. This prevents re-use of the time stamp file after logout in most cases.

Support was added for the kernel-based tty time stamps available in

which do not use an on-disk time stamp file.

Time stamp file path names are now based on the invoking user-ID instead of the user name. This avoids problems with user names that include a path separator character.

Many people have worked on

over the years; this version consists of code written primarily by:

See the CONTRIBUTORS.md file in the

distribution (https://www.sudo.ws/about/contributors/) for an exhaustive list of people who have contributed to

If you believe you have found a bug in

you can submit a bug report at https://bugzilla.sudo.ws/

Limited free support is available via the sudo-users mailing list, see https://www.sudo.ws/mailman/listinfo/sudo-users to subscribe or search the archives.

is provided

or https://www.sudo.ws/about/license/ for complete details.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

225 - Linux cli command proc_fb

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_fb and provides detailed information about the command proc_fb, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_fb.

NAME 🖥️ proc_fb 🖥️

frame buffer

DESCRIPTION

/proc/fb
Frame buffer information when CONFIG_FB is defined during kernel compilation.

226 - Linux cli command proc_pid_seccomp

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_seccomp and provides detailed information about the command proc_pid_seccomp, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_seccomp.

NAME 🖥️ proc_pid_seccomp 🖥️

secure computing mode

DESCRIPTION

/proc/pid/seccomp (Linux 2.6.12 to Linux 2.6.22)
This file can be used to read and change the process’s secure computing (seccomp) mode setting. It contains the value 0 if the process is not in seccomp mode, and 1 if the process is in strict seccomp mode (see seccomp(2)). Writing 1 to this file places the process irreversibly in strict seccomp mode. (Further attempts to write to the file fail with the EPERM error.)

In Linux 2.6.23, this file went away, to be replaced by the prctl(2) PR_GET_SECCOMP and PR_SET_SECCOMP operations (and later by seccomp(2) and the Seccomp field in /proc/pid/status).

227 - Linux cli command proc_sys_kernel

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_sys_kernel and provides detailed information about the command proc_sys_kernel, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_sys_kernel.

NAME 🖥️ proc_sys_kernel 🖥️

control a range of kernel parameters

DESCRIPTION

/proc/sys/kernel/
This directory contains files controlling a range of kernel parameters, as described below.

/proc/sys/kernel/acct
This file contains three numbers: highwater, lowwater, and frequency. If BSD-style process accounting is enabled, these values control its behavior. If free space on filesystem where the log lives goes below lowwater percent, accounting suspends. If free space gets above highwater percent, accounting resumes. frequency determines how often the kernel checks the amount of free space (value is in seconds). Default values are 4, 2, and 30. That is, suspend accounting if 2% or less space is free; resume it if 4% or more space is free; consider information about amount of free space valid for 30 seconds.

/proc/sys/kernel/auto_msgmni (Linux 2.6.27 to Linux 3.18)
From Linux 2.6.27 to Linux 3.18, this file was used to control recomputing of the value in /proc/sys/kernel/msgmni upon the addition or removal of memory or upon IPC namespace creation/removal. Echoing “1” into this file enabled msgmni automatic recomputing (and triggered a recomputation of msgmni based on the current amount of available memory and number of IPC namespaces). Echoing “0” disabled automatic recomputing. (Automatic recomputing was also disabled if a value was explicitly assigned to /proc/sys/kernel/msgmni.) The default value in auto_msgmni was 1.

Since Linux 3.19, the content of this file has no effect (because msgmni defaults to near the maximum value possible), and reads from this file always return the value “0”.

/proc/sys/kernel/cap_last_cap (since Linux 3.2)
See capabilities(7).

/proc/sys/kernel/cap-bound (from Linux 2.2 to Linux 2.6.24)
This file holds the value of the kernel capability bounding set (expressed as a signed decimal number). This set is ANDed against the capabilities permitted to a process during execve(2). Starting with Linux 2.6.25, the system-wide capability bounding set disappeared, and was replaced by a per-thread bounding set; see capabilities(7).

/proc/sys/kernel/core_pattern
See core(5).

/proc/sys/kernel/core_pipe_limit
See core(5).

/proc/sys/kernel/core_uses_pid
See core(5).

/proc/sys/kernel/ctrl-alt-del
This file controls the handling of Ctrl-Alt-Del from the keyboard. When the value in this file is 0, Ctrl-Alt-Del is trapped and sent to the init(1) program to handle a graceful restart. When the value is greater than zero, Linux’s reaction to a Vulcan Nerve Pinch (tm) will be an immediate reboot, without even syncing its dirty buffers. Note: when a program (like dosemu) has the keyboard in “raw” mode, the Ctrl-Alt-Del is intercepted by the program before it ever reaches the kernel tty layer, and it’s up to the program to decide what to do with it.

/proc/sys/kernel/dmesg_restrict (since Linux 2.6.37)
The value in this file determines who can see kernel syslog contents. A value of 0 in this file imposes no restrictions. If the value is 1, only privileged users can read the kernel syslog. (See syslog(2) for more details.) Since Linux 3.4, only users with the CAP_SYS_ADMIN capability may change the value in this file.

/proc/sys/kernel/domainname and /proc/sys/kernel/hostname
can be used to set the NIS/YP domainname and the hostname of your box in exactly the same way as the commands domainname(1) and hostname(1), that is:

# echo 'darkstar' > /proc/sys/kernel/hostname
# echo 'mydomain' > /proc/sys/kernel/domainname

has the same effect as

# hostname 'darkstar'
# domainname 'mydomain'

Note, however, that the classic darkstar.frop.org has the hostname “darkstar” and DNS (Internet Domain Name Server) domainname “frop.org”, not to be confused with the NIS (Network Information Service) or YP (Yellow Pages) domainname. These two domain names are in general different. For a detailed discussion see the hostname(1) man page.

/proc/sys/kernel/hotplug
This file contains the pathname for the hotplug policy agent. The default value in this file is /sbin/hotplug.

/proc/sys/kernel/htab-reclaim (before Linux 2.4.9.2)
(PowerPC only) If this file is set to a nonzero value, the PowerPC htab (see kernel file Documentation/powerpc/ppc_htab.txt) is pruned each time the system hits the idle loop.

/proc/sys/kernel/keys/
This directory contains various files that define parameters and limits for the key-management facility. These files are described in keyrings(7).

/proc/sys/kernel/kptr_restrict (since Linux 2.6.38)
The value in this file determines whether kernel addresses are exposed via /proc files and other interfaces. A value of 0 in this file imposes no restrictions. If the value is 1, kernel pointers printed using the %pK format specifier will be replaced with zeros unless the user has the CAP_SYSLOG capability. If the value is 2, kernel pointers printed using the %pK format specifier will be replaced with zeros regardless of the user’s capabilities. The initial default value for this file was 1, but the default was changed to 0 in Linux 2.6.39. Since Linux 3.4, only users with the CAP_SYS_ADMIN capability can change the value in this file.

/proc/sys/kernel/l2cr
(PowerPC only) This file contains a flag that controls the L2 cache of G3 processor boards. If 0, the cache is disabled. Enabled if nonzero.

/proc/sys/kernel/modprobe
This file contains the pathname for the kernel module loader. The default value is /sbin/modprobe. The file is present only if the kernel is built with the CONFIG_MODULES (CONFIG_KMOD in Linux 2.6.26 and earlier) option enabled. It is described by the Linux kernel source file Documentation/kmod.txt (present only in Linux 2.4 and earlier).

/proc/sys/kernel/modules_disabled (since Linux 2.6.31)
A toggle value indicating if modules are allowed to be loaded in an otherwise modular kernel. This toggle defaults to off (0), but can be set true (1). Once true, modules can be neither loaded nor unloaded, and the toggle cannot be set back to false. The file is present only if the kernel is built with the CONFIG_MODULES option enabled.

/proc/sys/kernel/msgmax (since Linux 2.2)
This file defines a system-wide limit specifying the maximum number of bytes in a single message written on a System V message queue.

/proc/sys/kernel/msgmni (since Linux 2.4)
This file defines the system-wide limit on the number of message queue identifiers. See also /proc/sys/kernel/auto_msgmni.

/proc/sys/kernel/msgmnb (since Linux 2.2)
This file defines a system-wide parameter used to initialize the msg_qbytes setting for subsequently created message queues. The msg_qbytes setting specifies the maximum number of bytes that may be written to the message queue.

/proc/sys/kernel/ngroups_max (since Linux 2.6.4)
This is a read-only file that displays the upper limit on the number of a process’s group memberships.

/proc/sys/kernel/ns_last_pid (since Linux 3.3)
See pid_namespaces(7).

/proc/sys/kernel/ostype and /proc/sys/kernel/osrelease
These files give substrings of /proc/version.

/proc/sys/kernel/overflowgid and /proc/sys/kernel/overflowuid
These files duplicate the files /proc/sys/fs/overflowgid and /proc/sys/fs/overflowuid.

/proc/sys/kernel/panic
This file gives read/write access to the kernel variable panic_timeout. If this is zero, the kernel will loop on a panic; if nonzero, it indicates that the kernel should autoreboot after this number of seconds. When you use the software watchdog device driver, the recommended setting is 60.

/proc/sys/kernel/panic_on_oops (since Linux 2.5.68)
This file controls the kernel’s behavior when an oops or BUG is encountered. If this file contains 0, then the system tries to continue operation. If it contains 1, then the system delays a few seconds (to give klogd time to record the oops output) and then panics. If the /proc/sys/kernel/panic file is also nonzero, then the machine will be rebooted.

/proc/sys/kernel/pid_max (since Linux 2.5.34)
This file specifies the value at which PIDs wrap around (i.e., the value in this file is one greater than the maximum PID). PIDs greater than this value are not allocated; thus, the value in this file also acts as a system-wide limit on the total number of processes and threads. The default value for this file, 32768, results in the same range of PIDs as on earlier kernels. On 32-bit platforms, 32768 is the maximum value for pid_max. On 64-bit systems, pid_max can be set to any value up to 2^22 (PID_MAX_LIMIT, approximately 4 million).

/proc/sys/kernel/powersave-nap (PowerPC only)
This file contains a flag. If set, Linux-PPC will use the “nap” mode of powersaving, otherwise the “doze” mode will be used.

/proc/sys/kernel/printk
See syslog(2).

/proc/sys/kernel/pty (since Linux 2.6.4)
This directory contains two files relating to the number of UNIX 98 pseudoterminals (see pts(4)) on the system.

/proc/sys/kernel/pty/max
This file defines the maximum number of pseudoterminals.

/proc/sys/kernel/pty/nr
This read-only file indicates how many pseudoterminals are currently in use.

/proc/sys/kernel/random/
This directory contains various parameters controlling the operation of the file /dev/random. See random(4) for further information.

/proc/sys/kernel/random/uuid (since Linux 2.4)
Each read from this read-only file returns a randomly generated 128-bit UUID, as a string in the standard UUID format.

/proc/sys/kernel/randomize_va_space (since Linux 2.6.12)
Select the address space layout randomization (ASLR) policy for the system (on architectures that support ASLR). Three values are supported for this file:

0
Turn ASLR off. This is the default for architectures that don’t support ASLR, and when the kernel is booted with the norandmaps parameter.

1
Make the addresses of mmap(2) allocations, the stack, and the VDSO page randomized. Among other things, this means that shared libraries will be loaded at randomized addresses. The text segment of PIE-linked binaries will also be loaded at a randomized address. This value is the default if the kernel was configured with CONFIG_COMPAT_BRK.

2
(Since Linux 2.6.25) Also support heap randomization. This value is the default if the kernel was not configured with CONFIG_COMPAT_BRK.

/proc/sys/kernel/real-root-dev
This file is documented in the Linux kernel source file Documentation/admin-guide/initrd.rst (or Documentation/initrd.txt before Linux 4.10).

/proc/sys/kernel/reboot-cmd (Sparc only)
This file seems to be a way to give an argument to the SPARC ROM/Flash boot loader. Maybe to tell it what to do after rebooting?

/proc/sys/kernel/rtsig-max
(Up to and including Linux 2.6.7; see setrlimit(2)) This file can be used to tune the maximum number of POSIX real-time (queued) signals that can be outstanding in the system.

/proc/sys/kernel/rtsig-nr
(Up to and including Linux 2.6.7.) This file shows the number of POSIX real-time signals currently queued.

/proc/pid/sched_autogroup_enabled (since Linux 2.6.38)
See sched(7).

/proc/sys/kernel/sched_child_runs_first (since Linux 2.6.23)
If this file contains the value zero, then, after a fork(2), the parent is first scheduled on the CPU. If the file contains a nonzero value, then the child is scheduled first on the CPU. (Of course, on a multiprocessor system, the parent and the child might both immediately be scheduled on a CPU.)

/proc/sys/kernel/sched_rr_timeslice_ms (since Linux 3.9)
See sched_rr_get_interval(2).

/proc/sys/kernel/sched_rt_period_us (since Linux 2.6.25)
See sched(7).

/proc/sys/kernel/sched_rt_runtime_us (since Linux 2.6.25)
See sched(7).

/proc/sys/kernel/seccomp/ (since Linux 4.14)
This directory provides additional seccomp information and configuration. See seccomp(2) for further details.

/proc/sys/kernel/sem (since Linux 2.4)
This file contains 4 numbers defining limits for System V IPC semaphores. These fields are, in order:

SEMMSL
The maximum semaphores per semaphore set.

SEMMNS
A system-wide limit on the number of semaphores in all semaphore sets.

SEMOPM
The maximum number of operations that may be specified in a semop(2) call.

SEMMNI
A system-wide limit on the maximum number of semaphore identifiers.

/proc/sys/kernel/sg-big-buff
This file shows the size of the generic SCSI device (sg) buffer. You can’t tune it just yet, but you could change it at compile time by editing include/scsi/sg.h and changing the value of SG_BIG_BUFF. However, there shouldn’t be any reason to change this value.

/proc/sys/kernel/shm_rmid_forced (since Linux 3.1)
If this file is set to 1, all System V shared memory segments will be marked for destruction as soon as the number of attached processes falls to zero; in other words, it is no longer possible to create shared memory segments that exist independently of any attached process.

The effect is as though a shmctl(2) IPC_RMID is performed on all existing segments as well as all segments created in the future (until this file is reset to 0). Note that existing segments that are attached to no process will be immediately destroyed when this file is set to 1. Setting this option will also destroy segments that were created, but never attached, upon termination of the process that created the segment with shmget(2).

Setting this file to 1 provides a way of ensuring that all System V shared memory segments are counted against the resource usage and resource limits (see the description of RLIMIT_AS in getrlimit(2)) of at least one process.

Because setting this file to 1 produces behavior that is nonstandard and could also break existing applications, the default value in this file is 0. Set this file to 1 only if you have a good understanding of the semantics of the applications using System V shared memory on your system.

/proc/sys/kernel/shmall (since Linux 2.2)
This file contains the system-wide limit on the total number of pages of System V shared memory.

/proc/sys/kernel/shmmax (since Linux 2.2)
This file can be used to query and set the run-time limit on the maximum (System V IPC) shared memory segment size that can be created. Shared memory segments up to 1 GB are now supported in the kernel. This value defaults to SHMMAX.

/proc/sys/kernel/shmmni (since Linux 2.4)
This file specifies the system-wide maximum number of System V shared memory segments that can be created.

/proc/sys/kernel/sysctl_writes_strict (since Linux 3.16)
The value in this file determines how the file offset affects the behavior of updating entries in files under /proc/sys. The file has three possible values:

-1
This provides legacy handling, with no printk warnings. Each write(2) must fully contain the value to be written, and multiple writes on the same file descriptor will overwrite the entire value, regardless of the file position.

0
(default) This provides the same behavior as for -1, but printk warnings are written for processes that perform writes when the file offset is not 0.

1
Respect the file offset when writing strings into /proc/sys files. Multiple writes will append to the value buffer. Anything written beyond the maximum length of the value buffer will be ignored. Writes to numeric /proc/sys entries must always be at file offset 0 and the value must be fully contained in the buffer provided to write(2).

/proc/sys/kernel/sysrq
This file controls the functions allowed to be invoked by the SysRq key. By default, the file contains 1 meaning that every possible SysRq request is allowed (in older kernel versions, SysRq was disabled by default, and you were required to specifically enable it at run-time, but this is not the case any more). Possible values in this file are:

0
Disable sysrq completely

1
Enable all functions of sysrq

> 1
Bit mask of allowed sysrq functions, as follows:

2
Enable control of console logging level
4
Enable control of keyboard (SAK, unraw)
8
Enable debugging dumps of processes etc.
16
Enable sync command
32
Enable remount read-only
64
Enable signaling of processes (term, kill, oom-kill)
128
Allow reboot/poweroff
256
Allow nicing of all real-time tasks

This file is present only if the CONFIG_MAGIC_SYSRQ kernel configuration option is enabled. For further details see the Linux kernel source file Documentation/admin-guide/sysrq.rst (or Documentation/sysrq.txt before Linux 4.10).

/proc/sys/kernel/version
This file contains a string such as:

#5 Wed Feb 25 21:49:24 MET 1998

The “#5” means that this is the fifth kernel built from this source base and the date following it indicates the time the kernel was built.

/proc/sys/kernel/threads-max (since Linux 2.3.11)
This file specifies the system-wide limit on the number of threads (tasks) that can be created on the system.

Since Linux 4.1, the value that can be written to threads-max is bounded. The minimum value that can be written is 20. The maximum value that can be written is given by the constant FUTEX_TID_MASK (0x3fffffff). If a value outside of this range is written to threads-max, the error EINVAL occurs.

The value written is checked against the available RAM pages. If the thread structures would occupy too much (more than 1/8th) of the available RAM pages, threads-max is reduced accordingly.

/proc/sys/kernel/yama/ptrace_scope (since Linux 3.5)
See ptrace(2).

/proc/sys/kernel/zero-paged (PowerPC only)
This file contains a flag. When enabled (nonzero), Linux-PPC will pre-zero pages in the idle loop, possibly speeding up get_free_pages.

228 - Linux cli command adduser.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command adduser.conf and provides detailed information about the command adduser.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the adduser.conf.

NAME 🖥️ adduser.conf 🖥️

configuration file for adduser(8) and addgroup(8)

DESCRIPTION

The file /etc/adduser.conf contains defaults for the programs adduser(8), addgroup(8), deluser(8) and delgroup(8). Each line holds a single value pair in the form option = value. Double or single quotes are allowed around the value, as is whitespace around the equals sign. Comment lines must have a hash sign (#) in the first column.

The valid configuration options are:

STDERRMSGLEVEL , STDOUTMSGLEVEL , and LOGMSGLEVEL
Minimum priority for messages logged to syslog/journal and the console, respectively. Values are trace, debug, info, warn, err, and fatal. Messages with the priority set here or higher get printed to the respective medium. Messages printed to stderr are not repeated on stdout. That allows the local admin to control addusers chattiness on the console and in the log independently, keeping probably confusing information to itself while still leaving helpful information in the log. Defaults to info for STDOUTMSGLEVEL and LOGMSGLEVEL and warn for STDERRMSGLEVEL.

ADD_EXTRA_GROUPS
Setting this to something other than 0 will cause adduser to add newly created non-system users to the list of groups defined by EXTRA_GROUPS (below). Defaults to 0.

DIR_MODE
The permissions mode for home directories of non-system users that are created by adduser(8). Defaults to 0700. Note that there are potential configurations (such as /~user web services, or in-home mail delivery) which will require changes to the default. See also SYS_DIR_MODE.

DHOME
The directory in which new home directories should be created. Defaults to /home.

DSHELL
The login shell to be used for all new users. Defaults to /bin/bash.

EXTRA_GROUPS
This is the space-separated list of groups that new non-system users will be added to. Defaults to users.

FIRST_SYSTEM_GID and LAST_SYSTEM_GID
specify an inclusive range of GIDs from which GIDs for system groups can be dynamically allocated. Defaults to 100 - 999.

FIRST_GID and LAST_GID
specify an inclusive range of GIDs from which GIDs for non-system groups can be dynamically allocated. Defaults to 1000 - 59999.

FIRST_SYSTEM_UID and LAST_SYSTEM_UID
specify an inclusive range of UIDs from which UIDs for system users can be dynamically allocated. Defaults to 100 - 999. Please note that system software, such as the users allocated by the base-passwd package, may assume that UIDs less than 100 are unallocated.

FIRST_UID and LAST_UID
specify an inclusive range of UIDs from which UIDs for non-system users can be dynamically allocated. Defaults to 1000 - 59999.

GID_POOL
See UID_POOL.

GROUPHOMES
If this is set to yes, the home directories will be created as /home/groupname/user. Defaults to no. This option is deprecated and will be removed.

LAST_GID
LAST_SYSTEM_GID
LAST_UID
LAST_SYSTEM_UID
See the FIRST_ variants of the option.

LETTERHOMES
If this is set to yes, then the home directories created will have an extra directory inserted which is the first letter of the loginname. For example: /home/u/user. Defaults to no. This option is deprecated and will be removed.

NAME_REGEX
Non-system user- and groupnames are checked against this regular expression. If the name doesn’t match this regexp, user and group creation in adduser(8) is refused unless –allow-bad-names is set. With –allow-bad-names set, weaker checks are performed. Defaults to the most conservative ^[a-z][-a-z0-9_]*$. See SYS_NAME_REGXEX and Valid names, below, for more information.

QUOTAUSER
If set to a nonempty value, new users will have quotas copied from that user using edquota -p QUOTAUSER newuser. Defaults to the empty string.

SETGID_HOME
If this is set to yes, then home directories for users with their own group (USERGROUPS = yes) will have the set-group-ID bit set. Note that this feature is deprecated and will be removed in a future version of adduser(8). Please use DIR_MODE instead. Defaults to no.

SKEL
The directory from which skeletal user configuration files will be copied. Defaults to /etc/skel.

SKEL_IGNORE_REGEX
When populating the newly created home directory of a non-system user, files in SKEL matching this regex are not copied. Defaults to to (.(dpkg|ucf)-(old|new|dist)$), the regular expression matching files left over from unmerged config files.

SYS_DIR_MODE
The permissions mode for home directories of system users that are created by adduser(8). Defaults to 0755. Note that changing the default permissions for system users may cause some packages to behave unreliably, if the program relies on the default setting. See also DIR_MODE.

SYS_NAME_REGEX
System user- and groupnames are checked against this regular expression. If the name doesn’t match this regexp, system user and group creation in adduser is refused unless –allow-bad-names is set. With –allow-bad-names set, weaker checks are performed. Defaults to the most conservative ^[a-z_][-a-z0-9_]*$. See NAME_REGEX, above, and Valid names, below, for more information.

UID_POOL and GID_POOL
specify a file or a directory containing UID and GID pool files. See UID and GID POOLS in the NOTES section. Both default to empty.

USERGROUPS
Specify whether each created non-system user will be given their own group to use. Defaults to yes.

USERS_GID and USERS_GROUP
Defines the groupname or GID of the group all newly-created non-system users are placed into. If USERGROUPS is yes, the group will be added as a supplementary group; if USERGROUPS is no,, it will be the primary group. If you don’t want all your users to be in one group, set USERGROUPS=yes, leave USERS_GROUP empty and set USERS_GID to “-1”. USERS_GROUP defaults to users, which has GID 100 on all Debian systems since it’s defined statically by the base-passwd package. It is a configuration error to define both variables even if the values are consistent.

NOTES

VALID NAMES

Historically, adduser(8) and addgroup(8) enforced conformity to IEEE Std 1003.1-2001, which allows only the following characters to appear in group- and usernames: letters, digits, underscores, periods, at signs (@) and dashes. The name may not start with a dash or @. The “$” sign is allowed at the end of usernames to allow typical Samba machine accounts.

The default settings for NAME_REGEX and SYS_NAME_REGEX allow usernames to contain lowercase letters and numbers, plus dash (-) and underscore (_); the name must begin with a letter (or an underscore for system users).

The least restrictive policy, available by using the –allow-all-names option, simply makes the same checks as useradd(8): cannot start with a dash, plus sign, or tilde; and cannot contain a colon, comma, slash, or whitespace.

This option can be used to create confusing or misleading names; use it with caution.

Please note that regardless of the regular expressions used to evaluate the username, it may be a maximum of 32 bytes; this may be less than 32 visual characters when using Unicode glyphs in the username.

UID AND GID POOLS

Some installations desire that a non-system account gets preconfigured properties when it is generated. Commonly, the local admin wants to make sure that even without using a directory service, an account or a group with a certain name has the same numeric UID/GID on all systems where it exists.

To enable this feature, define configuration variables UID_POOL (for user accounts) and/or GID_POOL (for groups) in /etc/adduser.conf and install the respective files in the configured places. The value is either a file or a directory. In the latter case all files named *.conf in that directory are considered.

The file format is similar to /etc/passwd: Text lines, fields separated by a colon. The values are username/groupname (mandatory), UID/GID (mandatory), comment field (optional, useful for user IDs only), home directory (ditto), shell (ditto).

It is possible to use the same file/directory for UID_POOL and GID_POOL.

If an account / group is created, adduser(8) searches in all UID/GID pool files for a line matching the name of the newly created account and uses the data found there to initialize the new account instead of using the defaults. Settings may be overridden from the command line.

FILES

/etc/adduser.conf

229 - Linux cli command proc_sys_proc

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_sys_proc and provides detailed information about the command proc_sys_proc, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_sys_proc.

NAME 🖥️ proc_sys_proc 🖥️

???

DESCRIPTION

/proc/sys/proc/
This directory may be empty.

230 - Linux cli command sysstat

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command sysstat and provides detailed information about the command sysstat, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the sysstat.

NAME 🖥️ sysstat 🖥️

sysstat configuration file.

DESCRIPTION

This file is read by sa1(8) and sa2(8) shell scripts from the sysstat’s set of tools. It consists of a sequence of shell variable assignments used to configure sysstat logging. The variables and their meanings are:

COMPRESSAFTER
Number of days after which daily data files are to be compressed. The compression program is given in the **ZIP **variable.

DELAY_RANGE
Tell sa2 script to wait for a random delay in the indicated range before running. This delay is expressed in seconds, and is aimed at preventing a massive I/O burst at the same time on VM sharing the same storage area. A value of 0 means that sa2 script will generate its reports files immediately.

HISTORY
The number of days during which a daily data file or a report should be kept. Data files or reports older than this number of days will be removed by the sa2(8) shell script. Data files and reports are normally saved in the /var/log/sysstat directory, under the name *saDD *(for data files) or *sarDD *(for reports), where the DD parameter indicates the current day.

The number of files actually kept in the /var/log/sysstat directory may be slightly higher than the **HISTORY **value due to the way the sa2 script figures out which files are to be removed (see below “How the sa2(8) script applies HISTORY value”). Using a value of 28 keeps a whole month’s worth of data. If you set HISTORY to a value greater than 28 then you should consider using sadc’s option -D to prevent older data files from being overwritten (see sadc(8) manual page). In this latter case data files are named *saYYYYMMDD *and reports sarYYYYMMDD, where *YYYY *stands for the current year, *MM *for the current month and DD for the current day.

How the sa2(8) script applies **HISTORY **value

The sa2 script uses the **find **command with the **-mtime **option to figure out which files are to be removed. The **find **command interprets this value as “N 24 hour periods”, ignoring any fractional part. This means that the last modified time of a given *sa[r]DD *data or report file, using a HISTORY of 1, has to have been modified at least two days ago before it will be removed. And for a **HISTORY **of 28 that would mean 29 days ago.

To figure out how a HISTORY of 28 is applied in practice, we need to consider that the **sa2 **script that issues the **find **command to remove the old files typically runs just before midnight on a given system, and since the first record from sadc can also be written to the previous day’s data file (thereby moving its modification time up a bit), the sa2 script will leave 30 files untouched. So for a setting of 28, and counting the data file of the current day, there will always be 31 files (or 30 files, depending on the number of days in a month) in the /var/log/sysstat directory during the majority of a given day. E.g.:

April 30th: 31 files (Apr 30th-1st, Mar 31th)
May 1st: 30 files (May 1st, Apr 30th-2nd)

Yet we can note the following exceptions (as inspected at Noon of the given day):

February 28th: 31 files (Feb 28th-1st, Jan 31st, 30th & 29th)
March 1st: 30 files (Mar 1st, Feb 28th-2nd, Jan 31st & 30th)
March 2nd: 29 files (Mar 1st & 2nd, Feb 28th-3rd, Jan. 31st)
March 3rd: 28 files (Mar 1st-3rd, Feb 28th-4th)
March 4th - March 28th: 28 files
March 29th: 29 files
March 30th: 30 files
March 31st: 31 files

(Determining the number of files in March on a leap year is left as an exercise for the reader).

Things are simpler if you use the *sa[r]YYYYMMDD *name format. Apply the same logic as above in this case and you will find that there are always **HISTORY **+ 3 files in the /var/log/sa directory during the majority of a given day.

REPEAT_HEADER
Maximum number of lines after which a header will be inserted in the report generated by sa2 script. By default there is only a header at the beginning of each report and it is not repeated afterwards.

REPORTS
Set this variable to **false **to prevent the sa2 script from generating reports (the *sarDD *files).

SA_DIR
Directory where the standard system activity daily data and report files are saved. Its default value is /var/log/sysstat.

SADC_OPTIONS
Options that should be passed to sadc(8). With these options (see sadc(8) manual page), you can select some additional data which are going to be saved in daily data files. These options are used only when a new data file is created. They will be ignored with an already existing one.

UMASK
The sa1 and sa2 scripts generate system activity data and report files in the /var/log/sa directory. By default the files are created with umask 0022 and are therefore readable for all users. Change this variable to restrict the permissions on the files (e.g. use 0027 to adhere to more strict security standards).

YESTERDAY
By default sa2 script generates yesterday’s summary, since the **cron **job usually runs right after midnight. If you want sa2 to generate the summary of the same day (for example when cron job runs at 23:53) set this variable to no.

ZIP
Program used to compress data and report files.

FILE

/etc/sysstat/sysstat

AUTHOR

Sebastien Godard (sysstat <at> orange.fr)

231 - Linux cli command fonts-conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command fonts-conf and provides detailed information about the command fonts-conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the fonts-conf.

NAME 🖥️ fonts-conf 🖥️

Font configuration files

SYNOPSIS

   /etc/fonts/fonts.conf
   /etc/fonts/fonts.dtd
   /etc/fonts/conf.d
   $XDG_CONFIG_HOME/fontconfig/conf.d
   $XDG_CONFIG_HOME/fontconfig/fonts.conf
   ~/.fonts.conf.d
   ~/.fonts.conf

DESCRIPTION

Fontconfig is a library designed to provide system-wide font configuration, customization and application access.

FUNCTIONAL OVERVIEW

Fontconfig contains two essential modules, the configuration module which builds an internal configuration from XML files and the matching module which accepts font patterns and returns the nearest matching font.

FONT CONFIGURATION

The configuration module consists of the FcConfig datatype, libexpat and FcConfigParse which walks over an XML tree and amends a configuration with data found within. From an external perspective, configuration of the library consists of generating a valid XML tree and feeding that to FcConfigParse. The only other mechanism provided to applications for changing the running configuration is to add fonts and directories to the list of application-provided font files.

The intent is to make font configurations relatively static, and shared by as many applications as possible. It is hoped that this will lead to more stable font selection when passing names from one application to another. XML was chosen as a configuration file format because it provides a format which is easy for external agents to edit while retaining the correct structure and syntax.

Font configuration is separate from font matching; applications needing to do their own matching can access the available fonts from the library and perform private matching. The intent is to permit applications to pick and choose appropriate functionality from the library instead of forcing them to choose between this library and a private configuration mechanism. The hope is that this will ensure that configuration of fonts for all applications can be centralized in one place. Centralizing font configuration will simplify and regularize font installation and customization.

FONT PROPERTIES

While font patterns may contain essentially any properties, there are some well known properties with associated types. Fontconfig uses some of these properties for font matching and font completion. Others are provided as a convenience for the applications’ rendering mechanism.

Property        Type    Description
--------------------------------------------------------------
family          String  Font family names
familylang      String  Languages corresponding to each family
style           String  Font style. Overrides weight and slant
stylelang       String  Languages corresponding to each style
fullname        String  Font full names (often includes style)
fullnamelang    String  Languages corresponding to each fullname
slant           Int     Italic, oblique or roman
weight          Int     Light, medium, demibold, bold or black
width           Int     Condensed, normal or expanded
size            Double  Point size
aspect          Double  Stretches glyphs horizontally before hinting
pixelsize       Double  Pixel size
spacing         Int     Proportional, dual-width, monospace or charcell
foundry         String  Font foundry name
antialias       Bool    Whether glyphs can be antialiased
hintstyle       Int     Automatic hinting style
hinting         Bool    Whether the rasterizer should use hinting
verticallayout  Bool    Use vertical layout
autohint        Bool    Use autohinter instead of normal hinter
globaladvance   Bool    Use font global advance data (deprecated)
file            String  The filename holding the font
index           Int     The index of the font within the file
ftface          FT_Face Use the specified FreeType face object
rasterizer      String  Which rasterizer is in use (deprecated)
outline         Bool    Whether the glyphs are outlines
scalable        Bool    Whether the glyphs are outlines or have color
dpi             Double  Target dots per inch
rgba            Int     unknown, rgb, bgr, vrgb, vbgr,
                        none - subpixel geometry
scale           Double  Scale factor for point->pixel conversions
                        (deprecated)
minspace        Bool    Eliminate leading from line spacing
charset         CharSet Unicode chars encoded by the font
lang            String  List of RFC-3066-style languages this
                        font supports
fontversion     Int     Version number of the font
capability      String  List of layout capabilities in the font
fontformat      String  String name of the font format
embolden        Bool    Rasterizer should synthetically embolden the font
embeddedbitmap  Bool    Use the embedded bitmap instead of the outline
decorative      Bool    Whether the style is a decorative variant
lcdfilter       Int     Type of LCD filter
namelang        String  Language name to be used for the default value of
                        familylang, stylelang, and fullnamelang
fontfeatures    String  List of the feature tags in OpenType to be enabled
prgname         String  String  Name of the running program
postscriptname  String  Font family name in PostScript
color           Bool    Whether any glyphs have color
symbol          Bool    Whether font uses MS symbol-font encoding
fontvariations  String  comma-separated string of axes in variable font
variable        Bool    Wheter font is Variable Font
fonthashint     Bool    Whether the font has hinting
order           Int     Order number of the font
desktop         String  Current desktop name
namedinstance   Bool    Whether font is a named instance
fontwarapper    String  The font wrapper format, current values are WOFF, WOFF2,
                        SFNT for any other SFNT font, and CFF for standalone
                        CFF fonts.

FONT MATCHING

Fontconfig performs matching by measuring the distance from a provided pattern to all of the available fonts in the system. The closest matching font is selected. This ensures that a font will always be returned, but doesn’t ensure that it is anything like the requested pattern.

Font matching starts with an application constructed pattern. The desired attributes of the resulting font are collected together in a pattern. Each property of the pattern can contain one or more values; these are listed in priority order; matches earlier in the list are considered “closer” than matches later in the list.

The initial pattern is modified by applying the list of editing instructions specific to patterns found in the configuration; each consists of a match predicate and a set of editing operations. They are executed in the order they appeared in the configuration. Each match causes the associated sequence of editing operations to be applied.

After the pattern has been edited, a sequence of default substitutions are performed to canonicalize the set of available properties; this avoids the need for the lower layers to constantly provide default values for various font properties during rendering.

The canonical font pattern is finally matched against all available fonts. The distance from the pattern to the font is measured for each of several properties: foundry, charset, family, lang, spacing, pixelsize, style, slant, weight, antialias, rasterizer and outline. This list is in priority order – results of comparing earlier elements of this list weigh more heavily than later elements.

There is one special case to this rule; family names are split into two bindings; strong and weak. Strong family names are given greater precedence in the match than lang elements while weak family names are given lower precedence than lang elements. This permits the document language to drive font selection when any document specified font is unavailable.

The pattern representing that font is augmented to include any properties found in the pattern but not found in the font itself; this permits the application to pass rendering instructions or any other data through the matching system. Finally, the list of editing instructions specific to fonts found in the configuration are applied to the pattern. This modified pattern is returned to the application.

The return value contains sufficient information to locate and rasterize the font, including the file name, pixel size and other rendering data. As none of the information involved pertains to the FreeType library, applications are free to use any rasterization engine or even to take the identified font file and access it directly.

The match/edit sequences in the configuration are performed in two passes because there are essentially two different operations necessary – the first is to modify how fonts are selected; aliasing families and adding suitable defaults. The second is to modify how the selected fonts are rasterized. Those must apply to the selected font, not the original pattern as false matches will often occur.

FONT NAMES

Fontconfig provides a textual representation for patterns that the library can both accept and generate. The representation is in three parts, first a list of family names, second a list of point sizes and finally a list of additional properties:

<families>-<point sizes>:<name1>=<values1>:<name2>=<values2>...

Values in a list are separated with commas. The name needn’t include either families or point sizes; they can be elided. In addition, there are symbolic constants that simultaneously indicate both a name and a value. Here are some examples:

Name                            Meaning
----------------------------------------------------------
Times-12                        12 point Times Roman
Times-12:bold                   12 point Times Bold
Courier:italic                  Courier Italic in the default size
Monospace:matrix=1 .1 0 1       The users preferred monospace font
                                with artificial obliquing

The ‘, ‘-’, ‘:’ and ‘,’ characters in family names must be preceded by a ‘\ character to avoid having them misinterpreted. Similarly, values containing ‘, ‘=’, ‘_’, ‘:’ and ‘,’ must also have them preceded by a ‘\ character. The ‘\ characters are stripped out of the family name and values as the font name is read.

DEBUGGING APPLICATIONS

To help diagnose font and applications problems, fontconfig is built with a large amount of internal debugging left enabled. It is controlled by means of the FC_DEBUG environment variable. The value of this variable is interpreted as a number, and each bit within that value controls different debugging messages.

Name         Value    Meaning
---------------------------------------------------------
MATCH            1    Brief information about font matching
MATCHV           2    Extensive font matching information
EDIT             4    Monitor match/test/edit execution
FONTSET          8    Track loading of font information at startup
CACHE           16    Watch cache files being written
CACHEV          32    Extensive cache file writing information
PARSE           64    (no longer in use)
SCAN           128    Watch font files being scanned to build caches
SCANV          256    Verbose font file scanning information
MEMORY         512    Monitor fontconfig memory usage
CONFIG        1024    Monitor which config files are loaded
LANGSET       2048    Dump char sets used to construct lang values
MATCH2        4096    Display font-matching transformation in patterns

Add the value of the desired debug levels together and assign that (in base 10) to the FC_DEBUG environment variable before running the application. Output from these statements is sent to stdout.

LANG TAGS

Each font in the database contains a list of languages it supports. This is computed by comparing the Unicode coverage of the font with the orthography of each language. Languages are tagged using an RFC-3066 compatible naming and occur in two parts – the ISO 639 language tag followed a hyphen and then by the ISO 3166 country code. The hyphen and country code may be elided.

Fontconfig has orthographies for several languages built into the library. No provision has been made for adding new ones aside from rebuilding the library. It currently supports 122 of the 139 languages named in ISO 639-1, 141 of the languages with two-letter codes from ISO 639-2 and another 30 languages with only three-letter codes. Languages with both two and three letter codes are provided with only the two letter code.

For languages used in multiple territories with radically different character sets, fontconfig includes per-territory orthographies. This includes Azerbaijani, Kurdish, Pashto, Tigrinya and Chinese.

CONFIGURATION FILE FORMAT

Configuration files for fontconfig are stored in XML format; this format makes external configuration tools easier to write and ensures that they will generate syntactically correct configuration files. As XML files are plain text, they can also be manipulated by the expert user using a text editor.

The fontconfig document type definition resides in the external entity “fonts.dtd”; this is normally stored in the default font configuration directory (/etc/fonts). Each configuration file should contain the following structure:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "urn:fontconfig:fonts.dtd">
<fontconfig>
...
</fontconfig>

<FONTCONFIG>

This is the top level element for a font configuration and can contain <dir>, <cachedir>, <include>, <match> and <alias> elements in any order.

<DIR PREFIX=“DEFAULT” SALT="">

This element contains a directory name which will be scanned for font files to include in the set of available fonts.

If ‘prefix’ is set to “default” or “cwd”, the current working directory will be added as the path prefix prior to the value. If ‘prefix’ is set to “xdg”, the value in the XDG_DATA_HOME environment variable will be added as the path prefix. please see XDG Base Directory Specification for more details. If ‘prefix’ is set to “relative”, the path of current file will be added prior to the value.

‘salt’ property affects to determine cache filename. this is useful for example when having different fonts sets on same path at container and share fonts from host on different font path.

<CACHEDIR PREFIX=“DEFAULT”>

This element contains a directory name that is supposed to be stored or read the cache of font information. If multiple elements are specified in the configuration file, the directory that can be accessed first in the list will be used to store the cache files. If it starts with ‘~’, it refers to a directory in the users home directory. If ‘prefix’ is set to “xdg”, the value in the XDG_CACHE_HOME environment variable will be added as the path prefix. please see XDG Base Directory Specification for more details. The default directory is ``$XDG_CACHE_HOME/fontconfig’’ and it contains the cache files named ``<hash value>-<architecture>.cache-<version>’’, where <version> is the fontconfig cache file version number (currently 8).

<INCLUDE IGNORE_MISSING=“NO” PREFIX=“DEFAULT”>

This element contains the name of an additional configuration file or directory. If a directory, every file within that directory starting with an ASCII digit (U+0030 - U+0039) and ending with the string ``.conf’’ will be processed in sorted order. When the XML datatype is traversed by FcConfigParse, the contents of the file(s) will also be incorporated into the configuration by passing the filename(s) to FcConfigLoadAndParse. If ‘ignore_missing’ is set to “yes” instead of the default “no”, a missing file or directory will elicit no warning message from the library. If ‘prefix’ is set to “xdg”, the value in the XDG_CONFIG_HOME environment variable will be added as the path prefix. please see XDG Base Directory Specification for more details.

<CONFIG>

This element provides a place to consolidate additional configuration information. <config> can contain <blank> and <rescan> elements in any order.

<DESCRIPTION DOMAIN=“FONTCONFIG-CONF”>

This element is supposed to hold strings which describe what a config is used for. This string can be translated through gettext. ‘domain’ needs to be set the proper name to apply then. fontconfig will tries to retrieve translations with ‘domain’ from gettext.

<BLANK>

Fonts often include “broken” glyphs which appear in the encoding but are drawn as blanks on the screen. Within the <blank> element, place each Unicode characters which is supposed to be blank in an <int> element. Characters outside of this set which are drawn as blank will be elided from the set of characters supported by the font.

<REMAP-DIR PREFIX=“DEFAULT” AS-PATH="" SALT="">

This element contains a directory name where will be mapped as the path ‘as-path’ in cached information. This is useful if the directory name is an alias (via a bind mount or symlink) to another directory in the system for which cached font information is likely to exist.

‘salt’ property affects to determine cache filename as same as <dir> element.

<RESET-DIRS />

This element removes all of fonts directories where added by <dir> elements. This is useful to override fonts directories from system to own fonts directories only.

<RESCAN>

The <rescan> element holds an <int> element which indicates the default interval between automatic checks for font configuration changes. Fontconfig will validate all of the configuration files and directories and automatically rebuild the internal datastructures when this interval passes.

<SELECTFONT>

This element is used to deny/allow list fonts from being listed or matched against. It holds acceptfont and rejectfont elements. This list is applied only once when caches is loaded. So if you want to filter out by some patterns, patterns is evaluated with something in cache only. In other words, target patterns except “scan” won’t takes any effects.

<ACCEPTFONT>

Fonts matched by an acceptfont element are “allowlisted”; such fonts are explicitly included in the set of fonts used to resolve list and match requests; including them in this list protects them from being “denylisted” by a rejectfont element. Acceptfont elements include glob and pattern elements which are used to match fonts.

<REJECTFONT>

Fonts matched by an rejectfont element are “denylisted”; such fonts are excluded from the set of fonts used to resolve list and match requests as if they didn’t exist in the system. Rejectfont elements include glob and pattern elements which are used to match fonts.

<GLOB>

Glob elements hold shell-style filename matching patterns (including ? and *) which match fonts based on their complete pathnames. If it starts with ‘~’, it refers to a directory in the users home directory. This can be used to exclude a set of directories (/usr/share/fonts/uglyfont*), or particular font file types (*.pcf.gz), but the latter mechanism relies rather heavily on filenaming conventions which can’t be relied upon. Note that globs only apply to directories, not to individual fonts.

<PATTERN>

Pattern elements perform list-style matching on incoming fonts; that is, they hold a list of elements and associated values. If all of those elements have a matching value, then the pattern matches the font. This can be used to select fonts based on attributes of the font (scalable, bold, etc), which is a more reliable mechanism than using file extensions. Pattern elements include patelt elements.

<PATELT NAME=“PROPERTY”>

Patelt elements hold a single pattern element and list of values. They must have a ’name’ attribute which indicates the pattern element name. Patelt elements include int, double, string, matrix, bool, charset and const elements.

<MATCH TARGET=“PATTERN”>

This element holds first a (possibly empty) list of <test> elements and then a (possibly empty) list of <edit> elements. Patterns which match all of the tests are subjected to all the edits. If ’target’ is set to “font” instead of the default “pattern”, then this element applies to the font name resulting from a match rather than a font pattern to be matched. If ’target’ is set to “scan”, then this element applies when the font is scanned to build the fontconfig database.

<TEST QUAL=“ANY” NAME=“PROPERTY” TARGET=“DEFAULT” COMPARE=“EQ”>

This element contains a single value which is compared with the target (‘pattern’, ‘font’, ‘scan’ or ‘default’) property “property” (substitute any of the property names seen above). ‘compare’ can be one of “eq”, “not_eq”, “less”, “less_eq”, “more”, “more_eq”, “contains” or “not_contains”. ‘qual’ may either be the default, “any”, in which case the match succeeds if any value associated with the property matches the test value, or “all”, in which case all of the values associated with the property must match the test value. ‘ignore-blanks’ takes a boolean value. if ‘ignore-blanks’ is set “true”, any blanks in the string will be ignored on its comparison. this takes effects only when compare=“eq” or compare=“not_eq”. When used in a <match target=“font”> element, the target= attribute in the <test> element selects between matching the original pattern or the font. “default” selects whichever target the outer <match> element has selected.

<EDIT NAME=“PROPERTY” MODE=“ASSIGN” BINDING=“WEAK”>

This element contains a list of expression elements (any of the value or operator elements). The expression elements are evaluated at run-time and modify the property “property”. The modification depends on whether “property” was matched by one of the associated <test> elements, if so, the modification may affect the first matched value. Any values inserted into the property are given the indicated binding (“strong”, “weak” or “same”) with “same” binding using the value from the matched pattern element. ‘mode’ is one of:

Mode                    With Match              Without Match
---------------------------------------------------------------------
"assign"                Replace matching value  Replace all values
"assign_replace"        Replace all values      Replace all values
"prepend"               Insert before matching  Insert at head of list
"prepend_first"         Insert at head of list  Insert at head of list
"append"                Append after matching   Append at end of list
"append_last"           Append at end of list   Append at end of list
"delete"                Delete matching value   Delete all values
"delete_all"            Delete all values       Delete all values

<INT>, <DOUBLE>, <STRING>, <BOOL>

These elements hold a single value of the indicated type. <bool> elements hold either true or false. An important limitation exists in the parsing of floating point numbers – fontconfig requires that the mantissa start with a digit, not a decimal point, so insert a leading zero for purely fractional values (e.g. use 0.5 instead of .5 and -0.5 instead of -.5).

<MATRIX>

This element holds four numerical expressions of an affine transformation. At their simplest these will be four <double> elements but they can also be more involved expressions.

<RANGE>

This element holds the two <int> elements of a range representation.

<CHARSET>

This element holds at least one <int> element of an Unicode code point or more.

<LANGSET>

This element holds at least one <string> element of a RFC-3066-style languages or more.

<NAME>

Holds a property name. Evaluates to the first value from the property of the pattern. If the ’target’ attribute is not present, it will default to ‘default’, in which case the property is returned from the font pattern during a target=“font” match, and to the pattern during a target=“pattern” match. The attribute can also take the values ‘font’ or ‘pattern’ to explicitly choose which pattern to use. It is an error to use a target of ‘font’ in a match that has target=“pattern”.

<CONST>

Holds the name of a constant; these are always integers and serve as symbolic names for common font values:

Constant        Property        Value
-------------------------------------
thin            weight          0
extralight      weight          40
ultralight      weight          40
light           weight          50
demilight       weight          55
semilight       weight          55
book            weight          75
regular         weight          80
normal          weight          80
medium          weight          100
demibold        weight          180
semibold        weight          180
bold            weight          200
extrabold       weight          205
ultrabold       weight          205
black           weight          210
heavy           weight          210
extrablack      weight          215
ultrablack      weight          215
roman           slant           0
italic          slant           100
oblique         slant           110
ultracondensed  width           50
extracondensed  width           63
condensed       width           75
semicondensed   width           87
normal          width           100
semiexpanded    width           113
expanded        width           125
extraexpanded   width           150
ultraexpanded   width           200
proportional    spacing         0
dual            spacing         90
mono            spacing         100
charcell        spacing         110
unknown         rgba            0
rgb             rgba            1
bgr             rgba            2
vrgb            rgba            3
vbgr            rgba            4
none            rgba            5
lcdnone         lcdfilter       0
lcddefault      lcdfilter       1
lcdlight        lcdfilter       2
lcdlegacy       lcdfilter       3
hintnone        hintstyle       0
hintslight      hintstyle       1
hintmedium      hintstyle       2
hintfull        hintstyle       3

<OR>, <AND>, <PLUS>, <MINUS>, <TIMES>, <DIVIDE>

These elements perform the specified operation on a list of expression elements. <or> and <and> are boolean, not bitwise.

<EQ>, <NOT_EQ>, <LESS>, <LESS_EQ>, <MORE>, <MORE_EQ>, <CONTAINS>, <NOT_CONTAINS

These elements compare two values, producing a boolean result.

<NOT>

Inverts the boolean sense of its one expression element

<IF>

This element takes three expression elements; if the value of the first is true, it produces the value of the second, otherwise it produces the value of the third.

<ALIAS>

Alias elements provide a shorthand notation for the set of common match operations needed to substitute one font family for another. They contain a <family> element followed by optional <prefer>, <accept> and <default> elements. Fonts matching the <family> element are edited to prepend the list of <prefer>ed families before the matching <family>, append the <accept>able families after the matching <family> and append the <default> families to the end of the family list.

<FAMILY>

Holds a single font family name

<PREFER>, <ACCEPT>, <DEFAULT>

These hold a list of <family> elements to be used by the <alias> element.

EXAMPLE CONFIGURATION FILE

SYSTEM CONFIGURATION FILE

This is an example of a system-wide configuration file

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "urn:fontconfig:fonts.dtd">
<!-- /etc/fonts/fonts.conf file to configure system font access -->
<fontconfig>
  <!--
    Find fonts in these directories
  -->
  <dir>/usr/share/fonts</dir>
  <dir>/usr/X11R6/lib/X11/fonts</dir>

  <!--
    Accept deprecated 'mono' alias, replacing it with 'monospace'
  -->
  <match target="pattern">
    <test qual="any" name="family">
      <string>mono</string>
    </test>
    <edit name="family" mode="assign">
      <string>monospace</string>
    </edit>
  </match>

  <!--
    Names not including any well known alias are given 'sans-serif'
  -->
  <match target="pattern">
    <test qual="all" name="family" compare="not_eq">
      <string>sans-serif</string>
    </test>
    <test qual="all" name="family" compare="not_eq">
      <string>serif</string>
    </test>
    <test qual="all" name="family" compare="not_eq">
      <string>monospace</string>
    </test>
    <edit name="family" mode="append_last">
      <string>sans-serif</string>
    </edit>
  </match>

  <!--
    Load per-user customization file, but don't complain
    if it doesn't exist
  -->
  <include ignore_missing="yes" prefix="xdg">
    fontconfig/fonts.conf
  </include>

  <!--
    Load local customization files, but don't complain
    if there aren't any
  -->
  <include ignore_missing="yes">conf.d</include>
  <include ignore_missing="yes">local.conf</include>

  <!--
    Alias well known font names to available TrueType fonts.
    These substitute TrueType faces for similar Type1
    faces to improve screen appearance.
  -->
  <alias>
    <family>Times</family>
    <prefer>
      <family>Times New Roman</family>
    </prefer>
    <default>
      <family>serif</family>
    </default>
  </alias>
  <alias>
    <family>Helvetica</family>
    <prefer>
      <family>Arial</family>
    </prefer>
    <default>
      <family>sans</family>
    </default>
  </alias>
  <alias>
    <family>Courier</family>
    <prefer>
      <family>Courier New</family>
    </prefer>
    <default>
      <family>monospace</family>
    </default>
  </alias>

  <!--
    Provide required aliases for standard names
    Do these after the users configuration file so that
    any aliases there are used preferentially
  -->
  <alias>
    <family>serif</family>
    <prefer>
      <family>Times New Roman</family>
    </prefer>
  </alias>
  <alias>
    <family>sans</family>
    <prefer>
      <family>Arial</family>
    </prefer>
  </alias>
  <alias>
    <family>monospace</family>
    <prefer>
      <family>Andale Mono</family>
    </prefer>
  </alias>

  <--
    The example of the requirements of OR operator;
    If the 'family' contains 'Courier New' OR 'Courier'
    add 'monospace' as the alternative
  -->
  <match target="pattern">
    <test name="family" compare="eq">
      <string>Courier New</string>
    </test>
    <edit name="family" mode="prepend">
      <string>monospace</string>
    </edit>
  </match>
  <match target="pattern">
    <test name="family" compare="eq">
      <string>Courier</string>
    </test>
    <edit name="family" mode="prepend">
      <string>monospace</string>
    </edit>
  </match>

</fontconfig>

USER CONFIGURATION FILE

This is an example of a per-user configuration file that lives in $XDG_CONFIG_HOME/fontconfig/fonts.conf

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "urn:fontconfig:fonts.dtd">
<!--
  $XDG_CONFIG_HOME/fontconfig/fonts.conf for per-user font configuration
-->
<fontconfig>

  <!--
    Private font directory
  -->
  <dir prefix="xdg">fonts</dir>

  <!--
    use rgb sub-pixel ordering to improve glyph appearance on
    LCD screens.  Changes affecting rendering, but not matching
    should always use target="font".
  -->
  <match target="font">
    <edit name="rgba" mode="assign">
      <const>rgb</const>
    </edit>
  </match>
  <!--
    use WenQuanYi Zen Hei font when serif is requested for Chinese
  -->
  <match>
    <!--
      If you don't want to use WenQuanYi Zen Hei font for zh-tw etc,
      you can use zh-cn instead of zh.
      Please note, even if you set zh-cn, it still matches zh.
      if you don't like it, you can use compare="eq"
      instead of compare="contains".
    -->
    <test name="lang" compare="contains">
      <string>zh</string>
    </test>
    <test name="family">
      <string>serif</string>
    </test>
    <edit name="family" mode="prepend">
      <string>WenQuanYi Zen Hei</string>
    </edit>
  </match>
  <!--
    use VL Gothic font when sans-serif is requested for Japanese
  -->
  <match>
    <test name="lang" compare="contains">
      <string>ja</string>
    </test>
    <test name="family">
      <string>sans-serif</string>
    </test>
    <edit name="family" mode="prepend">
      <string>VL Gothic</string>
    </edit>
  </match>
</fontconfig>

FILES

fonts.conf contains configuration information for the fontconfig library consisting of directories to look at for font information as well as instructions on editing program specified font patterns before attempting to match the available fonts. It is in XML format.

conf.d is the conventional name for a directory of additional configuration files managed by external applications or the local administrator. The filenames starting with decimal digits are sorted in lexicographic order and used as additional configuration files. All of these files are in XML format. The master fonts.conf file references this directory in an <include> directive.

fonts.dtd is a DTD that describes the format of the configuration files.

$XDG_CONFIG_HOME/fontconfig/conf.d and ~/.fonts.conf.d is the conventional name for a per-user directory of (typically auto-generated) configuration files, although the actual location is specified in the global fonts.conf file. please note that ~/.fonts.conf.d is deprecated now. it will not be read by default in the future version.

$XDG_CONFIG_HOME/fontconfig/fonts.conf and ~/.fonts.conf is the conventional location for per-user font configuration, although the actual location is specified in the global fonts.conf file. please note that ~/.fonts.conf is deprecated now. it will not be read by default in the future version.

$XDG_CACHE_HOME/fontconfig/*.cache-* and ~/.fontconfig/*.cache-* is the conventional repository of font information that isn’t found in the per-directory caches. This file is automatically maintained by fontconfig. please note that ~/.fontconfig/*.cache-* is deprecated now. it will not be read by default in the future version.

ENVIRONMENT VARIABLES

FONTCONFIG_FILE is used to override the default configuration file.

FONTCONFIG_PATH is used to override the default configuration directory.

FONTCONFIG_SYSROOT is used to set a default sysroot directory.

FC_DEBUG is used to output the detailed debugging messages. see Debugging Applications section for more details.

FC_DBG_MATCH_FILTER is used to filter out the patterns. this takes a comma-separated list of object names and effects only when FC_DEBUG has MATCH2. see Debugging Applications section for more details.

FC_LANG is used to specify the default language as the weak binding in the query. if this isn’t set, the default language will be determined from current locale.

FONTCONFIG_USE_MMAP is used to control the use of mmap(2) for the cache files if available. this take a boolean value. fontconfig will checks if the cache files are stored on the filesystem that is safe to use mmap(2). explicitly setting this environment variable will causes skipping this check and enforce to use or not use mmap(2) anyway.

SOURCE_DATE_EPOCH is used to ensure fc-cache(1) generates files in a deterministic manner in order to support reproducible builds. When set to a numeric representation of UNIX timestamp, fontconfig will prefer this value over using the modification timestamps of the input files in order to identify which cache files require regeneration. If SOURCE_DATE_EPOCH is not set (or is newer than the mtime of the directory), the existing behaviour is unchanged.

VERSION

Fontconfig version 2.15.0

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

232 - Linux cli command journald.conf.d

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command journald.conf.d and provides detailed information about the command journald.conf.d, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the journald.conf.d.

NAME 🖥️ journald.conf.d 🖥️

Journal service configuration files

SYNOPSIS

/etc/systemd/journald.conf

/run/systemd/journald.conf

/usr/local/lib/systemd/journald.conf

/usr/lib/systemd/journald.conf

/etc/systemd/journald.conf.d/*.conf

/run/systemd/journald.conf.d/*.conf

/usr/local/lib/systemd/journald.conf.d/*.conf

/usr/lib/systemd/journald.conf.d/*.conf

/etc/systemd/journald@NAMESPACE.conf

/etc/systemd/journald@NAMESPACE.conf.d/*.conf

/run/systemd/journald@NAMESPACE.conf.d/*.conf

/usr/local/lib/systemd/journald@NAMESPACE.conf.d/*.conf

/usr/lib/systemd/journald@NAMESPACE.conf.d/*.conf

DESCRIPTION

These files configure various parameters of the systemd journal service, systemd-journald.service(8). See systemd.syntax(7) for a general description of the syntax.

The systemd-journald instance managing the default namespace is configured by /etc/systemd/journald.conf and associated drop-ins. Instances managing other namespaces read /etc/systemd/journald@NAMESPACE.conf and associated drop-ins with the namespace identifier filled in. This allows each namespace to carry a distinct configuration. See systemd-journald.service(8) for details about journal namespaces.

CONFIGURATION DIRECTORIES AND PRECEDENCE

OPTIONS

All options are configured in the [Journal] section:

Storage=

Controls where to store journal data. One of “volatile”, “persistent”, “auto” and “none”. If “volatile”, journal log data will be stored only in memory, i.e. below the /run/log/journal hierarchy (which is created if needed). If “persistent”, data will be stored preferably on disk, i.e. below the /var/log/journal hierarchy (which is created if needed), with a fallback to /run/log/journal (which is created if needed), during early boot and if the disk is not writable. “auto” behaves like “persistent” if the /var/log/journal directory exists, and “volatile” otherwise (the existence of the directory controls the storage mode). “none” turns off all storage, all log data received will be dropped (but forwarding to other targets, such as the console, the kernel log buffer, or a syslog socket will still work). Defaults to “auto” in the default journal namespace, and “persistent” in all others.
Note that journald will initially use volatile storage, until a call to journalctl –flush (or sending SIGUSR1 to journald) will cause it to switch to persistent logging (under the conditions mentioned above). This is done automatically on boot via “systemd-journal-flush.service”.
Note that when this option is changed to “volatile”, existing persistent data is not removed. In the other direction, journalctl(1) with the –flush option may be used to move volatile data to persistent storage.
When journal namespacing (see LogNamespace= in systemd.exec(5)) is used, setting Storage= to “volatile” or “auto” will not have an effect on the creation of the per-namespace logs directory in /var/log/journal/, as the [email protected] service file by default carries LogsDirectory=. To turn that off, add a unit file drop-in file that sets LogsDirectory= to an empty string.
Note that per-user journal files are not supported unless persistent storage is enabled, thus making journalctl –user unavailable.
The storage to use can also be specified via the “journal.storage” credential. Values configured via configuration files take priority over values configured via the credential.
Added in version 186.

Compress=

Can take a boolean value. If enabled (the default), data objects that shall be stored in the journal and are larger than the default threshold of 512 bytes are compressed before they are written to the file system. It can also be set to a number of bytes to specify the compression threshold directly. Suffixes like K, M, and G can be used to specify larger units.

Seal=

Takes a boolean value. If enabled (the default), and a sealing key is available (as created by journalctl(1)s –setup-keys command), Forward Secure Sealing (FSS) for all persistent journal files is enabled. FSS is based on Seekable Sequential Key Generators[2] by G. A. Marson and B. Poettering (doi:10.1007/978-3-642-40203-6_7) and may be used to protect journal files from unnoticed alteration.
Added in version 189.

SplitMode=

Controls whether to split up journal files per user, either “uid” or “none”. Split journal files are primarily useful for access control: on UNIX/Linux access control is managed per file, and the journal daemon will assign users read access to their journal files. If “uid”, all regular users (with UID outside the range of system users, dynamic service users, and the nobody user) will each get their own journal files, and system users will log to the system journal. See Users, Groups, UIDs and GIDs on systemd systems[3] for more details about UID ranges. If “none”, journal files are not split up by user and all messages are instead stored in the single system journal. In this mode unprivileged users generally do not have access to their own log data. Note that splitting up journal files by user is only available for journals stored persistently. If journals are stored on volatile storage (see Storage= above), only a single journal file is used. Defaults to “uid”.
Added in version 190.

RateLimitIntervalSec=, RateLimitBurst=

Configures the rate limiting that is applied to all messages generated on the system. If, in the time interval defined by RateLimitIntervalSec=, more messages than specified in RateLimitBurst= are logged by a service, all further messages within the interval are dropped until the interval is over. A message about the number of dropped messages is generated. This rate limiting is applied per-service, so that two services which log do not interfere with each others limits. Defaults to 10000 messages in 30s. The time specification for RateLimitIntervalSec= may be specified in the following units: “s”, “min”, “h”, “ms”, “us”. To turn off any kind of rate limiting, set either value to 0.
Note that the effective rate limit is multiplied by a factor derived from the available free disk space for the journal. Currently, this factor is calculated using the base 2 logarithm.
Table 1. Example RateLimitBurst= rate modifications by the available disk space
Available Disk Space Burst Multiplier
<= 1MB 1
<= 16MB 2
<= 256MB 3
<= 4GB 4
<= 64GB 5
<= 1TB 6
If a service provides rate limits for itself through LogRateLimitIntervalSec= and/or LogRateLimitBurst= in systemd.exec(5), those values will override the settings specified here.

SystemMaxUse=, SystemKeepFree=, SystemMaxFileSize=, SystemMaxFiles=, RuntimeMaxUse=, RuntimeKeepFree=, RuntimeMaxFileSize=, RuntimeMaxFiles=

Enforce size limits on the journal files stored. The options prefixed with “System” apply to the journal files when stored on a persistent file system, more specifically /var/log/journal. The options prefixed with “Runtime” apply to the journal files when stored on a volatile in-memory file system, more specifically /run/log/journal. The former is used only when /var/ is mounted, writable, and the directory /var/log/journal exists. Otherwise, only the latter applies. Note that this means that during early boot and if the administrator disabled persistent logging, only the latter options apply, while the former apply if persistent logging is enabled and the system is fully booted up. journalctl and systemd-journald ignore all files with names not ending with “.journal” or “.journal~”, so only such files, located in the appropriate directories, are taken into account when calculating current disk usage.
SystemMaxUse= and RuntimeMaxUse= control how much disk space the journal may use up at most. SystemKeepFree= and RuntimeKeepFree= control how much disk space systemd-journald shall leave free for other uses. systemd-journald will respect both limits and use the smaller of the two values.
The first pair defaults to 10% and the second to 15% of the size of the respective file system, but each value is capped to 4G. If the file system is nearly full and either SystemKeepFree= or RuntimeKeepFree= are violated when systemd-journald is started, the limit will be raised to the percentage that is actually free. This means that if there was enough free space before and journal files were created, and subsequently something else causes the file system to fill up, journald will stop using more space, but it will not be removing existing files to reduce the footprint again, either. Also note that only archived files are deleted to reduce the space occupied by journal files. This means that, in effect, there might still be more space used than SystemMaxUse= or RuntimeMaxUse= limit after a vacuuming operation is complete.
SystemMaxFileSize= and RuntimeMaxFileSize= control how large individual journal files may grow at most. This influences the granularity in which disk space is made available through rotation, i.e. deletion of historic data. Defaults to one eighth of the values configured with SystemMaxUse= and RuntimeMaxUse= capped to 128M, so that usually seven rotated journal files are kept as history. If the journal compact mode is enabled (enabled by default), the maximum file size is capped to 4G.
Specify values in bytes or use K, M, G, T, P, E as units for the specified sizes (equal to 1024, 1024², … bytes). Note that size limits are enforced synchronously when journal files are extended, and no explicit rotation step triggered by time is needed.
SystemMaxFiles= and RuntimeMaxFiles= control how many individual journal files to keep at most. Note that only archived files are deleted to reduce the number of files until this limit is reached; active files will stay around. This means that, in effect, there might still be more journal files around in total than this limit after a vacuuming operation is complete. This setting defaults to 100.

MaxFileSec=

The maximum time to store entries in a single journal file before rotating to the next one. Normally, time-based rotation should not be required as size-based rotation with options such as SystemMaxFileSize= should be sufficient to ensure that journal files do not grow without bounds. However, to ensure that not too much data is lost at once when old journal files are deleted, it might make sense to change this value from the default of one month. Set to 0 to turn off this feature. This setting takes time values which may be suffixed with the units “year”, “month”, “week”, “day”, “h” or “m” to override the default time unit of seconds.
Added in version 195.

MaxRetentionSec=

The maximum time to store journal entries. This controls whether journal files containing entries older than the specified time span are deleted. Normally, time-based deletion of old journal files should not be required as size-based deletion with options such as SystemMaxUse= should be sufficient to ensure that journal files do not grow without bounds. However, to enforce data retention policies, it might make sense to change this value from the default of 0 (which turns off this feature). This setting also takes time values which may be suffixed with the units “year”, “month”, “week”, “day”, “h” or " m" to override the default time unit of seconds.
Added in version 195.

SyncIntervalSec=

The timeout before synchronizing journal files to disk. After syncing, journal files are placed in the OFFLINE state. Note that syncing is unconditionally done immediately after a log message of priority CRIT, ALERT or EMERG has been logged. This setting hence applies only to messages of the levels ERR, WARNING, NOTICE, INFO, DEBUG. The default timeout is 5 minutes.
Added in version 199.

ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole=, ForwardToWall=, ForwardToSocket=

Control whether log messages received by the journal daemon shall be forwarded to a traditional syslog daemon, to the kernel log buffer (kmsg), to the system console, sent as wall messages to all logged-in users or sent over a socket. These options take boolean arguments except for “ForwardToSocket=” which takes an address instead. If forwarding to syslog is enabled but nothing reads messages from the socket, forwarding to syslog has no effect. By default, only forwarding to wall is enabled. These settings may be overridden at boot time with the kernel command line options “systemd.journald.forward_to_syslog”, “systemd.journald.forward_to_kmsg”, “systemd.journald.forward_to_console”, and “systemd.journald.forward_to_wall”. If the option name is specified without “=” and the following argument, true is assumed. Otherwise, the argument is parsed as a boolean.
The socket forwarding address can be specified with the credential “journal.forward_to_socket”. The following socket types are supported:
AF_INET (e.g. “192.168.0.11:4444”), AF_INET6 (e.g. “[2001:db8::ff00:42:8329]:4444”), AF_UNIX (e.g. “/run/host/journal/socket”), AF_VSOCK (e.g. “vsock:2:1234”)
When forwarding to the console, the TTY to log to can be changed with TTYPath=, described below.
When forwarding to the kernel log buffer (kmsg), make sure to select a suitably large size for the log buffer, for example by adding “log_buf_len=8M” to the kernel command line. systemd will automatically disable kernels rate-limiting applied to userspace processes (equivalent to setting “printk.devkmsg=on”).
When forwarding over a socket the Journal Export Format[4] is used when sending over the wire. Notably this includes the metadata field __REALTIME_TIMESTAMP so that systemd-journal-remote (see systemd-journal-remote.service(8)) can be used to receive the forwarded journal entries.
Note: Forwarding is performed synchronously within journald, and may significantly affect its performance. This is particularly relevant when using ForwardToConsole=yes in cloud environments, where the console is often a slow, virtual serial port. Since journald is implemented as a conventional single-process daemon, forwarding to a completely hung console will block journald. This can have a cascading effect resulting in any services synchronously logging to the blocked journal also becoming blocked. Unless actively debugging/developing something, its generally preferable to setup a journalctl –follow style service redirected to the console, instead of ForwardToConsole=yes, for production use.
Note: Using ForwardToSocket= over IPv4/IPv6 links can be very slow due to the synchronous nature of the sockets. Take care to ensure your link is a low-latency local link if possible. Typically IP networking is not available everywhere journald runs, e.g. in the initrd during boot. Consider using AF_VSOCK/AF_UNIX sockets for this if possible.

MaxLevelStore=, MaxLevelSyslog=, MaxLevelKMsg=, MaxLevelConsole=, MaxLevelWall=, MaxLevelSocket=

Controls the maximum log level of messages that are stored in the journal, forwarded to syslog, kmsg, the console, the wall, or a socket (if that is enabled, see above). As argument, takes one of “emerg”, “alert”, “crit”, “err”, “warning”, “notice”, “info”, “debug”, or integer values in the range of 0–7 (corresponding to the same levels). Messages equal or below the log level specified are stored/forwarded, messages above are dropped. Defaults to “debug” for MaxLevelStore=, MaxLevelSyslog= and MaxLevelSocket=, to ensure that the all messages are stored in the journal, forwarded to syslog and the socket if one exists. Defaults to “notice” for MaxLevelKMsg=, “info” for MaxLevelConsole=, and “emerg” for MaxLevelWall=. These settings may be overridden at boot time with the kernel command line options “systemd.journald.max_level_store=”, “systemd.journald.max_level_syslog=”, “systemd.journald.max_level_kmsg=”, “systemd.journald.max_level_console=”, “systemd.journald.max_level_wall=”, “systemd.journald.max_level_socket=”.
Added in version 185.

ReadKMsg=

Takes a boolean value. If enabled systemd-journal processes /dev/kmsg messages generated by the kernel. In the default journal namespace this option is enabled by default, it is disabled in all others.
Added in version 235.

Audit=

Takes a boolean value. If enabled systemd-journald will turn on kernel auditing on start-up. If disabled it will turn it off. If unset it will neither enable nor disable it, leaving the previous state unchanged. This means if another tool turns on auditing even if systemd-journald left it off, it will still collect the generated messages. Defaults to on.
Note that this option does not control whether systemd-journald collects generated audit records, it just controls whether it tells the kernel to generate them. If you need to prevent systemd-journald from collecting the generated messages, the socket unit “systemd-journald-audit.socket” can be disabled and in this case this setting is without effect.
Added in version 246.

TTYPath=

Change the console TTY to use if ForwardToConsole=yes is used. Defaults to /dev/console.
Added in version 185.

LineMax=

The maximum line length to permit when converting stream logs into record logs. When a systemd units standard output/error are connected to the journal via a stream socket, the data read is split into individual log records at newline (" “, ASCII 10) and NUL characters. If no such delimiter is read for the specified number of bytes a hard log record boundary is artificially inserted, breaking up overly long lines into multiple log records. Selecting overly large values increases the possible memory usage of the Journal daemon for each stream client, as in the worst case the journal daemon needs to buffer the specified number of bytes in memory before it can flush a new log record to disk. Also note that permitting overly large line maximum line lengths affects compatibility with traditional log protocols as log records might not fit anymore into a single AF_UNIX or AF_INET datagram. Takes a size in bytes. If the value is suffixed with K, M, G or T, the specified size is parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. Defaults to 48K, which is relatively large but still small enough so that log records likely fit into network datagrams along with extra room for metadata. Note that values below 79 are not accepted and will be bumped to 79.
Added in version 235.

FORWARDING TO TRADITIONAL SYSLOG DAEMONS

Journal events can be transferred to a different logging daemon in two different ways. With the first method, messages are immediately forwarded to a socket (/run/systemd/journal/syslog), where the traditional syslog daemon can read them. This method is controlled by the ForwardToSyslog= option. With a second method, a syslog daemon behaves like a normal journal client, and reads messages from the journal files, similarly to journalctl(1). With this, messages do not have to be read immediately, which allows a logging daemon which is only started late in boot to access all messages since the start of the system. In addition, full structured meta-data is available to it. This method of course is available only if the messages are stored in a journal file at all. So it will not work if Storage=none is set. It should be noted that usually the second method is used by syslog daemons, so the Storage= option, and not the ForwardToSyslog= option, is relevant for them.

NOTES

Seekable Sequential Key Generators

https://eprint.iacr.org/2013/397

Users, Groups, UIDs and GIDs on systemd systems

https://systemd.io/UIDS-GIDS

Journal Export Format

https://systemd.io/JOURNAL_EXPORT_FORMATS/#journal-export-format

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

233 - Linux cli command snmp.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command snmp.conf and provides detailed information about the command snmp.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the snmp.conf.

NAME 🖥️ snmp.conf 🖥️

configuration files for the Net-SNMP applications

DESCRIPTION

Applications built using the Net-SNMP libraries typically use one or more configuration files to control various aspects of their operation. These files (snmp.conf and snmp.local.conf) can be located in one of several locations, as described in the snmp_config(5) manual page.

In particular, /etc/snmp/snmp.conf is a common file, containing the settings shared by all users of the system. ~/.snmp/snmp.conf is a personal file, with the settings specific to a particular user.

HOST-SPECIFIC FILES

Host-specific files may also be loaded and will be searched for if a transport name is specified that matches a PATH/hosts/HOST.conf file. For example, if you wanted a particular host to use SNMPv2c by default you could create a ~/.snmp/hosts/NAME.conf file and in it put:

defVersion 2c

Any connections set to connect to the hostname NAME will use SNMPv2c. Also see the transport token below for additional host-specific examples.

Host-specific configuration files are loaded at the time the connection is opened. Thus they’re generally loaded after all other configuration files and can be used to override settings from the generic files.

To avoid loading any host-specific config files set “dontLoadHostConfig true” in your snmp.conf file.

COMMAND-LINE OPTIONS

All of the tokens described in this file can be used on the command line of Net-SNMP applications as well by prefixing them with “–”. EG, specifying –dontLoadHostConfig=true on the command line will turn of loading of the host specific configuration files.

IMPORTANT NOTE

Several of these directives may contain sensitive information (such as pass phrases). Configuration files that include such settings should only be readable by the user concerned.

As well as application-specific configuration tokens, there are several directives that relate to standard library behaviour, relevant to most Net-SNMP applications. Many of these correspond to standard command-line options, which are described in the snmpcmd(1) manual page.

These directives can be divided into several distinct groups.

CLIENT BEHAVIOUR

defDomain application domain
The transport domain that should be used for a certain application type unless something else is specified.

defTarget application domain target
The target that should be used for connections to a certain application if the connection should be in a specific domain.

defaultPort PORT
defines the default UDP port that client SNMP applications will attempt to connect to. This can be overridden by explicitly including a port number in the AGENT specification. See the snmpcmd(1) manual page for more details.

If not specified, the default value for this token is 161.

transport HOSTSPECIFIER
This special token should go into a hostname-specific configuration file in a hosts sub-directory. For example if the file hosts/foo.conf exists in the search path it will be loaded if a transport name of foo was used. Within the foo.conf file you may put both general snmp.conf settings as well as a special transport string to specify the destination to connect to. For example, putting:

transport tcp:foo.example.com:9876

in the hosts/foo.conf file will make applications referencing the foo hostname (e.g. snmpget) to actually connect via TCP to foo.exmaple.com on port 9876.

defVersion (1|2c|3)
defines the default version of SNMP to use. This can be overridden using the -v option.

defCommunity STRING
defines the default community to use for SNMPv1 and SNMPv2c requests. This can be overridden using the -c option.

alias NAME DEFINITION
Creates an aliased tied to NAME for a given transport definition. The alias can the be referred to using an alias: prefix. Eg, a line of “alias here udp:127.0.0.1:6161” would allow you to use a destination host of “alias:here” instead of “udp:127.0.0.1:6161”. This becomes more useful with complex transport addresses involving IPv6 addresses, etc.

dumpPacket yes
defines whether to display a hexadecimal dump of the raw SNMP requests sent and received by the application. This is equivalent to the -d option.

doDebugging (1|0)
turns on debugging for all applications run if set to 1.

debugTokens TOKEN[,TOKEN…]
defines the debugging tokens that should be turned on when doDebugging is set. This is equivalent to the -D option.

16bitIDs yes
restricts requestIDs, etc to 16-bit values.

The SNMP specifications define these ID fields as 32-bit quantities, and the Net-SNMP library typically initialises them to random values for security. However certain (broken) agents cannot handle ID values greater than 2^16 - this option allows interoperability with such agents.

clientaddr [<transport-specifier>:]<transport-address>
specifies the source address to be used by command-line applications when sending SNMP requests. See snmpcmd(1) for more information about the format of addresses.

This value is also used by snmpd when generating notifications.

clientaddrUsesPort no
specifies, if clientaddr option contains a port number. Set this option to “yes”, if clientaddr contains a port number and this port should be used for sending outgoing SNMP requests. This option only affects IPv4 client addresses and is ignored for IPv6 client addresses.

clientRecvBuf INTEGER
specifies the desired size of the buffer to be used when receiving responses to SNMP requests. If the OS hard limit is lower than the clientRecvBuf value, then this will be used instead. Some platforms may decide to increase the size of the buffer actually used for internal housekeeping.

This directive will be ignored if the platforms does not support setsockopt().

clientSendBuf INTEGER
is similar to clientRecvBuf, but applies to the size of the buffer used when sending SNMP requests.

noRangeCheck yes
disables the validation of varbind values against the MIB definition for the relevant OID. This is equivalent to the -Ir option.

This directive is primarily relevant to the snmpset command, but will also apply to any application that calls snmp_add_var() with a non-NULL value.

noTokenWarnings
disables warnings about unknown config file tokens.

reverseEncodeBER (1|yes|true|0|no|false)
controls how the encoding of SNMP requests is handled.

The default behaviour is to encode packets starting from the end of the PDU and working backwards. This directive can be used to disable this behaviour, and build the encoded request in the (more obvious) forward direction.

It should not normally be necessary to change this setting, as the encoding is basically the same in either case - but working backwards typically produces a slightly more efficient encoding, and hence a smaller network datagram.

dontLoadHostConfig (1|yes|true|0|no|false)
Specifies whether or not the host-specific configuration files are loaded. Set to “true” to turn off the loading of the host specific configuration files.

retries INTEGER
Specifies the number of retries to be used in the requests.

timeout INTEGER
Specifies the timeout in seconds between retries.

SNMPv1/SNMPv2c SETTINGS

disableSNMPv1 (1|yes|true|0|no|false)

disableSNMPv2c (1|yes|true|0|no|false)
Disables protocol versions at runtime. Incoming and outgoing packets for the protocol will be dropped.

SNMPv3 SETTINGS

disableSNMPv3 (1|yes|true|0|no|false)
Disables protocol versions at runtime. Incoming and outgoing packets for the protocol will be dropped.

defSecurityName STRING
defines the default security name to use for SNMPv3 requests. This can be overridden using the -u option.

defSecurityLevel noAuthNoPriv|authNoPriv|authPriv
defines the default security level to use for SNMPv3 requests. This can be overridden using the -l option.

If not specified, the default value for this token is noAuthNoPriv.

“Note:
authPriv is only available if the software has been compiled to use the OpenSSL libraries.

defPassphrase STRING

defAuthPassphrase STRING

defPrivPassphrase STRING
define the default authentication and privacy pass phrases to use for SNMPv3 requests. These can be overridden using the -A and -X options respectively.

The defPassphrase value will be used for the authentication and/or privacy pass phrases if either of the other directives are not specified.

defAuthType MD5|SHA|SHA-512|SHA-384|SHA-256|SHA-224

defPrivType DES|AES
define the default authentication and privacy protocols to use for SNMPv3 requests. These can be overridden using the -a and -x options respectively.

If not specified, SNMPv3 requests will default to MD5 authentication and DES encryption.

“Note:
If the software has not been compiled to use the OpenSSL libraries, then only MD5 authentication is supported. Neither SHA authentication nor any form of encryption will be available.

defContext STRING
defines the default context to use for SNMPv3 requests. This can be overridden using the -n option.

If not specified, the default value for this token is the default context (i.e. the empty string “”).

defSecurityModel STRING
defines the security model to use for SNMPv3 requests. The default value is “usm” which is the only widely used security model for SNMPv3.

defAuthMasterKey 0xHEXSTRING

defPrivMasterKey 0xHEXSTRING

defAuthLocalizedKey 0xHEXSTRING

defPrivLocalizedKey 0xHEXSTRING
define the (hexadecimal) keys to be used for SNMPv3 secure communications. SNMPv3 keys are frequently derived from a passphrase, as discussed in the defPassphrase section above. However for improved security a truely random key can be generated and used instead (which would normally has better entropy than a password unless it is amazingly long). The directives are equivalent to the short-form command line options -3m, -3M, -3k, and -3K.

Localized keys are master keys which have been converted to a unique key which is only suitable for on particular SNMP engine (agent). The length of the key needs to be appropriate for the authentication or encryption type being used (auth keys: MD5=16 bytes, SHA1=20 bytes; priv keys: DES=16 bytes (8 bytes of which is used as an IV and not a key), and AES=16 bytes).

sshtosnmpsocket PATH
Sets the path of the sshtosnmp socket created by an application (e.g. snmpd) listening for incoming ssh connections through the sshtosnmp unix socket.

sshtosnmpsocketperms MODE [OWNER [GROUP]]
Sets the mode, owner and group of the sshtosnmp socket created by an application (e.g. snmpd) listening for incoming ssh connections through the sshtosnmp unix socket. The socket needs to be read/write privileged for SSH users that are allowed to connect to the SNMP service (VACM access still needs to be granted as well, most likely through the TSM security model).

sshusername NAME
Sets the SSH user name for logging into the remote system.

sshpubkey FILE
Set the public key file to use when connecting to a remote system.

sshprivkey FILE
Set the private key file to use when connecting to a remote system.

SERVER BEHAVIOUR

persistentDir DIRECTORY
defines the directory where snmpd and snmptrapd store persistent configuration settings.

If not specified, the persistent directory defaults to /var/lib/snmp

noPersistentLoad yes

noPersistentSave yes
disable the loading and saving of persistent configuration information.

Note:
This will break SNMPv3 operations (and other behaviour that relies on changes persisting across application restart). Use With Care.

tempFilePattern PATTERN
defines a filename template for creating temporary files, for handling input to and output from external shell commands. Used by the mkstemp() and mktemp() functions.

If not specified, the default pattern is "/tmp/snmpdXXXXXX".

serverRecvBuf INTEGER
specifies the desired size of the buffer to be used when receiving incoming SNMP requests. If the OS hard limit is lower than the serverRecvBuf value, then this will be used instead. Some platforms may decide to increase the size of the buffer actually used for internal housekeeping.

This directive will be ignored if the platforms does not support setsockopt().

serverSendBuf INTEGER
is similar to serverRecvBuf, but applies to the size of the buffer used when sending SNMP responses.

sourceFilterType none|acceptlist|blocklist
specifies whether or not addresses added with sourceFilterAddress are accepted or blocked. The default is none, indicating that incoming packets will not be checked agains the filter list.

sourceFilterAddress ADDRESS
specifies an address to be added to the source address filter list. sourceFilterType configuration determines whether or not addresses are accepted or blocked.

MIB HANDLING

mibdirs DIRLIST
specifies a list of directories to search for MIB files. This operates in the same way as the -M option - see snmpcmd(1) for details. Note that this value can be overridden by the MIBDIRS environment variable, and the -M option.

mibs MIBLIST
specifies a list of MIB modules (not files) that should be loaded. This operates in the same way as the -m option - see snmpcmd(1) for details. Note that this list can be overridden by the MIBS environment variable, and the -m option.

mibfile FILE
specifies a (single) MIB file to load, in addition to the list read from the mibs token (or equivalent configuration). Note that this value can be overridden by the MIBFILES environment variable.

showMibErrors (1|yes|true|0|no|false)
whether to display MIB parsing errors.

commentToEOL (1|yes|true|0|no|false)
whether MIB parsing should be strict about comment termination. Many MIB writers assume that ASN.1 comments extend to the end of the text line, rather than being terminated by the next “–” token. This token can be used to accept such (strictly incorrect) MIBs.
Note that this directive was previous (mis-)named strictCommentTerm, but with the reverse behaviour from that implied by the name. This earlier token is still accepted for backwards compatibility.

mibAllowUnderline (1|yes|true|0|no|false)
whether to allow underline characters in MIB object names and enumeration values. This token can be used to accept such (strictly incorrect) MIBs.

mibWarningLevel INTEGER
the minimum warning level of the warnings printed by the MIB parser.

OUTPUT CONFIGURATION

logTimestamp (1|yes|true|0|no|false)
Whether the commands should log timestamps with their error/message logging or not. Note that output will not look as pretty with timestamps if the source code that is doing the logging does incremental logging of messages that are not line buffered before being passed to the logging routines. This option is only used when file logging is active.

printNumericEnums (1|yes|true|0|no|false)
Equivalent to -Oe.

printNumericOids (1|yes|true|0|no|false)
Equivalent to -On.

dontBreakdownOids (1|yes|true|0|no|false)
Equivalent to -Ob.

escapeQuotes (1|yes|true|0|no|false)
Equivalent to -OE.

quickPrinting (1|yes|true|0|no|false)
Equivalent to -Oq.

printValueOnly (1|yes|true|0|no|false)
Equivalent to -Ov.

dontPrintUnits (1|yes|true|0|no|false)
Equivalent to -OU.

numericTimeticks (1|yes|true|0|no|false)
Equivalent to -Ot.

printHexText (1|yes|true|0|no|false)
Equivalent to -OT.

hexOutputLength integer
Specifies where to break up the output of hexadecimal strings. Set to 0 to disable line breaks. Defaults to 16.

suffixPrinting (0|1|2)
The value 1 is equivalent to -Os and the value 2 is equivalent to -OS.

oidOutputFormat (1|2|3|4|5|6)
Maps -O options as follow: -Os=1, -OS=2, -Of=3, -On=4, -Ou=5. The value 6 has no matching -O option. It suppresses output.

extendedIndex (1|yes|true|0|no|false)
Equivalent to -OX.

noDisplayHint (1|yes|true|0|no|false)
Disables the use of DISPLAY-HINT information when parsing indices and values to set. Equivalent to -Ih.

outputPrecision PRECISION
Uses the PRECISION string to allow modification of the value output format. See snmpcmd(1) for details. Equivalent to -Op (which takes precedence over the config file).

FILES

System-wide configuration files:
/etc/snmp/snmp.conf
/etc/snmp/snmp.local.conf

User-specific configuration settings:
$HOME/.snmp/snmp.conf
$HOME/.snmp/snmp.local.conf

“Destination
/etc/snmp/hosts/HOSTNAME.conf
$HOME/.snmp/hosts/HOSTNAME.conf

234 - Linux cli command proc_key-users

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_key-users and provides detailed information about the command proc_key-users, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_key-users.

NAME 🖥️ proc_key-users 🖥️

users - in-kernel key management

DESCRIPTION

/proc/keys (since Linux 2.6.10)
See keyrings(7).

/proc/key-users (since Linux 2.6.10)
See keyrings(7).

235 - Linux cli command core

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command core and provides detailed information about the command core, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the core.

NAME 🖥️ core 🖥️

core dump file

DESCRIPTION

The default action of certain signals is to cause a process to terminate and produce a core dump file, a file containing an image of the process’s memory at the time of termination. This image can be used in a debugger (e.g., gdb(1)) to inspect the state of the program at the time that it terminated. A list of the signals which cause a process to dump core can be found in signal(7).

A process can set its soft RLIMIT_CORE resource limit to place an upper limit on the size of the core dump file that will be produced if it receives a “core dump” signal; see getrlimit(2) for details.

There are various circumstances in which a core dump file is not produced:

The process does not have permission to write the core file. (By default, the core file is called core or core.pid, where pid is the ID of the process that dumped core, and is created in the current working directory. See below for details on naming.) Writing the core file fails if the directory in which it is to be created is not writable, or if a file with the same name exists and is not writable or is not a regular file (e.g., it is a directory or a symbolic link).
A (writable, regular) file with the same name as would be used for the core dump already exists, but there is more than one hard link to that file.
The filesystem where the core dump file would be created is full; or has run out of inodes; or is mounted read-only; or the user has reached their quota for the filesystem.
The directory in which the core dump file is to be created does not exist.
The RLIMIT_CORE (core file size) or RLIMIT_FSIZE (file size) resource limits for the process are set to zero; see getrlimit(2) and the documentation of the shell’s ulimit command (limit in csh(1)). However, RLIMIT_CORE will be ignored if the system is configured to pipe core dumps to a program.
The binary being executed by the process does not have read permission enabled. (This is a security measure to ensure that an executable whose contents are not readable does not produce a—possibly readable—core dump containing an image of the executable.)
The process is executing a set-user-ID (set-group-ID) program that is owned by a user (group) other than the real user (group) ID of the process, or the process is executing a program that has file capabilities (see capabilities(7)). (However, see the description of the prctl(2) PR_SET_DUMPABLE operation, and the description of the /proc/sys/fs/suid_dumpable file in proc(5).)
/proc/sys/kernel/core_pattern is empty and /proc/sys/kernel/core_uses_pid contains the value 0. (These files are described below.) Note that if /proc/sys/kernel/core_pattern is empty and /proc/sys/kernel/core_uses_pid contains the value 1, core dump files will have names of the form .pid, and such files are hidden unless one uses the ls(1) -a option.
(Since Linux 3.7) The kernel was configured without the CONFIG_COREDUMP option.

In addition, a core dump may exclude part of the address space of the process if the madvise(2) MADV_DONTDUMP flag was employed.

On systems that employ systemd(1) as the init framework, core dumps may instead be placed in a location determined by systemd(1). See below for further details.

Naming of core dump files

By default, a core dump file is named core, but the /proc/sys/kernel/core_pattern file (since Linux 2.6 and 2.4.21) can be set to define a template that is used to name core dump files. The template can contain % specifiers which are substituted by the following values when a core file is created:

%%
A single % character.
%c
Core file size soft resource limit of crashing process (since Linux 2.6.24).
%d
Dump mode—same as value returned by prctl(2) PR_GET_DUMPABLE (since Linux 3.7).
%e
The process or thread’s comm value, which typically is the same as the executable filename (without path prefix, and truncated to a maximum of 15 characters), but may have been modified to be something different; see the discussion of /proc/pid/comm and /proc/pid/task/tid/comm in proc(5).
%E
Pathname of executable, with slashes (’/’) replaced by exclamation marks (’!’) (since Linux 3.0).
%g
Numeric real GID of dumped process.
%h
Hostname (same as nodename returned by uname(2)).
%i
TID of thread that triggered core dump, as seen in the PID namespace in which the thread resides (since Linux 3.18).
%I
TID of thread that triggered core dump, as seen in the initial PID namespace (since Linux 3.18).
%p
PID of dumped process, as seen in the PID namespace in which the process resides.
%P
PID of dumped process, as seen in the initial PID namespace (since Linux 3.12).
%s
Number of signal causing dump.
%t
Time of dump, expressed as seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC).
%u
Numeric real UID of dumped process.

A single % at the end of the template is dropped from the core filename, as is the combination of a % followed by any character other than those listed above. All other characters in the template become a literal part of the core filename. The template may include ‘/’ characters, which are interpreted as delimiters for directory names. The maximum size of the resulting core filename is 128 bytes (64 bytes before Linux 2.6.19). The default value in this file is “core”. For backward compatibility, if /proc/sys/kernel/core_pattern does not include %p and /proc/sys/kernel/core_uses_pid (see below) is nonzero, then .PID will be appended to the core filename.

Paths are interpreted according to the settings that are active for the crashing process. That means the crashing process’s mount namespace (see mount_namespaces(7)), its current working directory (found via getcwd(2)), and its root directory (see chroot(2)).

Since Linux 2.4, Linux has also provided a more primitive method of controlling the name of the core dump file. If the /proc/sys/kernel/core_uses_pid file contains the value 0, then a core dump file is simply named core. If this file contains a nonzero value, then the core dump file includes the process ID in a name of the form core.PID.

Since Linux 3.6, if /proc/sys/fs/suid_dumpable is set to 2 (“suidsafe”), the pattern must be either an absolute pathname (starting with a leading ‘/’ character) or a pipe, as defined below.

Piping core dumps to a program

Since Linux 2.6.19, Linux supports an alternate syntax for the /proc/sys/kernel/core_pattern file. If the first character of this file is a pipe symbol (|), then the remainder of the line is interpreted as the command-line for a user-space program (or script) that is to be executed.

Since Linux 5.3.0, the pipe template is split on spaces into an argument list before the template parameters are expanded. In earlier kernels, the template parameters are expanded first and the resulting string is split on spaces into an argument list. This means that in earlier kernels executable names added by the %e and %E template parameters could get split into multiple arguments. So the core dump handler needs to put the executable names as the last argument and ensure it joins all parts of the executable name using spaces. Executable names with multiple spaces in them are not correctly represented in earlier kernels, meaning that the core dump handler needs to use mechanisms to find the executable name.

Instead of being written to a file, the core dump is given as standard input to the program. Note the following points:

The program must be specified using an absolute pathname (or a pathname relative to the root directory, /), and must immediately follow the ‘|’ character.
The command-line arguments can include any of the % specifiers listed above. For example, to pass the PID of the process that is being dumped, specify %p in an argument.
The process created to run the program runs as user and group root.
Running as root does not confer any exceptional security bypasses. Namely, LSMs (e.g., SELinux) are still active and may prevent the handler from accessing details about the crashed process via */proc/*pid.
The program pathname is interpreted with respect to the initial mount namespace as it is always executed there. It is not affected by the settings (e.g., root directory, mount namespace, current working directory) of the crashing process.
The process runs in the initial namespaces (PID, mount, user, and so on) and not in the namespaces of the crashing process. One can utilize specifiers such as %P to find the right */proc/*pid directory and probe/enter the crashing process’s namespaces if needed.
The process starts with its current working directory as the root directory. If desired, it is possible change to the working directory of the dumping process by employing the value provided by the %P specifier to change to the location of the dumping process via /proc/pid/cwd.
Command-line arguments can be supplied to the program (since Linux 2.6.24), delimited by white space (up to a total line length of 128 bytes).
The RLIMIT_CORE limit is not enforced for core dumps that are piped to a program via this mechanism.

/proc/sys/kernel/core_pipe_limit

When collecting core dumps via a pipe to a user-space program, it can be useful for the collecting program to gather data about the crashing process from that process’s */proc/*pid directory. In order to do this safely, the kernel must wait for the program collecting the core dump to exit, so as not to remove the crashing process’s */proc/*pid files prematurely. This in turn creates the possibility that a misbehaving collecting program can block the reaping of a crashed process by simply never exiting.

Since Linux 2.6.32, the /proc/sys/kernel/core_pipe_limit can be used to defend against this possibility. The value in this file defines how many concurrent crashing processes may be piped to user-space programs in parallel. If this value is exceeded, then those crashing processes above this value are noted in the kernel log and their core dumps are skipped.

A value of 0 in this file is special. It indicates that unlimited processes may be captured in parallel, but that no waiting will take place (i.e., the collecting program is not guaranteed access to /proc/<crashing-PID>). The default value for this file is 0.

Controlling which mappings are written to the core dump

Since Linux 2.6.23, the Linux-specific /proc/pid/coredump_filter file can be used to control which memory segments are written to the core dump file in the event that a core dump is performed for the process with the corresponding process ID.

The value in the file is a bit mask of memory mapping types (see mmap(2)). If a bit is set in the mask, then memory mappings of the corresponding type are dumped; otherwise they are not dumped. The bits in this file have the following meanings:

bit 0
Dump anonymous private mappings.
bit 1
Dump anonymous shared mappings.
bit 2
Dump file-backed private mappings.
bit 3
Dump file-backed shared mappings.
bit 4 (since Linux 2.6.24)
Dump ELF headers.
bit 5 (since Linux 2.6.28)
Dump private huge pages.
bit 6 (since Linux 2.6.28)
Dump shared huge pages.
bit 7 (since Linux 4.4)
Dump private DAX pages.
bit 8 (since Linux 4.4)
Dump shared DAX pages.

By default, the following bits are set: 0, 1, 4 (if the CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS kernel configuration option is enabled), and 5. This default can be modified at boot time using the coredump_filter boot option.

The value of this file is displayed in hexadecimal. (The default value is thus displayed as 33.)

Memory-mapped I/O pages such as frame buffer are never dumped, and virtual DSO (vdso(7)) pages are always dumped, regardless of the coredump_filter value.

A child process created via fork(2) inherits its parent’s coredump_filter value; the coredump_filter value is preserved across an execve(2).

It can be useful to set coredump_filter in the parent shell before running a program, for example:

$ echo 0x7 > /proc/self/coredump_filter
$ ./some_program

This file is provided only if the kernel was built with the CONFIG_ELF_CORE configuration option.

Core dumps and systemd

On systems using the systemd(1) init framework, core dumps may be placed in a location determined by systemd(1). To do this, systemd(1) employs the core_pattern feature that allows piping core dumps to a program. One can verify this by checking whether core dumps are being piped to the systemd-coredump(8) program:

$ cat /proc/sys/kernel/core_pattern
|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %e

In this case, core dumps will be placed in the location configured for systemd-coredump(8), typically as lz4(1) compressed files in the directory /var/lib/systemd/coredump/. One can list the core dumps that have been recorded by systemd-coredump(8) using coredumpctl(1):

$ coredumpctl list | tail -5
Wed 2017-10-11 22:25:30 CEST  2748 1000 1000 3 present  /usr/bin/sleep
Thu 2017-10-12 06:29:10 CEST  2716 1000 1000 3 present  /usr/bin/sleep
Thu 2017-10-12 06:30:50 CEST  2767 1000 1000 3 present  /usr/bin/sleep
Thu 2017-10-12 06:37:40 CEST  2918 1000 1000 3 present  /usr/bin/cat
Thu 2017-10-12 08:13:07 CEST  2955 1000 1000 3 present  /usr/bin/cat

The information shown for each core dump includes the date and time of the dump, the PID, UID, and GID of the dumping process, the signal number that caused the core dump, and the pathname of the executable that was being run by the dumped process. Various options to coredumpctl(1) allow a specified coredump file to be pulled from the systemd(1) location into a specified file. For example, to extract the core dump for PID 2955 shown above to a file named core in the current directory, one could use:

$ coredumpctl dump 2955 -o core

For more extensive details, see the coredumpctl(1) manual page.

To (persistently) disable the systemd(1) mechanism that archives core dumps, restoring to something more like traditional Linux behavior, one can set an override for the systemd(1) mechanism, using something like:

# echo "kernel.core_pattern=core.%p" > \
               /etc/sysctl.d/50-coredump.conf
# /lib/systemd/systemd-sysctl

It is also possible to temporarily (i.e., until the next reboot) change the core_pattern setting using a command such as the following (which causes the names of core dump files to include the executable name as well as the number of the signal which triggered the core dump):

# sysctl -w kernel.core_pattern="%e-%s.core"

NOTES

The gdb(1) gcore command can be used to obtain a core dump of a running process.

In Linux versions up to and including 2.6.27, if a multithreaded process (or, more precisely, a process that shares its memory with another process by being created with the CLONE_VM flag of clone(2)) dumps core, then the process ID is always appended to the core filename, unless the process ID was already included elsewhere in the filename via a %p specification in /proc/sys/kernel/core_pattern. (This is primarily useful when employing the obsolete LinuxThreads implementation, where each thread of a process has a different PID.)

EXAMPLES

The program below can be used to demonstrate the use of the pipe syntax in the /proc/sys/kernel/core_pattern file. The following shell session demonstrates the use of this program (compiled to create an executable named core_pattern_pipe_test):

$ cc -o core_pattern_pipe_test core_pattern_pipe_test.c
$ su
Password:
# echo "|$PWD/core_pattern_pipe_test %p UID=%u GID=%g sig=%s" > \
 /proc/sys/kernel/core_pattern
# exit
$ sleep 100
^\ # type control-backslash
Quit (core dumped)
$ cat core.info
argc=5
argc[0]=</home/mtk/core_pattern_pipe_test>
argc[1]=<20575>
argc[2]=<UID=1000>
argc[3]=<GID=100>
argc[4]=<sig=3>
Total bytes in core dump: 282624

Program source

/* core_pattern_pipe_test.c */
#define _GNU_SOURCE
#include <sys/stat.h>
#include <fcntl.h>
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define BUF_SIZE 1024
int
main(int argc, char *argv[])
{
    ssize_t nread, tot;
    char buf[BUF_SIZE];
    FILE *fp;
    char cwd[PATH_MAX];
    /* Change our current working directory to that of the
       crashing process. */
    snprintf(cwd, PATH_MAX, "/proc/%s/cwd", argv[1]);
    chdir(cwd);
    /* Write output to file "core.info" in that directory. */
    fp = fopen("core.info", "w+");
    if (fp == NULL)
        exit(EXIT_FAILURE);
    /* Display command-line arguments given to core_pattern
       pipe program. */
    fprintf(fp, "argc=%d

“, argc); for (size_t j = 0; j < argc; j++) fprintf(fp, “argc[%zu]=<%s> “, j, argv[j]); /* Count bytes in standard input (the core dump). */ tot = 0; while ((nread = read(STDIN_FILENO, buf, BUF_SIZE)) > 0) tot += nread; fprintf(fp, “Total bytes in core dump: %zd “, tot); fclose(fp); exit(EXIT_SUCCESS); }

236 - Linux cli command deb-postinst

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command deb-postinst and provides detailed information about the command deb-postinst, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the deb-postinst.

NAME 🖥️ deb-postinst 🖥️

postinst - package post-installation maintainer script

SYNOPSIS

DEBIAN/postinst

DESCRIPTION

A package can perform several post-installation actions via maintainer scripts, by including an executable postinst file in its control archive (i.e. DEBIAN/postinst during package creation).

The script can be called in the following ways:

postinst configure old-version
After the package was installed.

postinst triggered “trigger-name…”
After the package was triggered. The list of space-separated trigger-names is passed as the second argument.

old-postinst abort-upgrade new-version
If prerm fails during upgrade or fails on failed-upgrade.

old-postinst abort-remove
If prerm fails during remove.

postinst abort-deconfigure in-favour new-package new-version

[ removing old-package old-version ]

If prerm fails during deconfigure in-favour of a package.

postinst abort-remove in-favour new-package new-version
If prerm fails during remove in-favour for replacement due to conflict.

237 - Linux cli command org.bluez.MediaControl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.MediaControl and provides detailed information about the command org.bluez.MediaControl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.MediaControl.

NAME 🖥️ org.bluez.MediaControl 🖥️

BlueZ D-Bus MediaControl API documentation

INTERFACE

Service
org.bluez
Interface
org.bluez.MediaControl1
Object path
[variable prefix]/{hci0,hci1,…}/dev_XX_XX_XX_XX_XX_XX

Methods

void Play() [Deprecated]

Resume playback.

void Pause() [Deprecated]

Pause playback.

void Stop() [Deprecated]

Stop playback.

void Next() [Deprecated]

Next item.

void Previous() [Deprecated]

Previous item.

void VolumeUp() [Deprecated]

Adjust remote volume one step up

void VolumeDown() [Deprecated]

Adjust remote volume one step down

void FastForward() [Deprecated]

Fast forward playback, this action is only stopped when another method in this interface is called.

void Rewind() [Deprecated]

Rewind playback, this action is only stopped when another method in this interface is called.

Properties

boolean Connected [readonly]

object Player [readonly, optional]

Addressed Player object path.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

238 - Linux cli command hosts_access

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command hosts_access and provides detailed information about the command hosts_access, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the hosts_access.

NAME 🖥️ hosts_access 🖥️

format of host access control files

DESCRIPTION

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

The extended version of the access control language is described in the hosts_options(5) document. Note that this language supersedes the meaning of shell_command as documented below.

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

ACCESS CONTROL FILES

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

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

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

ACCESS CONTROL RULES

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

A newline character is ignored when it is preceded by a backslash character. This permits you to break up long lines so that they are easier to edit.
Blank lines or lines that begin with a `#’ character are ignored. This permits you to insert comments and whitespace so that the tables are easier to read.
All other lines should satisfy the following format, things between [] being optional:

daemon_list : client_list [ : shell_command ]

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

client_list is a list of one or more host names, host addresses, patterns or wildcards (see below) that will be matched against the client host name or address.

The more complex forms daemon@host and user@host are explained in the sections on server endpoint patterns and on client username lookups, respectively.

List elements should be separated by blanks and/or commas.

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

PATTERNS

The access control language implements the following patterns:

A string that begins with a `.’ character. A host name is matched if the last components of its name match the specified pattern. For example, the pattern `.tue.nl’ matches the host name `wzv.win.tue.nl'.
A string that ends with a `.’ character. A host address is matched if its first numeric fields match the given string. For example, the pattern `131.155.’ matches the address of (almost) every host on the Eindhoven University network (131.155.x.x).
A string that begins with an `@’ character is treated as an NIS (formerly YP) netgroup name. A host name is matched if it is a host member of the specified netgroup. Netgroup matches are not supported for daemon process names or for client user names. On Debian systems, support for NIS netgroups has been disabled since package version 7.6.q-33.
An expression of the form `n.n.n.n/m.m.m.m’ is interpreted as a `net/mask’ pair. An IPv4 host address is matched if `net’ is equal to the bitwise AND of the address and the `mask’. For example, the net/mask pattern `131.155.72.0/255.255.254.0’ matches every address in the range `131.155.72.0’ through `131.155.73.255’. `255.255.255.255’ is not a valid mask value, so a single host can be matched just by its IP.
An expression of the form `n.n.n.n/mm’ is interpreted as a `net/masklength’ pair, where `mm’ is the number of consecutive `1’ bits in the netmask applied to the `n.n.n.n’ address.
An expression of the form `[n:n:n:n:n:n:n:n]/m’ is interpreted as a `[net]/prefixlen’ pair. An IPv6 host address is matched if `prefixlen’ bits of `net’ is equal to the `prefixlen’ bits of the address. For example, the [net]/prefixlen pattern `[3ffe:505:2:1::]/64’ matches every address in the range `3ffe:505:2:1::’ through `3ffe:505:2:1:ffff:ffff:ffff:ffff'.
A string that begins with a `/’ character is treated as a file name. A host name or address is matched if it matches any host name or address pattern listed in the named file. The file format is zero or more lines with zero or more host name or address patterns separated by whitespace. A file name pattern can be used anywhere a host name or address pattern can be used.
Wildcards `*’ and `?’ can be used to match hostnames or IP addresses. This method of matching cannot be used in conjunction with `net/mask’ matching, hostname matching beginning with `.’ or IP address matching ending with `.'.

WILDCARDS

The access control language supports explicit wildcards:

ALL
The universal wildcard, always matches.

LOCAL
Matches any host whose name does not contain a dot character.

UNKNOWN
Matches any user whose name is unknown, and matches any host whose name or address are unknown. This pattern should be used with care: host names may be unavailable due to temporary name server problems. A network address will be unavailable when the software cannot figure out what type of network it is talking to.

KNOWN
Matches any user whose name is known, and matches any host whose name and address are known. This pattern should be used with care: host names may be unavailable due to temporary name server problems. A network address will be unavailable when the software cannot figure out what type of network it is talking to.

PARANOID
Matches any host whose name does not match its address. When tcpd is built with -DPARANOID (default mode), it drops requests from such clients even before looking at the access control tables. Build without -DPARANOID when you want more control over such requests.

OPERATORS

EXCEPT
Intended use is of the form: `list_1 EXCEPT list_2’; this construct matches anything that matches list_1 unless it matches list_2. The EXCEPT operator can be used in daemon_lists and in client_lists. The EXCEPT operator can be nested: if the control language would permit the use of parentheses, `a EXCEPT b EXCEPT c’ would parse as `(a EXCEPT (b EXCEPT c))'.

SHELL COMMANDS

If the first-matched access control rule contains a shell command, that command is subjected to %<letter> substitutions (see next section). The result is executed by a /bin/sh child process with standard input, output and error connected to /dev/null. Specify an `&’ at the end of the command if you do not want to wait until it has completed.

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

The hosts_options(5) document describes an alternative language that uses the shell command field in a different and incompatible way.

% EXPANSIONS

The following expansions are available within shell commands:

%a (%A)
The client (server) host address.

%c
Client information: user@host, user@address, a host name, or just an address, depending on how much information is available.

%d
The daemon process name (argv[0] value).

%h (%H)
The client (server) host name or address, if the host name is unavailable.

%n (%N)
The client (server) host name (or “unknown” or “paranoid”).

%r (%R)
The clients (servers) port number (or “0”).

%p
The daemon process id.

%s
Server information: daemon@host, daemon@address, or just a daemon name, depending on how much information is available.

%u
The client user name (or “unknown”).

%%
Expands to a single `%’ character.

Characters in % expansions that may confuse the shell are replaced by underscores.

SERVER ENDPOINT PATTERNS

In order to distinguish clients by the network address that they connect to, use patterns of the form:

process_name@host_pattern : client_list …

Patterns like these can be used when the machine has different internet addresses with different internet hostnames. Service providers can use this facility to offer FTP, GOPHER or WWW archives with internet names that may even belong to different organizations. See also the `twist’ option in the hosts_options(5) document. Some systems (Solaris, FreeBSD) can have more than one internet address on one physical interface; with other systems you may have to resort to SLIP or PPP pseudo interfaces that live in a dedicated network address space.

The host_pattern obeys the same syntax rules as host names and addresses in client_list context. Usually, server endpoint information is available only with connection-oriented services.

CLIENT USERNAME LOOKUP

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

daemon_list : … user_pattern@host_pattern …

The daemon wrappers can be configured at compile time to perform rule-driven username lookups (default) or to always interrogate the client host. In the case of rule-driven username lookups, the above rule would cause username lookup only when both the daemon_list and the host_pattern match.

A user pattern has the same syntax as a daemon process pattern, so the same wildcards apply (netgroup membership is not supported). One should not get carried away with username lookups, though.

The client username information cannot be trusted when it is needed most, i.e. when the client system has been compromised. In general, ALL and (UN)KNOWN are the only user name patterns that make sense.
Username lookups are possible only with TCP-based services, and only when the client host runs a suitable daemon; in all other cases the result is “unknown”.
A well-known UNIX kernel bug may cause loss of service when username lookups are blocked by a firewall. The wrapper README document describes a procedure to find out if your kernel has this bug.
Username lookups may cause noticeable delays for non-UNIX users. The default timeout for username lookups is 10 seconds: too short to cope with slow networks, but long enough to irritate PC users.

Selective username lookups can alleviate the last problem. For example, a rule like:

daemon_list : @pcnetgroup ALL@ALL

would match members of the pc netgroup without doing username lookups, but would perform username lookups with all other systems.

DETECTING ADDRESS SPOOFING ATTACKS

A flaw in the sequence number generator of many TCP/IP implementations allows intruders to easily impersonate trusted hosts and to break in via, for example, the remote shell service. The IDENT (RFC931 etc.) service can be used to detect such and other host address spoofing attacks.

Before accepting a client request, the wrappers can use the IDENT service to find out that the client did not send the request at all. When the client host provides IDENT service, a negative IDENT lookup result (the client matches `UNKNOWN@host’) is strong evidence of a host spoofing attack.

A positive IDENT lookup result (the client matches `KNOWN@host’) is less trustworthy. It is possible for an intruder to spoof both the client connection and the IDENT lookup, although doing so is much harder than spoofing just a client connection. It may also be that the client’s IDENT server is lying.

Note: IDENT lookups don’t work with UDP services.

EXAMPLES

The language is flexible enough that different types of access control policy can be expressed with a minimum of fuss. Although the language uses two access control tables, the most common policies can be implemented with one of the tables being trivial or even empty.

When reading the examples below it is important to realize that the allow table is scanned before the deny table, that the search terminates when a match is found, and that access is granted when no match is found at all.

The examples use host and domain names. They can be improved by including address and/or network/netmask information, to reduce the impact of temporary name server lookup failures.

MOSTLY CLOSED

In this case, access is denied by default. Only explicitly authorized hosts are permitted access.

The default policy (no access) is implemented with a trivial deny file:

/etc/hosts.deny:

ALL: ALL

This denies all service to all hosts, unless they are permitted access by entries in the allow file.

The explicitly authorized hosts are listed in the allow file. For example:

/etc/hosts.allow:

ALL: LOCAL @some_netgroup
ALL: .foobar.edu EXCEPT terminalserver.foobar.edu

The first rule permits access from hosts in the local domain (no `.’ in the host name) and from members of the some_netgroup netgroup. The second rule permits access from all hosts in the foobar.edu domain (notice the leading dot), with the exception of terminalserver.foobar.edu.

MOSTLY OPEN

Here, access is granted by default; only explicitly specified hosts are refused service.

The default policy (access granted) makes the allow file redundant so that it can be omitted. The explicitly non-authorized hosts are listed in the deny file. For example:

/etc/hosts.deny:

ALL: some.host.name, .some.domain
ALL EXCEPT in.fingerd: other.host.name, .other.domain

The first rule denies some hosts and domains all services; the second rule still permits finger requests from other hosts and domains.

BOOBY TRAPS

The next example permits tftp requests from hosts in the local domain (notice the leading dot). Requests from any other hosts are denied. Instead of the requested file, a finger probe is sent to the offending host. The result is mailed to the superuser.

/etc/hosts.allow:

in.tftpd: LOCAL, .my.domain

/etc/hosts.deny:
in.tftpd: ALL: (/usr/sbin/safe_finger -l @%h | \
	/usr/bin/mail -s %d-%h root) &

The safe_finger command comes with the tcpd wrapper and should be installed in a suitable place. It limits possible damage from data sent by the remote finger server. It gives better protection than the standard finger command.

The expansion of the %h (client host) and %d (service name) sequences is described in the section on shell commands.

Warning: do not booby-trap your finger daemon, unless you are prepared for infinite finger loops.

On network firewall systems this trick can be carried even further. The typical network firewall only provides a limited set of services to the outer world. All other services can be “bugged” just like the above tftp example. The result is an excellent early-warning system.

DIAGNOSTICS

An error is reported when a syntax error is found in a host access control rule; when the length of an access control rule exceeds the capacity of an internal buffer; when an access control rule is not terminated by a newline character; when the result of %<letter> expansion would overflow an internal buffer; when a system call fails that shouldn’t. All problems are reported via the syslog daemon.

FILES

/etc/hosts.allow, (daemon,client) pairs that are granted access.
/etc/hosts.deny, (daemon,client) pairs that are denied access.

BUGS

If a name server lookup times out, the host name will not be available to the access control software, even though the host is registered.

Domain name server lookups are case insensitive; NIS (formerly YP) netgroup lookups are case sensitive.

AUTHOR

Wietse Venema ([email protected])
Department of Mathematics and Computing Science
Eindhoven University of Technology
Den Dolech 2, P.O. Box 513, 
5600 MB Eindhoven, The Netherlands

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

239 - Linux cli command issue

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command issue and provides detailed information about the command issue, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the issue.

NAME 🖥️ issue 🖥️

prelogin message and identification file

DESCRIPTION

/etc/issue is a text file which contains a message or system identification to be printed before the login prompt. It may contain various **@**char and ****char sequences, if supported by the getty-type program employed on the system.

FILES

/etc/issue

240 - Linux cli command veritytab

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command veritytab and provides detailed information about the command veritytab, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the veritytab.

NAME 🖥️ veritytab 🖥️

Configuration for verity block devices

SYNOPSIS

/etc/veritytab

DESCRIPTION

The /etc/veritytab file describes verity protected block devices that are set up during system boot.

Empty lines and lines starting with the “#” character are ignored. Each of the remaining lines describes one verity protected block device. Fields are delimited by white space.

Each line is in the form

volume-name data-device hash-device roothash [options]

The first four fields are mandatory, the remaining one is optional.

The first field contains the name of the resulting verity volume; its block device is set up below /dev/mapper/.

The second field contains a path to the underlying block data device, or a specification of a block device via UUID= followed by the UUID.

The third field contains a path to the underlying block hash device, or a specification of a block device via UUID= followed by the UUID.

The fourth field is the roothash in hexadecimal.

The fifth field, if present, is a comma-delimited list of options. The following options are recognized:

**superblock=**BOOL

Use dm-verity with or without permanent on-disk superblock.
Added in version 254.

**format=**NUMBER

Specifies the hash version type. Format type “0” is original Chrome OS version. Format type “1” is modern version.
Added in version 254.

**data-block-size=**BYTES

Used block size for the data device. (Note kernel supports only page-size as maximum here; Multiples of 512 bytes.)
Added in version 254.

**hash-block-size=**BYTES

Used block size for the hash device. (Note kernel supports only page-size as maximum here; Multiples of 512 bytes.)
Added in version 254.

**data-blocks=**BLOCKS

Number of blocks of data device used in verification. If not specified, the whole device is used.
Added in version 254.

**hash-offset=**BYTES

Offset of hash area/superblock on “hash-device”. (Multiples of 512 bytes.)
Added in version 254.

**salt=**HEX

Salt used for format or verification. Format is a hexadecimal string; 256 bytes long maximum; “-” is the special value for empty.
Added in version 254.

**uuid=**UUID

Use the provided UUID instead of generating new one. The UUID must be provided in standard UUID format, e.g. “12345678-1234-1234-1234-123456789abc”.
Added in version 254.

ignore-corruption, restart-on-corruption, panic-on-corruption

Defines what to do if a data verity problem is detected (data corruption). Without these options kernel fails the IO operation with I/O error. With –ignore-corruption option the corruption is only logged. With –restart-on-corruption or –panic-on-corruption the kernel is restarted (panicked) immediately. (You have to provide way how to avoid restart loops.)
Added in version 248.

ignore-zero-blocks

Instruct kernel to not verify blocks that are expected to contain zeroes and always directly return zeroes instead.
Warning
Use this option only in very specific cases. This option is available since Linux kernel version 4.5.
Added in version 248.

check-at-most-once

Instruct kernel to verify blocks only the first time they are read from the data device, rather than every time.
Warning
It provides a reduced level of security because only offline tampering of the data devices content will be detected, not online tampering. This option is available since Linux kernel version 4.17.
Added in version 248.

**hash=**HASH

Hash algorithm for dm-verity. This should be the name of the algorithm, like “sha1”. For default see veritysetup –help.
Added in version 254.

**fec-device=**PATH

Use forward error correction (FEC) to recover from corruption if hash verification fails. Use encoding data from the specified device. The fec device argument can be block device or file image. If fec device path doesnt exist, it will be created as file. Note: block sizes for data and hash devices must match. Also, if the verity data_device is encrypted the fec_device should be too.
Added in version 254.

**fec-offset=**BYTES

This is the offset, in bytes, from the start of the FEC device to the beginning of the encoding data. (Aligned on 512 bytes.)
Added in version 254.

**fec-roots=**NUM

Number of generator roots. This equals to the number of parity bytes in the encoding data. In RS(M, N) encoding, the number of roots is M-N. M is 255 and M-N is between 2 and 24 (including).
Added in version 254.

**root-hash-signature=PATH|base64:**HEX

A base64 string encoding the root hash signature prefixed by “base64:” or a path to roothash signature file used to verify the root hash (in kernel). This feature requires Linux kernel version 5.4 or more recent.
Added in version 248.

_netdev

Marks this veritysetup device as requiring network. It will be started after the network is available, similarly to systemd.mount(5) units marked with _netdev. The service unit to set up this device will be ordered between remote-fs-pre.target and remote-veritysetup.target, instead of veritysetup-pre.target and veritysetup.target.
Hint: if this device is used for a mount point that is specified in fstab(5), the _netdev option should also be used for the mount point. Otherwise, a dependency loop might be created where the mount point will be pulled in by local-fs.target, while the service to configure the network is usually only started after the local file system has been mounted.
Added in version 248.

noauto

This device will not be added to veritysetup.target. This means that it will not be automatically enabled on boot, unless something else pulls it in. In particular, if the device is used for a mount point, itll be enabled automatically during boot, unless the mount point itself is also disabled with noauto.
Added in version 248.

nofail

This device will not be a hard dependency of veritysetup.target. Itll still be pulled in and started, but the system will not wait for the device to show up and be enabled, and boot will not fail if this is unsuccessful. Note that other units that depend on the enabled device may still fail. In particular, if the device is used for a mount point, the mount point itself also needs to have the nofail option, or the boot will fail if the device is not enabled successfully.
Added in version 248.

x-initrd.attach

Setup this verity protected block device in the initrd, similarly to systemd.mount(5) units marked with x-initrd.mount.
Although its not necessary to mark the mount entry for the root file system with x-initrd.mount, x-initrd.attach is still recommended with the verity protected block device containing the root file system as otherwise systemd will attempt to detach the device during the regular system shutdown while its still in use. With this option the device will still be detached but later after the root file system is unmounted.
All other verity protected block devices that contain file systems mounted in the initrd should use this option.
Added in version 248.

At early boot and when the system manager configuration is reloaded, this file is translated into native systemd units by systemd-veritysetup-generator(8).

EXAMPLES

Example 1. /etc/veritytab example

Set up two verity protected block devices. One using device blocks, another using files.

usr PARTUUID=783e45ae-7aa3-484a-beef-a80ff9c19cbb PARTUUID=21dc1dfe-4c33-8b48-98a9-918a22eb3e37 36e3f740ad502e2c25e2a23d9c7c17bf0fdad2300b7580842d4b7ec1fb0fa263 auto data /etc/data /etc/hash a5ee4b42f70ae1f46a08a7c92c2e0a20672ad2f514792730f5d49d7606ab8fdf auto

241 - Linux cli command hostname

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command hostname and provides detailed information about the command hostname, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the hostname.

NAME 🖥️ hostname 🖥️

Local hostname configuration file

SYNOPSIS

/etc/hostname

DESCRIPTION

The /etc/hostname file configures the name of the local system. Unless overridden as described in the next section, systemd(1) will set this hostname during boot using the sethostname(2) system call.

The file should contain a single newline-terminated hostname string. Comments (lines starting with a “#”) are ignored. The hostname should be composed of up to 64 7-bit ASCII lower-case alphanumeric characters or hyphens forming a valid DNS domain name. It is recommended that this name contains only a single label, i.e. without any dots. Invalid characters will be filtered out in an attempt to make the name valid, but obviously it is recommended to use a valid name and not rely on this filtering.

You may use hostnamectl(1) to change the value of this file during runtime from the command line. Use systemd-firstboot(1) to initialize it on mounted (but not booted) system images.

HOSTNAME SEMANTICS

systemd(1) and the associated tools will obtain the hostname in the following ways:

·
If the kernel command line parameter systemd.hostname= specifies a valid hostname, systemd(1) will use it to set the hostname during early boot, see kernel-command-line(7),

·
Otherwise, the “static” hostname specified by /etc/hostname as described above will be used.

·
Otherwise, a transient hostname may be set during runtime, for example based on information in a DHCP lease, see systemd-hostnamed.service(8). Both NetworkManager[1] and systemd-networkd.service(8) allow this. Note that systemd-hostnamed.service(8) gives higher priority to the static hostname, so the transient hostname will only be used if the static hostname is not configured.

·
Otherwise, a fallback hostname configured at compilation time will be used (“localhost”).

Effectively, the static hostname has higher priority than a transient hostname, which has higher priority than the fallback hostname. Transient hostnames are equivalent, so setting a new transient hostname causes the previous transient hostname to be forgotten. The hostname specified on the kernel command line is like a transient hostname, with the exception that it has higher priority when the machine boots. Also note that those are the semantics implemented by systemd tools, but other programs may also set the hostname.

HISTORY

The simple configuration file format of /etc/hostname originates from Debian GNU/Linux.

NOTES

NetworkManager

https://developer.gnome.org/NetworkManager/stable/

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

242 - Linux cli command proc_ioports

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_ioports and provides detailed information about the command proc_ioports, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_ioports.

NAME 🖥️ proc_ioports 🖥️

I/O port regions

DESCRIPTION

/proc/ioports
This is a list of currently registered Input-Output port regions that are in use.

243 - Linux cli command exim4_host_local_deny_exceptions

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command exim4_host_local_deny_exceptions and provides detailed information about the command exim4_host_local_deny_exceptions, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the exim4_host_local_deny_exceptions.

NAME 🖥️ exim4_host_local_deny_exceptions 🖥️

config_files - Files in use by the Debian exim4 packages

SYNOPSIS

DESCRIPTION

This manual page describes the files that are in use by the Debian exim4 packages and which are not part of an exim installation done from source.

/etc/aliases

You should at least set up an alias for postmaster in the /etc/aliases file.

/etc/email-addresses

is used to rewrite the email addresses of users. This is particularly useful for users who use their ISP’s domain for email.

The file should contain lines of the form

user: [email protected]
otheruser: [email protected]

/etc/exim4/local_host_blacklist

In the blacklist, the trick is to read a line break as “or” if it follows a positive item, and as “and” if it follows a negative item.

For example, a /etc/exim4/local_host_blacklist

192.168.10.0/24
!172.16.10.128/26
172.16.10.0/24
10.0.0.0/8

Exim just evaluates left to right (or up-down in the file listing context), so you don’t get the same kind of operator binding as in a programming language.

/etc/exim4/host_local_deny_exceptions

/etc/exim4/local_sender_blacklist

In the blacklist, the trick is to read a line break as “or” if it follows a positive item, and as “and” if it follows a negative item.

For example, a /etc/exim4/local_sender_blacklist

domain1.example
[email protected]
domain2.example
domain3.example

Exim just evaluates left to right (or up-down in the file listing context), so you don’t get the same kind of operator binding as in a programming language.

/etc/exim4/sender_local_deny_exceptions

/etc/exim4/local_sender_callout

/etc/exim4/local_rcpt_callout

/etc/exim4/local_domain_dnsbl_whitelist

/etc/exim4/hubbed_hosts

The file should contain key-value pairs of domain pattern and route data of the form

domain: host-list options
dict.ref.example: mail-1.ref.example:mail-2.ref.example
foo.example: internal.mail.example.com
bar.example: 192.168.183.3

which will cause mail for foo.example to be sent to the host internal.mail.example (IP address derived from A record only), and mail to bar.example to be sent to 192.168.183.3.

See spec.txt chapter 20.3 through 20.7 for a more detailed explanation of host list format and available options.

/etc/exim4/passwd

contains account and password data for SMTP authentication when the local exim is SMTP server and clients authenticate to the local exim.

The file should contain lines of the form

username:crypted-password:clear-password

clear-password is only necessary if you want to offer CRAM-MD5 authentication. If you don’t plan on doing so, the third column can be omitted completely.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim 640.

/etc/exim4/passwd.client

contains account and password data for SMTP authentication when exim is authenticating as a client to some remote server.

The file should contain lines of the form

target.mail.server.example:login-user-name:password

This goes inevitably wrong if the host name of the mail server is a CNAME (a DNS alias), or the reverse lookup does not fit the forward one.

password is your SMTP password in clear text. If you do not know about your SMTP password, you can try using your POP3 password as a first guess.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim 640.

/etc/exim4/exim.crt

/etc/exim4/exim.key

/etc/mailname

The “mail name” of the system. See Debian policy Chapter Customized programs and exim4-base’s README.Debian for further details.

BUGS

Plenty. Please report them through the Debian BTS

This manual page needs a major re-work. If somebody knows better groff than us and has more experience in writing manual pages, any patches would be greatly appreciated.

NOTES

Unresolvable items in host lists

Adding or keeping items in the abovementioned host lists which are not resolvable by DNS has severe consequences.

notresolvable.example.com:rejectme.example.com

Starting the list with the special pattern +ignore_unknown as a safeguard against this behavior is strongly recommended if hostnames are used in hostlists.

AUTHOR

Marc Haber <[email protected]> with help from Ross Boylan.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

244 - Linux cli command proc_pid_smaps

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_smaps and provides detailed information about the command proc_pid_smaps, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_smaps.

NAME 🖥️ proc_pid_smaps 🖥️

XXX: What does ’s’ in “smaps” stand for?

DESCRIPTION

/proc/pid/smaps (since Linux 2.6.14)
This file shows memory consumption for each of the process’s mappings. (The pmap(1) command displays similar information, in a form that may be easier for parsing.) For each mapping there is a series of lines such as the following:

00400000-0048a000 r-xp 00000000 fd:03 960637       /bin/bash
Size:                552 kB
Rss:                 460 kB
Pss:                 100 kB
Shared_Clean:        452 kB
Shared_Dirty:          0 kB
Private_Clean:         8 kB
Private_Dirty:         0 kB
Referenced:          460 kB
Anonymous:             0 kB
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Locked:                0 kB
ProtectionKey:         0
VmFlags: rd ex mr mw me dw

The first of these lines shows the same information as is displayed for the mapping in /proc/pid/maps. The following lines show the size of the mapping, the amount of the mapping that is currently resident in RAM (“Rss”), the process’s proportional share of this mapping (“Pss”), the number of clean and dirty shared pages in the mapping, and the number of clean and dirty private pages in the mapping. “Referenced” indicates the amount of memory currently marked as referenced or accessed. “Anonymous” shows the amount of memory that does not belong to any file. “Swap” shows how much would-be-anonymous memory is also used, but out on swap.

The “KernelPageSize” line (available since Linux 2.6.29) is the page size used by the kernel to back the virtual memory area. This matches the size used by the MMU in the majority of cases. However, one counter-example occurs on PPC64 kernels whereby a kernel using 64 kB as a base page size may still use 4 kB pages for the MMU on older processors. To distinguish the two attributes, the “MMUPageSize” line (also available since Linux 2.6.29) reports the page size used by the MMU.

The “Locked” indicates whether the mapping is locked in memory or not.

The “ProtectionKey” line (available since Linux 4.9, on x86 only) contains the memory protection key (see pkeys(7)) associated with the virtual memory area. This entry is present only if the kernel was built with the CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS configuration option (since Linux 4.6).

The “VmFlags” line (available since Linux 3.8) represents the kernel flags associated with the virtual memory area, encoded using the following two-letter codes:

rd	-	readable
wr	-	writable
ex	-	executable
sh	-	shared
mr	-	may read
mw	-	may write
me	-	may execute
ms	-	may share
gd	-	stack segment grows down
pf	-	pure PFN range
dw	-	disabled write to the mapped file
lo	-	pages are locked in memory
io	-	memory mapped I/O area
sr	-	sequential read advise provided
rr	-	random read advise provided
dc	-	do not copy area on fork
de	-	do not expand area on remapping
ac	-	area is accountable
nr	-	swap space is not reserved for the area
ht	-	area uses huge tlb pages
sf	-	perform synchronous page faults (since Linux 4.15)
nl	-	non-linear mapping (removed in Linux 4.0)
ar	-	architecture specific flag
wf	-	wipe on fork (since Linux 4.14)
dd	-	do not include area into core dump
sd	-	soft-dirty flag (since Linux 3.13)
mm	-	mixed map area
hg	-	huge page advise flag
nh	-	no-huge page advise flag
mg	-	mergeable advise flag
um	-	userfaultfd missing pages tracking (since Linux 4.3)
uw	-	userfaultfd wprotect pages tracking (since Linux 4.3)

The /proc/pid/smaps file is present only if the CONFIG_PROC_PAGE_MONITOR kernel configuration option is enabled.

245 - Linux cli command proc_pid_exe

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_exe and provides detailed information about the command proc_pid_exe, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_exe.

NAME 🖥️ proc_pid_exe 🖥️

symbolic link to program pathname

DESCRIPTION

/proc/pid/exe
Under Linux 2.2 and later, this file is a symbolic link containing the actual pathname of the executed command. This symbolic link can be dereferenced normally; attempting to open it will open the executable. You can even type /proc/pid/exe to run another copy of the same executable that is being run by process pid. If the pathname has been unlinked, the symbolic link will contain the string ’ (deleted)’ appended to the original pathname. In a multithreaded process, the contents of this symbolic link are not available if the main thread has already terminated (typically by calling pthread_exit(3)).

Permission to dereference or read (readlink(2)) this symbolic link is governed by a ptrace access mode PTRACE_MODE_READ_FSCREDS check; see ptrace(2).

Under Linux 2.0 and earlier, /proc/pid/exe is a pointer to the binary which was executed, and appears as a symbolic link. A readlink(2) call on this file under Linux 2.0 returns a string in the format:

[device]:inode

For example, [0301]:1502 would be inode 1502 on device major 03 (IDE, MFM, etc. drives) minor 01 (first partition on the first drive).

find(1) with the -inum option can be used to locate the file.

246 - Linux cli command snmpd.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command snmpd.conf and provides detailed information about the command snmpd.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the snmpd.conf.

NAME 🖥️ snmpd.conf 🖥️

configuration file for the Net-SNMP SNMP agent

DESCRIPTION

The Net-SNMP agent uses one or more configuration files to control its operation and the management information provided. These files (snmpd.conf and snmpd.local.conf) can be located in one of several locations, as described in the snmp_config(5) manual page.

The (perl) application snmpconf can be used to generate configuration files for the most common agent requirements. See the snmpconf(1) manual page for more information, or try running the command:

snmpconf -g basic_setup

There are a large number of directives that can be specified, but these mostly fall into four distinct categories:

those controlling who can access the agent
those configuring the information that is supplied by the agent
those controlling active monitoring of the local system
those concerned with extending the functionality of the agent.

Some directives don’t fall naturally into any of these four categories, but this covers the majority of the contents of a typical snmpd.conf file. A full list of recognised directives can be obtained by running the command:

snmpd -H

AGENT BEHAVIOUR

Although most configuration directives are concerned with the MIB information supplied by the agent, there are a handful of directives that control the behaviour of snmpd considered simply as a daemon providing a network service.

agentaddress [<transport-specifier>:]<transport-address>[,…]
defines a list of listening addresses, on which to receive incoming SNMP requests. See the section LISTENING ADDRESSES in the snmpd(8) manual page for more information about the format of listening addresses.

The default behaviour is to listen on UDP port 161 on all IPv4 interfaces.

agentgroup {GROUP|#GID}
changes to the specified group after opening the listening port(s). This may refer to a group by name (GROUP), or a numeric group ID starting with ‘#’ (#GID).

agentuser {USER|#UID}
changes to the specified user after opening the listening port(s). This may refer to a user by name (USER), or a numeric user ID starting with ‘#’ (#UID).

leave_pidfile yes
instructs the agent to not remove its pid file on shutdown. Equivalent to specifying “-U” on the command line.

maxGetbulkRepeats NUM
Sets the maximum number of responses allowed for a single variable in a getbulk request. Set to 0 to enable the default and set it to -1 to enable unlimited. Because memory is allocated ahead of time, setting this to unlimited is not considered safe if your user population can not be trusted. A repeat number greater than this will be truncated to this value.

This is set by default to -1.

maxGetbulkResponses NUM
Sets the maximum number of responses allowed for a getbulk request. This is set by default to 100. Set to 0 to enable the default and set it to -1 to enable unlimited. Because memory is allocated ahead of time, setting this to unlimited is not considered safe if your user population can not be trusted.

In general, the total number of responses will not be allowed to exceed the maxGetbulkResponses number, and the total number returned will be an integer multiple of the number of variables requested times the calculated number of repeats allow to fit below this number.

Also note that processing of maxGetbulkRepeats is handled first.

ifmib_max_num_ifaces NUM
Sets the maximum number of interfaces included in IF-MIB data collection. For servers with a large number of interfaces (ppp, dummy, bridge, etc) the IF-MIB processing will take a large chunk of CPU for ioctl calls (on Linux). Setting a reasonable maximum for the CPU used will reduce the CPU load for IF-MIB processing. For example, configuring “ifmib_max_num_ifaces 500” will include only the first 500 interfaces based on ifindex and ignore all others for IF-MIB processing.

The default (without this configured) is to include all interfaces.

include_ifmib_iface_prefix PREFIX1 PREFIX2 …
Sets the interface name prefixes to include in the IF-MIB data collection. For servers with a large number of interfaces (ppp, dummy, bridge, etc) the IF-MIB processing will take a large chunk of CPU for ioctl calls (on Linux). A set of space separated interface name prefixes will reduce the CPU load for IF-MIB processing. For example, configuring “include_ifmib_iface_prefix eth dummy lo” will include only interfaces with these prefixes and ignore all others for IF-MIB processing. If regex support is compiled in, each of the prefixes is a regular expression (which is not permitted to contain a space or tab character).

The default (without this configured) is to include all interfaces.

SNMPv3 Configuration - Real Security

SNMPv3 is added flexible security models to the SNMP packet structure so that multiple security solutions could be used. SNMPv3 was original defined with a “User-based Security Model” (USM) [RFC3414] that required maintaining a SNMP-specific user database. This was later determined to be troublesome to maintain and had some minor security issues. The IETF has since added additional security models to tunnel SNMP over SSH [RFC5592] and DTLS/TLS [RFC-to-be]. Net-SNMP contains robust support for SNMPv3/USM, SNMPv3/TLS, and SNMPv3/DTLS. It contains partial support for SNMPv3/SSH as well but has not been as extensively tested. It also contains code for support for an experimental Kerberos based SNMPv3 that never got standardized.

Hopefully more SNMP software and devices will eventually support SNMP over (D)TLS or SSH, but it is likely that devices with original support for SNMP will only contain support for USM users. If your network manager supports SNMP over (D)TLS or SNMP over SSH we suggest you use one of these mechanisms instead of using USM, but as always with Net-SNMP we give you the options to pick from so you can make the choice that is best for you.

SNMPv3 generic parameters

These parameters are generic to all the forms of SNMPv3. The SNMPv3 protocol defines “engineIDs” that uniquely identify an agent. The string must be consistent through time and should not change or conflict with another agent’s engineID. Ever. Internally, Net-SNMP by default creates a unique engineID that is based off of the current system time and a random number. This should be sufficient for most users unless you’re embedding our agent in a device where these numbers won’t vary between boxes on the devices initial boot.

EngineIDs are used both as a “context” for selecting information from the device and SNMPv3 with USM uses it to create unique entries for users in its user table.

The Net-SNMP agent offers the following mechanisms for setting the engineID, but again you should only use them if you know what you’re doing:

engineID STRING
specifies that the engineID should be built from the given text STRING.

engineIDType 1|2|3
specifies that the engineID should be built from the IPv4 address (1), IPv6 address (2) or MAC address (3). Note that changing the IP address (or switching the network interface card) may cause problems.

engineIDNic INTERFACE
defines which interface to use when determining the MAC address. If engineIDType 3 is not specified, then this directive has no effect.

The default is to use eth0.

SNMPv3 over TLS

SNMPv3 may be tunneled over TLS and DTLS. TLS runs over TCP and DTLS is the UDP equivalent. Wes Hardaker (the founder of Net-SNMP) performed a study and presented it at an IETF meeting that showed that TCP based protocols are sufficient for stable networks but quickly becomes a problem in unstable networks with even moderate levels of packet loss (~ 20-30%). If you are going to use TLS or DTLS, you should use the one appropriate for your networking environment. You should potentially turn them both on so your management system can access either the UDP or the TCP port as needed.

Many of the configuration tokens described below are prefixed with a ‘[snmp]’ tag. If you place these tokens in your snmpd.conf file, this take is required. See the snmp_config(5) manual page for the meaning of this context switch.

[snmp] localCert <specifier>
This token defines the default X.509 public key to use as the server’s identity. It should either be a fingerprint or a filename. To create a public key for use, please run the “net-snmp-cert” utility which will help you create the required certificate.

The default value for this is the certificate in the “snmpd” named certificate file.

[snmp] tlsAlgorithms <algorithms>
This string will select the algorithms to use when negotiating security during (D)TLS session establishment. See the openssl manual page ciphers(1) for details on the format. Examples strings include:

DEFAULT
ALL
HIGH
HIGH:!AES128-SHA

The default value is whatever openssl itself was configured with.

[snmp] x509CRLFile
If you are using a Certificate Authority (CA) that publishes a Certificate Revocation List (CRL) then this token can be used to specify the location in the filesystem of a copy of the CRL file. Note that Net-SNMP will not pull a CRL over http and this must be a file, not a URL. Additionally, OpenSSL does not reload a CRL file when it has changed so modifications or updates to the file will only be noticed upon a restart of the snmpd agent.

certSecName PRIORITY FINGERPRINT OPTIONS
OPTIONS can be one of <–sn SECNAME | –rfc822 | –dns | –ip | –cn | –any>.

The certSecName token will specify how to map a certificate field from the client’s X.509 certificate to a SNMPv3 username. Use the –sn SECNAME flag to directly specify a securityName for a given certificate. The other flags extract a particular component of the certificate for use as a snmpv3 securityName. These fields are one of: A SubjectAltName containing an rfc822 value (eg [email protected]), A SubjectAltName containing a dns name value (eg foo.net-snmp.org), an IP address (eg 192.0.2.1) or a common name “Wes Hardaker”. The –any flag specifies that any of the subjecAltName fields may be used. Make sure once a securityName has been selected that it is given authorization via the VACM controls discussed later in this manual page.

See the http://www.net-snmp.org/wiki/index.php/Using_DTLS web page for more detailed instructions for setting up (D)TLS.

trustCert <specifier>
For X509 to properly verify a certificate, it should be verifiable up until a trust anchor for it. This trust anchor is typically a CA certificate but it could also be a self-signed certificate. The “trustCert” token should be used to load specific trust anchors into the verification engine.

SNMP over (D)TLS requires the use of the Transport Security Model (TSM), so read the section on the usage of the Transport Security Model as well. Make sure when you configure the VACM to accept connections from (D)TLS that you use the “tsm” security model. E.G.:

rwuser -s tsm [email protected]

SNMPv3 over SSH Support

To use SSH, you’ll need to configure sshd to invoke the sshtosnmp program as well as configure the access control settings to allow access through the tsm security model using the user name provided to snmpd by the ssh transport.

SNMPv3 with the Transport Security Model (TSM)

The Transport Security Model [RFC5591] defines a SNMPv3 security system for use with “tunneled” security protocols like TLS, DTLS and SSH. It is a very simple security model that simply lets properly protected packets to pass through into the snmp application. The transport is required to pass a securityName to use to the TSM and the TSM may optionally prefix this with a transport string (see below).

tsmUseTransportPrefix (1|yes|true|0|no|false)
If set to true, the TSM module will take every securityName passed to it from the transports underneath and prefix it with a string that specifically identities the transport it came from. This is useful to avoid securityName clashes with transports that generate identical security names. For example, if the ssh security transport delivered the security name of “hardaker” for a SSH connection and the TLS security transport also delivered the security name of “hardaker” for a TLS connection then it would be impossible to separate out these two users to provide separate access control rights. With the tsmUseTransportPrefix set to true, however, the securityNames would be prefixed appropriately with one of: “tls:”, “dtls:” or “ssh:”.

SNMPv3 with the User-based Security Model (USM)

SNMPv3 was originally defined using the User-Based Security Model (USM), which contains a private list of users and keys specific to the SNMPv3 protocol. The operational community, however, declared it a pain to manipulate yet another database and would prefer to use existing infrastructure. To that end the IETF created the ISMS working group to battle that problem, and the ISMS working group decided to tunnel SNMP over SSH and DTLS to make use existing user and authentication infrastructures.

SNMPv3 USM Users

To use the USM based SNMPv3-specific users, you’ll need to create them. It is recommended you use the net-snmp-config command to do this, but you can also do it by directly specifying createUser directives yourself instead:

createUser [-e ENGINEID] username (MD5|SHA|SHA-512|SHA-384|SHA-256|SHA-224) authpassphrase [DES|AES] [privpassphrase]

MD5|SHA|SHA-512|SHA-384|SHA-256|SHA-224 are the authentication types to use. DES and AES are the privacy protocols to use. If the privacy passphrase is not specified, it is assumed to be the same as the authentication passphrase. Note that the users created will be useless unless they are also added to the VACM access control tables described above.

SHA|SHA-512|SHA-384|SHA-256|SHA-224 authentication and DES/AES privacy require OpenSSL to be installed and the agent to be built with OpenSSL support. MD5 authentication may be used without OpenSSL.

Warning: the minimum pass phrase length is 8 characters.

SNMPv3 users can be created at runtime using the snmpusm(1) command.

Instead of figuring out how to use this directive and where to put it (see below), just run “net-snmp-config –create-snmpv3-user” instead, which will add one of these lines to the right place.

This directive should be placed into the /var/lib/snmp/snmpd.conf file instead of the other normal locations. The reason is that the information is read from the file and then the line is removed (eliminating the storage of the master password for that user) and replaced with the key that is derived from it. This key is a localized key, so that if it is stolen it can not be used to access other agents. If the password is stolen, however, it can be.

If you need to localize the user to a particular EngineID (this is useful mostly in the similar snmptrapd.conf file), you can use the -e argument to specify an EngineID as a hex value (EG, “0x01020304”).

If you want to generate either your master or localized keys directly, replace the given password with a hexstring (preceded by a “0x”) and precede the hex string by a -m or -l token (respectively). EGs:

[these keys are not secure but are easy to visually parse for counting purposes. Please generate random keys instead of using these examples]
createUser myuser SHA -l 0x0001020304050607080900010203040506070809 AES -l 0x00010203040506070809000102030405
createUser myuser SHA -m 0x0001020304050607080900010203040506070809 AES -m 0x0001020304050607080900010203040506070809

Due to the way localization happens, localized privacy keys are expected to be the length needed by the algorithm (128 bits for all supported algorithms). Master encryption keys, though, need to be the length required by the authentication algorithm not the length required by the encrypting algorithm (MD5: 16 bytes, SHA: 20 bytes).

ACCESS CONTROL

snmpd supports the View-Based Access Control Model (VACM) as defined in RFC 2575, to control who can retrieve or update information. To this end, it recognizes various directives relating to access control.

Traditional Access Control

Most simple access control requirements can be specified using the directives rouser/rwuser (for SNMPv3) or rocommunity/rwcommunity (for SNMPv1 or SNMPv2c).

rouser [-s SECMODEL] USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]

rwuser [-s SECMODEL] USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]
specify an SNMPv3 user that will be allowed read-only (GET and GETNEXT) or read-write (GET, GETNEXT and SET) access respectively. By default, this will provide access to the full OID tree for authenticated (including encrypted) SNMPv3 requests, using the default context. An alternative minimum security level can be specified using noauth (to allow unauthenticated requests), or priv (to enforce use of encryption). The OID field restricts access for that user to the subtree rooted at the given OID, or the named view. An optional context can also be specified, or “context*” to denote a context prefix. If no context field is specified (or the token “*” is used), the directive will match all possible contexts.

If SECMODEL is specified then it will be the security model required for that user (note that identical user names may come in over different security models and will be appropriately separated via the access control settings). The default security model is “usm” and the other common security models are likely “tsm” when using (D)TLS or SSH support and “ksm” if the Kerberos support has been compiled in.

rocommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]

rwcommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
specify an SNMPv1 or SNMPv2c community that will be allowed read-only (GET and GETNEXT) or read-write (GET, GETNEXT and SET) access respectively. By default, this will provide access to the full OID tree for such requests, regardless of where they were sent from. The SOURCE token can be used to restrict access to requests from the specified system(s) - see com2sec for the full details. The OID field restricts access for that community to the subtree rooted at the given OID, or named view. Contexts are typically less relevant to community-based SNMP versions, but the same behaviour applies here.

rocommunity6 COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]

rwcommunity6 COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
are directives relating to requests received using IPv6 (if the agent supports such transport domains). The interpretation of the SOURCE, OID, VIEW and CONTEXT tokens are exactly the same as for the IPv4 versions.

In each case, only one directive should be specified for a given SNMPv3 user, or community string. It is not appropriate to specify both rouser and rwuser directives referring to the same SNMPv3 user (or equivalent community settings). The rwuser directive provides all the access of rouser (as well as allowing SET support). The same holds true for the community-based directives.

More complex access requirements (such as access to two or more distinct OID subtrees, or different views for GET and SET requests) should use one of the other access control mechanisms. Note that if several distinct communities or SNMPv3 users need to be granted the same level of access, it would also be more efficient to use the main VACM configuration directives.

VACM Configuration

The full flexibility of the VACM is available using four configuration directives - com2sec, group, view and access. These provide direct configuration of the underlying VACM tables.

com2sec [-Cn CONTEXT] SECNAME SOURCE COMMUNITY

com2sec6 [-Cn CONTEXT] SECNAME SOURCE COMMUNITY
map an SNMPv1 or SNMPv2c community string to a security name - either from a particular range of source addresses, or globally (“default”). A restricted source can either be a specific hostname (or address), or a subnet - represented as IP/MASK (e.g. 10.10.10.0/255.255.255.0), or IP/BITS (e.g. 10.10.10.0/24), or the IPv6 equivalents. A restriction preceded by an exclamation mark (!) denies access from that address or subnet, e.g., !10.10.10.0/24 denies requests from that sources in that subnet. Deny restrictions must be before permit. E.g., the following example permits access from all of 10.0.0.0/8 except for 10.10.10.0/24:

com2sec sec1 !10.10.10.0/24 public
com2sec sec1 10.0.0.0/8 public

Access from outside of 10.0.0.0/8 would still be denied.

The same community string can be specified in several separate directives (presumably with different source tokens), and the first source/community combination that matches the incoming request will be selected. Various source/community combinations can also map to the same security name.

If a CONTEXT is specified (using -Cn), the community string will be mapped to a security name in the named SNMPv3 context. Otherwise the default context ("") will be used.

com2secunix [-Cn CONTEXT] SECNAME SOCKPATH COMMUNITY
is the Unix domain sockets version of com2sec.

group GROUP {v1|v2c|usm|tsm|ksm} SECNAME
maps a security name (in the specified security model) into a named group. Several group directives can specify the same group name, allowing a single access setting to apply to several users and/or community strings.

Note that groups must be set up for the two community-based models separately - a single com2sec (or equivalent) directive will typically be accompanied by two group directives.

view VNAME TYPE OID [MASK]
defines a named “view” - a subset of the overall OID tree. This is most commonly a single subtree, but several view directives can be given with the same view name (VNAME), to build up a more complex collection of OIDs. TYPE is either included or excluded, which can again define a more complex view (e.g by excluding certain sensitive objects from an otherwise accessible subtree).

MASK is a list of hex octets (optionally separated by ‘.’ or ‘:’) with the set bits indicating which subidentifiers in the view OID to match against. If not specified, this defaults to matching the OID exactly (all bits set), thus defining a simple OID subtree. So:

view iso1 included .iso 0xf0
view iso2 included .iso
view iso3 included .iso.org.dod.mgmt 0xf0

would all define the same view, covering the whole of the ‘iso(1)’ subtree (with the third example ignoring the subidentifiers not covered by the mask).

More usefully, the mask can be used to define a view covering a particular row (or rows) in a table, by matching against the appropriate table index value, but skipping the column subidentifier:

view ifRow4 included .1.3.6.1.2.1.2.2.1.0.4 0xff:a0

Note that a mask longer than 8 bits must use ‘:’ to separate the individual octets.

access GROUP CONTEXT {any|v1|v2c|usm|tsm|ksm} LEVEL PREFX READ WRITE NOTIFY
maps from a group of users/communities (with a particular security model and minimum security level, and in a specific context) to one of three views, depending on the request being processed.

LEVEL is one of noauth, auth, or priv. PREFX specifies how CONTEXT should be matched against the context of the incoming request, either exact or prefix. READ, WRITE and NOTIFY specifies the view to be used for GET*, SET and TRAP/INFORM requests (althought the NOTIFY view is not currently used). For v1 or v2c access, LEVEL will need to be noauth.

Typed-View Configuration

The final group of directives extend the VACM approach into a more flexible mechanism, which can be applied to other access control requirements. Rather than the fixed three views of the standard VACM mechanism, this can be used to configure various different view types. As far as the main SNMP agent is concerned, the two main view types are read and write, corresponding to the READ and WRITE views of the main access directive. See the ‘snmptrapd.conf(5)’ man page for discussion of other view types.

authcommunity TYPES COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
is an alternative to the rocommunity/rwcommunity directives. TYPES will usually be read or read,write respectively. The view specification can either be an OID subtree (as before), or a named view (defined using the view directive) for greater flexibility. If this is omitted, then access will be allowed to the full OID tree. If CONTEXT is specified, access is configured within this SNMPv3 context. Otherwise the default context ("") is used.

authuser TYPES [-s MODEL] USER [LEVEL [OID | -V VIEW [CONTEXT]]]
is an alternative to the rouser/rwuser directives. The fields TYPES, OID, VIEW and CONTEXT have the same meaning as for authcommunity.

authgroup TYPES [-s MODEL] GROUP [LEVEL [OID | -V VIEW [CONTEXT]]]
is a companion to the authuser directive, specifying access for a particular group (defined using the group directive as usual). Both authuser and authgroup default to authenticated requests - LEVEL can also be specified as noauth or priv to allow unauthenticated requests, or require encryption respectively. Both authuser and authgroup directives also default to configuring access for SNMPv3/USM requests - use the ‘-s’ flag to specify an alternative security model (using the same values as for access above).

authaccess TYPES [-s MODEL] GROUP VIEW [LEVEL [CONTEXT]]
also configures the access for a particular group, specifying the name and type of view to apply. The MODEL and LEVEL fields are interpreted in the same way as for authgroup. If CONTEXT is specified, access is configured within this SNMPv3 context (or contexts with this prefix if the CONTEXT field ends with ‘*’). Otherwise the default context ("") is used.

setaccess GROUP CONTEXT MODEL LEVEL PREFIX VIEW TYPES
is a direct equivalent to the original access directive, typically listing the view types as read or read,write as appropriate. (or see ‘snmptrapd.conf(5)’ for other possibilities). All other fields have the same interpretation as with access.

SYSTEM INFORMATION

Most of the information reported by the Net-SNMP agent is retrieved from the underlying system, or dynamically configured via SNMP SET requests (and retained from one run of the agent to the next). However, certain MIB objects can be configured or controlled via the snmpd.conf(5) file.

System Group

Most of the scalar objects in the ‘system’ group can be configured in this way:

sysLocation STRING

sysContact STRING

sysName STRING
set the system location, system contact or system name (sysLocation.0, sysContact.0 and sysName.0) for the agent respectively. Ordinarily these objects are writable via suitably authorized SNMP SET requests. However, specifying one of these directives makes the corresponding object read-only, and attempts to SET it will result in a notWritable error response.

sysServices NUMBER
sets the value of the sysServices.0 object. For a host system, a good value is 72 (application + end-to-end layers). If this directive is not specified, then no value will be reported for the sysServices.0 object.

sysDescr STRING

sysObjectID OID
sets the system description or object ID for the agent. Although these MIB objects are not SNMP-writable, these directives can be used by a network administrator to configure suitable values for them.

Interfaces Group

interface NAME TYPE SPEED
can be used to provide appropriate type and speed settings for interfaces where the agent fails to determine this information correctly. TYPE is a type value as given in the IANAifType-MIB, and can be specified numerically or by name (assuming this MIB is loaded).

interface_fadeout TIMEOUT
specifies, for how long the agent keeps entries in ifTable after appropriate interfaces have been removed from system (typically various ppp, tap or tun interfaces). Timeout value is in seconds. Default value is 300 (=5 minutes).

interface_replace_old yes
can be used to remove already existing entries in ifTable when an interface with the same name appears on the system. E.g. when ppp0 interface is removed, it is still listed in the table for interface_fadeout seconds. This option ensures, that the old ppp0 interface is removed even before the interface_fadeout timeour when new ppp0 (with different ifIndex) shows up.

Host Resources Group

This requires that the agent was built with support for the host module (which is now included as part of the default build configuration on the major supported platforms).

ignoreDisk STRING
controls which disk devices are scanned as part of populating the hrDiskStorageTable (and hrDeviceTable). The HostRes implementation code includes a list of disk device patterns appropriate for the current operating system, some of which may cause the agent to block when trying to open the corresponding disk devices. This might lead to a timeout when walking these tables, possibly resulting in inconsistent behaviour. This directive can be used to specify particular devices (either individually or wildcarded) that should not be checked.

Note:
Please consult the source (host/hr_disk.c) and check for the Add_HR_Disk_entry calls relevant for a particular O/S to determine the list of devices that will be scanned.

The pattern can include one or more wildcard expressions. See snmpd.examples(5) for illustration of the wildcard syntax.

ignoremount [-r] STRING
controls which mounts should be omitted from the hrStorageTable. If the Net-SNMP agent gets hung on accessing a filesystem, or the filesystem is always mostly full (and thus leads to spurious alerts), you can omit it by listing the full path in this directive.

If the “-r” option is provided, the pattern can include one or more regular expressions.

skipNFSInHostResources true
controls whether NFS and NFS-like file systems should be omitted from the hrStorageTable (true or 1) or not (false or 0, which is the default). If the Net-SNMP agent gets hung on NFS-mounted filesystems, you can try setting this to ‘1’.

Alternately, more granular control over which mounts should be omitted from the hrStorageTable can be achieved via the ignoremount directive.

storageUseNFS [1|2]
controls how NFS and NFS-like file systems should be reported in the hrStorageTable. as ‘Network Disks’ (1) or ‘Fixed Disks’ (2) Historically, the Net-SNMP agent has reported such file systems as ‘Fixed Disks’, and this is still the default behaviour. Setting this directive to ‘1’ reports such file systems as ‘Network Disks’, as required by the Host Resources MIB.

realStorageUnits
controlls how the agent reports hrStorageAllocationUnits, hrStorageSize and hrStorageUsed in hrStorageTable. For big storage drives with small allocation units the agent re-calculates these values so they all fit Integer32 and hrStorageAllocationUnits x hrStorageSize gives real size of the storage.

Example:
Linux xfs 16TB filesystem with 4096 bytes large blocks will be reported as hrStorageAllocationUnits = 8192 and hrStorageSize = 2147483647, so 8192 x 2147483647 gives real size of the filesystem (=16 TB).

Setting this directive to ‘1’ turns off this calculation and the agent reports real hrStorageAllocationUnits, but it might report wrong hrStorageSize for big drives because the value won’t fit into Integer32. In this case, hrStorageAllocationUnits x hrStorageSize won’t give real size of the storage.

Process Monitoring

The hrSWRun group of the Host Resources MIB provides information about individual processes running on the local system. The prTable of the UCD-SNMP-MIB complements this by reporting on selected services (which may involve multiple processes). This requires that the agent was built with support for the ucd-snmp/proc module (which is included as part of the default build configuration).

proc NAME [MAX [MIN]]
monitors the number of processes called NAME (as reported by “/bin/ps -e”) running on the local system.

If the number of NAMEd processes is less than MIN or greater than MAX, then the corresponding prErrorFlag instance will be set to 1, and a suitable description message reported via the prErrMessage instance.

Note:
This situation will not automatically trigger a trap to report the problem - see the DisMan Event MIB section later.

If neither MAX nor MIN are specified, they will default to infinity and 1 respectively (“at least one”). If only MAX is specified, MIN will default to 0 (“no more than MAX”). If MAX is 0 (and MIN is not), this indicates infinity (“at least MIN”). If both MAX and MIN are 0, this indicates a process that should not be running.

procfix NAME PROG ARGS
registers a command that can be run to fix errors with the given process NAME. This will be invoked when the corresponding prErrFix instance is set to 1.

Note:
This command will not be invoked automatically.

The procfix directive must be specified after the matching proc directive, and cannot be used on its own.

If no proc directives are defined, then walking the prTable will fail (noSuchObject).

Disk Usage Monitoring

This requires that the agent was built with support for the ucd-snmp/disk module (which is included as part of the default build configuration).

disk PATH [ MINSPACE | MINPERCENT% ]
monitors the disk mounted at PATH for available disk space. Disks mounted after the agent has started will not be monitored, unless includeAllDisks option is specified.

The minimum threshold can either be specified in kB (MINSPACE) or as a percentage of the total disk (MINPERCENT% with a ‘%’ character), defaulting to 100kB if neither are specified. If the free disk space falls below this threshold, then the corresponding dskErrorFlag instance will be set to 1, and a suitable description message reported via the dskErrorMsg instance.

Note:
This situation will not automatically trigger a trap to report the problem - see the DisMan Event MIB section later.

includeAllDisks MINPERCENT%
configures monitoring of all disks found on the system, using the specified (percentage) threshold. The dskTable is dynamically updated, unmounted disks disappear from the table and newly mounted disks are added to the table. The threshold for individual disks can be adjusted using suitable disk directives (which can come either before or after the includeAllDisks directive).

Note:
Whether disk directives appears before or after includeAllDisks may affect the indexing of the dskTable.

Only one includeAllDisks directive should be specified - any subsequent copies will be ignored.

The list of mounted disks will be determined from HOST-RESOURCES-MIB::hrFSTable.

If neither any disk directives or includeAllDisks are defined, then walking the dskTable will fail (noSuchObject).

Disk I/O Monitoring

This requires that the agent was built with support for the ucd-snmp/diskio module (which is not included as part of the default build configuration).

By default, all block devices known to the operating system are included in the diskIOTable. On platforms other than Linux, this module has no configuration directives.

On Linux systems, it is possible to exclude several classes of block devices from the diskIOTable in order to avoid cluttering the table with useless zero statistics for pseudo-devices that often are not in use but are configured by default to exist in most recent Linux distributions.

diskio_exclude_fd yes
Excludes all Linux floppy disk block devices, whose names start with “fd”, e.g. “fd0”

diskio_exclude_loop yes
Excludes all Linux loopback block devices, whose names start with “loop”, e.g. “loop0”

diskio_exclude_ram yes
Excludes all LInux ramdisk block devices, whose names start with “ram”, e.g. “ram0”

On Linux systems, it is also possible to report only explicitly accepted devices. It may take significant amount of time to process diskIOTable data on systems with tens of thousands of block devices and accept only the important ones avoids large CPU consumption.

diskio <device>
Enables acceptlist of devices and adds the device to the acceptlist. Only explicitly acceptlisted devices will be reported. This option may be used multiple times.

System Load Monitoring

This requires that the agent was built with support for either the ucd-snmp/loadave module or the ucd-snmp/memory module respectively (both of which are included as part of the default build configuration).

load MAX1 [MAX5 [MAX15]]
monitors the load average of the local system, specifying thresholds for the 1-minute, 5-minute and 15-minute averages. If any of these loads exceed the associated maximum value, then the corresponding laErrorFlag instance will be set to 1, and a suitable description message reported via the laErrMessage instance.

Note:
This situation will not automatically trigger a trap to report the problem - see the DisMan Event MIB section later.

If the MAX15 threshold is omitted, it will default to the MAX5 value. If both MAX5 and MAX15 are omitted, they will default to the MAX1 value. If this directive is not specified, all three thresholds will default to a value of DEFMAXLOADAVE.

If a threshold value of 0 is given, the agent will not report errors via the relevant laErrorFlag or laErrMessage instances, regardless of the current load.

Unlike the proc and disk directives, walking the walking the laTable will succeed (assuming the ucd-snmp/loadave module was configured into the agent), even if the load directive is not present.

swap MIN
monitors the amount of swap space available on the local system. If this falls below the specified threshold (MIN kB), then the memErrorSwap object will be set to 1, and a suitable description message reported via memSwapErrorMsg.

Note:
This situation will not automatically trigger a trap to report the problem - see the DisMan Event MIB section later.

If this directive is not specified, the default threshold is 16 MB.

Log File Monitoring

This requires that the agent was built with support for either the ucd-snmp/file or ucd-snmp/logmatch modules respectively (both of which are included as part of the default build configuration).

file FILE [MAXSIZE]
monitors the size of the specified file (in kB). If MAXSIZE is specified, and the size of the file exceeds this threshold, then the corresponding fileErrorFlag instance will be set to 1, and a suitable description message reported via the fileErrorMsg instance.

Note:
This situation will not automatically trigger a trap to report the problem - see the DisMan Event MIB section later.

Note: A maximum of 20 files can be monitored.

Note: If no file directives are defined, then walking the fileTable will fail (noSuchObject).

logmatch NAME FILE CYCLETIME REGEX
monitors the specified file for occurances of the specified pattern REGEX. The file position is stored internally so the entire file is only read initially, every subsequent pass will only read the new lines added to the file since the last read.

NAME
name of the logmatch instance (will appear as logMatchName under logMatch/logMatchTable/logMatchEntry/logMatchName in the ucd-snmp MIB tree)

FILE
absolute path to the logfile to be monitored. Note that this path can contain date/time directives (like in the UNIX ‘date’ command). See the manual page for ‘strftime’ for the various directives accepted.

CYCLETIME
time interval for each logfile read and internal variable update in seconds. Note: an SNMPGET* operation will also trigger an immediate logfile read and variable update.

REGEX
the regular expression to be used. Note: DO NOT enclose the regular expression in quotes even if there are spaces in the expression as the quotes will also become part of the pattern to be matched!

Example:

logmatch apache-GETs /usr/local/apache/logs/access.log-%Y-%m-%d 60 GET.*HTTP.*

This logmatch instance is named ‘apache-GETs’, uses ‘GET.*HTTP.*’ as its regular expression and it will monitor the file named (assuming today is May 6th 2009): ‘/usr/local/apache/logs/access.log-2009-05-06’, tomorrow it will look for ‘access.log-2009-05-07’. The logfile is read every 60 seconds.

Note: A maximum of 250 logmatch directives can be specified.

Note: If no logmatch directives are defined, then walking the logMatchTable will fail (noSuchObject).

ACTIVE MONITORING

The usual behaviour of an SNMP agent is to wait for incoming SNMP requests and respond to them - if no requests are received, an agent will typically not initiate any actions. This section describes various directives that can configure snmpd to take a more active role.

Notification Handling

trapcommunity STRING
defines the default community string to be used when sending traps. Note that this directive must be used prior to any community-based trap destination directives that need to use it.

trapsink [-profile p] [-name n] [-tag t] [-s src] HOST [COMMUNITY [PORT]]

trap2sink [-profile p] [-name n] [-tag t] [-s src] HOST [COMMUNITY [PORT]]

informsink [-profile p] [-name n] [-tag t] [-s src] HOST [COMMUNITY [PORT]]
define the address of a notification receiver that should be sent SNMPv1 TRAPs, SNMPv2c TRAP2s, or SNMPv2 INFORM notifications respectively. See the section LISTENING ADDRESSES in the snmpd(8) manual page for more information about the format of listening addresses. If COMMUNITY is not specified, the most recent trapcommunity string will be used.

If the transport address does not include an explicit port specification, then PORT will be used. If this is not specified, the well known SNMP trap port (162) will be used.

Note:
This mechanism is being deprecated, and the listening port should be specified via the transport specification HOST instead.

The optional name and tag parameters specifies the name or tag that will be used for SNMP-NOTIFICATION-MIB table entries. The profile specifies which notification filter profile entry will be used for filtering outgoing notifications. (See notificationFilter)

The optional src parameter specifies the source address that will be used when sending the trap packet to this sink. It is specified as a <transport-address>, using the same <transport-specifier> as the destination HOST. See the section LISTENING ADDRESSES in the snmpd(8) manual page for more information about the format.

If several sink directives are specified, multiple copies of each notification (in the appropriate formats) will be generated.

Note:
It is not normally appropriate to list two (or all three) sink directives with the same destination.

trapsess [-profile p] [-name n] [-tag t] [-s src] [SNMPCMD_ARGS] HOST
provides a more generic mechanism for defining notification destinations. SNMPCMD_ARGS should be the command-line options required for an equivalent snmptrap (or snmpinform) command to send the desired notification. The option -Ci can be used (with -v2c or -v3) to generate an INFORM notification rather than an unacknowledged TRAP.

This is the appropriate directive for defining SNMPv3 trap receivers. See http://www.net-snmp.org/tutorial/tutorial-5/commands/snmptrap-v3.html for more information about SNMPv3 notification behaviour.

notificationFilter NAME OID MASK TYPE
specifies a SNMP-NOTIFICATION-MIB notification filter profile, which may be used to filter traps. TYPE must be included or excluded, Some examples:

notificationFilter all_ok .1.3 0x00 included
notificationFilter no_coldstart .1.3 0x00 included
notificationFilter no_coldstart .1.3.6.1.6.3.1.1.5.1 0x00 excluded

trapsink -profile no_coldstart 192.168.1.3:3162 secret3

authtrapenable {1|2}
determines whether to generate authentication failure traps (enabled(1)) or not (disabled(2) - the default). Ordinarily the corresponding MIB object (snmpEnableAuthenTraps.0) is read-write, but specifying this directive makes this object read-only, and attempts to set the value via SET requests will result in a notWritable error response.

v1trapaddress HOST
defines the agent address, which is inserted into SNMPv1 TRAPs. Arbitrary local IPv4 address is chosen if this option is ommited. This option is useful mainly when the agent is visible from outside world by specific address only (e.g. because of network address translation or firewall).

DisMan Event MIB

The previous directives can be used to configure where traps should be sent, but are not concerned with when to send such traps (or what traps should be generated). This is the domain of the Event MIB - developed by the Distributed Management (DisMan) working group of the IETF.

This requires that the agent was built with support for the disman/event module (which is now included as part of the default build configuration for the most recent distribution).

Note:
The behaviour of the latest implementation differs in some minor respects from the previous code - nothing too significant, but existing scripts may possibly need some minor adjustments.

iquerySecName NAME

agentSecName NAME
specifies the default SNMPv3 username, to be used when making internal queries to retrieve any necessary information (either for evaluating the monitored expression, or building a notification payload). These internal queries always use SNMPv3, even if normal querying of the agent is done using SNMPv1 or SNMPv2c.

Note that this user must also be explicitly created (createUser) and given appropriate access rights (e.g. rouser). This directive is purely concerned with defining which user should be used - not with actually setting this user up.

monitor [OPTIONS] NAME EXPRESSION
defines a MIB object to monitor. If the EXPRESSION condition holds (see below), then this will trigger the corresponding event, and either send a notification or apply a SET assignment (or both). Note that the event will only be triggered once, when the expression first matches. This monitor entry will not fire again until the monitored condition first becomes false, and then matches again. NAME is an administrative name for this expression, and is used for indexing the mteTriggerTable (and related tables). Each monitor line must have a unique NAME. Monitor lines with a duplicate name are discarded and cause snmpd to log a duplicate index complaint. Note also that such monitors use an internal SNMPv3 request to retrieve the values being monitored (even if normal agent queries typically use SNMPv1 or SNMPv2c). See the iquerySecName token described above.

EXPRESSION
There are three types of monitor expression supported by the Event MIB - existence, boolean and threshold tests.

OID | ! OID | != OID
defines an existence(0) monitor test. A bare OID specifies a present(0) test, which will fire when (an instance of) the monitored OID is created. An expression of the form ! OID specifies an absent(1) test, which will fire when the monitored OID is delected. An expression of the form != OID specifies a changed(2) test, which will fire whenever the monitored value(s) change. Note that there must be whitespace before the OID token.

OID OP VALUE
defines a boolean(1) monitor test. OP should be one of the defined comparison operators (!=, ==, <, <=, >, >=) and VALUE should be an integer value to compare against. Note that there must be whitespace around the OP token. A comparison such as OID !=0 will not be handled correctly.

OID MIN MAX [DMIN DMAX]
defines a threshold(2) monitor test. MIN and MAX are integer values, specifying lower and upper thresholds. If the value of the monitored OID falls below the lower threshold (MIN) or rises above the upper threshold (MAX), then the monitor entry will trigger the corresponding event.

Note that the rising threshold event will only be re-armed when the monitored value falls below the lower threshold (MIN). Similarly, the falling threshold event will be re-armed by the upper threshold (MAX).

The optional parameters DMIN and DMAX configure a pair of similar threshold tests, but working with the delta differences between successive sample values.

OPTIONS
There are various options to control the behaviour of the monitored expression. These include:

-D
indicates that the expression should be evaluated using delta differences between sample values (rather than the values themselves).

-d OID

-di OID
specifies a discontinuity marker for validating delta differences. A -di object instance will be used exactly as given. A -d object will have the instance subidentifiers from the corresponding (wildcarded) expression object appended. If the -I flag is specified, then there is no difference between these two options.

This option also implies -D.

-e EVENT
specifies the event to be invoked when this monitor entry is triggered. If this option is not given, the monitor entry will generate one of the standard notifications defined in the DISMAN-EVENT-MIB.

-I
indicates that the monitored expression should be applied to the specified OID as a single instance. By default, the OID will be treated as a wildcarded object, and the monitor expanded to cover all matching instances.

-i OID

-o OID
define additional varbinds to be added to the notification payload when this monitor trigger fires. For a wildcarded expression, the suffix of the matched instance will be added to any OIDs specified using -o, while OIDs specified using -i will be treated as exact instances. If the -I flag is specified, then there is no difference between these two options.

See strictDisman for details of the ordering of notification payloads.

-r FREQUENCY
monitors the given expression every FREQUENCY, where FREQUENCY is in seconds or optionally suffixed by one of s (for seconds), m (for minutes), h (for hours), d (for days), or w (for weeks). By default, the expression will be evaluated every 600s (10 minutes).

-S
indicates that the monitor expression should not be evaluated when the agent first starts up. The first evaluation will be done once the first repeat interval has expired.

-s
indicates that the monitor expression should be evaluated when the agent first starts up. This is the default behaviour.

Note:
Notifications triggered by this initial evaluation will be sent before the coldStart trap.

-u SECNAME
specifies a security name to use for scanning the local host, instead of the default iquerySecName. Once again, this user must be explicitly created and given suitable access rights.

notificationEvent ENAME NOTIFICATION [-m] [-i OID | -o OID ]*
defines a notification event named ENAME. This can be triggered from a given monitor entry by specifying the option -e ENAME (see above). NOTIFICATION should be the OID of the NOTIFICATION-TYPE definition for the notification to be generated.

If the -m option is given, the notification payload will include the standard varbinds as specified in the OBJECTS clause of the notification MIB definition. This option must come after the NOTIFICATION OID (and the relevant MIB file must be available and loaded by the agent). Otherwise, these varbinds must be listed explicitly (either here or in the corresponding monitor directive).

The -i OID and -o OID options specify additional varbinds to be appended to the notification payload, after the standard list. If the monitor entry that triggered this event involved a wildcarded expression, the suffix of the matched instance will be added to any OIDs specified using -o, while OIDs specified using -i will be treated as exact instances. If the -I flag was specified to the monitor directive, then there is no difference between these two options.

setEvent ENAME [-I] OID = VALUE
defines a set event named ENAME, assigning the (integer) VALUE to the specified OID. This can be triggered from a given monitor entry by specifying the option -e ENAME (see above).

If the monitor entry that triggered this event involved a wildcarded expression, the suffix of the matched instance will normally be added to the OID. If the -I flag was specified to either of the monitor or setEvent directives, the specified OID will be regarded as an exact single instance.

strictDisman yes
The definition of SNMP notifications states that the varbinds defined in the OBJECT clause should come first (in the order specified), followed by any “extra” varbinds that the notification generator feels might be useful. The most natural approach would be to associate these mandatory varbinds with the notificationEvent entry, and append any varbinds associated with the monitor entry that triggered the notification to the end of this list. This is the default behaviour of the Net-SNMP Event MIB implementation.

Unfortunately, the DisMan Event MIB specifications actually state that the trigger-related varbinds should come first, followed by the event-related ones. This directive can be used to restore this strictly-correct (but inappropriate) behaviour.

Note:
Strict DisMan ordering may result in generating invalid notifications payload lists if the notificationEvent -n flag is used together with monitor -o (or -i) varbind options.

If no monitor entries specify payload varbinds, then the setting of this directive is irrelevant.

linkUpDownNotifications yes
will configure the Event MIB tables to monitor the ifTable for network interfaces being taken up or down, and triggering a linkUp or linkDown notification as appropriate.

This is exactly equivalent to the configuration:

notificationEvent  linkUpTrap    linkUp   ifIndex ifAdminStatus ifOperStatus
notificationEvent  linkDownTrap  linkDown ifIndex ifAdminStatus ifOperStatus

monitor  -r 60 -e linkUpTrap   "Generate linkUp" ifOperStatus != 2
monitor  -r 60 -e linkDownTrap "Generate linkDown" ifOperStatus == 2

defaultMonitors yes
will configure the Event MIB tables to monitor the various UCD-SNMP-MIB tables for problems (as indicated by the appropriate xxErrFlag column objects).

This is exactly equivalent to the configuration:

monitor	-o prNames -o prErrMessage "process table" prErrorFlag != 0
monitor	-o memErrorName -o memSwapErrorMsg "memory" memSwapError != 0
monitor	-o extNames -o extOutput "extTable" extResult != 0
monitor	-o dskPath -o dskErrorMsg "dskTable" dskErrorFlag != 0
monitor	-o laNames -o laErrMessage  "laTable" laErrorFlag != 0
monitor	-o fileName -o fileErrorMsg  "fileTable" fileErrorFlag != 0

In both these latter cases, the snmpd.conf must also contain a iquerySecName directive, together with a corresponding createUser entry and suitable access control configuration.

DisMan Schedule MIB

The DisMan working group also produced a mechanism for scheduling particular actions (a specified SET assignment) at given times. This requires that the agent was built with support for the disman/schedule module (which is included as part of the default build configuration for the most recent distribution).

There are three ways of specifying the scheduled action:

repeat FREQUENCY OID = VALUE
configures a SET assignment of the (integer) VALUE to the MIB instance OID, to be run every FREQUENCY seconds, where FREQUENCY is in seconds or optionally suffixed by one of s (for seconds), m (for minutes), h (for hours), d (for days), or w (for weeks).

cron MINUTE HOUR DAY MONTH WEEKDAY OID = VALUE
configures a SET assignment of the (integer) VALUE to the MIB instance OID, to be run at the times specified by the fields MINUTE to WEEKDAY. These follow the same pattern as the equivalent crontab(5) fields.

Note:
These fields should be specified as a (comma-separated) list of numeric values. Named values for the MONTH and WEEKDAY fields are not supported, and neither are value ranges. A wildcard match can be specified as ‘*’.

The DAY field can also accept negative values, to indicate days counting backwards from the end of the month.

at MINUTE HOUR DAY MONTH WEEKDAY OID = VALUE
configures a one-shot SET assignment, to be run at the first matching time as specified by the fields MINUTE to WEEKDAY. The interpretation of these fields is exactly the same as for the cron directive.

Data Delivery via Notfiications

Note: this functionality is only available if the deliver/deliverByNotify mib module was complied in to the agent

In some situations it may be advantageous to deliver SNMP data over SNMP Notifications (TRAPs and INFORMs) rather than the typical process of having the manager issue requests for the data (via GETs and GETNEXTs). Reasons for doing this are numerous, but frequently corner cases. The most common reason for wanting this behaviour might be to monitor devices that reside behind NATs or Firewalls that prevent incoming SNMP traffic.

It should be noted that although most management software is capable of logging notifications, very little (if any) management software will updated their “knowledge database” based on the contents of SNMP notifications. IE, it won’t (for example) update the interface traffic counter history that is used to produce graphs. Most larger network management packages have a separate database for storing data received via SNMP requests (GETs and GETNEXTs) vs those received from notifications. Researching the capabilities of your management station software is required before assuming this functionality will solve your data delivery requirements.

Notifications generated via this mechanism will be sent to the standard set of configured notification targets. See the “Notification Handling” section of this document for further information.

deliverByNotify [-p] [-m] [-s MAXSIZE] FREQUENCY OID
This directive tells the SNMP agent to self-walk the OID, collect all the data and send it out every FREQUENCY seconds, where FREQUENCY is in seconds or optionally suffixed by one of s (for seconds), m (for minutes), h (for hours), d (for days), or w (for weeks). By default scalars are included in the notification that specify the how often the notification will be sent (unless the -p option is specified) and which message number of how many messages a particular notification is (unless -m is specified). To break the notifications into manageable packet sizes, use the -s flag to specify the approximate maximum number of bytes that a notification message should be limited to. If more than MAXSIZE of bytes is needed then multiple notifications will be sent to deliver the data. Note that the calculations for ensuring the maximum size is met are approximations and thus it can be absolutely guaranteed they’ll be under that size, so leave a padding buffer if it is critical that you avoid fragmentation. A value of -1 indicates force everything into a single message no matter how big it is.

Example usage: the following will deliver the contents of the ifTable once an hour and the contents of the system group once every 2 hours:

deliverByNotify 3600 ifTable
deliverByNotify 7200 system

deliverByNotifyMaxPacketSize SIZEINBYTES
Sets the default notification size limit (see the -s flag above).

deliverByNotifyOid OID

deliverByNotifyFrequencyOid OID

deliverByNotifyMessageNumberOid OID

deliverByNotifyMaxMessageNumberOid OID
These set the data OID that the notification will be sent under, the scalar OID, the message number OID, and the maximum message number OID. These default to objects in the NET-SNMP-PERIODIC-NOTIFY-MIB.

EXTENDING AGENT FUNCTIONALITY

One of the first distinguishing features of the original UCD suite was the ability to extend the functionality of the agent - not just by recompiling with code for new MIB modules, but also by configuring the running agent to report additional information. There are a number of techniques to support this, including:

running external commands (exec, extend, pass)
loading new code dynamically (embedded perl, dlmod)
communicating with other agents (proxy, SMUX, AgentX)

Arbitrary Extension Commands

The earliest extension mechanism was the ability to run arbitrary commands or shell scripts. Such commands do not need to be aware of SNMP operations, or conform to any particular behaviour - the MIB structures are designed to accommodate any form of command output. Use of this mechanism requires that the agent was built with support for the ucd-snmp/extensible and/or agent/extend modules (which are both included as part of the default build configuration).

exec [MIBOID] NAME PROG ARGS

sh [MIBOID] NAME PROG ARGS
invoke the named PROG with arguments of ARGS. By default the exit status and first line of output from the command will be reported via the extTable, discarding any additional output.

Note:
Entries in this table appear in the order they are read from the configuration file. This means that adding new exec (or sh) directives and restarting the agent, may affect the indexing of other entries.

The PROG argument for exec directives must be a full path to a real binary, as it is executed via the exec() system call. To invoke a shell script, use the sh directive instead.

If MIBOID is specified, then the results will be rooted at this point in the OID tree, returning the exit statement as MIBOID.100.0 and the entire command output in a pseudo-table based at MIBNUM.101 - with one ‘row’ for each line of output.

Note:
The layout of this “relocatable” form of exec (or sh) output does not strictly form a valid MIB structure. This mechanism is being deprecated - please see the extend directive (described below) instead.

The agent does not cache the exit status or output of the executed program.

execfix NAME PROG ARGS
registers a command that can be invoked on demand - typically to respond to or fix errors with the corresponding exec or sh entry. When the extErrFix instance for a given NAMEd entry is set to the integer value of 1, this command will be called.

Note:
This directive can only be used in combination with a corresponding exec or sh directive, which must be defined first. Attempting to define an unaccompanied execfix directive will fail.

exec and sh extensions can only be configured via the snmpd.conf file. They cannot be set up via SNMP SET requests.

extend [-cacheTime TIME] [-execType TYPE] [MIBOID] NAME PROG ARGS
works in a similar manner to the exec directive, but with a number of improvements. The MIB tables (nsExtendConfigTable etc) are indexed by the NAME token, so are unaffected by the order in which entries are read from the configuration files. There are two result tables - one (nsExtendOutput1Table) containing the exit status, the first line and full output (as a single string) for each extend entry, and the other (nsExtendOutput2Table) containing the complete output as a series of separate lines.

If -cacheTime is specified, then its argument is used as the cache timeout (in whole seconds) for this extend entry. This mechanism provides a non-volatile way to specify the cache timeout.

If -execType is specified and has a value of sh, then this extend entry will be run in a shell. Otherwise it will be run in the default exec fashion. This mechanism provides a non-volatile way to specify the exec type.

If MIBOID is specified, then the configuration and result tables will be rooted at this point in the OID tree, but are otherwise structured in exactly the same way. This means that several separate extend directives can specify the same MIBOID root, without conflicting.

The exit status and output is cached for each entry individually, and can be cleared (and the caching behaviour configured) using the nsCacheTable.

extendfix NAME PROG ARGS
registers a command that can be invoked on demand, by setting the appropriate nsExtendRunType instance to the value run-command(3). Unlike the equivalent execfix, this directive does not need to be paired with a corresponding extend entry, and can appear on its own.

MIB-Specific Extension Commands

The first group of extension directives invoke arbitrary commands, and rely on the MIB structure (and management applications) having the flexibility to accommodate and interpret the output. This is a convenient way to make information available quickly and simply, but is of no use when implementing specific MIB objects, where the extension must conform to the structure of the MIB (rather than vice versa). The remaining extension mechanisms are all concerned with such MIB-specific situations - starting with “pass-through” scripts. Use of this mechanism requires that the agent was built with support for the ucd-snmp/pass and ucd-snmp/pass_persist modules (which are both included as part of the default build configuration).

pass [-p priority] MIBOID PROG
will pass control of the subtree rooted at MIBOID to the specified PROG command. GET and GETNEXT requests for OIDs within this tree will trigger this command, called as:

PROG -g OID

PROG -n OID

respectively, where OID is the requested OID. The PROG command should return the response varbind as three separate lines printed to stdout - the first line should be the OID of the returned value, the second should be its TYPE (one of the text strings integer, gauge, counter, timeticks, ipaddress, objectid, octet, or string ), and the third should be the value itself. (Note: octets are sent as ASCII, space-separated hex strings, e.g. “00 3f dd 00 c6 be”.)

If the command cannot return an appropriate varbind - e.g the specified OID did not correspond to a valid instance for a GET request, or there were no following instances for a GETNEXT - then it should exit without producing any output. This will result in an SNMP noSuchName error, or a noSuchInstance exception.

Note:
The SMIv2 type counter64 and SNMPv2 noSuchObject exception are not supported.

A SET request will result in the command being called as:

PROG -s OID TYPE VALUE

where TYPE is one of the tokens listed above, indicating the type of the value passed as the third parameter.

If the assignment is successful, the PROG command should exit without producing any output. Errors should be indicated by writing one of the strings not-writable, or wrong-type to stdout, and the agent will generate the appropriate error response.

Note:
The other SNMPv2 errors are not supported.

In either case, the command should exit once it has finished processing. Each request (and each varbind within a single request) will trigger a separate invocation of the command.

The default registration priority is 127. This can be changed by supplying the optional -p flag, with lower priority registrations being used in preference to higher priority values.

pass_persist [-p priority] MIBOID PROG
will also pass control of the subtree rooted at MIBOID to the specified PROG command. However this command will continue to run after the initial request has been answered, so subsequent requests can be processed without the startup overheads.

Upon initialization, PROG will be passed the string “PING " on stdin, and should respond by printing “PONG " to stdout.

For GET and GETNEXT requests, PROG will be passed two lines on stdin, the command (get or getnext) and the requested OID. It should respond by printing three lines to stdout - the OID for the result varbind, the TYPE and the VALUE itself - exactly as for the pass directive above. If the command cannot return an appropriate varbind, it should print print “NONE " to stdout (but continue running).

For SET requests, PROG will be passed three lines on stdin, the command (set) and the requested OID, followed by the type and value (both on the same line). If the assignment is successful, the command should print “DONE " to stdout. Errors should be indicated by writing one of the strings not-writable, wrong-type, wrong-length, wrong-value or inconsistent-value to stdout, and the agent will generate the appropriate error response. In either case, the command should continue running.

The registration priority can be changed using the optional -p flag, just as for the pass directive.

pass and pass_persist extensions can only be configured via the snmpd.conf file. They cannot be set up via SNMP SET requests.

Embedded Perl Support

Programs using the previous extension mechanisms can be written in any convenient programming language - including perl, which is a common choice for pass-through extensions in particular. However the Net-SNMP agent also includes support for embedded perl technology (similar to mod_perl for the Apache web server). This allows the agent to interpret perl scripts directly, thus avoiding the overhead of spawning processes and initializing the perl system when a request is received.

Use of this mechanism requires that the agent was built with support for the embedded perl mechanism, which is not part of the default build environment. It must be explicitly included by specifying the ‘–enable-embedded-perl’ option to the configure script when the package is first built.

If enabled, the following directives will be recognised:

disablePerl true
will turn off embedded perl support entirely (e.g. if there are problems with the perl installation).

perlInitFile FILE
loads the specified initialisation file (if present) immediately before the first perl directive is parsed. If not explicitly specified, the agent will look for the default initialisation file /usr/share/snmp/snmp_perl.pl.

The default initialisation file creates an instance of a NetSNMP::agent object - a variable $agent which can be used to register perl-based MIB handler routines.

perl EXPRESSION
evaluates the given expression. This would typically register a handler routine to be called when a section of the OID tree was requested:

perl use Data::Dumper; perl sub myroutine { print “got called: “,Dumper(@_),” “; } perl $agent->register(‘mylink’, ‘.1.3.6.1.8765’, &myroutine);

This expression could also source an external file:

perl 'do /path/to/file.pl';

or perform any other perl-based processing that might be required.

Dynamically Loadable Modules

Most of the MIBs supported by the Net-SNMP agent are implemented as C code modules, which were compiled and linked into the agent libraries when the suite was first built. Such implementation modules can also be compiled independently and loaded into the running agent once it has started. Use of this mechanism requires that the agent was built with support for the ucd-snmp/dlmod module (which is included as part of the default build configuration).

dlmod NAME PATH
will load the shared object module from the file PATH (an absolute filename), and call the initialisation routine init_NAME.

Note:
If the specified PATH is not a fully qualified filename, it will be interpreted relative to /usr/lib/x86_64-linux-gnu/snmp/dlmod, and .so will be appended to the filename.

This functionality can also be configured using SNMP SET requests to the UCD-DLMOD-MIB.

Proxy Support

Another mechanism for extending the functionality of the agent is to pass selected requests (or selected varbinds) to another SNMP agent, which can be running on the same host (presumably listening on a different port), or on a remote system. This can be viewed either as the main agent delegating requests to the remote one, or acting as a proxy for it. Use of this mechanism requires that the agent was built with support for the ucd-snmp/proxy module (which is included as part of the default build configuration).

proxy [-Cn CONTEXTNAME] [SNMPCMD_ARGS] HOST OID [REMOTEOID]
will pass any incoming requests under OID to the agent listening on the port specified by the transport address HOST. See the section LISTENING ADDRESSES in the snmpd(8) manual page for more information about the format of listening addresses.

Note:
To proxy the entire MIB tree, use the OID .1.3 (not the top-level .1)

The SNMPCMD_ARGS should provide sufficient version and administrative information to generate a valid SNMP request (see snmpcmd(1)).

Note:
The proxied request will not use the administrative settings from the original request.

If a CONTEXTNAME is specified, this will register the proxy delegation within the named context in the local agent. Defining multiple proxy directives for the same OID but different contexts can be used to query several remote agents through a single proxy, by specifying the appropriate SNMPv3 context in the incoming request (or using suitable configured community strings - see the com2sec directive).

Specifying the REMOID parameter will map the local MIB tree rooted at OID to an equivalent subtree rooted at REMOID on the remote agent.

SMUX Sub-Agents

The Net-SNMP agent supports the SMUX protocol (RFC 1227) to communicate with SMUX-based subagents (such as gated, zebra or quagga). Use of this mechanism requires that the agent was built with support for the smux module, which is not part of the default build environment, and must be explicitly included by specifying the ‘–with-mib-modules=smux’ option to the configure script when the package is first built.

Note:
This extension protocol has been officially deprecated in favour of AgentX (see below).

smuxpeer OID PASS
will register a subtree for SMUX-based processing, to be authenticated using the password PASS. If a subagent (or “peer”) connects to the agent and registers this subtree then requests for OIDs within it will be passed to that SMUX subagent for processing.

A suitable entry for an OSPF routing daemon (such as gated, zebra or quagga) might be something like

smuxpeer .1.3.6.1.2.1.14 ospf_pass

smuxsocket <IPv4-address>
defines the IPv4 address for SMUX peers to communicate with the Net-SNMP agent. The default is to listen on all IPv4 interfaces (“0.0.0.0”), unless the package has been configured with “–enable-local-smux” at build time, which causes it to only listen on 127.0.0.1 by default. SMUX uses the well-known TCP port 199.

Note the Net-SNMP agent will only operate as a SMUX master agent. It does not support acting in a SMUX subagent role.

AgentX Sub-Agents

The Net-SNMP agent supports the AgentX protocol (RFC 2741) in both master and subagent roles. Use of this mechanism requires that the agent was built with support for the agentx module (which is included as part of the default build configuration), and also that this support is explicitly enabled (e.g. via the snmpd.conf file).

There are two directives specifically relevant to running as an AgentX master agent:

master agentx
will enable the AgentX functionality and cause the agent to start listening for incoming AgentX registrations. This can also be activated by specifying the ‘-x’ command-line option (to specify an alternative listening socket).

agentXPerms SOCKPERMS [DIRPERMS [USER|UID [GROUP|GID]]]
Defines the permissions and ownership of the AgentX Unix Domain socket, and the parent directories of this socket. SOCKPERMS and DIRPERMS must be octal digits (see chmod(1) ). By default this socket will only be accessible to subagents which have the same userid as the agent.

There is one directive specifically relevant to running as an AgentX sub-agent:

agentXPingInterval NUM
will make the subagent try and reconnect every NUM seconds to the master if it ever becomes (or starts) disconnected.

The remaining directives are relevant to both AgentX master and sub-agents:

agentXSocket [<transport-specifier>:]<transport-address>[,…]
defines the address the master agent listens at, or the subagent should connect to. The default is the Unix Domain socket "/var/agentx/master". Another common alternative is tcp:localhost:705. See the section LISTENING ADDRESSES in the snmpd(8) manual page for more information about the format of addresses.

Note:
Specifying an AgentX socket does not automatically enable AgentX functionality (unlike the ‘-x’ command-line option).

agentXTimeout NUM
defines the timeout period (NUM seconds) for an AgentX request. Default is 1 second. NUM also be specified with a suffix of one of s (for seconds), m (for minutes), h (for hours), d (for days), or w (for weeks).

agentXRetries NUM
defines the number of retries for an AgentX request. Default is 5 retries.

net-snmp ships with both C and Perl APIs to develop your own AgentX subagent.

OTHER CONFIGURATION

override [-rw] OID TYPE VALUE
This directive allows you to override a particular OID with a different value (and possibly a different type of value). The -rw flag will allow snmp SETs to modify it’s value as well. (note that if you’re overriding original functionality, that functionality will be entirely lost. Thus SETS will do nothing more than modify the internal overridden value and will not perform any of the original functionality intended to be provided by the MIB object. It’s an emulation only.) An example:

override sysDescr.0 octet_str "my own sysDescr"

That line will set the sysDescr.0 value to “my own sysDescr” as well as make it modifiable with SNMP SETs as well (which is actually illegal according to the MIB specifications).

Note that care must be taken when using this. For example, if you try to override a property of the 3rd interface in the ifTable with a new value and later the numbering within the ifTable changes it’s index ordering you’ll end up with problems and your modified value won’t appear in the right place in the table.

Valid TYPEs are: integer, uinteger, octet_str, object_id, counter, null (for gauges, use “uinteger”; for bit strings, use “octet_str”). Note that setting an object to “null” effectively delete’s it as being accessible. No VALUE needs to be given if the object type is null.

More types should be available in the future.

If you’re trying to figure out aspects of the various mib modules (possibly some that you’ve added yourself), the following may help you spit out some useful debugging information. First off, please read the snmpd manual page on the -D flag. Then the following configuration snmpd.conf token, combined with the -D flag, can produce useful output:

injectHandler HANDLER modulename [beforeThis]
This will insert new handlers into the section of the mib tree referenced by “modulename”. If “beforeThis” is specified then the module will be injected before the named module. This is useful for getting a handler into the exact right position in the chain.

The types of handlers available for insertion are:

stash_cache
Caches information returned from the lower level. This greatly help the performance of the agent, at the cost of caching the data such that its no longer “live” for 30 seconds (in this future, this will be configurable). Note that this means snmpd will use more memory as well while the information is cached. Currently this only works for handlers registered using the table_iterator support, which is only a few mib tables. To use it, you need to make sure to install it before the table_iterator point in the chain, so to do this:

injectHandler stash_cache NAME table_iterator

If you want a table to play with, try walking the nsModuleTable with and without this injected.

debug
Prints out lots of debugging information when the -Dhelper:debug flag is passed to the snmpd application.

read_only
Forces turning off write support for the given module.

serialize
If a module is failing to handle multiple requests properly (using the new 5.0 module API), this will force the module to only receive one request at a time.

bulk_to_next
If a module registers to handle getbulk support, but for some reason is failing to implement it properly, this module will convert all getbulk requests to getnext requests before the final module receives it.

dontLogTCPWrappersConnects
If the snmpd was compiled with TCP Wrapper support, it logs every connection made to the agent. This setting disables the log messages for accepted connections. Denied connections will still be logged.

Figuring out module names
To figure out which modules you can inject things into, run snmpwalk on the nsModuleTable which will give a list of all named modules registered within the agent.

Internal Data tables

table NAME

add_row NAME INDEX(ES) VALUE(S)

NOTES

The Net-SNMP agent can be instructed to re-read the various configuration files, either via an snmpset assignment of integer(1) to UCD-SNMP-MIB::versionUpdateConfig.0 (.1.3.6.1.4.1.2021.100.11.0), or by sending a kill -HUP signal to the agent process.
All directives listed with a value of “yes” actually accept a range of boolean values. These will accept any of 1, yes or true to enable the corresponding behaviour, or any of 0, no or false to disable it. The default in each case is for the feature to be turned off, so these directives are typically only used to enable the appropriate behaviour.

EXAMPLE CONFIGURATION FILE

See the EXAMPLE.CONF file in the top level source directory for a more detailed example of how the above information is used in real examples.

FILES

/etc/snmp/snmpd.conf

247 - Linux cli command kernel-img.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command kernel-img.conf and provides detailed information about the command kernel-img.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the kernel-img.conf.

NAME 🖥️ kernel-img.conf 🖥️

img.conf - configuration file for Linux kernel packages

SYNOPSIS

/etc/kernel-img.conf

DESCRIPTION

The file /etc/kernel-img.conf is used by the kernel package installation and removal process to allow local options for handling some aspects of the installation. Most configuration variables apply only to kernel image packages.

Not all kernel image package creators support this file, or all the configuration variables. Support status for the file itself is:

Package creator	Status
Debian linux source package	supported
Ubuntu linux source package	supported
kernel-package	supported
make deb-pkg	ignored

The format of the file is a simple VAR**=**VALUE pair. Boolean values may be specified as Yes, True, 1, and No, False, 0, and are case insensitive. This file is automatically created by the installation script in certain circumstances.

At the moment, the user modifiable variables supported are:

do_symlinks
If set, the postinst and postrm scripts will maintain symlinks to default kernel and initramfs images, as described in linux-update-symlinks(8). This variable is set by default.

Package creator	Status
Debian linux source package	supported
Ubuntu linux source package	supported
kernel-package	ignored since v12.001;
	previously supported

image_dest
Set this variable to the directory in which symlinks to the default kernel and initramfs images should be maintained. The default value is /.

Package creator	Status
Debian linux source package	supported
Ubuntu linux source package	supported
kernel-package	ignored since v12.001;
	previously supported

link_in_boot
If set, this has the same effect as image_dest = /boot and overrides any other setting of image_dest. This variable is unset by default.

Package creator	Status
Debian linux source package	supported
Ubuntu linux source package	supported
kernel-package	ignored since v12.001;
	previously supported

postinst_hook
DEPRECATED: Set this variable to a script to be executed during installation. The path can be a relative path if the script lives in a safe path – that is, if it lives in /bin, /sbin, /usr/bin, or /usr/sbin, or must be an absolute path instead. Before calling this script, the environment variable STEM shall be set to the value of the –stem argument (or the default value, linux), and in packages created by kernel-package KERNEL_PACKAGE_VERSION shall be set to the version of the kernel-package that created the package. This script shall be called with two arguments, the first being the version of the kernel image, and the second argument being the location of the kernel image itself. Errors in the script shall cause the postinst to fail. Since debconf is in use before the script is called, this script should issue no diagnostic messages to stdout – while the postinst does call db_stop, debconf does not restore stdout, so messages to stdout disappear. An example script for grub users is present in /usr/share/doc/kernel-package/ directory. This script is run after the scripts in /etc/kernel/postinst.d directory.

Package creator	Status
Debian linux source package	unsupported since v4.6.1-1;
	previously supported
Ubuntu linux source package	unsupported since v4.15.0-18.19;
	previously supported
kernel-package	deprecated

postrm_hook
DEPRECATED: Set this variable to a script to be executed in the postrm (that is, after the image has been removed) after all the remove actions have been performed. The path can be a relative path if the script lives in a safe path – that is, if it lives in /bin, /sbin, /usr/bin, or /usr/sbin, or must be an absolute path instead. In packages created by kernel-package, the environment variable KERNEL_PACKAGE_VERSION shall be set to the version of the kernel-package that created the package. This script shall be called with two arguments, the first being the version of the kernel image, and the second argument being the location of the kernel image itself. Errors in the script shall produce a warning message, but shall be otherwise ignored. Since debconf is in use before the script is called, this script should issue no diagnostic messages to stdout – while the postinst does call db_stop, debconf does not restore stdout, so messages to stdout disappear. This script is run after the scripts in /etc/kernel/postrm.d directory.

Package creator	Status
Debian linux source package	unsupported since v4.6.1-1;
	previously supported
Ubuntu linux source package	unsupported since v4.15.0-18.19;
	previously supported
kernel-package	deprecated

preinst_hook
DEPRECATED: Set this variable to a script to be executed before the package is unpacked, and can be used to put in additional checks. The path can be a relative path if the script lives in a safe path – that is, if it lives in /bin, /sbin, /usr/bin, or /usr/sbin, or must be an absolute path instead. In packages created by kernel-package, the environment variable KERNEL_PACKAGE_VERSION shall be set to the version of the kernel-package that created the package. This script shall be called with two arguments, the first being the version of the kernel image, and the second argument being the location of the kernel image itself. This script is run after the scripts in /etc/kernel/preinst.d directory.

Package creator	Status
Debian linux source package	unsupported since v4.6.1-1;
	previously supported
Ubuntu linux source package	unsupported since v4.15.0-18.19;
	previously supported
kernel-package	deprecated

prerm_hook
DEPRECATED: Set this variable to a script to be executed before the package files are removed (so any added files may be removed) . The path can be a relative path if the script lives in a safe path – that is, if it lives in /bin, /sbin, /usr/bin, or /usr/sbin, or must be an absolute path instead. In packages created by kernel-package, the environment variable KERNEL_PACKAGE_VERSION shall be set to the version of the kernel-package that created the package. This script shall be called with two arguments, the first being the version of the kernel image, and the second argument being the location of the kernel image itself. Errors in the script shall cause the prerm to fail. Since debconf is in use before the script is called, this script should issue no diagnostic messages to stdout – while the postinst does call db_stop, debconf does not restore stdout, so messages to stdout disappear. This script is run after the scripts in /etc/kernel/prerm.d directory.

Package creator	Status
Debian linux source package	unsupported since v4.6.1-1;
	previously supported
Ubuntu linux source package	unsupported since v4.15.0-18.19;
	previously supported
kernel-package	deprecated

src_postinst_hook
DEPRECATED: Unlike the other hook variables, this is meant for a script run during the post inst of a docs, headers or a source package. Using this hook for the headers package is now being deprecated, at some point the headers post install script shall only run the header_postinst_hook. The path can be a relative path if the script lives in a safe path – that is, if it lives in /bin, /sbin, /usr/bin, or /usr/sbin, or must be an absolute path instead. The environment variable KERNEL_PACKAGE_VERSION shall be set to the version of the kernel-package that created the package. This script shall be called with two arguments, the first being the name of the package being installed (could be kernel source or headers), and the second argument being the version of the package being installed. Errors in the script shall cause the postinst to fail. This script is run after the scripts in /etc/kernel/src_postinst.d directory.

Package creator	Status
Debian linux source package	unsupported
Ubuntu linux source package	unsupported
kernel-package	deprecated

header_postinst_hook
DEPRECATED: Unlike the other hook variables, this is meant for a script run during the post inst of a headers package only. The path can be a relative path if the script lives in a safe path – that is, if it lives in /bin, /sbin, /usr/bin, or /usr/sbin, or must be an absolute path instead. In packages created by kernel-package, the environment variable KERNEL_PACKAGE_VERSION shall be set to the version of the kernel-package that created the package. This script shall be called with two arguments, the first being the name of the package being installed, and the second argument being the version of the package being installed. Errors in the script shall cause the postinst to fail. This script is run after the scripts in /etc/kernel/header_postinst.d directory.

Package creator	Status
Debian linux source package	unsupported
Ubuntu linux source package	unsupported since v4.15.0-18.19;
	previously supported
kernel-package	deprecated

clobber_modules
If set, the preinst shall silently try to move /lib/modules/version out of the way if it is the same version as the image being installed. Use at your own risk. This variable is unset by default.

Package creator	Status
Debian linux source package	ignored
Ubuntu linux source package	ignored
kernel-package	supported

warn_reboot
This variable can be used to turn off the warning given when installing a kernel image which is the same version as the currently running version. If the modules list is changed, the modules dependencies may have been changed, and the modules for the new kernel may not run correctly on the running kernel if the kernel ABI has changed in the meanwhile. It is a good idea to reboot, and this is a note to remind you. If you know what you are doing, you can set this variable to no. This variable is set by default.

Package creator	Status
Debian linux source package	ignored
Ubuntu linux source package	ignored
kernel-package	supported

relink_build_link
This option manipulates the build link created by recent kernels. If the link is a dangling link, and if a the corresponding kernel headers appear to have been installed on the system, a new symlink shall be created to point to them. The default is to relink the build link (YES).

Package creator	Status
Debian linux source package	ignored
Ubuntu linux source package	ignored
kernel-package	supported

force_build_link
This option manipulates the build link created by recent kernels. If the link is a dangling link, a new symlink shall be created to point to kernel headers data in /usr/src, whether they have been installed or not. The default is unset, we don’t create potentially dangling symlinks by default.

Package creator	Status
Debian linux source package	ignored
Ubuntu linux source package	ignored
kernel-package	supported

relink_src_link
This option manipulates the source link created by recent kernels. If the link is a dangling link it is deleted at install time. The default is to relink (delete) the source link (YES).

Package creator	Status
Debian linux source package	ignored
Ubuntu linux source package	ignored
kernel-package	supported

silent_modules
This option has been put in for the people who are vastly irritated on being warned about preexisting modules directory /lib/modules/$version. That directory may belong to an old or defunct kernel image package, in which case problems may arise with leftover modules in that directory tree, or the directory may legitimately exist due to a independent modules package being installed for this kernel version that has already been unpacked. In this latter case the existence of the directory is benign. If you set this variable, you shall no longer be given a chance to abort if a preexisting modules directory /lib/modules/$version is detected. This is unset by default.

Package creator	Status
Debian linux source package	ignored
Ubuntu linux source package	ignored
kernel-package	supported

ignore_depmod_err
If set, does not prompt to continue after a depmod problem in the postinst script. This facilitates automated installs, though it may mask a problem with the kernel image. A diagnostic is still issued. This is unset by default.

Package creator	Status
Debian linux source package	unsupported since v4.4.1-1~exp1;
	previously supported
Ubuntu linux source package	unsupported since v4.15.0-18.19;
	previously ignored
kernel-package	supported

FILES

The file described here is /etc/kernel-img.conf. kernel-common includes example scripts suitable for dropping into /etc/kernel/*.d installed in /usr/share/doc/kernel-common/examples.

AUTHOR

This manual page was written by Manoj Srivastava <[email protected]> and Ben Hutchings <[email protected]> for the Debian GNU/Linux system.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

248 - Linux cli command pgm

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command pgm and provides detailed information about the command pgm, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the pgm.

NAME 🖥️ pgm 🖥️

Netpbm grayscale image format

DESCRIPTION

This program is part of Netpbm(1) .

The PGM format is a lowest common denominator grayscale file format. It is designed to be extremely easy to learn and write programs for. (It’s so simple that most people will simply reverse engineer it because it’s easier than reading this specification).

A PGM image represents a grayscale graphic image. There are many pseudo-PGM formats in use where everything is as specified herein except for the meaning of individual pixel values. For most purposes, a PGM image can just be thought of an array of arbitrary integers, and all the programs in the world that think they’re processing a grayscale image can easily be tricked into processing something else.

The name “PGM” is an acronym derived from “Portable Gray Map.”

One official variant of PGM is the transparency mask. A transparency mask in Netpbm is represented by a PGM image, except that in place of pixel intensities, there are opaqueness values. See below.

THE FORMAT

The format definition is as follows. You can use the libnetpbm(1) C subroutine library to conveniently and accurately read and interpret the format.

A PGM file consists of a sequence of one or more PGM images. There are no data, delimiters, or padding before, after, or between images.

Each PGM image consists of the following:

A “magic number” for identifying the file type. A pgm image’s magic number is the two characters “P5”.
Whitespace (blanks, TABs, CRs, LFs).
A width, formatted as ASCII characters in decimal.
Whitespace.
A height, again in ASCII decimal.
Whitespace.
The maximum gray value (Maxval), again in ASCII decimal. Must be less than 65536, and more than zero.
A single whitespace character (usually a newline).
A raster of Height rows, in order from top to bottom. Each row consists of Width gray values, in order from left to right. Each gray value is a number from 0 through Maxval, with 0 being black and Maxval being white. Each gray value is represented in pure binary by either 1 or 2 bytes. If the Maxval is less than 256, it is 1 byte. Otherwise, it is 2 bytes. The most significant byte is first.

A row of an image is horizontal. A column is vertical. The pixels in the image are square and contiguous.

Each gray value is a number proportional to the intensity of the pixel, adjusted by the ITU-R Recommendation BT.709 gamma transfer function. (That transfer function specifies a gamma number of 2.2 and has a linear section for small intensities). A value of zero is therefore black. A value of Maxval represents CIE D65 white and the most intense value in the image and any other image to which the image might be compared.

BT.709’s range of channel values (16-240) is irrelevant to PGM.

Note that a common variation from the PGM format is to have the gray value be “linear,” i.e. as specified above except without the gamma adjustment. pnmgamma takes such a PGM variant as input and produces a true PGM as output.

Another popular variation from PGM is to substitute the newer sRGB transfer function for the BT.709 one. You can use pnmgamma to convert between this variation and true PGM.

In the transparency mask variation from PGM, the value represents opaqueness. It is proportional to the fraction of intensity of a pixel that would show in place of an underlying pixel. So what normally means white represents total opaqueness and what normally means black represents total transparency. In between, you would compute the intensity of a composite pixel of an “under” and “over” pixel as under * (1-(alpha/alpha_maxval)) + over * (alpha/alpha_maxval). Note that there is no gamma transfer function in the transparency mask.

Strings starting with “#” may be comments, the same as with PBM(1) .

Note that you can use pamdepth to convert between a the format with 1 byte per gray value and the one with 2 bytes per gray value.

Plain PGM

There is actually another version of the PGM format that is fairly rare: “plain” PGM format. The format above, which generally considered the normal one, is known as the “raw” PGM format. See pbm(1) for some commentary on how plain and raw formats relate to one another and how to use them.

The difference in the plain format is:

There is exactly one image in a file.
The magic number is P2 instead of P5.
Each pixel in the raster is represented as an ASCII decimal number (of arbitrary size).
Each pixel in the raster has white space before and after it. There must be at least one character of white space between any two pixels, but there is no maximum.
No line should be longer than 70 characters.

Here is an example of a small image in the plain PGM format.

P2
# feep.pgm
24 7
15
0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
0  3  3  3  3  0  0  7  7  7  7  0  0 11 11 11 11  0  0 15 15 15 15  0
0  3  0  0  0  0  0  7  0  0  0  0  0 11  0  0  0  0  0 15  0  0 15  0
0  3  3  3  0  0  0  7  7  7  0  0  0 11 11 11  0  0  0 15 15 15 15  0
0  3  0  0  0  0  0  7  0  0  0  0  0 11  0  0  0  0  0 15  0  0  0  0
0  3  0  0  0  0  0  7  7  7  7  0  0 11 11 11 11  0  0 15  0  0  0  0
0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0

There is a newline character at the end of each of these lines.

Programs that read this format should be as lenient as possible, accepting anything that looks remotely like a PGM.

INTERNET MEDIA TYPE

No Internet Media Type (aka MIME type, content type) for PGM has been registered with IANA, but the value image/x-portable-graymap is conventional.

Note that the PNM Internet Media Type image/x-portable-anymap also applies.

FILE NAME

There are no requirements on the name of a PGM file, but the convention is to use the suffix “.pgm”. “pnm” is also conventional, for cases where distinguishing between the particular subformats of PNM is not convenient.

COMPATIBILITY

Before April 2000, a raw format PGM file could not have a maxval greater than 255. Hence, it could not have more than one byte per sample. Old programs may depend on this.

Before July 2000, there could be at most one image in a PGM file. As a result, most tools to process PGM files ignore (and don’t read) any data after the first image.

AUTHOR

DOCUMENT SOURCE

This manual page was generated by the Netpbm tool ‘makeman’ from HTML source. The master documentation is at

http://netpbm.sourceforge.net/doc/pgm.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

249 - Linux cli command proc_pid_setgroups

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_setgroups and provides detailed information about the command proc_pid_setgroups, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_setgroups.

NAME 🖥️ proc_pid_setgroups 🖥️

allow or deny setting groups

DESCRIPTION

/proc/pid/setgroups (since Linux 3.19)
See user_namespaces(7).

250 - Linux cli command hdparm.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command hdparm.conf and provides detailed information about the command hdparm.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the hdparm.conf.

NAME 🖥️ hdparm.conf 🖥️

Debian configuration file for hdparm

DESCRIPTION

This is the default configuration for hdparm for Debian. It is a rather simple script, so please follow the following guidelines :) Any line that begins with a comment is ignored - add as many as you like.

Since hdparm doesn’t use init script anymore, this configuration is mainly used by udev. Still one can re-apply settings from the config file by calling either

/usr/lib/pm-utils/power.d/95hdparm-apm resume

or by calling

DEVNAME=/dev/<disk> /usr/lib/udev/hdparm

Note that an in-line comment is not supported. If a line consists of whitespace only (tabs, spaces, carriage return), it will be ignored, so you can space control fields as you like. ANYTHING ELSE IS PARSED!!

This means that lines with stray characters or lines that use non # comment characters will be interpreted by the initscript. This has probably minor, but potentially serious, side effects for your hard drives, so please follow the guidelines. Patches to improve flexibilty welcome.

Note that if the init script causes boot problems, you can pass ’nohdparm’ on the kernel command line, and the script will not be run.

Setting an option outside of one of the stanzas enables it for all drives.

If an option is listed twice, the second instance replaces the first.

/sbin/hdparm is not run unless a block of the form:

DEV {

option
option
}

exists. This blocks will cause /sbin/hdparm OPTIONS DEV to be run. Where OPTIONS is the concatenation of all options previously defined outside of a block and all options defined with in the block.

OPTIONS

See man 8 hdparm

AUTHOR

hdparm was written by Mark Lord <[email protected]>. The initial manual page was created by Stephen Gran <[email protected]> for the Debian GNU/Linux system (but may be used by others).

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

251 - Linux cli command gitmailmap

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitmailmap and provides detailed information about the command gitmailmap, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitmailmap.

NAME 🖥️ gitmailmap 🖥️

Map author/committer names and/or E-Mail addresses

SYNOPSIS

$GIT_WORK_TREE/.mailmap

DESCRIPTION

If the file .mailmap exists at the toplevel of the repository, or at the location pointed to by the mailmap.file or mailmap.blob configuration options (see git-config(1)), it is used to map author and committer names and email addresses to canonical real names and email addresses.

SYNTAX

The # character begins a comment to the end of line, blank lines are ignored.

In the simple form, each line in the file consists of the canonical real name of an author, whitespace, and an email address used in the commit (enclosed by < and >) to map to the name. For example:

Proper Name [email protected]

The more complex forms are:

[email protected] [email protected]

which allows mailmap to replace only the email part of a commit, and:

Proper Name [email protected] [email protected]

which allows mailmap to replace both the name and the email of a commit matching the specified commit email address, and:

Proper Name [email protected] Commit Name [email protected]

which allows mailmap to replace both the name and the email of a commit matching both the specified commit name and email address.

Both E-Mails and names are matched case-insensitively. For example this would also match the Commit Name <[email protected]> above:

Proper Name [email protected] CoMmIt NaMe [email protected]

NOTES

Git does not follow symbolic links when accessing a .mailmap file in the working tree. This keeps behavior consistent when the file is accessed from the index or a tree versus from the filesystem.

EXAMPLES

Your history contains commits by two authors, Jane and Joe, whose names appear in the repository under several forms:

Joe Developer [email protected] Joe R. Developer [email protected] Jane Doe [email protected] Jane Doe <jane@laptop.(none)> Jane D. <jane@desktop.(none)>

Now suppose that Joe wants his middle name initial used, and Jane prefers her family name fully spelled out. A .mailmap file to correct the names would look like:

Joe R. Developer [email protected] Jane Doe [email protected] Jane Doe <jane@desktop.(none)>

Note that there’s no need to map the name for <jane@laptop.(none)> to only correct the names. However, leaving the obviously broken <jane@laptop.(none)> and <jane@desktop.(none)> E-Mails as-is is usually not what you want. A .mailmap file which also corrects those is:

Joe R. Developer [email protected] Jane Doe [email protected] <jane@laptop.(none)> Jane Doe [email protected] <jane@desktop.(none)>

Finally, let’s say that Joe and Jane shared an E-Mail address, but not a name, e.g. by having these two commits in the history generated by a bug reporting system. I.e. names appearing in history as:

Joe [email protected] Jane [email protected]

A full .mailmap file which also handles those cases (an addition of two lines to the above example) would be:

Joe R. Developer [email protected] Jane Doe [email protected] <jane@laptop.(none)> Jane Doe [email protected] <jane@desktop.(none)> Joe R. Developer [email protected] Joe [email protected] Jane Doe [email protected] Jane [email protected]

GIT

Part of the git(1) suite

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

252 - Linux cli command dhclient.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command dhclient.conf and provides detailed information about the command dhclient.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the dhclient.conf.

NAME 🖥️ dhclient.conf 🖥️

DHCP client configuration file

DESCRIPTION

The dhclient.conf file contains configuration information for dhclient, the Internet Systems Consortium DHCP Client.

The dhclient.conf file is a free-form ASCII text file. It is parsed by the recursive-descent parser built into dhclient. The file may contain extra tabs and newlines for formatting purposes. Keywords in the file are case-insensitive. Comments may be placed anywhere within the file (except within quotes). Comments begin with the # character and end at the end of the line.

The dhclient.conf file can be used to configure the behaviour of the client in a wide variety of ways: protocol timing, information requested from the server, information required of the server, defaults to use if the server does not provide certain information, values with which to override information provided by the server, or values to prepend or append to information provided by the server. The configuration file can also be preinitialized with addresses to use on networks that don’t have DHCP servers.

PROTOCOL TIMING

The timing behaviour of the client need not be configured by the user. If no timing configuration is provided by the user, a fairly reasonable timing behaviour will be used by default - one which results in fairly timely updates without placing an inordinate load on the server.

If required the following statements can be used to adjust the timing behaviour of the DHCPv4 client. The DHCPv6 protocol provides values to use and they are not currently configurable.

The timeout statement

timeout time**;**

The timeout statement determines the amount of time that must pass between the time that the client begins to try to determine its address and the time that it decides that it’s not going to be able to contact a server. By default, this timeout is sixty seconds. After the timeout has passed, if there are any static leases defined in the configuration file, or any leases remaining in the lease database that have not yet expired, the client will loop through these leases attempting to validate them, and if it finds one that appears to be valid, it will use that lease’s address. If there are no valid static leases or unexpired leases in the lease database, the client will restart the protocol after the defined retry interval.

The retry statement

retry time**;**

The retry statement determines the time that must pass after the client has determined that there is no DHCP server present before it tries again to contact a DHCP server. By default, this is five minutes.

The select-timeout statement

select-timeout time**;**

It is possible (some might say desirable) for there to be more than one DHCP server serving any given network. In this case, it is possible that a client may be sent more than one offer in response to its initial lease discovery message. It may be that one of these offers is preferable to the other (e.g., one offer may have the address the client previously used, and the other may not).

The select-timeout is the time after the client sends its first lease discovery request at which it stops waiting for offers from servers, assuming that it has received at least one such offer. If no offers have been received by the time the select-timeout has expired, the client will accept the first offer that arrives.

By default, the select-timeout is zero seconds - that is, the client will take the first offer it sees.

The reboot statement

reboot time**;**

When the client is restarted, it first tries to reacquire the last address it had. This is called the INIT-REBOOT state. If it is still attached to the same network it was attached to when it last ran, this is the quickest way to get started. The reboot statement sets the time that must elapse after the client first tries to reacquire its old address before it gives up and tries to discover a new address. By default, the reboot timeout is ten seconds.

The backoff-cutoff statement

backoff-cutoff time**;**

The client uses an exponential backoff algorithm with some randomness, so that if many clients try to configure themselves at the same time, they will not make their requests in lockstep. The backoff-cutoff statement determines the maximum amount of time that the client is allowed to back off, the actual value will be evaluated randomly between 1/2 to 1 1/2 times the time specified. It defaults to fifteen seconds.

The initial-interval statement

initial-interval time**;**

The initial-interval statement sets the amount of time between the first attempt to reach a server and the second attempt to reach a server. Each time a message is sent, the interval between messages is incremented by twice the current interval multiplied by a random number between zero and one. If it is greater than the backoff-cutoff amount, it is set to that amount. It defaults to ten seconds.

The initial-delay statement

initial-delay time**;**

initial-delay parameter sets the maximum time client can wait after start before commencing first transmission. According to RFC2131 Section 4.4.1, client should wait a random time between startup and the actual first transmission. Previous versions of ISC DHCP client used to wait random time up to 5 seconds, but that was unwanted due to impact on startup time. As such, new versions have the default initial delay set to 0. To restore old behavior, please set initial-delay to 5.

DHCPv6 LEASE SELECTION

In the DHCPv6 protocol the client will wait a small amount of time to allow ADVERTISE messages from multiple servers to arrive. It will then need to choose from all of the messages that may have arrived before proceeding to making a request of the selected server.

The first selection criteria is the set of options and addresses in the message. Messages that don’t include an option specified as required will be given a score of 0 and not used. If the -R option is given on the command line then messages that don’t include the correct number of bindings (IA-NA, IA-TA or IA-PD) will be discarded.

The next criteria is the preference value from the message. With the highest preference value being used even if leases with better addresses or options are available.

Finally the lease is scored and the lease with the highest score is selected. A lease’s score is based on the number of bindings, number of addresses and number of options it contains:

	bindings * X + addresses * Y + options

By default X = 10000 and Y = 100, this will cause the client to select a lease with more bindings over a lease with less bindings but more addresses. The weightings were changed as part of implementing RFC 7550. Previously they were X = 50 and Y = 100 meaning more addresses were preferred over more bindings. If you wish to continue using the old style you may do so by editing the file includes/site.h and uncommenting the define for USE_ORIGINAL_CLIENT_LEASE_WEIGHTS.

LEASE REQUIREMENTS AND REQUESTS

The DHCP protocol allows the client to request that the server send it specific information, and not send it other information that it is not prepared to accept. The protocol also allows the client to reject offers from servers if they don’t contain information the client needs, or if the information provided is not satisfactory.

There is a variety of data contained in offers that DHCP servers send to DHCP clients. The data that can be specifically requested is what are called DHCP Options. DHCP Options are defined in dhcp-options(5).

The request statement

[ also ] request [ [ option-space . ] option ] [, … ];

The request statement causes the client to request that any server responding to the client send the client its values for the specified options. Only the option names should be specified in the request statement - not option parameters. By default, the DHCPv4 client requests the subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers and host-name options while the DHCPv6 client requests the dhcp6 name-servers and domain-search options. Note that if you enter a ‘request’ statement, you over-ride these defaults and these options will not be requested.

In some cases, it may be desirable to send no parameter request list at all. To do this, simply write the request statement but specify no parameters:

	request;

In most cases, it is desirable to simply add one option to the request list which is of interest to the client in question. In this case, it is best to ‘also request’ the additional options:

	also request domain-search, dhcp6.sip-servers-addresses;

The require statement

[ also ] require [ [ option-space . ] option ] [, … ];

The require statement lists options that must be sent in order for an offer to be accepted. Offers that do not contain all the listed options will be ignored. There is no default require list.

	require name-servers;

	interface eth0 {
		also require domain-search;
	}

The send statement

send [ option declaration ] ;

The send statement causes the client to send the specified option to the server with the specified value. This is a full option declaration as described in dhcp-options(5). Options that are always sent in the DHCP protocol should not be specified here, except that the client can specify a requested dhcp-lease-time option other than the default requested lease time, which is two hours. The other obvious use for this statement is to send information to the server that will allow it to differentiate between this client and other clients or kinds of clients.

DYNAMIC DNS

The client now has some very limited support for doing DNS updates when a lease is acquired. This is prototypical, and probably doesn’t do what you want. It also only works if you happen to have control over your DNS server, which isn’t very likely.

Note that everything in this section is true whether you are using DHCPv4 or DHCPv6. The exact same syntax is used for both.

To make it work, you have to declare a key and zone as in the DHCP server (see dhcpd.conf(5) for details). You also need to configure the fqdn option on the client, as follows:

  send fqdn.fqdn "grosse.example.com.";
  send fqdn.encoded on;
  send fqdn.server-update off;
  also request fqdn, dhcp6.fqdn;

The fqdn.fqdn option MUST be a fully-qualified domain name. You MUST define a zone statement for the zone to be updated. The fqdn.encoded option may need to be set to on or off, depending on the DHCP server you are using.

The do-forward-updates statement

do-forward-updates [ flag ] ;

If you want to do DNS updates in the DHCP client script (see dhclient-script(8)) rather than having the DHCP client do the update directly (for example, if you want to use SIG(0) authentication, which is not supported directly by the DHCP client, you can instruct the client not to do the update using the do-forward-updates statement. Flag should be true if you want the DHCP client to do the update, and false if you don’t want the DHCP client to do the update. By default, the DHCP client will do the DNS update.

OPTION MODIFIERS

In some cases, a client may receive option data from the server which is not really appropriate for that client, or may not receive information that it needs, and for which a useful default value exists. It may also receive information which is useful, but which needs to be supplemented with local information. To handle these needs, several option modifiers are available.

The default statement

default [ option declaration ] ;

If for some option the client should use the value supplied by the server, but needs to use some default value if no value was supplied by the server, these values can be defined in the default statement.

The supersede statement

supersede [ option declaration ] ;

If for some option the client should always use a locally-configured value or values rather than whatever is supplied by the server, these values can be defined in the supersede statement.

The prepend statement

prepend [ option declaration ] ;

If for some set of options the client should use a value you supply, and then use the values supplied by the server, if any, these values can be defined in the prepend statement. The prepend statement can only be used for options which allow more than one value to be given. This restriction is not enforced - if you ignore it, the behaviour will be unpredictable.

The append statement

append [ option declaration ] ;

If for some set of options the client should first use the values supplied by the server, if any, and then use values you supply, these values can be defined in the append statement. The append statement can only be used for options which allow more than one value to be given. This restriction is not enforced - if you ignore it, the behaviour will be unpredictable.

LEASE DECLARATIONS

The lease declaration

lease { lease-declaration [ … lease-declaration ] }

The DHCP client may decide after some period of time (see PROTOCOL TIMING) that it is not going to succeed in contacting a server. At that time, it consults its own database of old leases and tests each one that has not yet timed out by pinging the listed router for that lease to see if that lease could work. It is possible to define one or more fixed leases in the client configuration file for networks where there is no DHCP or BOOTP service, so that the client can still automatically configure its address. This is done with the lease statement.

NOTE: the lease statement is also used in the dhclient.leases file in order to record leases that have been received from DHCP servers. Some of the syntax for leases as described below is only needed in the dhclient.leases file. Such syntax is documented here for completeness.

A lease statement consists of the lease keyword, followed by a left curly brace, followed by one or more lease declaration statements, followed by a right curly brace. The following lease declarations are possible:

bootp;

The bootp statement is used to indicate that the lease was acquired using the BOOTP protocol rather than the DHCP protocol. It is never necessary to specify this in the client configuration file. The client uses this syntax in its lease database file.

interface "string";

The interface lease statement is used to indicate the interface on which the lease is valid. If set, this lease will only be tried on a particular interface. When the client receives a lease from a server, it always records the interface number on which it received that lease. If predefined leases are specified in the dhclient.conf file, the interface should also be specified, although this is not required.

fixed-address ip-address**;**

The fixed-address statement is used to set the ip address of a particular lease. This is required for all lease statements. The IP address must be specified as a dotted quad (e.g., 12.34.56.78).

filename “string”;

The filename statement specifies the name of the boot filename to use. This is not used by the standard client configuration script, but is included for completeness.

server-name “string”;

The server-name statement specifies the name of the boot server name to use. This is also not used by the standard client configuration script.

option option-declaration**;**

The option statement is used to specify the value of an option supplied by the server, or, in the case of predefined leases declared in dhclient.conf, the value that the user wishes the client configuration script to use if the predefined lease is used.

script “script-name”;

The script statement is used to specify the pathname of the dhcp client configuration script. This script is used by the dhcp client to set each interface’s initial configuration prior to requesting an address, to test the address once it has been offered, and to set the interface’s final configuration once a lease has been acquired. If no lease is acquired, the script is used to test predefined leases, if any, and also called once if no valid lease can be identified. For more information, see dhclient-script(8).

vendor option space “name”;

The vendor option space statement is used to specify which option space should be used for decoding the vendor-encapsulate-options option if one is received. The dhcp-vendor-identifier can be used to request a specific class of vendor options from the server. See dhcp-options(5) for details.

medium “media setup”;

The medium statement can be used on systems where network interfaces cannot automatically determine the type of network to which they are connected. The media setup string is a system-dependent parameter which is passed to the dhcp client configuration script when initializing the interface. On Unix and Unix-like systems, the argument is passed on the ifconfig command line when configuring the interface.

The dhcp client automatically declares this parameter if it uses a media type (see the media statement) when configuring the interface in order to obtain a lease. This statement should be used in predefined leases only if the network interface requires media type configuration.

renew date**;**

rebind date**;**

expire date**;**

The renew statement defines the time at which the dhcp client should begin trying to contact its server to renew a lease that it is using. The rebind statement defines the time at which the dhcp client should begin to try to contact any dhcp server in order to renew its lease. The expire statement defines the time at which the dhcp client must stop using a lease if it has not been able to contact a server in order to renew it.

These declarations are automatically set in leases acquired by the DHCP client, but must also be configured in predefined leases - a predefined lease whose expiry time has passed will not be used by the DHCP client.

Dates are specified in one of two ways. The software will output times in these two formats depending on if the db-time-format configuration parameter has been set to default or local.

If it is set to default, then date values appear as follows:

<weekday> <year>/<month>/<day> <hour>:<minute>:<second>

The weekday is present to make it easy for a human to tell when a lease expires - it’s specified as a number from zero to six, with zero being Sunday. When declaring a predefined lease, it can always be specified as zero. The year is specified with the century, so it should generally be four digits except for really long leases. The month is specified as a number starting with 1 for January. The day of the month is likewise specified starting with 1. The hour is a number between 0 and 23, the minute a number between 0 and 59, and the second also a number between 0 and 59.

If the db-time-format configuration was set to local, then the date values appear as follows:

epoch <seconds-since-epoch>; # <day-name> <month-name> <day-number> <hours>:<minutes>:<seconds> <year>

The seconds-since-epoch is as according to the system’s local clock (often referred to as “unix time”). The # symbol supplies a comment that describes what actual time this is as according to the system’s configured timezone, at the time the value was written. It is provided only for human inspection, the epoch time is the only recommended value for machine inspection.

Note that when defining a static lease, one may use either time format one wishes, and need not include the comment or values after it.

If the time is infinite in duration, then the date is never instead of an actual date.

ALIAS DECLARATIONS

alias { declarations … }

Some DHCP clients running TCP/IP roaming protocols may require that in addition to the lease they may acquire via DHCP, their interface also be configured with a predefined IP alias so that they can have a permanent IP address even while roaming. The Internet Systems Consortium DHCP client doesn’t support roaming with fixed addresses directly, but in order to facilitate such experimentation, the dhcp client can be set up to configure an IP alias using the alias declaration.

The alias declaration resembles a lease declaration, except that options other than the subnet-mask option are ignored by the standard client configuration script, and expiry times are ignored. A typical alias declaration includes an interface declaration, a fixed-address declaration for the IP alias address, and a subnet-mask option declaration. A medium statement should never be included in an alias declaration.

OTHER DECLARATIONS

db-time-format [ default | local ] ;

The db-time-format option determines which of two output methods are used for printing times in leases files. The default format provides day-and-time in UTC, whereas local uses a seconds-since-epoch to store the time value, and helpfully places a local timezone time in a comment on the same line. The formats are described in detail in this manpage, within the LEASE DECLARATIONS section.

The lease-id-format parameter

lease-id-format format;****
The format parameter must be either octal or hex. This parameter governs the format used to write certain values to lease files. With the default format, octal, values are written as quoted strings in which non-printable characters are represented as octal escapes - a backslash character followed by three octal digits. When the hex format is specified, values are written as an unquoted series of hexadecimal digit pairs, separated by colons.
Currently, the values written out based on lease-id-format are the default-duid and the IAID value (DHCPv6 only). The client automatically reads the values in either format. Note that when the format is octal, rather than as an octal string, IAID is output as hex if it contains no printable characters or as a string if contains only printable characters. This is done to maintain backward compatibility.
reject cidr-ip-address [, … cidr-ip-address ] ;
The reject statement causes the DHCP client to reject offers from servers whose server identifier matches any of the specified hosts or subnets. This can be used to avoid being configured by rogue or misconfigured dhcp servers, although it should be a last resort - better to track down the bad DHCP server and fix it.
The cidr-ip-address configuration type is of the form ip-address[**/**prefixlen], where ip-address is a dotted quad IP address, and prefixlen is the CIDR prefix length of the subnet, counting the number of significant bits in the netmask starting from the leftmost end. Example configuration syntax:
reject 192.168.0.0*/16,** 10.0.0.5**;***
The above example would cause offers from any server identifier in the entire RFC 1918 “Class C” network 192.168.0.0/16, or the specific single address 10.0.0.5, to be rejected.
interface “name” { declarations … }
A client with more than one network interface may require different behaviour depending on which interface is being configured. All timing parameters and declarations other than lease and alias declarations can be enclosed in an interface declaration, and those parameters will then be used only for the interface that matches the specified name. Interfaces for which there is no interface declaration will use the parameters declared outside of any interface declaration, or the default settings.
Note well: ISC dhclient only maintains one list of interfaces, which is either determined at startup from command line arguments, or otherwise is autodetected. If you supplied the list of interfaces on the command line, this configuration clause will add the named interface to the list in such a way that will cause it to be configured by DHCP. Which may not be the result you had intended. This is an undesirable side effect that will be addressed in a future release.
pseudo “name” “real-name” { declarations … }
Under some circumstances it can be useful to declare a pseudo-interface and have the DHCP client acquire a configuration for that interface. Each interface that the DHCP client is supporting normally has a DHCP client state machine running on it to acquire and maintain its lease. A pseudo-interface is just another state machine running on the interface named real-name, with its own lease and its own state. If you use this feature, you must provide a client identifier for both the pseudo-interface and the actual interface, and the two identifiers must be different. You must also provide a separate client script for the pseudo-interface to do what you want with the IP address. For example:
	interface "ep0" {
		send dhcp-client-identifier "my-client-ep0";
	}
	pseudo "secondary" "ep0" {
		send dhcp-client-identifier "my-client-ep0-secondary";
		script "/etc/dhclient-secondary";
	}
The client script for the pseudo-interface should not configure the interface up or down - essentially, all it needs to handle are the states where a lease has been acquired or renewed, and the states where a lease has expired. See dhclient-script(8) for more information.
media “media setup” [ , “media setup”, … ];
The media statement defines one or more media configuration parameters which may be tried while attempting to acquire an IP address. The dhcp client will cycle through each media setup string on the list, configuring the interface using that setup and attempting to boot, and then trying the next one. This can be used for network interfaces which aren’t capable of sensing the media type unaided - whichever media type succeeds in getting a request to the server and hearing the reply is probably right (no guarantees).
The media setup is only used for the initial phase of address acquisition (the DHCPDISCOVER and DHCPOFFER packets). Once an address has been acquired, the dhcp client will record it in its lease database and will record the media type used to acquire the address. Whenever the client tries to renew the lease, it will use that same media type. The lease must expire before the client will go back to cycling through media types.
hardware link-type mac-address**;**
The hardware statement defines the hardware MAC address to use for this interface, for DHCP servers or relays to direct their replies. dhclient will determine the interface’s MAC address automatically, so use of this parameter is not recommended. The link-type corresponds to the interface’s link layer type (example: ’ethernet’), while the mac-address is a string of colon-separated hexadecimal values for octets.
anycast-mac link-type mac-address**;**
The anycast-mac statement over-rides the all-ones broadcast MAC address dhclient will use when it is transmitting packets to the all-ones limited broadcast IPv4 address. This configuration parameter is useful to reduce the number of broadcast packets transmitted by DHCP clients, but is only useful if you know the DHCP service(s) anycast MAC address prior to configuring your client. The link-type and mac-address parameters are configured in a similar manner to the hardware statement.

SAMPLE

The following configuration file was used on a laptop running NetBSD 1.3, though the domains have been modified. The laptop has an IP alias of 192.5.5.213, and has one interface, ep0 (a 3com 3C589C). Booting intervals have been shortened somewhat from the default, because the client is known to spend most of its time on networks with little DHCP activity. The laptop does roam to multiple networks.

timeout 60;
retry 60;
reboot 10;
select-timeout 5;
initial-interval 2;
reject 192.33.137.209;

interface "ep0" {
    send host-name "andare.example.com";
    hardware ethernet 00:a0:24:ab:fb:9c;
    send dhcp-client-identifier 1:0:a0:24:ab:fb:9c;
    send dhcp-lease-time 3600;
    supersede domain-search "example.com", "rc.isc.org", "home.isc.org";
    prepend domain-name-servers 127.0.0.1;
    request subnet-mask, broadcast-address, time-offset, routers,
	    domain-name, domain-name-servers, host-name;
    require subnet-mask, domain-name-servers;
    script "/usr/sbin/dhclient-script";
    media "media 10baseT/UTP", "media 10base2/BNC";
}

alias {
  interface "ep0";
  fixed-address 192.5.5.213;
  option subnet-mask 255.255.255.255;
}

This is a very complicated dhclient.conf file - in general, yours should be much simpler. In many cases, it’s sufficient to just create an empty dhclient.conf file - the defaults are usually fine.

AUTHOR

dhclient(8) Information about Internet Systems Consortium can be found at https://www.isc.org.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

253 - Linux cli command sysctl.d

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command sysctl.d and provides detailed information about the command sysctl.d, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the sysctl.d.

NAME 🖥️ sysctl.d 🖥️

Configure kernel parameters at boot

SYNOPSIS

/etc/sysctl.d/*.conf

/run/sysctl.d/*.conf

/usr/local/lib/sysctl.d/*.conf

/usr/lib/sysctl.d/*.conf

key.name.under.proc.sys = some value
key/name/under/proc/sys = some value
key/middle.part.with.dots/foo = 123
key.middle/part/with/dots.foo = 123
-key.that.will.not.fail = value
key.pattern.*.with.glob = whatever
-key.pattern.excluded.with.glob
key.pattern.overridden.with.glob = custom

DESCRIPTION

At boot, systemd-sysctl.service(8) reads configuration files from the above directories to configure sysctl(8) kernel parameters.

CONFIGURATION FORMAT

The configuration files contain a list of variable assignments, separated by newlines. Empty lines and lines whose first non-whitespace character is “#” or “;” are ignored.

Note that either “/” or “.” may be used as separators within sysctl variable names. If the first separator is a slash, remaining slashes and dots are left intact. If the first separator is a dot, dots and slashes are interchanged. “kernel.domainname=foo” and “kernel/domainname=foo” are equivalent and will cause “foo” to be written to /proc/sys/kernel/domainname. Either “net.ipv4.conf.enp3s0/200.forwarding” or “net/ipv4/conf/enp3s0.200/forwarding” may be used to refer to /proc/sys/net/ipv4/conf/enp3s0.200/forwarding. A glob glob(7) pattern may be used to write the same value to all matching keys. Keys for which an explicit pattern exists will be excluded from any glob matching. In addition, a key may be explicitly excluded from being set by any matching glob patterns by specifying the key name prefixed with a “-” character and not followed by “=”, see SYNOPSIS.

Any access permission errors and attempts to write variables not present on the local system are logged at debug level and do not cause the service to fail. Other types of errors when setting variables are logged with higher priority and cause the service to return failure at the end (after processing other variables). As an exception, if a variable assignment is prefixed with a single “-” character, failure to set the variable for any reason will be logged at debug level and will not cause the service to fail.

The settings configured with sysctl.d files will be applied early on boot. The network interface-specific options will also be applied individually for each network interface as it shows up in the system. (More specifically, net.ipv4.conf.*, net.ipv6.conf.*, net.ipv4.neigh.* and net.ipv6.neigh.*).

Many sysctl parameters only become available when certain kernel modules are loaded. Modules are usually loaded on demand, e.g. when certain hardware is plugged in or network brought up. This means that systemd-sysctl.service(8) which runs during early boot will not configure such parameters if they become available after it has run. To set such parameters, it is recommended to add an udev(7) rule to set those parameters when they become available. Alternatively, a slightly simpler and less efficient option is to add the module to modules-load.d(5), causing it to be loaded statically before sysctl settings are applied (see example below).

CONFIGURATION DIRECTORIES AND PRECEDENCE

Configuration files are read from directories in /etc/, /run/, /usr/local/lib/, and /usr/lib/, in order of precedence, as listed in the SYNOPSIS section above. Files must have the “.conf” extension. Files in /etc/ override files with the same name in /run/, /usr/local/lib/, and /usr/lib/. Files in /run/ override files with the same name under /usr/.

All configuration files are sorted by their filename in lexicographic order, regardless of which of the directories they reside in. If multiple files specify the same option, the entry in the file with the lexicographically latest name will take precedence. Thus, the configuration in a certain file may either be replaced completely (by placing a file with the same name in a directory with higher priority), or individual settings might be changed (by specifying additional settings in a file with a different name that is ordered later).

Packages should install their configuration files in /usr/lib/ (distribution packages) or /usr/local/lib/ (local installs) [1]. Files in /etc/ are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages.

It is recommended to prefix all filenames with a two-digit number and a dash to simplify the ordering. It is recommended to use the range 10-40 for configuration files in /usr/ and the range 60-90 for configuration files in /etc/ and /run/, to make sure that local and transient configuration files will always take priority over configuration files shipped by the OS vendor.

If the administrator wants to disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in the configuration directory in /etc/, with the same filename as the vendor configuration file. If the vendor configuration file is included in the initrd image, the image has to be regenerated.

EXAMPLES

Example 1. Set kernel YP domain name

/etc/sysctl.d/domain-name.conf:

kernel.domainname=example.com

Example 2. Apply settings available only when a certain module is loaded (method one)

/etc/udev/rules.d/99-bridge.rules:

ACTION==“add”, SUBSYSTEM==“module”, KERNEL==“br_netfilter”,
RUN+="/usr/lib/systemd/systemd-sysctl –prefix=/net/bridge"

/etc/sysctl.d/bridge.conf:

net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-arptables = 0

This method applies settings when the module is loaded. Please note that, unless the br_netfilter module is loaded, bridged packets will not be filtered by Netfilter (starting with kernel 3.18), so simply not loading the module is sufficient to avoid filtering.

Example 3. Apply settings available only when a certain module is loaded (method two)

/etc/modules-load.d/bridge.conf:

br_netfilter

/etc/sysctl.d/bridge.conf:

net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-arptables = 0

This method forces the module to be always loaded. Please note that, unless the br_netfilter module is loaded, bridged packets will not be filtered with Netfilter (starting with kernel 3.18), so simply not loading the module is sufficient to avoid filtering.

Example 4. Set network routing properties for all interfaces

/etc/sysctl.d/20-rp_filter.conf:

net.ipv4.conf.default.rp_filter = 2 net.ipv4.conf.*.rp_filter = 2 -net.ipv4.conf.all.rp_filter net.ipv4.conf.hub0.rp_filter = 1

The rp_filter key will be set to “2” for all interfaces, except “hub0”. We set net.ipv4.conf.default.rp_filter first, so any interfaces which are added later will get this value (this also covers any interfaces detected while were running). The glob matches any interfaces which were detected earlier. The glob will also match net.ipv4.conf.all.rp_filter, which we dont want to set at all, so it is explicitly excluded. And “hub0” is excluded from the glob because it has an explicit setting.

NOTES

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

254 - Linux cli command org.bluez.AdvertisementMonitor

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.AdvertisementMonitor and provides detailed information about the command org.bluez.AdvertisementMonitor, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.AdvertisementMonitor.

NAME 🖥️ org.bluez.AdvertisementMonitor 🖥️

BlueZ D-Bus AdvertisementMonitor API documentation

DESCRIPTION

This API allows an client to specify a job of monitoring advertisements by registering the root of hierarchy and then exposing advertisement monitors under the root with filtering conditions, thresholds of RSSI and timers of RSSI thresholds.

Once a monitoring job is activated by bluetoothd(8), the client can expect to get notified on the targeted advertisements no matter if there is an ongoing discovery session (see StartDiscovery() in org.bluez.Adapter(5)).

INTERFACE

Service
org.bluez
Interface
org.bluez.AdvertisementMonitor1 [experimental]
Object path
freely definable

Methods

void Release() [noreply]

This gets called as a signal for a client to perform clean-up when:
Monitor cannot be activated after it was exposed
Monitor has been deactivated.

void Activate() [noreply]

After a monitor was exposed, this gets called as a signal for client to get acknowledged when a monitor has been activated, so the client can expect to receive calls on DeviceFound() or DeviceLost().

void DeviceFound(object device) [noreply]

This gets called to notify the client of finding the targeted device. Once receiving the call, the client should start to monitor the corresponding device to retrieve the changes on RSSI and advertisement content.

void DeviceLost(object device) [noreply]

This gets called to notify the client of losing the targeted device. Once receiving this call, the client should stop monitoring the corresponding device.

Properties

string Type [read-only]

The type of the monitor. See SupportedMonitorTypes in org.bluez.AdvertisementMonitorManager(5) for the available options.

int16 RSSILowThreshold [read-only, optional]

Used in conjunction with RSSILowTimeout to determine whether a device becomes out-of-range. Valid range is -127 to 20 (dBm), while 127 indicates unset.

int16 RSSIHighThreshold [read-only, optional]

Used in conjunction with RSSIHighTimeout to determine whether a device becomes in-range. Valid range is -127 to 20 (dBm), while 127 indicates unset.

uint16 RSSILowTimeout [read-only, optional]

The time it takes to consider a device as out-of-range. If this many seconds elapses without receiving any signal at least as strong as RSSILowThreshold, a currently in-range device will be considered as out-of-range (lost). Valid range is 1 to 300 (seconds), while 0 indicates unset.

uint16 RSSIHighTimeout [read-only, optional]

The time it takes to consider a device as in-range. If this many seconds elapses while we continuouslyreceive signals at least as strong as RSSIHighThreshold, a currently out-of-range device will be considered as in-range (found). Valid range is 1 to 300 (seconds), while 0 indicates unset.

uint16 RSSISamplingPeriod [read-only, optional]

Grouping rules on how to propagate the received advertisement packets to the client.
Possible values:
0
All advertisement packets from in-range devices would be propagated.
255
Only the first advertisement packet of in-range devices would be propagated. If the device becomes lost, then the first packet when it is found again will also be propagated.
1 to 254
Advertisement packets would be grouped into 100ms * N time period. Packets in the same group will only be reported once, with the RSSI value being averaged out.
Currently this is unimplemented in user space, so the value is only used to be forwarded to the kernel.

array{(uint8, uint8, array{byte})} Patterns [read-only, optional]

If the Type property is set to “or_patterns”, then this property must exist and have at least one entry in the array.
The structure of a pattern contains the following:
uint8 start_position
The index in an AD data field where the search hould start. The beginning of an AD data field is index 0.
uint8 AD_data_type
See https://www.bluetooth.com/specifications/assigned-numbers/ generic-access-profile/ for the possible allowed value.
array{byte} content_of_pattern
This is the value of the pattern. The maximum length of the bytes is 31.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

255 - Linux cli command org.bluez.GattService

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.GattService and provides detailed information about the command org.bluez.GattService, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.GattService.

NAME 🖥️ org.bluez.GattService 🖥️

BlueZ D-Bus GattService API documentation

DESCRIPTION

GATT local/server and remote/client services share the same high-level D-Bus API.

Local/Server refers to GATT based service exported by a plugin or an external application.

Remote/Client refers to GATT services exported by the peer.

INTERFACE

Client

Service
org.bluez
Interface
org.bluez.GattService1
Object path
[variable prefix]/{hci0,hci1,…}/dev_XX_XX_XX_XX_XX_XX/serviceXX

Server

Service
unique name
Interface
org.bluez.GattService1
Object path
freely definable

Properties

string UUID [read-only]

128-bit service UUID.

boolean Primary [read-only]

Indicates whether or not this GATT service is a primary service. If false, the service is secondary.

object Device [read-only, optional]

Object path of the Bluetooth device the service belongs to. Only present on services from remote devices.

array{object} Includes [read-only, optional]

Array of object paths representing the included services of this service.

uint16 Handle [read-only] (client only)

Service handle.

uint16 Handle [read-write, optional] (Server Only)

Service handle. When available in the server it would attempt to use to allocate into the database which may fail, to auto allocate the value 0x0000 shall be used which will cause the allocated handle to be set once registered.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

256 - Linux cli command gitprotocol-pack

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitprotocol-pack and provides detailed information about the command gitprotocol-pack, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitprotocol-pack.

NAME 🖥️ gitprotocol-pack 🖥️

pack - How packs are transferred over-the-wire

SYNOPSIS

<over-the-wire-protocol>

DESCRIPTION

Git supports transferring data in packfiles over the ssh://, git://, http:// and file:// transports. There exist two sets of protocols, one for pushing data from a client to a server and another for fetching data from a server to a client. The three transports (ssh, git, file) use the same protocol to transfer data. http is documented in gitprotocol-http(5).

The processes invoked in the canonical Git implementation are upload-pack on the server side and fetch-pack on the client side for fetching data; then receive-pack on the server and send-pack on the client for pushing data. The protocol functions to have a server tell a client what is currently on the server, then for the two to negotiate the smallest amount of data to send in order to fully update one or the other.

PKT-LINE FORMAT

The descriptions below build on the pkt-line format described in gitprotocol-common(5). When the grammar indicates PKT-LINE(…), unless otherwise noted the usual pkt-line LF rules apply: the sender SHOULD include a LF, but the receiver MUST NOT complain if it is not present.

An error packet is a special pkt-line that contains an error string.

error-line = PKT-LINE(“ERR” SP explanation-text)

Throughout the protocol, where PKT-LINE(…) is expected, an error packet MAY be sent. Once this packet is sent by a client or a server, the data transfer process defined in this protocol is terminated.

TRANSPORTS

There are three transports over which the packfile protocol is initiated. The Git transport is a simple, unauthenticated server that takes the command (almost always upload-pack, though Git servers can be configured to be globally writable, in which receive- pack initiation is also allowed) with which the client wishes to communicate and executes it and connects it to the requesting process.

In the SSH transport, the client just runs the upload-pack or receive-pack process on the server over the SSH protocol and then communicates with that invoked process over the SSH connection.

The file:// transport runs the upload-pack or receive-pack process locally and communicates with it over a pipe.

EXTRA PARAMETERS

The protocol provides a mechanism in which clients can send additional information in its first message to the server. These are called “Extra Parameters”, and are supported by the Git, SSH, and HTTP protocols.

Each Extra Parameter takes the form of <key>=<value> or <key>.

Servers that receive any such Extra Parameters MUST ignore all unrecognized keys. Currently, the only Extra Parameter recognized is “version” with a value of 1 or 2. See gitprotocol-v2(5) for more information on protocol version 2.

GIT TRANSPORT

The Git transport starts off by sending the command and repository on the wire using the pkt-line format, followed by a NUL byte and a hostname parameter, terminated by a NUL byte.

0033git-upload-pack /project.git�host=myserver.com�

The transport may send Extra Parameters by adding an additional NUL byte, and then adding one or more NUL-terminated strings:

003egit-upload-pack /project.git�host=myserver.com��version=1�

git-proto-request = request-command SP pathname NUL [ host-parameter NUL ] [ NUL extra-parameters ] request-command = “git-upload-pack” / “git-receive-pack” / “git-upload-archive” ; case sensitive pathname = ( %x01-ff ) ; exclude NUL host-parameter = “host=” hostname [ “:” port ] extra-parameters = 1extra-parameter extra-parameter = 1*( %x01-ff ) NUL

host-parameter is used for the git-daemon name based virtual hosting. See –interpolated-path option to git daemon, with the %H/%CH format characters.

Basically what the Git client is doing to connect to an upload-pack process on the server side over the Git protocol is this:

$ echo -e -n
“003agit-upload-pack /schacon/gitbook.git�host=example.com�” | nc -v example.com 9418

SSH TRANSPORT

Initiating the upload-pack or receive-pack processes over SSH is executing the binary on the server via SSH remote execution. It is basically equivalent to running this:

$ ssh git.example.com “git-upload-pack /project.git”

For a server to support Git pushing and pulling for a given user over SSH, that user needs to be able to execute one or both of those commands via the SSH shell that they are provided on login. On some systems, that shell access is limited to only being able to run those two commands, or even just one of them.

In an ssh:// format URI, it’s absolute in the URI, so the / after the host name (or port number) is sent as an argument, which is then read by the remote git-upload-pack exactly as is, so it’s effectively an absolute path in the remote filesystem.

git clone ssh://[email protected]/project.git | v ssh [email protected] “git-upload-pack /project.git”

In a “user@host:path” format URI, it’s relative to the user’s home directory, because the Git client will run:

git clone [email protected]:project.git | v ssh [email protected] “git-upload-pack project.git”

The exception is if a ~ is used, in which case we execute it without the leading /.

ssh://[email protected]/~alice/project.git, | v ssh [email protected] “git-upload-pack ~alice/project.git”

Depending on the value of the protocol.version configuration variable, Git may attempt to send Extra Parameters as a colon-separated string in the GIT_PROTOCOL environment variable. This is done only if the ssh.variant configuration variable indicates that the ssh command supports passing environment variables as an argument.

A few things to remember here:

·
The “command name” is spelled with dash (e.g. git-upload-pack), but this can be overridden by the client;

·
The repository path is always quoted with single quotes.

FETCHING DATA FROM A SERVER

When one Git repository wants to get data that a second repository has, the first can fetch from the second. This operation determines what data the server has that the client does not then streams that data down to the client in packfile format.

REFERENCE DISCOVERY

When the client initially connects the server will immediately respond with a version number (if “version=1” is sent as an Extra Parameter), and a listing of each reference it has (all branches and tags) along with the object name that each reference currently points to.

$ echo -e -n “0045git-upload-pack /schacon/gitbook.git�host=example.com��version=1�” | nc -v example.com 9418 000eversion 1 00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD�multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag 00441d3fcd5ced445d1abc402225c0b8a1299641f497 refs/heads/integration 003f7217a7c7e582c46cec22a130adf4b9d7d950fba0 refs/heads/master 003cb88d2441cac0977faf98efc80305012112238d9d refs/tags/v0.9 003c525128480b96c89e6418b1e40909bf6c5b2d580f refs/tags/v1.0 003fe92df48743b7bc7d26bcaabfddde0a1e20cae47c refs/tags/v1.0^{} 0000

The returned response is a pkt-line stream describing each ref and its current value. The stream MUST be sorted by name according to the C locale ordering.

If HEAD is a valid ref, HEAD MUST appear as the first advertised ref. If HEAD is not a valid ref, HEAD MUST NOT appear in the advertisement list at all, but other refs may still appear.

The stream MUST include capability declarations behind a NUL on the first ref. The peeled value of a ref (that is “ref^{}”) MUST be immediately after the ref itself, if presented. A conforming server MUST peel the ref if it’s an annotated tag.

advertised-refs = *1(“version 1”) (no-refs / list-of-refs) *shallow flush-pkt

  no-refs          =  PKT-LINE(zero-id SP "capabilities^{}"
                      NUL capability-list)

  list-of-refs     =  first-ref *other-ref
  first-ref        =  PKT-LINE(obj-id SP refname
                      NUL capability-list)

  other-ref        =  PKT-LINE(other-tip / other-peeled)
  other-tip        =  obj-id SP refname
  other-peeled     =  obj-id SP refname "^{}"

  shallow          =  PKT-LINE("shallow" SP obj-id)

  capability-list  =  capability *(SP capability)
  capability       =  1*(LC_ALPHA / DIGIT / "-" / "_")
  LC_ALPHA         =  %x61-7A

Server and client MUST use lowercase for obj-id, both MUST treat obj-id as case-insensitive.

See protocol-capabilities.txt for a list of allowed server capabilities and descriptions.

PACKFILE NEGOTIATION

After reference and capabilities discovery, the client can decide to terminate the connection by sending a flush-pkt, telling the server it can now gracefully terminate, and disconnect, when it does not need any pack data. This can happen with the ls-remote command, and also can happen when the client already is up to date.

Otherwise, it enters the negotiation phase, where the client and server determine what the minimal packfile necessary for transport is, by telling the server what objects it wants, its shallow objects (if any), and the maximum commit depth it wants (if any). The client will also send a list of the capabilities it wants to be in effect, out of what the server said it could do with the first want line.

upload-request = want-list *shallow-line *1depth-request [filter-request] flush-pkt

  want-list         =  first-want
                       *additional-want

  shallow-line      =  PKT-LINE("shallow" SP obj-id)

  depth-request     =  PKT-LINE("deepen" SP depth) /
                       PKT-LINE("deepen-since" SP timestamp) /
                       PKT-LINE("deepen-not" SP ref)

  first-want        =  PKT-LINE("want" SP obj-id SP capability-list)
  additional-want   =  PKT-LINE("want" SP obj-id)

  depth             =  1*DIGIT

  filter-request    =  PKT-LINE("filter" SP filter-spec)

Clients MUST send all the obj-ids it wants from the reference discovery phase as want lines. Clients MUST send at least one want command in the request body. Clients MUST NOT mention an obj-id in a want command which did not appear in the response obtained through ref discovery.

The client MUST write all obj-ids which it only has shallow copies of (meaning that it does not have the parents of a commit) as shallow lines so that the server is aware of the limitations of the client’s history.

The client now sends the maximum commit history depth it wants for this transaction, which is the number of commits it wants from the tip of the history, if any, as a deepen line. A depth of 0 is the same as not making a depth request. The client does not want to receive any commits beyond this depth, nor does it want objects needed only to complete those commits. Commits whose parents are not received as a result are defined as shallow and marked as such in the server. This information is sent back to the client in the next step.

The client can optionally request that pack-objects omit various objects from the packfile using one of several filtering techniques. These are intended for use with partial clone and partial fetch operations. An object that does not meet a filter-spec value is omitted unless explicitly requested in a want line. See rev-list for possible filter-spec values.

Once all the want’s and shallow’s (and optional deepen) are transferred, clients MUST send a flush-pkt, to tell the server side that it is done sending the list.

Otherwise, if the client sent a positive depth request, the server will determine which commits will and will not be shallow and send this information to the client. If the client did not request a positive depth, this step is skipped.

shallow-update = *shallow-line *unshallow-line flush-pkt
  shallow-line     =  PKT-LINE("shallow" SP obj-id)

  unshallow-line   =  PKT-LINE("unshallow" SP obj-id)

If the client has requested a positive depth, the server will compute the set of commits which are no deeper than the desired depth. The set of commits starts at the client’s wants.

The server writes shallow lines for each commit whose parents will not be sent as a result. The server writes an unshallow line for each commit which the client has indicated is shallow, but is no longer shallow at the currently requested depth (that is, its parents will now be sent). The server MUST NOT mark as unshallow anything which the client has not indicated was shallow.

Now the client will send a list of the obj-ids it has using have lines, so the server can make a packfile that only contains the objects that the client needs. In multi_ack mode, the canonical implementation will send up to 32 of these at a time, then will send a flush-pkt. The canonical implementation will skip ahead and send the next 32 immediately, so that there is always a block of 32 “in-flight on the wire” at a time.

upload-haves = have-list compute-end

  have-list         =  *have-line
  have-line         =  PKT-LINE("have" SP obj-id)
  compute-end       =  flush-pkt / PKT-LINE("done")

If the server reads have lines, it then will respond by ACKing any of the obj-ids the client said it had that the server also has. The server will ACK obj-ids differently depending on which ack mode is chosen by the client.

In multi_ack mode:

·
the server will respond with ACK obj-id continue for any common commits.

·
once the server has found an acceptable common base commit and is ready to make a packfile, it will blindly ACK all have obj-ids back to the client.

·
the server will then send a NAK and then wait for another response from the client - either a done or another list of have lines.

In multi_ack_detailed mode:

·
the server will differentiate the ACKs where it is signaling that it is ready to send data with ACK obj-id ready lines, and signals the identified common commits with ACK obj-id common lines.

Without either multi_ack or multi_ack_detailed:

·
upload-pack sends “ACK obj-id” on the first common object it finds. After that it says nothing until the client gives it a “done”.

·
upload-pack sends “NAK” on a flush-pkt if no common object has been found yet. If one has been found, and thus an ACK was already sent, it’s silent on the flush-pkt.

After the client has gotten enough ACK responses that it can determine that the server has enough information to send an efficient packfile (in the canonical implementation, this is determined when it has received enough ACKs that it can color everything left in the –date-order queue as common with the server, or the –date-order queue is empty), or the client determines that it wants to give up (in the canonical implementation, this is determined when the client sends 256 have lines without getting any of them ACKed by the server - meaning there is nothing in common and the server should just send all of its objects), then the client will send a done command. The done command signals to the server that the client is ready to receive its packfile data.

However, the 256 limit only turns on in the canonical client implementation if we have received at least one “ACK %s continue” during a prior round. This helps to ensure that at least one common ancestor is found before we give up entirely.

Once the done line is read from the client, the server will either send a final ACK obj-id or it will send a NAK. obj-id is the object name of the last commit determined to be common. The server only sends ACK after done if there is at least one common base and multi_ack or multi_ack_detailed is enabled. The server always sends NAK after done if there is no common base found.

Instead of ACK or NAK, the server may send an error message (for example, if it does not recognize an object in a want line received from the client).

Then the server will start sending its packfile data.

server-response = *ack_multi ack / nak ack_multi = PKT-LINE(“ACK” SP obj-id ack_status) ack_status = “continue” / “common” / “ready” ack = PKT-LINE(“ACK” SP obj-id) nak = PKT-LINE(“NAK”)

A simple clone may look like this (with no have lines):

C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d multi_ack
side-band-64k ofs-delta

   C: 0032want 7d1665144a3a975c05f1f43902ddaf084e784dbe

   C: 0032want 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a

   C: 0032want 7e47fe2bd8d01d481f44d7af0531bd93d3b21c01

   C: 0032want 74730d410fcb6603ace96f1dc55ea6196122532d

   C: 0000
   C: 0009done

   S: 0008NAK

   S: [PACKFILE]

An incremental update (fetch) response might look like this:

C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d multi_ack
side-band-64k ofs-delta

   C: 0032want 7d1665144a3a975c05f1f43902ddaf084e784dbe

   C: 0032want 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a

   C: 0000
   C: 0032have 7e47fe2bd8d01d481f44d7af0531bd93d3b21c01

   C: [30 more have lines]
   C: 0032have 74730d410fcb6603ace96f1dc55ea6196122532d

   C: 0000

   S: 003aACK 7e47fe2bd8d01d481f44d7af0531bd93d3b21c01 continue

   S: 003aACK 74730d410fcb6603ace96f1dc55ea6196122532d continue

   S: 0008NAK

   C: 0009done

   S: 0031ACK 74730d410fcb6603ace96f1dc55ea6196122532d

   S: [PACKFILE]

PACKFILE DATA

Now that the client and server have finished negotiation about what the minimal amount of data that needs to be sent to the client is, the server will construct and send the required data in packfile format.

See gitformat-pack(5) for what the packfile itself actually looks like.

If side-band or side-band-64k capabilities have been specified by the client, the server will send the packfile data multiplexed.

Each packet starting with the packet-line length of the amount of data that follows, followed by a single byte specifying the sideband the following data is coming in on.

In side-band mode, it will send up to 999 data bytes plus 1 control code, for a total of up to 1000 bytes in a pkt-line. In side-band-64k mode it will send up to 65519 data bytes plus 1 control code, for a total of up to 65520 bytes in a pkt-line.

The sideband byte will be a 1, 2 or a 3. Sideband 1 will contain packfile data, sideband 2 will be used for progress information that the client will generally print to stderr and sideband 3 is used for error information.

If no side-band capability was specified, the server will stream the entire packfile without multiplexing.

PUSHING DATA TO A SERVER

Pushing data to a server will invoke the receive-pack process on the server, which will allow the client to tell it which references it should update and then send all the data the server will need for those new references to be complete. Once all the data is received and validated, the server will then update its references to what the client specified.

AUTHENTICATION

The protocol itself contains no authentication mechanisms. That is to be handled by the transport, such as SSH, before the receive-pack process is invoked. If receive-pack is configured over the Git transport, those repositories will be writable by anyone who can access that port (9418) as that transport is unauthenticated.

REFERENCE DISCOVERY

The reference discovery phase is done nearly the same way as it is in the fetching protocol. Each reference obj-id and name on the server is sent in packet-line format to the client, followed by a flush-pkt. The only real difference is that the capability listing is different - the only possible values are report-status, report-status-v2, delete-refs, ofs-delta, atomic and push-options.

REFERENCE UPDATE REQUEST AND PACKFILE TRANSFER

Once the client knows what references the server is at, it can send a list of reference update requests. For each reference on the server that it wants to update, it sends a line listing the obj-id currently on the server, the obj-id the client would like to update it to and the name of the reference.

This list is followed by a flush-pkt.

update-requests = *shallow ( command-list | push-cert )

  shallow           =  PKT-LINE("shallow" SP obj-id)

  command-list      =  PKT-LINE(command NUL capability-list)
                       *PKT-LINE(command)
                       flush-pkt

  command           =  create / delete / update
  create            =  zero-id SP new-id  SP name
  delete            =  old-id  SP zero-id SP name
  update            =  old-id  SP new-id  SP name

  old-id            =  obj-id
  new-id            =  obj-id

  push-cert         = PKT-LINE("push-cert" NUL capability-list LF)
                      PKT-LINE("certificate version 0.1" LF)
                      PKT-LINE("pusher" SP ident LF)
                      PKT-LINE("pushee" SP url LF)
                      PKT-LINE("nonce" SP nonce LF)
                      *PKT-LINE("push-option" SP push-option LF)
                      PKT-LINE(LF)
                      *PKT-LINE(command LF)
                      *PKT-LINE(gpg-signature-lines LF)
                      PKT-LINE("push-cert-end" LF)

  push-option       =  1*( VCHAR | SP )

If the server has advertised the push-options capability and the client has specified push-options as part of the capability list above, the client then sends its push options followed by a flush-pkt.

push-options = *PKT-LINE(push-option) flush-pkt

For backwards compatibility with older Git servers, if the client sends a push cert and push options, it MUST send its push options both embedded within the push cert and after the push cert. (Note that the push options within the cert are prefixed, but the push options after the cert are not.) Both these lists MUST be the same, modulo the prefix.

After that the packfile that should contain all the objects that the server will need to complete the new references will be sent.

packfile = “PACK” 28*(OCTET)

If the receiving end does not support delete-refs, the sending end MUST NOT ask for delete command.

If the receiving end does not support push-cert, the sending end MUST NOT send a push-cert command. When a push-cert command is sent, command-list MUST NOT be sent; the commands recorded in the push certificate is used instead.

The packfile MUST NOT be sent if the only command used is delete.

A packfile MUST be sent if either create or update command is used, even if the server already has all the necessary objects. In this case the client MUST send an empty packfile. The only time this is likely to happen is if the client is creating a new branch or a tag that points to an existing obj-id.

The server will receive the packfile, unpack it, then validate each reference that is being updated that it hasn’t changed while the request was being processed (the obj-id is still the same as the old-id), and it will run any update hooks to make sure that the update is acceptable. If all of that is fine, the server will then update the references.

PUSH CERTIFICATE

A push certificate begins with a set of header lines. After the header and an empty line, the protocol commands follow, one per line. Note that the trailing LF in push-cert PKT-LINEs is not optional; it must be present.

Currently, the following header fields are defined:

pusher ident

Identify the GPG key in “Human Readable Name <email@address[1]>” format.

pushee url

The repository URL (anonymized, if the URL contains authentication material) the user who ran git push intended to push into.

nonce nonce

The nonce string the receiving repository asked the pushing user to include in the certificate, to prevent replay attacks.

The GPG signature lines are a detached signature for the contents recorded in the push certificate before the signature block begins. The detached signature is used to certify that the commands were given by the pusher, who must be the signer.

REPORT STATUS

After receiving the pack data from the sender, the receiver sends a report if report-status or report-status-v2 capability is in effect. It is a short listing of what happened in that update. It will first list the status of the packfile unpacking as either unpack ok or unpack [error]. Then it will list the status for each of the references that it tried to update. Each line is either ok [refname] if the update was successful, or ng [refname] [error] if the update was not.

report-status = unpack-status 1*(command-status) flush-pkt

  unpack-status     = PKT-LINE("unpack" SP unpack-result)
  unpack-result     = "ok" / error-msg

  command-status    = command-ok / command-fail
  command-ok        = PKT-LINE("ok" SP refname)
  command-fail      = PKT-LINE("ng" SP refname SP error-msg)

  error-msg         = 1*(OCTET) ; where not "ok"

The report-status-v2 capability extends the protocol by adding new option lines in order to support reporting of reference rewritten by the proc-receive hook. The proc-receive hook may handle a command for a pseudo-reference which may create or update one or more references, and each reference may have different name, different new-oid, and different old-oid.

report-status-v2 = unpack-status 1*(command-status-v2) flush-pkt

  unpack-status     = PKT-LINE("unpack" SP unpack-result)
  unpack-result     = "ok" / error-msg

  command-status-v2 = command-ok-v2 / command-fail
  command-ok-v2     = command-ok
                      *option-line

  command-ok        = PKT-LINE("ok" SP refname)
  command-fail      = PKT-LINE("ng" SP refname SP error-msg)

  error-msg         = 1*(OCTET) ; where not "ok"

  option-line       = *1(option-refname)
                      *1(option-old-oid)
                      *1(option-new-oid)
                      *1(option-forced-update)

  option-refname    = PKT-LINE("option" SP "refname" SP refname)
  option-old-oid    = PKT-LINE("option" SP "old-oid" SP obj-id)
  option-new-oid    = PKT-LINE("option" SP "new-oid" SP obj-id)
  option-force      = PKT-LINE("option" SP "forced-update")

Updates can be unsuccessful for a number of reasons. The reference can have changed since the reference discovery phase was originally sent, meaning someone pushed in the meantime. The reference being pushed could be a non-fast-forward reference and the update hooks or configuration could be set to not allow that, etc. Also, some references can be updated while others can be rejected.

An example client/server communication might look like this:

S: 006274730d410fcb6603ace96f1dc55ea6196122532d refs/heads/local�report-status delete-refs ofs-delta

   S: 003e7d1665144a3a975c05f1f43902ddaf084e784dbe refs/heads/debug

   S: 003f74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/master

   S: 003d74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/team

   S: 0000

   C: 00677d1665144a3a975c05f1f43902ddaf084e784dbe 74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/debug

   C: 006874730d410fcb6603ace96f1dc55ea6196122532d 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a refs/heads/master

   C: 0000
   C: [PACKDATA]

   S: 000eunpack ok

   S: 0018ok refs/heads/debug

   S: 002ang refs/heads/master non-fast-forward

GIT

Part of the git(1) suite

NOTES

email@address

mailto:email@address

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

257 - Linux cli command fstab

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command fstab and provides detailed information about the command fstab, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the fstab.

NAME 🖥️ fstab 🖥️

static information about the filesystems

SYNOPSIS

/etc/fstab

DESCRIPTION

The file fstab contains descriptive information about the filesystems the system can mount. fstab is only read by programs, and not written; it is the duty of the system administrator to properly create and maintain this file. The order of records in fstab is important because fsck(8), mount(8), and umount(8) sequentially iterate through fstab doing their thing.

The file is not read by mount(8) only but often is used by many other tools and daemons, and proper functionality may require additional steps. For example, on systemd-based systems, it’s recommended to use systemctl daemon-reload after fstab modification.

Each filesystem is described on a separate line. Fields on each line are separated by tabs or spaces. Lines starting with # are comments. Blank lines are ignored.

The following is a typical example of an fstab entry:

LABEL=t-home2 /home ext4 defaults,auto_da_alloc 0 2

The first field (fs_spec).

This field describes the block special device, remote filesystem or filesystem image for loop device to be mounted or swap file or swap device to be enabled.

For ordinary mounts, it will hold (a link to) a block special device node (as created by mknod(2)) for the device to be mounted, like /dev/cdrom or /dev/sdb7. For NFS mounts, this field is <host>:<dir>, e.g., knuth.aeb.nl:/. For filesystems with no storage, any string can be used, and will show up in df(1) output, for example. Typical usage is proc for procfs; mem, none, or tmpfs for tmpfs. Other special filesystems, like udev and sysfs, are typically not listed in fstab.

LABEL=<label> or UUID=<uuid> may be given instead of a device name. This is the recommended method, as device names are often a coincidence of hardware detection order, and can change when other disks are added or removed. For example, LABEL=Boot or UUID=3e6be9de-8139-11d1-9106-a43f08d823a6. (Use a filesystem-specific tool like e2label(8), xfs_admin(8), or fatlabel(8) to set LABELs on filesystems).

It’s also possible to use PARTUUID= and PARTLABEL=. These partitions identifiers are supported for example for GUID Partition Table (GPT).

See mount(8), blkid(8) or lsblk(8) for more details about device identifiers.

Note that mount(8) uses UUIDs as strings. The string representation of the UUID should be based on lower case characters. But when specifying the volume ID of FAT or NTFS file systems upper case characters are used (e.g UUID=“A40D-85E7” or UUID=“61DB7756DB7779B3”).

The second field (fs_file).

This field describes the mount point (target) for the filesystem. For swap area, this field should be specified as `none. If the name of the mount point contains spaces or tabs these can be escaped as ` and respectively.

The third field (fs_vfstype).

This field describes the type of the filesystem. Linux supports many filesystem types: ext4, xfs, btrfs, f2fs, vfat, ntfs, hfsplus, tmpfs, sysfs, proc, iso9660, udf, squashfs, nfs, cifs, and many more. For more details, see mount(8).

An entry swap denotes a file or partition to be used for swapping, cf. swapon(8). An entry none is useful for bind or move mounts.

More than one type may be specified in a comma-separated list.

mount(8) and umount(8) support filesystem subtypes. The subtype is defined by .subtype suffix. For example fuse.sshfs. It’s recommended to use subtype notation rather than add any prefix to the first fstab field (for example sshfs#example.com is deprecated).

The fourth field (fs_mntops).

This field describes the mount options associated with the filesystem.

It is formatted as a comma-separated list of options and is optional for mount(8) or swapon(8). The usual convention is to use at least “defaults” keyword there.

It usually contains the type of mount (ro or rw, the default is rw), plus any additional options appropriate to the filesystem type (including performance-tuning options). For details, see mount(8) or swapon(8).

Basic filesystem-independent options are:

defaults

use default options. The default depends on the kernel and the filesystem. mount(8) does not have any hardcoded set of default options. The kernel default is usually rw, suid, dev, exec, auto, nouser, and async.

noauto

do not mount when mount -a is given (e.g., at boot time)

user

allow a user to mount

owner

allow device owner to mount

comment

or x-<name> for use by fstab-maintaining programs

nofail

do not report errors for this device if it does not exist.

The fifth field (fs_freq).

This field is used by dump(8) to determine which filesystems need to be dumped. Defaults to zero (don’t dump) if not present.

The sixth field (fs_passno).

This field is used by fsck(8) to determine the order in which filesystem checks are done at boot time. The root filesystem should be specified with a fs_passno of 1. Other filesystems should have a fs_passno of 2. Filesystems within a drive will be checked sequentially, but filesystems on different drives will be checked at the same time to utilize parallelism available in the hardware. Defaults to zero (don’t check the filesystem) if not present.

FILES

/etc/fstab, <fstab.h>

NOTES

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

The keyword ignore as a filesystem type (3rd field) is no longer supported by the pure libmount based mount utility (since util-linux v2.22).

This document describes handling of fstab by util-linux and libmount. For systemd, read systemd documentation. There are slight differences.

HISTORY

The ancestor of this fstab file format appeared in 4.0BSD.

REPORTING BUGS

For bug reports, use the issue tracker at <https://github.com/util-linux/util-linux/issues>.

AVAILABILITY

fstab is part of the util-linux package which can be downloaded from Linux Kernel Archive <https://www.kernel.org/pub/linux/utils/util-linux/>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

258 - Linux cli command proc_pid_mounts

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_mounts and provides detailed information about the command proc_pid_mounts, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_mounts.

NAME 🖥️ proc_pid_mounts 🖥️

mounted filesystems

DESCRIPTION

259 - Linux cli command proc_sys_vm

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_sys_vm and provides detailed information about the command proc_sys_vm, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_sys_vm.

NAME 🖥️ proc_sys_vm 🖥️

virtual memory subsystem

DESCRIPTION

/proc/sys/vm/
This directory contains files for memory management tuning, buffer, and cache management.

/proc/sys/vm/admin_reserve_kbytes (since Linux 3.10)
This file defines the amount of free memory (in KiB) on the system that should be reserved for users with the capability CAP_SYS_ADMIN.

The default value in this file is the minimum of [3% of free pages, 8MiB] expressed as KiB. The default is intended to provide enough for the superuser to log in and kill a process, if necessary, under the default overcommit ‘guess’ mode (i.e., 0 in /proc/sys/vm/overcommit_memory).

Systems running in “overcommit never” mode (i.e., 2 in /proc/sys/vm/overcommit_memory) should increase the value in this file to account for the full virtual memory size of the programs used to recover (e.g., login(1) ssh(1), and top(1)) Otherwise, the superuser may not be able to log in to recover the system. For example, on x86-64 a suitable value is 131072 (128MiB reserved).

Changing the value in this file takes effect whenever an application requests memory.

/proc/sys/vm/compact_memory (since Linux 2.6.35)
When 1 is written to this file, all zones are compacted such that free memory is available in contiguous blocks where possible. The effect of this action can be seen by examining /proc/buddyinfo.

Present only if the kernel was configured with CONFIG_COMPACTION.

/proc/sys/vm/drop_caches (since Linux 2.6.16)
Writing to this file causes the kernel to drop clean caches, dentries, and inodes from memory, causing that memory to become free. This can be useful for memory management testing and performing reproducible filesystem benchmarks. Because writing to this file causes the benefits of caching to be lost, it can degrade overall system performance.

To free pagecache, use:

echo 1 > /proc/sys/vm/drop_caches

To free dentries and inodes, use:

echo 2 > /proc/sys/vm/drop_caches

To free pagecache, dentries, and inodes, use:

echo 3 > /proc/sys/vm/drop_caches

Because writing to this file is a nondestructive operation and dirty objects are not freeable, the user should run sync(1) first.

/proc/sys/vm/sysctl_hugetlb_shm_group (since Linux 2.6.7)
This writable file contains a group ID that is allowed to allocate memory using huge pages. If a process has a filesystem group ID or any supplementary group ID that matches this group ID, then it can make huge-page allocations without holding the CAP_IPC_LOCK capability; see memfd_create(2), mmap(2), and shmget(2).

/proc/sys/vm/legacy_va_layout (since Linux 2.6.9)
If nonzero, this disables the new 32-bit memory-mapping layout; the kernel will use the legacy (2.4) layout for all processes.

/proc/sys/vm/memory_failure_early_kill (since Linux 2.6.32)
Control how to kill processes when an uncorrected memory error (typically a 2-bit error in a memory module) that cannot be handled by the kernel is detected in the background by hardware. In some cases (like the page still having a valid copy on disk), the kernel will handle the failure transparently without affecting any applications. But if there is no other up-to-date copy of the data, it will kill processes to prevent any data corruptions from propagating.

The file has one of the following values:

1
Kill all processes that have the corrupted-and-not-reloadable page mapped as soon as the corruption is detected. Note that this is not supported for a few types of pages, such as kernel internally allocated data or the swap cache, but works for the majority of user pages.

0
Unmap the corrupted page from all processes and kill a process only if it tries to access the page.

The kill is performed using a SIGBUS signal with si_code set to BUS_MCEERR_AO. Processes can handle this if they want to; see sigaction(2) for more details.

This feature is active only on architectures/platforms with advanced machine check handling and depends on the hardware capabilities.

Applications can override the memory_failure_early_kill setting individually with the prctl(2) PR_MCE_KILL operation.

Present only if the kernel was configured with CONFIG_MEMORY_FAILURE.

/proc/sys/vm/memory_failure_recovery (since Linux 2.6.32)
Enable memory failure recovery (when supported by the platform).

1
Attempt recovery.

0
Always panic on a memory failure.

Present only if the kernel was configured with CONFIG_MEMORY_FAILURE.

/proc/sys/vm/oom_dump_tasks (since Linux 2.6.25)
Enables a system-wide task dump (excluding kernel threads) to be produced when the kernel performs an OOM-killing. The dump includes the following information for each task (thread, process): thread ID, real user ID, thread group ID (process ID), virtual memory size, resident set size, the CPU that the task is scheduled on, oom_adj score (see the description of /proc/pid/oom_adj), and command name. This is helpful to determine why the OOM-killer was invoked and to identify the rogue task that caused it.

If this contains the value zero, this information is suppressed. On very large systems with thousands of tasks, it may not be feasible to dump the memory state information for each one. Such systems should not be forced to incur a performance penalty in OOM situations when the information may not be desired.

If this is set to nonzero, this information is shown whenever the OOM-killer actually kills a memory-hogging task.

The default value is 0.

/proc/sys/vm/oom_kill_allocating_task (since Linux 2.6.24)
This enables or disables killing the OOM-triggering task in out-of-memory situations.

If this is set to zero, the OOM-killer will scan through the entire tasklist and select a task based on heuristics to kill. This normally selects a rogue memory-hogging task that frees up a large amount of memory when killed.

If this is set to nonzero, the OOM-killer simply kills the task that triggered the out-of-memory condition. This avoids a possibly expensive tasklist scan.

If /proc/sys/vm/panic_on_oom is nonzero, it takes precedence over whatever value is used in /proc/sys/vm/oom_kill_allocating_task.

The default value is 0.

/proc/sys/vm/overcommit_kbytes (since Linux 3.14)
This writable file provides an alternative to /proc/sys/vm/overcommit_ratio for controlling the CommitLimit when /proc/sys/vm/overcommit_memory has the value 2. It allows the amount of memory overcommitting to be specified as an absolute value (in kB), rather than as a percentage, as is done with overcommit_ratio. This allows for finer-grained control of CommitLimit on systems with extremely large memory sizes.

Only one of overcommit_kbytes or overcommit_ratio can have an effect: if overcommit_kbytes has a nonzero value, then it is used to calculate CommitLimit, otherwise overcommit_ratio is used. Writing a value to either of these files causes the value in the other file to be set to zero.

/proc/sys/vm/overcommit_memory
This file contains the kernel virtual memory accounting mode. Values are:

0: heuristic overcommit (this is the default)
1: always overcommit, never check
2: always check, never overcommit

In mode 0, calls of mmap(2) with MAP_NORESERVE are not checked, and the default check is very weak, leading to the risk of getting a process “OOM-killed”.

In mode 1, the kernel pretends there is always enough memory, until memory actually runs out. One use case for this mode is scientific computing applications that employ large sparse arrays. Before Linux 2.6.0, any nonzero value implies mode 1.

In mode 2 (available since Linux 2.6), the total virtual address space that can be allocated (CommitLimit in /proc/meminfo) is calculated as

CommitLimit = (total_RAM - total_huge_TLB) *
	      overcommit_ratio / 100 + total_swap

where:

total_RAM is the total amount of RAM on the system;
total_huge_TLB is the amount of memory set aside for huge pages;
overcommit_ratio is the value in /proc/sys/vm/overcommit_ratio; and
total_swap is the amount of swap space.

For example, on a system with 16 GB of physical RAM, 16 GB of swap, no space dedicated to huge pages, and an overcommit_ratio of 50, this formula yields a CommitLimit of 24 GB.

Since Linux 3.14, if the value in /proc/sys/vm/overcommit_kbytes is nonzero, then CommitLimit is instead calculated as:

CommitLimit = overcommit_kbytes + total_swap

See also the description of /proc/sys/vm/admin_reserve_kbytes and /proc/sys/vm/user_reserve_kbytes.

/proc/sys/vm/overcommit_ratio (since Linux 2.6.0)
This writable file defines a percentage by which memory can be overcommitted. The default value in the file is 50. See the description of /proc/sys/vm/overcommit_memory.

/proc/sys/vm/panic_on_oom (since Linux 2.6.18)
This enables or disables a kernel panic in an out-of-memory situation.

If this file is set to the value 0, the kernel’s OOM-killer will kill some rogue process. Usually, the OOM-killer is able to kill a rogue process and the system will survive.

If this file is set to the value 1, then the kernel normally panics when out-of-memory happens. However, if a process limits allocations to certain nodes using memory policies (mbind(2) MPOL_BIND) or cpusets (cpuset(7)) and those nodes reach memory exhaustion status, one process may be killed by the OOM-killer. No panic occurs in this case: because other nodes’ memory may be free, this means the system as a whole may not have reached an out-of-memory situation yet.

If this file is set to the value 2, the kernel always panics when an out-of-memory condition occurs.

The default value is 0. 1 and 2 are for failover of clustering. Select either according to your policy of failover.

/proc/sys/vm/swappiness
The value in this file controls how aggressively the kernel will swap memory pages. Higher values increase aggressiveness, lower values decrease aggressiveness. The default value is 60.

/proc/sys/vm/user_reserve_kbytes (since Linux 3.10)
Specifies an amount of memory (in KiB) to reserve for user processes. This is intended to prevent a user from starting a single memory hogging process, such that they cannot recover (kill the hog). The value in this file has an effect only when /proc/sys/vm/overcommit_memory is set to 2 (“overcommit never” mode). In this case, the system reserves an amount of memory that is the minimum of [3% of current process size, user_reserve_kbytes].

The default value in this file is the minimum of [3% of free pages, 128MiB] expressed as KiB.

If the value in this file is set to zero, then a user will be allowed to allocate all free memory with a single process (minus the amount reserved by /proc/sys/vm/admin_reserve_kbytes). Any subsequent attempts to execute a command will result in “fork: Cannot allocate memory”.

Changing the value in this file takes effect whenever an application requests memory.

/proc/sys/vm/unprivileged_userfaultfd (since Linux 5.2)
This (writable) file exposes a flag that controls whether unprivileged processes are allowed to employ userfaultfd(2). If this file has the value 1, then unprivileged processes may use userfaultfd(2). If this file has the value 0, then only processes that have the CAP_SYS_PTRACE capability may employ userfaultfd(2). The default value in this file is 1.

260 - Linux cli command org.bluez.MediaItem

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.MediaItem and provides detailed information about the command org.bluez.MediaItem, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.MediaItem.

NAME 🖥️ org.bluez.MediaItem 🖥️

BlueZ D-Bus MediaItem API documentation

INTERFACE

Service
unique name (Target role) org.bluez (Controller role)
Interface
org.bluez.MediaItem1
Object path
freely definable (Target role) [variable prefix]/{hci0,hci1,…}/dev_XX_XX_XX_XX_XX_XX/playerX/itemX (Controller role)

Methods

void Play()

Play item
Possible Errors:
org.bluez.Error.NotSupported
org.bluez.Error.Failed

void AddtoNowPlaying()

Add item to now playing list
Possible Errors:
org.bluez.Error.NotSupported
org.bluez.Error.Failed

Properties

object Player [readonly]

Player object path the item belongs to

string Name [readonly]

Item displayable name

string Type [readonly]

Item type
Possible values: “video”, “audio”, “folder”

string FolderType [readonly, optional]

Folder type.
Possible values: “mixed”, “titles”, “albums”, “artists”
Available if property Type is “Folder”

boolean Playable [readonly, optional]

Indicates if the item can be played
Available if property Type is “folder”

dict Metadata [readonly]

Item metadata.
Possible values:
string Title
Item title name
Available if property Type is “audio” or “video”
string Artist
Item artist name
Available if property Type is “audio” or “video”
string Album
Item album name
Available if property Type is “audio” or “video”
string Genre
Item genre name
Available if property Type is “audio” or “video”
uint32 NumberOfTracks
Item album number of tracks in total
Available if property Type is “audio” or “video”
uint32 Number
Item album number
Available if property Type is “audio” or “video”
uint32 Duration
Item duration in milliseconds
Available if property Type is “audio” or “video”

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

261 - Linux cli command proc_pid_uid_map

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_uid_map and provides detailed information about the command proc_pid_uid_map, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_uid_map.

NAME 🖥️ proc_pid_uid_map 🖥️

user and group ID mappings

DESCRIPTION

/proc/pid/gid_map (since Linux 3.5)
See user_namespaces(7).

/proc/pid/uid_map (since Linux 3.5)
See user_namespaces(7).

262 - Linux cli command odbcinst.ini

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command odbcinst.ini and provides detailed information about the command odbcinst.ini, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the odbcinst.ini.

NAME 🖥️ odbcinst.ini 🖥️

unixODBC driver configuration file

DESCRIPTION

/etc/odbcinst.ini is a configuration file for unixODBC drivers.

The file can be updated by using the odbcinst utility (recommended) or edited by hand.

FILE FORMAT

The general .ini file format is:

[SectionName1] key1 = value1 key2 = value2 …
[SectionName2]
key1 = value1
key2 = value2
...

Each ODBC driver has its own section and can be referred to by the name of that section in files such as odbc.ini. Within each section, unixODBC also recognises the following configuration keys:

Description
A text string briefly describing the driver.

Driver
A filesystem path to the actual driver library.

Setup
A filesystem path to the driver setup library.

FileUsage
The section named [ODBC] configures global options. Keys recognised in the [ODBC] section include:

Trace
Enable ODBC driver trace output, which is written to the file path specified by TraceFile.

Some ODBC drivers have their own trace control options. Unlike the Trace option, these separate options are usually specified at the Data Source Name (DSN) level.

Trace will be enabled if the corresponding value contains any case variant of “1”, “y”, “yes” or “on”.

TraceFile
Specifies the system path or path-pattern to which ODBC driver trace output will be written. This option has no effect unless Trace is enabled. The default file location for trace output is /tmp/sql.log.

WARNING: Setting TraceFile to a path writable by multiple users might not work correctly, as only the first user will be able to create and open the file.

TEMPLATE FILES

Many ODBC drivers come with .ini file templates, which can be installed by using the odbcinst utility.

Template files use the same format as odbcinst.ini.

EXAMPLES

To install the unixODBC PostgreSQL driver, the following configuration can be entered into odbcinst.ini:

[PostgreSQL] Description = PostgreSQL driver for GNU/Linux Driver = /usr/lib/psqlodbcw.so Setup = /usr/lib/libodbcpsqlS.so FileUsage = 1

Driver paths can vary, depending on your operating system and whether your distribution is multi-arch enabled. Some drivers also require Driver64 and Setup64 entries.

The above section can be referenced in odbc.ini as follows:

Driver = PostgreSQL

The recommended way of adding the PostgreSQL driver to your system is by creating a template file containing:

[PostgreSQL] Description = PostgreSQL driver for GNU/Linux Driver = /usr/lib/psqlodbcw.so Setup = /usr/lib/libodbcpsqlS.so

and calling odbcinst as follows:

**# odbcinst -i -d -f **template.ini

AUTHORS

The authors of unixODBC are Peter Harvey <[email protected]> and Nick Gorham <[email protected]>.

For a full list of contributors, refer to the AUTHORS file.

COPYRIGHT

unixODBC is licensed under the GNU Lesser General Public License. For details about the license, see the COPYING file.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

263 - Linux cli command exim4_passwd_client

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command exim4_passwd_client and provides detailed information about the command exim4_passwd_client, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the exim4_passwd_client.

NAME 🖥️ exim4_passwd_client 🖥️

config_files - Files in use by the Debian exim4 packages

SYNOPSIS

DESCRIPTION

This manual page describes the files that are in use by the Debian exim4 packages and which are not part of an exim installation done from source.

/etc/aliases

You should at least set up an alias for postmaster in the /etc/aliases file.

/etc/email-addresses

is used to rewrite the email addresses of users. This is particularly useful for users who use their ISP’s domain for email.

The file should contain lines of the form

user: [email protected]
otheruser: [email protected]

/etc/exim4/local_host_blacklist

In the blacklist, the trick is to read a line break as “or” if it follows a positive item, and as “and” if it follows a negative item.

For example, a /etc/exim4/local_host_blacklist

192.168.10.0/24
!172.16.10.128/26
172.16.10.0/24
10.0.0.0/8

Exim just evaluates left to right (or up-down in the file listing context), so you don’t get the same kind of operator binding as in a programming language.

/etc/exim4/host_local_deny_exceptions

/etc/exim4/local_sender_blacklist

In the blacklist, the trick is to read a line break as “or” if it follows a positive item, and as “and” if it follows a negative item.

For example, a /etc/exim4/local_sender_blacklist

domain1.example
[email protected]
domain2.example
domain3.example

Exim just evaluates left to right (or up-down in the file listing context), so you don’t get the same kind of operator binding as in a programming language.

/etc/exim4/sender_local_deny_exceptions

/etc/exim4/local_sender_callout

/etc/exim4/local_rcpt_callout

/etc/exim4/local_domain_dnsbl_whitelist

/etc/exim4/hubbed_hosts

The file should contain key-value pairs of domain pattern and route data of the form

domain: host-list options
dict.ref.example: mail-1.ref.example:mail-2.ref.example
foo.example: internal.mail.example.com
bar.example: 192.168.183.3

which will cause mail for foo.example to be sent to the host internal.mail.example (IP address derived from A record only), and mail to bar.example to be sent to 192.168.183.3.

See spec.txt chapter 20.3 through 20.7 for a more detailed explanation of host list format and available options.

/etc/exim4/passwd

contains account and password data for SMTP authentication when the local exim is SMTP server and clients authenticate to the local exim.

The file should contain lines of the form

username:crypted-password:clear-password

clear-password is only necessary if you want to offer CRAM-MD5 authentication. If you don’t plan on doing so, the third column can be omitted completely.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim 640.

/etc/exim4/passwd.client

contains account and password data for SMTP authentication when exim is authenticating as a client to some remote server.

The file should contain lines of the form

target.mail.server.example:login-user-name:password

This goes inevitably wrong if the host name of the mail server is a CNAME (a DNS alias), or the reverse lookup does not fit the forward one.

password is your SMTP password in clear text. If you do not know about your SMTP password, you can try using your POP3 password as a first guess.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim 640.

/etc/exim4/exim.crt

/etc/exim4/exim.key

/etc/mailname

The “mail name” of the system. See Debian policy Chapter Customized programs and exim4-base’s README.Debian for further details.

BUGS

Plenty. Please report them through the Debian BTS

This manual page needs a major re-work. If somebody knows better groff than us and has more experience in writing manual pages, any patches would be greatly appreciated.

NOTES

Unresolvable items in host lists

Adding or keeping items in the abovementioned host lists which are not resolvable by DNS has severe consequences.

notresolvable.example.com:rejectme.example.com

Starting the list with the special pattern +ignore_unknown as a safeguard against this behavior is strongly recommended if hostnames are used in hostlists.

AUTHOR

Marc Haber <[email protected]> with help from Ross Boylan.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

264 - Linux cli command proc_pid_cmdline

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_cmdline and provides detailed information about the command proc_pid_cmdline, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_cmdline.

NAME 🖥️ proc_pid_cmdline 🖥️

command line

DESCRIPTION

/proc/pid/cmdline
This read-only file holds the complete command line for the process, unless the process is a zombie. In the latter case, there is nothing in this file: that is, a read on this file will return 0 characters.

For processes which are still running, the command-line arguments appear in this file in the same layout as they do in process memory: If the process is well-behaved, it is a set of strings separated by null bytes (‘�’), with a further null byte after the last string.

This is the common case, but processes have the freedom to override the memory region and break assumptions about the contents or format of the /proc/pid/cmdline file.

If, after an execve(2), the process modifies its argv strings, those changes will show up here. This is not the same thing as modifying the argv array.

Furthermore, a process may change the memory location that this file refers via prctl(2) operations such as PR_SET_MM_ARG_START.

Think of this file as the command line that the process wants you to see.

265 - Linux cli command proc_pid_attr

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_attr and provides detailed information about the command proc_pid_attr, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_attr.

NAME 🖥️ proc_pid_attr 🖥️

security-related attributes

DESCRIPTION

/proc/pid/attr/
The files in this directory provide an API for security modules. The contents of this directory are files that can be read and written in order to set security-related attributes. This directory was added to support SELinux, but the intention was that the API be general enough to support other security modules. For the purpose of explanation, examples of how SELinux uses these files are provided below.

This directory is present only if the kernel was configured with CONFIG_SECURITY.

/proc/pid/attr/current (since Linux 2.6.0)
The contents of this file represent the current security attributes of the process.

In SELinux, this file is used to get the security context of a process. Prior to Linux 2.6.11, this file could not be used to set the security context (a write was always denied), since SELinux limited process security transitions to execve(2) (see the description of /proc/pid/attr/exec, below). Since Linux 2.6.11, SELinux lifted this restriction and began supporting “set” operations via writes to this node if authorized by policy, although use of this operation is only suitable for applications that are trusted to maintain any desired separation between the old and new security contexts.

Prior to Linux 2.6.28, SELinux did not allow threads within a multithreaded process to set their security context via this node as it would yield an inconsistency among the security contexts of the threads sharing the same memory space. Since Linux 2.6.28, SELinux lifted this restriction and began supporting “set” operations for threads within a multithreaded process if the new security context is bounded by the old security context, where the bounded relation is defined in policy and guarantees that the new security context has a subset of the permissions of the old security context.

Other security modules may choose to support “set” operations via writes to this node.

/proc/pid/attr/exec (since Linux 2.6.0)
This file represents the attributes to assign to the process upon a subsequent execve(2).

In SELinux, this is needed to support role/domain transitions, and execve(2) is the preferred point to make such transitions because it offers better control over the initialization of the process in the new security label and the inheritance of state. In SELinux, this attribute is reset on execve(2) so that the new program reverts to the default behavior for any execve(2) calls that it may make. In SELinux, a process can set only its own /proc/pid/attr/exec attribute.

/proc/pid/attr/fscreate (since Linux 2.6.0)
This file represents the attributes to assign to files created by subsequent calls to open(2), mkdir(2), symlink(2), and mknod(2)

SELinux employs this file to support creation of a file (using the aforementioned system calls) in a secure state, so that there is no risk of inappropriate access being obtained between the time of creation and the time that attributes are set. In SELinux, this attribute is reset on execve(2), so that the new program reverts to the default behavior for any file creation calls it may make, but the attribute will persist across multiple file creation calls within a program unless it is explicitly reset. In SELinux, a process can set only its own /proc/pid/attr/fscreate attribute.

/proc/pid/attr/keycreate (since Linux 2.6.18)
If a process writes a security context into this file, all subsequently created keys (add_key(2)) will be labeled with this context. For further information, see the kernel source file Documentation/security/keys/core.rst (or file Documentation/security/keys.txt between Linux 3.0 and Linux 4.13, or Documentation/keys.txt before Linux 3.0).

/proc/pid/attr/prev (since Linux 2.6.0)
This file contains the security context of the process before the last execve(2); that is, the previous value of /proc/pid/attr/current.

/proc/pid/attr/socketcreate (since Linux 2.6.18)
If a process writes a security context into this file, all subsequently created sockets will be labeled with this context.

266 - Linux cli command mailcap

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command mailcap and provides detailed information about the command mailcap, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the mailcap.

NAME 🖥️ mailcap 🖥️

metamail capabilities file

DESCRIPTION

The mailcap file is read by the metamail program to determine how to display non-text at the local site.

The syntax of a mailcap file is quite simple, at least compared to termcap files. Any line that starts with “#” is a comment. Blank lines are ignored. Otherwise, each line defines a single mailcap entry for a single content type. Long lines may be continued by ending them with a backslash character, \

Each individual mailcap entry consists of a content-type specification, a command to execute, and (possibly) a set of optional “flag” values. For example, a very simple mailcap entry (which is actually a built-in default behavior for metamail) would look like this:

text/plain; cat %s

The optional flags can be used to specify additional information about the mail-handling command. For example:

text/plain; cat %s; copiousoutput

can be used to indicate that the output of the ‘cat’ command may be voluminous, requiring either a scrolling window, a pager, or some other appropriate coping mechanism.

The “type” field (text/plain, in the above example) is simply any legal content type name, as defined by informational RFC 1524. In practice, this is almost any string. It is the string that will be matched against the “Content-type” header (or the value passed in with -c) to decide if this is the mailcap entry that matches the current message. Additionally, the type field may specify a subtype (e.g. “text/ISO-8859-1”) or a wildcard to match all subtypes (e.g. “image/*”).

The “command” field is any UNIX command (“cat %s” in the above example), and is used to specify the interpreter for the given type of message. It will be passed to the shell via the system(3) facility. Semicolons and backslashes within the command must be quoted with backslashes. If the command contains “%s”, those two characters will be replaced by the name of a file that contains the body of the message. If it contains “%t”, those two characters will be replaced by the content-type field, including the subtype, if any. (That is, if the content-type was “image/pbm; opt1=something-else”, then “%t” would be replaced by “image/pbm”.) If the command field contains “%{” followed by a parameter name and a closing “}”, then all those characters will be replaced by the value of the named parameter, if any, from the Content-type header. Thus, in the previous example, “%{opt1}” will be replaced by “something-else”. Finally, if the command contains “", those two characters will be replaced by a single % character. (In fact, the backslash can be used to quote any character, including itself.)

If no “%s” appears in the command field, then instead of placing the message body in a temporary file, metamail will pass the body to the command on the standard input. This is helpful in saving /tmp file space, but can be problematic for window-oriented applications under some window systems such as MGR.

Two special codes can appear in the viewing command for objects of type multipart (any subtype). These are “%n” and “%F”. %n will be replaced by the number of parts within the multipart object. %F will be replaced by a series of arguments, two for each part, giving first the content-type and then the name of the temporary file where the decoded part has been stored. In addition, for each file created by %F, a second file is created, with the same name followed by “H”, which contains the header information for that body part. This will not be needed by most multipart handlers, but it is there if you ever need it.

The “notes=xxx” field is an uninterpreted string that is used to specify the name of the person who installed this entry in the mailcap file. (The “xxx” may be replaced by any text string.)

The “test=xxx” field is a command that is executed to determine whether or not the mailcap line actually applies. That is, if the content-type field matches the content-type on the message, but a “test=” field is present, then the test must succeed before the mailcap line is considered to “match” the message being viewed. The command may be any UNIX command, using the same syntax and the same %-escapes as for the viewing command, as described above. A command is considered to succeed if it exits with a zero exit status, and to fail otherwise.

The “print=xxx” field is a command that is executed to print the data instead of display it interactively. This behavior is usually a consequence of invoking metamail with the “-h” switch.

The “textualnewlines” field can be used in the rather obscure case where metamail’s default rules for treating newlines in base64-encoded data are unsatisfactory. By default, metamail will translate CRLF to the local newline character in decoded base64 output if the content-type is “text” (any subtype), but will not do so otherwise. A mailcap entry with a field of “textualnewlines=1” will force such translation for the specified content-type, while “textualnewlines=0” will guarantee that the translation does not take place even for textual content-types.

The “compose” field may be used to specify a program that can be used to compose a new body or body part in the given format. Its intended use is to support mail composing agents that support the composition of multiple types of mail using external composing agents. As with the view-command, the compose command will be executed after replacing certain escape sequences starting with “%”. In particular, %s should be replaced by the name of a file to which the composed data is to be written by the specified composing program, thus allowing the calling program (e.g. metamail) to tell the called program where to store the composed data. If %s does not appear, then the composed data will be assumed to be written by the composing programs to standard output. The result of the composing program may be data that is NOT yet suitable for mail transport – that is, a Content-Transfer-Encoding may still need to be applied to the data.

The “composetyped” field is similar to the “compose” field, but is to be used when the composing program needs to specify the Content-type header field to be applied to the composed data. The “compose” field is simpler, and is preferred for use with existing (non-mail-oriented) programs for composing data in a given format. The “composetyped” field is necessary when the Content-type information must include auxiliary parameters, and the composition program must then know enough about mail formats to produce output that includes the mail type information, and to apply any necessary Content-Transfer-Encoding. Conceptually, “compose” specifies a program that simply outputs the specified type of data in its raw form, while “composetyped” specifies a program that outputs the data as a MIME object, with all necessary Content-* headers already in place.

needsterminal
If this flag is given, the named interpreter needs to interact with the user on a terminal. In some environments (e.g. a window-oriented mail reader under X11) this will require the creation of a new terminal emulation window, while in most environments it will not. If the mailcap entry specifies “needsterminal” and metamail is not running on a terminal (as determined by isatty(3), the -x option, and the MM_NOTTTY environment variable) then metamail will try to run the command in a new terminal emulation window. Currently, metamail knows how to create new windows under the X11, SunTools, and WM window systems.

copiousoutput
This flag should be given whenever the interpreter is capable of producing more than a few lines of output on stdout, and does no interaction with the user. If the mailcap entry specifies copiousoutput, and pagination has been requested via the “-p” command, then the output of the command being executed will be piped through a pagination program (“more” by default, but this can be overridden with the METAMAIL_PAGER environment variable).

BUILT-IN CONTENT-TYPE SUPPORT

The metamail program has built-in support for a few key content-types. In particular, it supports the text type, the multipart and multipart/alternative type, and the message/rfc822 types. This support is incomplete for many subtypes – for example, it only supports US-ASCII text in general. This kind of built-in support can be OVERRIDDEN by an entry in any mailcap file on the user’s search path. Metamail also has rudimentary built-in support for types that are totally unrecognized – i.e. for which no mailcap entry or built-in handler exists. For such unrecognized types, metamail will write a file with a “clean” copy of the data – i.e. a copy in which all mail headers have been removed, and in which any 7-bit transport encoding has been decoded.

FILES

$HOME/.mailcap:/etc/mailcap:/usr/share/etc/mailcap:/usr/local/etc/mailcap – default path for mailcap files.

COPYRIGHT

Permission to use, copy, modify, and distribute this material for any purpose and without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies, and that the name of Bellcore not be used in advertising or publicity pertaining to this material without the specific, prior written permission of an authorized representative of Bellcore. BELLCORE MAKES NO REPRESENTATIONS ABOUT THE ACCURACY OR SUITABILITY OF THIS MATERIAL FOR ANY PURPOSE. IT IS PROVIDED “AS IS”, WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES.

AUTHOR

Nathaniel S. Borenstein

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

267 - Linux cli command tmpfiles.d

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command tmpfiles.d and provides detailed information about the command tmpfiles.d, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the tmpfiles.d.

NAME 🖥️ tmpfiles.d 🖥️

Configuration for creation, deletion, and cleaning of files and directories

SYNOPSIS

/etc/tmpfiles.d/*.conf

/run/tmpfiles.d/*.conf

/usr/local/lib/tmpfiles.d/*.conf

/usr/lib/tmpfiles.d/*.conf

~/.config/user-tmpfiles.d/*.conf

$XDG_RUNTIME_DIR/user-tmpfiles.d/*.conf

~/.local/share/user-tmpfiles.d/*.conf

…

/usr/local/share/user-tmpfiles.d/*.conf

/usr/share/user-tmpfiles.d/*.conf

#Type Path                                     Mode User Group Age         Argument
f     /file/to/create                          mode user group -           content
f+    /file/to/create-or-truncate              mode user group -           content
w     /file/to/write-to                        -    -    -     -           content
w+    /file/to/append-to                       -    -    -     -           content
d     /directory/to/create-and-clean-up        mode user group cleanup-age -
D     /directory/to/create-and-remove          mode user group cleanup-age -
e     /directory/to/clean-up                   mode user group cleanup-age -
v     /subvolume-or-directory/to/create        mode user group cleanup-age -
q     /subvolume-or-directory/to/create        mode user group cleanup-age -
Q     /subvolume-or-directory/to/create        mode user group cleanup-age -
p     /fifo/to/create                          mode user group -           -
p+    /fifo/to/[re]create                      mode user group -           -
L     /symlink/to/create                       -    -    -     -           symlink/target/path
L+    /symlink/to/[re]create                   -    -    -     -           symlink/target/path
c     /dev/char-device-to-create               mode user group -           major:minor
c+    /dev/char-device-to-[re]create           mode user group -           major:minor
b     /dev/block-device-to-create              mode user group -           major:minor
b+    /dev/block-device-to-[re]create          mode user group -           major:minor
C     /target/to/create                        -    -    -     cleanup-age /source/to/copy
C+    /target/to/create                        -    -    -     cleanup-age /source/to/copy
x     /path-or-glob/to/ignore/recursively      -    -    -     cleanup-age -
X     /path-or-glob/to/ignore                  -    -    -     cleanup-age -
r     /path-or-glob/to/remove                  -    -    -     -           -
R     /path-or-glob/to/remove/recursively      -    -    -     -           -
z     /path-or-glob/to/adjust/mode             mode user group -           -
Z     /path-or-glob/to/adjust/mode/recursively mode user group -           -
t     /path-or-glob/to/set/xattrs              -    -    -     -           xattrs
T     /path-or-glob/to/set/xattrs/recursively  -    -    -     -           xattrs
h     /path-or-glob/to/set/attrs               -    -    -     -           file attrs
H     /path-or-glob/to/set/attrs/recursively   -    -    -     -           file attrs
a     /path-or-glob/to/set/acls                -    -    -     -           POSIX ACLs
a+    /path-or-glob/to/append/acls             -    -    -     -           POSIX ACLs
A     /path-or-glob/to/set/acls/recursively    -    -    -     -           POSIX ACLs
A+    /path-or-glob/to/append/acls/recursively -    -    -     -           POSIX ACLs

DESCRIPTION

tmpfiles.d configuration files provide a generic mechanism to define the creation of regular files, directories, pipes, and device nodes, adjustments to their access mode, ownership, attributes, quota assignments, and contents, and finally their time-based removal. It is mostly commonly used for volatile and temporary files and directories (such as those located under /run/, /tmp/, /var/tmp/, the API file systems such as /sys/ or /proc/, as well as some other directories below /var/).

systemd-tmpfiles(8) uses this configuration to create volatile files and directories during boot and to do periodic cleanup afterwards. See systemd-tmpfiles(8) for the description of systemd-tmpfiles-setup.service, systemd-tmpfiles-clean.service, and associated units.

System daemons frequently require private runtime directories below /run/ to store communication sockets and similar. For these, it is better to use RuntimeDirectory= in their unit files (see systemd.exec(5) for details), if the flexibility provided by tmpfiles.d is not required. The advantages are that the configuration required by the unit is centralized in one place, and that the lifetime of the directory is tied to the lifetime of the service itself. Similarly, StateDirectory=, CacheDirectory=, LogsDirectory=, and ConfigurationDirectory= should be used to create directories under /var/lib/, /var/cache/, /var/log/, and /etc/. tmpfiles.d should be used for files whose lifetime is independent of any service or requires more complicated configuration.

CONFIGURATION DIRECTORIES AND PRECEDENCE

Each configuration file shall be named in the style of package.conf or package-part.conf. The second variant should be used when it is desirable to make it easy to override just this part of configuration.

Files in /etc/tmpfiles.d override files with the same name in /usr/lib/tmpfiles.d and /run/tmpfiles.d. Files in /run/tmpfiles.d override files with the same name in /usr/lib/tmpfiles.d. Packages should install their configuration files in /usr/lib/tmpfiles.d. Files in /etc/tmpfiles.d are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages. All configuration files are sorted by their filename in lexicographic order, regardless of which of the directories they reside in. If multiple files specify the same path, the entry in the file with the lexicographically earliest name will be applied (note that lines suppressed due to the “!” are filtered before application, meaning that if an early line carries the exclamation mark and is suppressed because of that, a later line matching in path will be applied). All other conflicting entries will be logged as errors. When two lines are prefix path and suffix path of each other, then the prefix line is always created first, the suffix later (and if removal applies to the line, the order is reversed: the suffix is removed first, the prefix later). Lines that take globs are applied after those accepting no globs. If multiple operations shall be applied on the same file (such as ACL, xattr, file attribute adjustments), these are always done in the same fixed order. Except for those cases, the files/directories are processed in the order they are listed.

If the administrator wants to disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in /etc/tmpfiles.d/ bearing the same filename.

CONFIGURATION FILE FORMAT

The configuration format is one line per path, containing type, path, mode, ownership, age, and argument fields. The lines are separated by newlines, the fields by whitespace:

#Type Path Mode User Group Age Argument… d /run/user 0755 root root 10d - L /tmp/foobar - - - - /dev/null

Fields may contain C-style escapes. With the exception of the seventh field (the “argument”) all fields may be enclosed in quotes. Note that any whitespace found in the line after the beginning of the argument field will be considered part of the argument field. To begin the argument field with a whitespace character, use C-style escapes (e.g. " “).

Type

The type consists of a single letter and optionally one or more modifier characters: a plus sign ("+”), exclamation mark ("!"), minus sign ("-"), equals sign ("="), tilde character ("~") and/or caret ("^").

The following line types are understood:

f, f+

f will create a file if it does not exist yet. If the argument parameter is given and the file did not exist yet, it will be written to the file. f+ will create or truncate the file. If the argument parameter is given, it will be written to the file. Does not follow symlinks.

w, w+

Write the argument parameter to a file, if the file exists. If suffixed with +, the line will be appended to the file. If your configuration writes multiple lines to the same file, use w+. Lines of this type accept shell-style globs in place of normal path names. The argument parameter will be written without a trailing newline. C-style backslash escapes are interpreted. Follows symlinks.

Create a directory. The mode and ownership will be adjusted if specified. Contents of this directory are subject to time-based cleanup if the age argument is specified.

Similar to d, but in addition the contents of the directory will be removed when –remove is used.

Adjust the mode and ownership of existing directories and remove their contents based on age. Lines of this type accept shell-style globs in place of normal path names. Contents of the directories are subject to time-based cleanup if the age argument is specified. If the age argument is “0”, contents will be unconditionally deleted every time systemd-tmpfiles(8) –clean is run.
For this entry to be useful, at least one of the mode, user, group, or age arguments must be specified, since otherwise this entry has no effect. As an exception, an entry with no effect may be useful when combined with !, see the examples.
Added in version 230.

Create a subvolume if the path does not exist yet, the file system supports subvolumes (btrfs), and the system itself is installed into a subvolume (specifically: the root directory / is itself a subvolume). Otherwise, create a normal directory, in the same way as d.
A subvolume created with this line type is not assigned to any higher-level quota group. For that, use q or Q, which allow creating simple quota group hierarchies, see below.
Added in version 219.

Create a subvolume or directory the same as v, but assign the subvolume to the same higher-level quota groups as the parent. This ensures that higher-level limits and accounting applied to the parent subvolume also include the specified subvolume. On non-btrfs file systems, this line type is identical to d.
If the subvolume already exists, no change to the quota hierarchy is made, regardless of whether the subvolume is already attached to a quota group or not. Also see Q below. See btrfs-qgroup(8) for details about the btrfs quota group concept.
Added in version 228.

Create the subvolume or directory the same as v, but assign the new subvolume to a new leaf quota group. Instead of copying the higher-level quota group assignments from the parent as is done with q, the lowest quota group of the parent subvolume is determined that is not the leaf quota group. Then, an “intermediary” quota group is inserted that is one level below this level, and shares the same ID part as the specified subvolume. If no higher-level quota group exists for the parent subvolume, a new quota group at level 255 sharing the same ID as the specified subvolume is inserted instead. This new intermediary quota group is then assigned to the parent subvolumes higher-level quota groups, and the specified subvolumes leaf quota group is assigned to it.
Effectively, this has a similar effect as q, however introduces a new higher-level quota group for the specified subvolume that may be used to enforce limits and accounting to the specified subvolume and children subvolume created within it. Thus, by creating subvolumes only via q and Q, a concept of “subtree quotas” is implemented. Each subvolume for which Q is set will get a “subtree” quota group created, and all child subvolumes created within it will be assigned to it. Each subvolume for which q is set will not get such a “subtree” quota group, but it is ensured that they are added to the same “subtree” quota group as their immediate parents.
It is recommended to use Q for subvolumes that typically contain further subvolumes, and where it is desirable to have accounting and quota limits on all child subvolumes together. Examples for Q are typically /home/ or /var/lib/machines/. In contrast, q should be used for subvolumes that either usually do not include further subvolumes or where no accounting and quota limits are needed that apply to all child subvolumes together. Examples for q are typically /var/ or /var/tmp/.
As with q, Q has no effect on the quota group hierarchy if the subvolume already exists, regardless of whether the subvolume already belong to a quota group or not.
Added in version 228.

p, p+

Create a named pipe (FIFO) if it does not exist yet. If suffixed with + and a file already exists where the pipe is to be created, it will be removed and be replaced by the pipe.

L, L+

Create a symlink if it does not exist yet. If suffixed with + and a file or directory already exists where the symlink is to be created, it will be removed and be replaced by the symlink. If the argument is omitted, symlinks to files with the same name residing in the directory /usr/share/factory/ are created. Note that permissions on symlinks are ignored.

c, c+

Create a character device node if it does not exist yet. If suffixed with + and a file already exists where the device node is to be created, it will be removed and be replaced by the device node. It is recommended to suffix this entry with an exclamation mark to only create static device nodes at boot, as udev will not manage static device nodes that are created at runtime.

b, b+

Create a block device node if it does not exist yet. If suffixed with + and a file already exists where the device node is to be created, it will be removed and be replaced by the device node. It is recommended to suffix this entry with an exclamation mark to only create static device nodes at boot, as udev will not manage static device nodes that are created at runtime.

C, C+

Recursively copy a file or directory, if the destination files or directories do not exist yet or the destination directory is empty. Note that this command will not descend into subdirectories if the destination directory already exists and is not empty, unless the action is suffixed with +. Instead, the entire copy operation is skipped. If the argument is omitted, files from the source directory /usr/share/factory/ with the same name are copied. Does not follow symlinks. Contents of the directories are subject to time-based cleanup if the age argument is specified.
Added in version 214.

Ignore a path during cleaning. Use this type to exclude paths from clean-up as controlled with the Age parameter. Lines of this type accept shell-style globs in place of normal path names.

Ignore a path during cleaning. Use this type to exclude paths from clean-up as controlled with the Age parameter. Unlike x, this parameter will not exclude the content if path is a directory, but only directory itself. Lines of this type accept shell-style globs in place of normal path names.
Added in version 198.

Remove a file or directory if it exists. This may not be used to remove non-empty directories, use R for that. Lines of this type accept shell-style globs in place of normal path names. Does not follow symlinks.

Recursively remove a path and all its subdirectories (if it is a directory). Lines of this type accept shell-style globs in place of normal path names. Does not follow symlinks.

Adjust the access mode, user and group ownership, and restore the SELinux security context of a file or directory, if it exists. Lines of this type accept shell-style globs in place of normal path names. Does not follow symlinks.

Recursively set the access mode, user and group ownership, and restore the SELinux security context of a file or directory if it exists, as well as of its subdirectories and the files contained therein (if applicable). Lines of this type accept shell-style globs in place of normal path names. Does not follow symlinks.

Set extended attributes, see attr(5) for details. The argument field should take one or more assignment expressions in the form namespace.attribute=value, for examples see below. Lines of this type accept shell-style globs in place of normal path names. This can be useful for setting SMACK labels. Does not follow symlinks.
Please note that extended attributes settable with this line type are a different concept from the Linux file attributes settable with h/H, see below.
Added in version 218.

Same as t, but operates recursively.
Added in version 219.

Set Linux file/directory attributes. Lines of this type accept shell-style globs in place of normal path names.
The format of the argument field is [+-=][aAcCdDeijPsStTu]. The prefix + (the default one) causes the attributes to be added; - causes the attributes to be removed; = causes the attributes to be set exactly as the following letters. The letters “aAcCdDeijPsStTu” select the new attributes for the files, see chattr(1) for further information.
Passing only = as argument resets all the file attributes listed above. It has to be pointed out that the = prefix limits itself to the attributes corresponding to the letters listed here. All other attributes will be left untouched. Does not follow symlinks.
Please note that the Linux file attributes settable with this line type are a different concept from the extended attributes settable with t/T, see above.

Sames as h, but operates recursively.
Added in version 220.

a, a+

Set POSIX ACLs (access control lists), see acl(5). Additionally, if X is used, the execute bit is set only if the file is a directory or already has execute permission for some user, as mentioned in setfacl(1). If suffixed with +, the specified entries will be added to the existing set. systemd-tmpfiles(8) will automatically add the required base entries for user and group based on the access mode of the file, unless base entries already exist or are explicitly specified. The mask will be added if not specified explicitly or already present. Lines of this type accept shell-style globs in place of normal path names. This can be useful for allowing additional access to certain files. Does not follow symlinks.
Added in version 219.

A, A+

Same as a and a+, but recursive. Does not follow symlinks.
Added in version 219.

Type Modifiers

If the exclamation mark ("!") is used, this line is only safe to execute during boot, and can break a running system. Lines without the exclamation mark are presumed to be safe to execute at any time, e.g. on package upgrades. systemd-tmpfiles(8) will take lines with an exclamation mark only into consideration, if the –boot option is given.

For example:

Make sure these are created by default so that nobody else can
d /tmp/.X11-unix 1777 root root 10d

# Unlink the X11 lock files
r! /tmp/.X[0-9]*-lock

The second line in contrast to the first one would break a running system, and will only be executed with –boot.

If the minus sign ("-") is used, this line failing to run successfully during create (and only create) will not cause the execution of systemd-tmpfiles to return an error.

For example:

Modify sysfs but dont fail if we are in a container with a read-only /proc
w- /proc/sys/vm/swappiness - - - - 10

If the equals sign ("=") is used, the file types of existing objects in the specified path are checked, and removed if they do not match. This includes any implicitly created parent directories (which can be either directories or directory symlinks). For example, if there is a FIFO in place of one of the parent path components it will be replaced with a directory.

If the tilde character ("~") is used, the argument (i.e. 6th) column is Base64 decoded[1] before use. This modifier is only supported on line types that can write file contents, i.e. f, f+, w, +. This is useful for writing arbitrary binary data (including newlines and NUL bytes) to files. Note that if this switch is used, the argument is not subject to specifier expansion, neither before nor after Base64 decoding.

If the caret character ("^") is used, the argument (i.e. 6th) column takes a service credential name to read the argument data from. See System and Service Credentials[2] for details about the credentials concept. This modifier is only supported on line types that can write file contents, i.e. f, f+, w, w+. This is useful for writing arbitrary files with contents sourced from elsewhere, including from VM or container managers further up. If the specified credential is not set for the systemd-tmpfiles service, the line is silently skipped. If “^” and “~” are combined Base64 decoding is applied to the credential contents.

Note that for all line types that result in creation of any kind of file node (i.e. f, d/D/v/q/Q, p, L, c/b and C) leading directories are implicitly created if needed, owned by root with an access mode of 0755. In order to create them with different modes or ownership make sure to add appropriate d lines.

Path

The file system path specification supports simple specifier expansion, see below. The path (after expansion) must be absolute.

Mode

The file access mode to use when creating this file or directory. If omitted or when set to “-”, the default is used: 0755 for directories, 0644 for all other file objects. For z, Z lines, if omitted or when set to “-”, the file access mode will not be modified. This parameter is ignored for x, r, R, L, t, and a lines.

Optionally, if prefixed with “~”, the access mode is masked based on the already set access bits for existing file or directories: if the existing file has all executable bits unset, all executable bits are removed from the new access mode, too. Similarly, if all read bits are removed from the old access mode, they will be removed from the new access mode too, and if all write bits are removed, they will be removed from the new access mode too. In addition, the sticky/SUID/SGID bit is removed unless applied to a directory. This functionality is particularly useful in conjunction with Z.

By default the access mode of listed inodes is set to the specified mode regardless if it is created anew, or already existed. Optionally, if prefixed with “:”, the configured access mode is only applied when creating new inodes, and if the inode the line refers to already exists, its access mode is left in place unmodified.

User, Group

The user and group to use for this file or directory. This may either be a numeric ID or a user/group name. If omitted or when set to “-”, the user and group of the user who invokes systemd-tmpfiles(8) is used. For z and Z lines, when omitted or when set to “-”, the file ownership will not be modified. These parameters are ignored for x, r, R, t, and a lines.

This field should generally only reference system users/groups, i.e. users/groups that are guaranteed to be resolvable during early boot. If this field references users/groups that only become resolveable during later boot (i.e. after NIS, LDAP or a similar networked directory service become available), execution of the operations declared by the line will likely fail. Also see Notes on Resolvability of User and Group Names[3] for more information on requirements on system user/group definitions.

By default the ownership of listed inodes is set to the specified user/group regardless if it is created anew, or already existed. Optionally, if prefixed with “:”, the configured user/group information is only applied when creating new inodes, and if the inode the line refers to already exists, its user/group is left in place unmodified.

Age

The date field, when set, is used to decide what files to delete when cleaning. If a file or directory is older than the current time minus the age field, it is deleted. The field format is a series of integers each followed by one of the following suffixes for the respective time units: s, m or min, h, d, w, ms, and us, meaning seconds, minutes, hours, days, weeks, milliseconds, and microseconds, respectively. Full names of the time units can be used too.

If multiple integers and units are specified, the time values are summed. If an integer is given without a unit, s is assumed.

When the age is set to zero, the files are cleaned unconditionally.

The age field only applies to lines starting with d, D, e, v, q, Q, C, x and X. If omitted or set to “-”, no automatic clean-up is done.

If the age field starts with a tilde character “~”, clean-up is only applied to files and directories one level inside the directory specified, but not the files and directories immediately inside it.

The age of a file system entry is determined from its last modification timestamp (mtime), its last access timestamp (atime), and (except for directories) its last status change timestamp (ctime). By default, any of these three (or two) values will prevent cleanup if it is more recent than the current time minus the age field. To restrict the deletion based on particular type of file timestamps, the age-by argument can be used.

The age-by argument overrides the timestamp types to be used for the age check. It can be specified by prefixing the age argument with a sequence of characters to specify the timestamp types and a colon (":"): “age-by…:cleanup-age”. The argument can consist of a (A for directories), b (B for directories), c (C for directories), or m (M for directories). Those respectively indicate access, creation, last status change, and last modification time of a file system entry. The lower-case letter signifies that the given timestamp type should be considered for files, while the upper-case letter signifies that the given timestamp type should be considered for directories. See statx(2) file timestamp fields for more details about timestamp types.

If not specified, the age-by field defaults to abcmABM, i.e. by default all file timestamps are taken into consideration, with the exception of the last status change timestamp (ctime) for directories. This is because the aging logic itself will alter the ctime whenever it deletes a file inside it. To ensure that running the aging logic does not feed back into the next iteration of itself, ctime for directories is ignored by default.

For example:

Files created and modified, and directories accessed more than
# an hour ago in "/tmp/foo/bar", are subject to time-based cleanup.
d /tmp/foo/bar - - - bmA:1h -

Note that while the aging algorithm is run an exclusive BSD file lock (see flock(2)) is taken on each directory/file the algorithm decides to remove. If the aging algorithm finds a lock (shared or exclusive) is already taken on some directory/file, it (and everything below it) is skipped. Applications may use this to temporarily exclude certain directory subtrees from the aging algorithm: the applications can take a BSD file lock themselves, and as long as they keep it aging of the directory/file and everything below it is disabled.

This behavior can be used to ensure guaranteed cleanup of files or directories whose lifetime should be aligned with the process that created them by having that process create them in a location monitored by systemd-tmpfiles with an age of “0”, and having the process immediately lock the directory or file before using it. Because the BSD lock is process specific, the file is guaranteed to be unlocked as soon as the process exits, meaning that even if the process crashes, those files and directories will be unlocked and cleaned up by systemd-tmpfiles.

Argument

For L lines determines the destination path of the symlink. For c and b, determines the major/minor of the device node, with major and minor formatted as integers, separated by “:”, e.g. “1:3”. For f and w, the argument may be used to specify a short string that is written to the file, suffixed by a newline. For C, specifies the source file or directory. For t and T, determines extended attributes to be set. For a and A, determines ACL attributes to be set. For h and H, determines the file attributes to set. Ignored for all other lines.

This field can contain specifiers, see below.

SPECIFIERS

Specifiers can be used in the “path” and “argument” fields. An unknown or unresolvable specifier is treated as invalid configuration. The following expansions are understood:

Table 1. Specifiers available

Specifier	Meaning	Details
"%a"	Architecture	A short string identifying the architecture of the local system. A string such as x86, x86-64 or arm64. See the architectures defined for ConditionArchitecture= in systemd.unit(5) for a full list.
"%A"	Operating system image version	The operating system image version identifier of the running system, as read from the IMAGE_VERSION= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.
"%b"	Boot ID	The boot ID of the running system, formatted as string. See random(4) for more information.
"%B"	Operating system build ID	The operating system build identifier of the running system, as read from the BUILD_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.
"%C"	System or user cache directory	In --user mode, this is the same as $XDG_CACHE_HOME, and /var/cache otherwise.
"%g"	User group	This is the name of the group running the command. In case of the system instance this resolves to "root".
"%G"	User GID	This is the numeric GID of the group running the command. In case of the system instance this resolves to 0.
"%h"	User home directory	This is the home directory of the user running the command. In case of the system instance this resolves to "/root".
"%H"	Host name	The hostname of the running system.
"%l"	Short host name	The hostname of the running system, truncated at the first dot to remove any domain component.
"%L"	System or user log directory	In --user mode, this is the same as $XDG_STATE_HOME with /log appended, and /var/log otherwise.
"%m"	Machine ID	The machine ID of the running system, formatted as string. See machine-id(5) for more information.
"%M"	Operating system image identifier	The operating system image identifier of the running system, as read from the IMAGE_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.
"%o"	Operating system ID	The operating system identifier of the running system, as read from the ID= field of /etc/os-release. See os-release(5) for more information.
"%S"	System or user state directory	In --user mode, this is the same as $XDG_STATE_HOME, and /var/lib otherwise.
"%t"	System or user runtime directory	In --user mode, this is the same $XDG_RUNTIME_DIR, and /run/ otherwise.
"%T"	Directory for temporary files	This is either /tmp or the path "$TMPDIR", "$TEMP" or "$TMP" are set to. (Note that the directory may be specified without a trailing slash.)
"%u"	User name	This is the name of the user running the command. In case of the system instance this resolves to "root".
"%U"	User UID	This is the numeric UID of the user running the command. In case of the system instance this resolves to 0.
"%v"	Kernel release	Identical to uname -r output.
"%V"	Directory for larger and persistent temporary files	This is either /var/tmp or the path "$TMPDIR", "$TEMP" or "$TMP" are set to. (Note that the directory may be specified without a trailing slash.)
"%w"	Operating system version ID	The operating system version identifier of the running system, as read from the VERSION_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.
"%W"	Operating system variant ID	The operating system variant identifier of the running system, as read from the VARIANT_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.
"%%"	Single percent sign	Use "%%" in place of "%" to specify a single percent sign.

EXAMPLES

Example 1. Create directories with specific mode and ownership

screen(1), needs two directories created at boot with specific modes and ownership:

/usr/lib/tmpfiles.d/screen.conf

d /run/screens  1777 root screen 10d
d /run/uscreens 0755 root screen 10d12h

Contents of /run/screens and /run/uscreens will be cleaned up after 10 and 10½ days, respectively.

Example 2. Create a directory with a SMACK attribute

D /run/cups - - - - t /run/cups - - - - security.SMACK64=printing user.attr-with-spaces=“foo bar”

The directory will be owned by root and have default mode. Its contents are not subject to time-based cleanup, but will be obliterated when systemd-tmpfiles –remove runs.

Example 3. Create a directory and prevent its contents from cleanup

abrt(1), needs a directory created at boot with specific mode and ownership and its content should be preserved from the automatic cleanup applied to the contents of /var/tmp:

/usr/lib/tmpfiles.d/tmp.conf
d /var/tmp 1777 root root 30d

/usr/lib/tmpfiles.d/abrt.conf
d /var/tmp/abrt 0755 abrt abrt -

Example 4. Apply clean up during boot and based on time

/usr/lib/tmpfiles.d/dnf.conf

r! /var/cache/dnf/*/*/download_lock.pid
r! /var/cache/dnf/*/*/metadata_lock.pid
r! /var/lib/dnf/rpmdb_lock.pid
e  /var/cache/dnf/ - - - 30d

The lock files will be removed during boot. Any files and directories in /var/cache/dnf/ will be removed after they have not been accessed in 30 days.

Example 5. Empty the contents of a cache directory on boot

/usr/lib/tmpfiles.d/krb5rcache.conf
e! /var/cache/krb5rcache - - - 0

Any files and subdirectories in /var/cache/krb5rcache/ will be removed on boot. The directory will not be created.

Example 6. Provision SSH public key access for root user via Credentials in QEMU

-smbios type=11,value=io.systemd.credential.binary:tmpfiles.extra=$(echo -e “d /root/.ssh 0750 root root - f~ /root/.ssh/authorized_keys 0600 root root - $(ssh-add -L | base64 -w 0)” | base64 -w 0)

By passing this line to QEMU, the public key of the current user will be encoded in base64, added to a tmpfiles.d line that tells systemd-tmpfiles to decode it into /root/.ssh/authorized_keys, encode that line itself in base64 and pass it as a Credential that will be picked up by systemd from SMBIOS on boot.

/RUN/ AND /VAR/RUN/

/var/run/ is a deprecated symlink to /run/, and applications should use the latter. systemd-tmpfiles will warn if /var/run/ is used.

NOTES

Base64 decoded

https://www.rfc-editor.org/rfc/rfc4648.html

System and Service Credentials

https://systemd.io/CREDENTIALS

Notes on Resolvability of User and Group Names

https://systemd.io/UIDS-GIDS/#notes-on-resolvability-of-user-and-group-names

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

268 - Linux cli command ssh_config

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ssh_config and provides detailed information about the command ssh_config, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ssh_config.

obtains configuration data from the following sources in the following order:

command-line options

user’s configuration file

system-wide configuration file

Unless noted otherwise, for each parameter, the first obtained value will be used. The configuration files contain sections separated by

specifications, and that section is only applied for hosts that match one of the patterns given in the specification. The matched host name is usually the one given on the command line (see the

option for exceptions).

Since the first obtained value for each parameter is used, more host-specific declarations should be given near the beginning of the file, and general defaults at the end.

Note that the Debian

package sets several options as standard in

which are not the default in

files are included at the start of the system-wide configuration file, so options set there will override those in

The file contains keyword-argument pairs, one per line. Lines starting with

and empty lines are interpreted as comments. Arguments may optionally be enclosed in double quotes

in order to represent arguments containing spaces. Configuration options may be separated by whitespace or optional whitespace and exactly one

the latter format is useful to avoid the need to quote whitespace when specifying configuration options using the

and

option.

The possible keywords and their meanings are as follows (note that keywords are case-insensitive and arguments are case-sensitive):

Restricts the following declarations (up to the next

keyword) to be only for those hosts that match one of the patterns given after the keyword. If more than one pattern is provided, they should be separated by whitespace. A single

as a pattern can be used to provide global defaults for all hosts. The host is usually the

argument given on the command line (see the

keyword for exceptions).

A pattern entry may be negated by prefixing it with an exclamation mark

If a negated entry is matched, then the

entry is ignored, regardless of whether any other patterns on the line match. Negated matches are therefore useful to provide exceptions for wildcard matches.

See

for more information on patterns.

Restricts the following declarations (up to the next

keyword) to be used only when the conditions following the

keyword are satisfied. Match conditions are specified using one or more criteria or the single token

which always matches. The available criteria keywords are:

and

The

criteria must appear alone or immediately after

Other criteria may be combined arbitrarily. All criteria but

and

require an argument. Criteria may be negated by prepending an exclamation mark

The

keyword matches only when the configuration file is being re-parsed after hostname canonicalization (see the

option). This may be useful to specify conditions that work with canonical host names only.

The

keyword requests that the configuration be re-parsed (regardless of whether

is enabled), and matches only during this final pass. If

is enabled, then

and

match during the same pass.

The

keyword executes the specified command under the user’s shell. If the command returns a zero exit status then the condition is considered true. Commands containing whitespace characters must be quoted. Arguments to

accept the tokens described in the

section.

The

keyword matches the addresses of active local network interfaces against the supplied list of networks in CIDR format. This may be convenient for varying the effective configuration on devices that roam between networks. Note that network address is not a trustworthy criteria in many situations (e.g. when the network is automatically configured using DHCP) and so caution should be applied if using it to control security-sensitive configuration.

The other keywords’ criteria must be single entries or comma-separated lists and may use the wildcard and negation operators described in the

section. The criteria for the

keyword are matched against the target hostname, after any substitution by the

options. The

keyword matches against the hostname as it was specified on the command-line. The

keyword matches a tag name specified by a prior

directive or on the

command-line using the

flag. The

keyword matches against the target username on the remote host. The

keyword matches against the name of the local user running

(this keyword may be useful in system-wide

files).

Specifies whether keys should be automatically added to a running

If this option is set to

and a key is loaded from a file, the key and its passphrase are added to the agent with the default lifetime, as if by

If this option is set to

will require confirmation using the

program before adding a key (see

for details). If this option is set to

each use of the key must be confirmed, as if the

option was specified to

If this option is set to

no keys are added to the agent. Alternately, this option may be specified as a time interval using the format described in the

section of

to specify the key’s lifetime in

after which it will automatically be removed. The argument must be

(the default),

(optionally followed by a time interval),

or a time interval.

Specifies which address family to use when connecting. Valid arguments are

(the default),

(use IPv4 only), or

(use IPv6 only).

If set to

user interaction such as password prompts and host key confirmation requests will be disabled. In addition, the

option will be set to 300 seconds by default (Debian-specific). This option is useful in scripts and other batch jobs where no user is present to interact with

and where it is desirable to detect a broken network swiftly. The argument must be

(the default).

Use the specified address on the local machine as the source address of the connection. Only useful on systems with more than one address.

Use the address of the specified interface on the local machine as the source address of the connection.

When

is enabled, this option specifies the list of domain suffixes in which to search for the specified destination host.

Specifies whether to fail with an error when hostname canonicalization fails. The default,

will attempt to look up the unqualified hostname using the system resolver’s search rules. A value of

will cause

to fail instantly if

is enabled and the target hostname cannot be found in any of the domains specified by

Controls whether explicit hostname canonicalization is performed. The default,

is not to perform any name rewriting and let the system resolver handle all hostname lookups. If set to

then, for connections that do not use a

will attempt to canonicalize the hostname specified on the command line using the

suffixes and

rules. If

is set to

then canonicalization is applied to proxied connections too.

If this option is enabled, then the configuration files are processed again using the new target name to pick up any new configuration in matching

and

stanzas. A value of

disables the use of a

host.

Specifies the maximum number of dot characters in a hostname before canonicalization is disabled. The default, 1, allows a single dot (i.e. hostname.subdomain).

Specifies rules to determine whether CNAMEs should be followed when canonicalizing hostnames. The rules consist of one or more arguments of

where

is a pattern-list of domains that may follow CNAMEs in canonicalization, and

is a pattern-list of domains that they may resolve to.

For example,

will allow hostnames matching

to be canonicalized to names in the

domains.

A single argument of

causes no CNAMEs to be considered for canonicalization. This is the default behaviour.

Specifies which algorithms are allowed for signing of certificates by certificate authorities (CAs). The default is:

ssh-ed25519,ecdsa-sha2-nistp256, ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, [email protected], [email protected], rsa-sha2-512,rsa-sha2-256

If the specified list begins with a

character, then the specified algorithms will be appended to the default set instead of replacing them. If the specified list begins with a

character, then the specified algorithms (including wildcards) will be removed from the default set instead of replacing them.

will not accept host certificates signed using algorithms other than those specified.

Specifies a file from which the user’s certificate is read. A corresponding private key must be provided separately in order to use this certificate either from an

directive or

flag to

via

or via a

Arguments to

may use the tilde syntax to refer to a user’s home directory, the tokens described in the

section and environment variables as described in the

section.

It is possible to have multiple certificate files specified in configuration files; these certificates will be tried in sequence. Multiple

directives will add to the list of certificates used for authentication.

Specifies whether and how quickly

should close inactive channels. Timeouts are specified as one or more

pairs separated by whitespace, where the

must be the special keyword

or a channel type name from the list below, optionally containing wildcard characters.

The timeout value

is specified in seconds or may use any of the units documented in the

section. For example,

would cause interactive sessions to terminate after five minutes of inactivity. Specifying a zero value disables the inactivity timeout.

The special timeout

The available channel type names include:

Open connections to

Open TCP or Unix socket (respectively) connections that have been established from a

local forwarding, i.e.

Open TCP or Unix socket (respectively) connections that have been established to a

listening on behalf of a

remote forwarding, i.e.

The interactive main session, including shell session, command execution,

etc.

Open

connections.

Open X11 forwarding sessions.

The default is not to expire channels of any type for inactivity.

If set to

will additionally check the host IP address in the

file. This allows it to detect if a host key changed due to DNS spoofing and will add addresses of destination hosts to

in the process, regardless of the setting of

If the option is set to

(the default), the check will not be executed.

Specifies the ciphers allowed and their order of preference. Multiple ciphers must be comma-separated. If the specified list begins with a

character, then the specified ciphers will be appended to the default set instead of replacing them. If the specified list begins with a

character, then the specified ciphers (including wildcards) will be removed from the default set instead of replacing them. If the specified list begins with a

character, then the specified ciphers will be placed at the head of the default set.

The supported ciphers are:

3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr [email protected] [email protected] [email protected]

The default is:

[email protected], aes128-ctr,aes192-ctr,aes256-ctr, [email protected],[email protected]

The list of available ciphers may also be obtained using

Specifies that all local, remote, and dynamic port forwardings specified in the configuration files or on the command line be cleared. This option is primarily useful when used from the

command line to clear port forwardings set in configuration files, and is automatically set by

and

The argument must be

(the default).

Specifies whether to use compression. The argument must be

(the default).

Specifies the number of tries (one per second) to make before exiting. The argument must be an integer. This may be useful in scripts if the connection sometimes fails. The default is 1.

Specifies the timeout (in seconds) used when connecting to the SSH server, instead of using the default system TCP timeout. This timeout is applied both to establishing the connection and to performing the initial SSH protocol handshake and key exchange.

Enables the sharing of multiple sessions over a single network connection. When set to

will listen for connections on a control socket specified using the

argument. Additional sessions can connect to this socket using the same

with

set to

(the default). These sessions will try to reuse the master instance’s network connection rather than initiating new ones, but will fall back to connecting normally if the control socket does not exist, or is not listening.

Setting this to

will cause

to listen for control connections, but require confirmation using

If the

cannot be opened,

will continue without connecting to a master instance.

X11 and

forwarding is supported over these multiplexed connections, however the display and agent forwarded will be the one belonging to the master connection i.e. it is not possible to forward multiple displays or agents.

Two additional options allow for opportunistic multiplexing: try to use a master connection but fall back to creating a new one if one does not already exist. These options are:

and

The latter requires confirmation like the

option.

Specify the path to the control socket used for connection sharing as described in the

section above or the string

to disable connection sharing. Arguments to

may use the tilde syntax to refer to a user’s home directory, the tokens described in the

section and environment variables as described in the

section. It is recommended that any

used for opportunistic connection sharing include at least %h, %p, and %r (or alternatively %C) and be placed in a directory that is not writable by other users. This ensures that shared connections are uniquely identified.

When used in conjunction with

specifies that the master connection should remain open in the background (waiting for future client connections) after the initial client connection has been closed. If set to

(the default), then the master connection will not be placed into the background, and will close as soon as the initial client connection is closed. If set to

or 0, then the master connection will remain in the background indefinitely (until killed or closed via a mechanism such as the

If set to a time in seconds, or a time in any of the formats documented in

then the backgrounded master connection will automatically terminate after it has remained idle (with no client connections) for the specified time.

Specifies that a TCP port on the local machine be forwarded over the secure channel, and the application protocol is then used to determine where to connect to from the remote machine.

The argument must be

IPv6 addresses can be specified by enclosing addresses in square brackets. By default, the local port is bound in accordance with the

setting. However, an explicit

may be used to bind the connection to a specific address. The

indicates that the listening port be bound for local use only, while an empty address or

indicates that the port should be available from all interfaces.

Currently the SOCKS4 and SOCKS5 protocols are supported, and

will act as a SOCKS server. Multiple forwardings may be specified, and additional forwardings can be given on the command line. Only the superuser can forward privileged ports.

Enables the command line option in the

menu for interactive sessions (default

By default, the command line is disabled.

Setting this option to

in the global client configuration file

enables the use of the helper program

during

The argument must be

(the default). This option should be placed in the non-hostspecific section. See

for more information.

Sets the escape character (default:

The escape character can also be set on the command line. The argument should be a single character,

followed by a letter, or

to disable the escape character entirely (making the connection transparent for binary data).

Specifies whether

should terminate the connection if it cannot set up all requested dynamic, tunnel, local, and remote port forwardings, (e.g. if either end is unable to bind and listen on a specified port). Note that

does not apply to connections made over port forwardings and will not, for example, cause

to exit if TCP connections to the ultimate forwarding destination fail. The argument must be

(the default).

Specifies the hash algorithm used when displaying key fingerprints. Valid options are:

and

(the default).

Requests

to go to background just before command execution. This is useful if

is going to ask for passwords or passphrases, but the user wants it in the background. This implies the

configuration option being set to

The recommended way to start X11 programs at a remote site is with something like

which is the same as

if the

configuration option is set to

If the

configuration option is set to

then a client started with the

configuration option being set to

will wait for all remote port forwards to be successfully established before placing itself in the background. The argument to this keyword must be

(same as the

option) or

(the default).

Specifies whether the connection to the authentication agent (if any) will be forwarded to the remote machine. The argument may be

(the default), an explicit path to an agent socket or the name of an environment variable (beginning with

in which to find the path.

Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent’s Unix-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.

Specifies whether X11 connections will be automatically redirected over the secure channel and

set. The argument must be

(the default).

X11 forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the user’s X11 authorization database) can access the local X11 display through the forwarded connection. An attacker may then be able to perform activities such as keystroke monitoring if the

option is also enabled.

Specify a timeout for untrusted X11 forwarding using the format described in the

section of

X11 connections received by

after this time will be refused. Setting

to zero will disable the timeout and permit X11 forwarding for the life of the connection. The default is to disable untrusted X11 forwarding after twenty minutes has elapsed.

If this option is set to

(the Debian-specific default), remote X11 clients will have full access to the original X11 display.

If this option is set to

(the upstream default), remote X11 clients will be considered untrusted and prevented from stealing or tampering with data belonging to trusted X11 clients. Furthermore, the

token used for the session will be set to expire after 20 minutes. Remote clients will be refused access after this time.

See the X11 SECURITY extension specification for full details on the restrictions imposed on untrusted clients.

Specifies whether remote hosts are allowed to connect to local forwarded ports. By default,

binds local port forwardings to the loopback address. This prevents other remote hosts from connecting to forwarded ports.

can be used to specify that ssh should bind local port forwardings to the wildcard address, thus allowing remote hosts to connect to forwarded ports. The argument must be

(the default).

Specifies one or more files to use for the global host key database, separated by whitespace. The default is

Specifies whether user authentication based on GSSAPI is allowed. The default is

If set, specifies the GSSAPI client identity that ssh should use when connecting to the server. The default is unset, which means that the default identity will be used.

Forward (delegate) credentials to the server. The default is

Specifies whether key exchange based on GSSAPI may be used. When using GSSAPI key exchange the server need not have a host key. The default is

If set to

then renewal of the client’s GSSAPI credentials will force the rekeying of the ssh connection. With a compatible server, this will delegate the renewed credentials to a session on the server.

Checks are made to ensure that credentials are only propagated when the new credentials match the old ones on the originating client and where the receiving server still has the old set in its cache.

The default is

For this to work

needs to be enabled in the server and also used by the client.

If set, specifies the GSSAPI server identity that ssh should expect when connecting to the server. The default is unset, which means that the expected GSSAPI server identity will be determined from the target hostname.

Set to

to indicate that the DNS is trusted to securely canonicalize the name of the host being connected to. If

the hostname entered on the command line will be passed untouched to the GSSAPI library. The default is

The list of key exchange algorithms that are offered for GSSAPI key exchange. Possible values are

gss-gex-sha1-, gss-group1-sha1-, gss-group14-sha1-, gss-group14-sha256-, gss-group16-sha512-, gss-nistp256-sha256-, gss-curve25519-sha256-

The default is

This option only applies to connections using GSSAPI.

Indicates that

should hash host names and addresses when they are added to

These hashed names may be used normally by

and

but they do not visually reveal identifying information if the file’s contents are disclosed. The default is

Note that existing names and addresses in known hosts files will not be converted automatically, but may be manually hashed using

Use of this option may break facilities such as tab-completion that rely on being able to read unhashed host names from

Specifies the signature algorithms that will be used for hostbased authentication as a comma-separated list of patterns. Alternately if the specified list begins with a

character, then the specified signature algorithms will be appended to the default set instead of replacing them. If the specified list begins with a

character, then the specified signature algorithms (including wildcards) will be removed from the default set instead of replacing them. If the specified list begins with a

character, then the specified signature algorithms will be placed at the head of the default set. The default for this option is:

The

option of

may be used to list supported signature algorithms. This was formerly named HostbasedKeyTypes.

Specifies whether to try rhosts based authentication with public key authentication. The argument must be

(the default).

Specifies the host key signature algorithms that the client wants to use in order of preference. Alternately if the specified list begins with a

character, then the specified signature algorithms will be appended to the default set instead of replacing them. If the specified list begins with a

character, then the specified signature algorithms (including wildcards) will be removed from the default set instead of replacing them. If the specified list begins with a

character, then the specified signature algorithms will be placed at the head of the default set. The default for this option is:

If hostkeys are known for the destination host then this default is modified to prefer their algorithms.

The list of available signature algorithms may also be obtained using

Specifies an alias that should be used instead of the real host name when looking up or saving the host key in the host key database files and when validating host certificates. This option is useful for tunneling SSH connections or for multiple servers running on a single host.

Specifies the real host name to log into. This can be used to specify nicknames or abbreviations for hosts. Arguments to

accept the tokens described in the

section. Numeric IP addresses are also permitted (both on the command line and in

specifications). The default is the name given on the command line.

Specifies that

should only use the configured authentication identity and certificate files (either the default files, or those explicitly configured in the

files or passed on the

command-line), even if

or a

offers more identities. The argument to this keyword must be

(the default). This option is intended for situations where ssh-agent offers many different identities.

Specifies the

socket used to communicate with the authentication agent.

This option overrides the

environment variable and can be used to select a specific agent. Setting the socket name to

disables the use of an authentication agent. If the string

is specified, the location of the socket will be read from the

environment variable. Otherwise if the specified value begins with a

character, then it will be treated as an environment variable containing the location of the socket.

Arguments to

may use the tilde syntax to refer to a user’s home directory, the tokens described in the

section and environment variables as described in the

section.

Specifies a file from which the user’s DSA, ECDSA, authenticator-hosted ECDSA, Ed25519, authenticator-hosted Ed25519 or RSA authentication identity is read. You can also specify a public key file to use the corresponding private key that is loaded in

when the private key file is not present locally. The default is

and

Additionally, any identities represented by the authentication agent will be used for authentication unless

is set. If no certificates have been explicitly specified by

will try to load certificate information from the filename obtained by appending

to the path of a specified

Arguments to

may use the tilde syntax to refer to a user’s home directory or the tokens described in the

section. Alternately an argument of

may be used to indicate no identity files should be loaded.

It is possible to have multiple identity files specified in configuration files; all these identities will be tried in sequence. Multiple

directives will add to the list of identities tried (this behaviour differs from that of other configuration directives).

may be used in conjunction with

to select which identities in an agent are offered during authentication.

may also be used in conjunction with

in order to provide any certificate also needed for authentication with the identity.

Specifies a pattern-list of unknown options to be ignored if they are encountered in configuration parsing. This may be used to suppress errors if

contains options that are unrecognised by

It is recommended that

be listed early in the configuration file as it will not be applied to unknown options that appear before it.

Include the specified configuration file(s). Multiple pathnames may be specified and each pathname may contain

wildcards and, for user configurations, shell-like

references to user home directories. Wildcards will be expanded and processed in lexical order. Files without absolute paths are assumed to be in

if included in a user configuration file or

if included from the system configuration file.

directive may appear inside a

block to perform conditional inclusion.

Specifies the IPv4 type-of-service or DSCP class for connections. Accepted values are

a numeric value, or

for interactive sessions and

for non-interactive sessions.

Specifies whether to use keyboard-interactive authentication. The argument to this keyword must be

(the default) or

is a deprecated alias for this.

Specifies the list of methods to use in keyboard-interactive authentication. Multiple method names must be comma-separated. The default is to use the server specified list. The methods available vary depending on what the server supports. For an OpenSSH server, it may be zero or more of:

and

Specifies the available KEX (Key Exchange) algorithms. Multiple algorithms must be comma-separated. If the specified list begins with a

character, then the specified algorithms will be appended to the default set instead of replacing them. If the specified list begins with a

character, then the specified algorithms (including wildcards) will be removed from the default set instead of replacing them. If the specified list begins with a

character, then the specified algorithms will be placed at the head of the default set. The default is:

[email protected], curve25519-sha256,[email protected], ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521, diffie-hellman-group-exchange-sha256, diffie-hellman-group16-sha512, diffie-hellman-group18-sha512, diffie-hellman-group14-sha256

The list of available key exchange algorithms may also be obtained using

Specifies a command to use to obtain a list of host keys, in addition to those listed in

and

This command is executed after the files have been read. It may write host key lines to standard output in identical format to the usual files (described in the

section in

Arguments to

accept the tokens described in the

section. The command may be invoked multiple times per connection: once when preparing the preference list of host key algorithms to use, again to obtain the host key for the requested host name and, if

is enabled, one more time to obtain the host key matching the server’s address. If the command exits abnormally or returns a non-zero exit status then the connection is terminated.

Specifies a command to execute on the local machine after successfully connecting to the server. The command string extends to the end of the line, and is executed with the user’s shell. Arguments to

accept the tokens described in the

section.

The command is run synchronously and does not have access to the session of the

that spawned it. It should not be used for interactive commands.

This directive is ignored unless

has been enabled.

Specifies that a TCP port on the local machine be forwarded over the secure channel to the specified host and port from the remote machine. The first argument specifies the listener and may be

or a Unix domain socket path. The second argument is the destination and may be

or a Unix domain socket path if the remote host supports it.

IPv6 addresses can be specified by enclosing addresses in square brackets. Multiple forwardings may be specified, and additional forwardings can be given on the command line. Only the superuser can forward privileged ports. By default, the local port is bound in accordance with the

setting. However, an explicit

may be used to bind the connection to a specific address. The

indicates that the listening port be bound for local use only, while an empty address or

indicates that the port should be available from all interfaces. Unix domain socket paths may use the tokens described in the

section and environment variables as described in the

section.

Gives the verbosity level that is used when logging messages from

Specify one or more overrides to LogLevel. An override consists of a pattern lists that matches the source file, function and line number to force detailed logging for. For example, an override pattern of:

kex.c:*:1000,*:kex_exchange_identification():*,packet.c:*

would enable detailed logging for line 1000 of

everything in the

function, and all code in the

file. This option is intended for debugging and no overrides are enabled by default.

Specifies the MAC (message authentication code) algorithms in order of preference. The MAC algorithm is used for data integrity protection. Multiple algorithms must be comma-separated. If the specified list begins with a

character, then the specified algorithms will be appended to the default set instead of replacing them. If the specified list begins with a

character, then the specified algorithms (including wildcards) will be removed from the default set instead of replacing them. If the specified list begins with a

character, then the specified algorithms will be placed at the head of the default set.

The algorithms that contain

calculate the MAC after encryption (encrypt-then-mac). These are considered safer and their use recommended.

The default is:

[email protected],[email protected], [email protected],[email protected], [email protected], [email protected],[email protected], hmac-sha2-256,hmac-sha2-512,hmac-sha1

The list of available MAC algorithms may also be obtained using

Disable host authentication for localhost (loopback addresses). The argument to this keyword must be

(the default).

Specifies the number of password prompts before giving up. The argument to this keyword must be an integer. The default is 3.

Specifies whether

should try to obscure inter-keystroke timings from passive observers of network traffic. If enabled, then for interactive sessions,

will send keystrokes at fixed intervals of a few tens of milliseconds and will send fake keystroke packets for some time after typing ceases. The argument to this keyword must be

or an interval specifier of the form

(e.g.

for 80 milliseconds). The default is to obscure keystrokes using a 20ms packet interval. Note that smaller intervals will result in higher fake keystroke packet rates.

Specifies whether to use password authentication. The argument to this keyword must be

(the default) or

Allow local command execution via the

option or using the

escape sequence in

The argument must be

(the default).

Specifies the destinations to which remote TCP port forwarding is permitted when

is used as a SOCKS proxy. The forwarding specification must be one of the following forms:

Multiple forwards may be specified by separating them with whitespace. An argument of

can be used to remove all restrictions and permit any forwarding requests. An argument of

can be used to prohibit all forwarding requests. The wildcard

can be used for host or port to allow all hosts or ports respectively. Otherwise, no pattern matching or address lookups are performed on supplied names.

Specifies which PKCS#11 provider to use or

to indicate that no provider should be used (the default). The argument to this keyword is a path to the PKCS#11 shared library

should use to communicate with a PKCS#11 token providing keys for user authentication.

Specifies the port number to connect on the remote host. The default is 22.

Specifies the order in which the client should try authentication methods. This allows a client to prefer one method (e.g.

over another method (e.g.

The default is:

gssapi-with-mic,hostbased,publickey, keyboard-interactive,password

Specifies the command to use to connect to the server. The command string extends to the end of the line, and is executed using the user’s shell

directive to avoid a lingering shell process.

Arguments to

accept the tokens described in the

section. The command can be basically anything, and should read from its standard input and write to its standard output. It should eventually connect an

server running on some machine, or execute

somewhere. Host key management will be done using the

of the host being connected (defaulting to the name typed by the user). Setting the command to

disables this option entirely. Note that

is not available for connects with a proxy command.

This directive is useful in conjunction with

and its proxy support. For example, the following directive would connect via an HTTP proxy at 192.0.2.0:

ProxyCommand /usr/bin/nc -X connect -x 192.0.2.0:8080 %h %p

Specifies one or more jump proxies as either

or an ssh URI

Multiple proxies may be separated by comma characters and will be visited sequentially. Setting this option will cause

to connect to the target host by first making a

connection to the specified

host and then establishing a TCP forwarding to the ultimate target from there. Setting the host to

disables this option entirely.

Note that this option will compete with the

option - whichever is specified first will prevent later instances of the other from taking effect.

Note also that the configuration for the destination host (either supplied via the command-line or the configuration file) is not generally applied to jump hosts.

should be used if specific configuration is required for jump hosts.

Specifies that

will pass a connected file descriptor back to

instead of continuing to execute and pass data. The default is

Specifies the signature algorithms that will be used for public key authentication as a comma-separated list of patterns. If the specified list begins with a

character, then the algorithms after it will be appended to the default instead of replacing it. If the specified list begins with a

character, then the specified algorithms (including wildcards) will be removed from the default set instead of replacing them. If the specified list begins with a

character, then the specified algorithms will be placed at the head of the default set. The default for this option is:

The list of available signature algorithms may also be obtained using

Specifies whether to try public key authentication. The argument to this keyword must be

(the default),

The final two options enable public key authentication while respectively disabling or enabling the OpenSSH host-bound authentication protocol extension required for restricted

forwarding.

to indicate Kilobytes, Megabytes, or Gigabytes, respectively. The default is between

and

depending on the cipher. The optional second value is specified in seconds and may use any of the units documented in the TIME FORMATS section of

The default value for

which means that rekeying is performed after the cipher’s default amount of data has been sent or received and no time based rekeying is done.

Specifies a command to execute on the remote machine after successfully connecting to the server. The command string extends to the end of the line, and is executed with the user’s shell. Arguments to

accept the tokens described in the

section.

Specifies that a TCP port on the remote machine be forwarded over the secure channel. The remote port may either be forwarded to a specified host and port from the local machine, or may act as a SOCKS 4/5 proxy that allows a remote client to connect to arbitrary destinations from the local machine. The first argument is the listening specification and may be

or, if the remote host supports it, a Unix domain socket path. If forwarding to a specific destination then the second argument must be

or a Unix domain socket path, otherwise if no destination argument is specified then the remote forwarding will be established as a SOCKS proxy. When acting as a SOCKS proxy, the destination of the connection can be restricted by

IPv6 addresses can be specified by enclosing addresses in square brackets. Multiple forwardings may be specified, and additional forwardings can be given on the command line. Privileged ports can be forwarded only when logging in as root on the remote machine. Unix domain socket paths may use the tokens described in the

section and environment variables as described in the

section.

If the

argument is 0, the listen port will be dynamically allocated on the server and reported to the client at run time.

If the

is not specified, the default is to only bind to loopback addresses. If the

or an empty string, then the forwarding is requested to listen on all interfaces. Specifying a remote

will only succeed if the server’s

option is enabled (see

Specifies whether to request a pseudo-tty for the session. The argument may be one of:

(never request a TTY),

(always request a TTY when standard input is a TTY),

(always request a TTY) or

(request a TTY when opening a login session). This option mirrors the

and

flags for

Specifies the minimum RSA key size (in bits) that

will accept. User authentication keys smaller than this limit will be ignored. Servers that present host keys smaller than this limit will cause the connection to be terminated. The default is

bits. Note that this limit may only be raised from the default.

Specifies revoked host public keys. Keys listed in this file will be refused for host authentication. Note that if this file does not exist or is not readable, then host authentication will be refused for all hosts. Keys may be specified as a text file, listing one public key per line, or as an OpenSSH Key Revocation List (KRL) as generated by

For more information on KRLs, see the KEY REVOCATION LISTS section in

Arguments to

may use the tilde syntax to refer to a user’s home directory, the tokens described in the

section and environment variables as described in the

section.

Specifies a path to a library that will be used when loading any FIDO authenticator-hosted keys, overriding the default of using the built-in USB HID support.

If the specified value begins with a

character, then it will be treated as an environment variable containing the path to the library.

Specifies what variables from the local

should be sent to the server. The server must also support it, and the server must be configured to accept these environment variables. Note that the

environment variable is always sent whenever a pseudo-terminal is requested as it is required by the protocol. Refer to

for how to configure the server. Variables are specified by name, which may contain wildcard characters. Multiple environment variables may be separated by whitespace or spread across multiple

directives.

See

for more information on patterns.

It is possible to clear previously set

variable names by prefixing patterns with

The default is not to send any environment variables.

Sets the number of server alive messages (see below) which may be sent without

receiving any messages back from the server. If this threshold is reached while server alive messages are being sent, ssh will disconnect from the server, terminating the session. It is important to note that the use of server alive messages is very different from

(below). The server alive messages are sent through the encrypted channel and therefore will not be spoofable. The TCP keepalive option enabled by

is spoofable. The server alive mechanism is valuable when the client or server depend on knowing when a connection has become unresponsive.

The default value is 3. If, for example,

(see below) is set to 15 and

is left at the default, if the server becomes unresponsive, ssh will disconnect after approximately 45 seconds.

Sets a timeout interval in seconds after which if no data has been received from the server,

will send a message through the encrypted channel to request a response from the server. The default is 0, indicating that these messages will not be sent to the server, or 300 if the

option is set (Debian-specific).

and

are Debian-specific compatibility aliases for this option.

May be used to either request invocation of a subsystem on the remote system, or to prevent the execution of a remote command at all. The latter is useful for just forwarding ports. The argument to this keyword must be

(same as the

option),

(same as the

option) or

(shell or command execution).

Directly specify one or more environment variables and their contents to be sent to the server. Similarly to

with the exception of the

variable, the server must be prepared to accept the environment variable.

Redirects stdin from

(actually, prevents reading from stdin). Either this or the equivalent

option must be used when

is run in the background. The argument to this keyword must be

(same as the

option) or

(the default).

Sets the octal file creation mode mask

used when creating a Unix-domain socket file for local or remote port forwarding. This option is only used for port forwarding to a Unix-domain socket file.

Specifies whether to remove an existing Unix-domain socket file for local or remote port forwarding before creating a new one. If the socket file already exists and

is not enabled,

will be unable to forward the port to the Unix-domain socket file. This option is only used for port forwarding to a Unix-domain socket file.

The argument must be

(the default).

If this flag is set to

will never automatically add host keys to the

file, and refuses to connect to hosts whose host key has changed. This provides maximum protection against man-in-the-middle (MITM) attacks, though it can be annoying when the

file is poorly maintained or when connections to new hosts are frequently made. This option forces the user to manually add all new hosts.

If this flag is set to

then ssh will automatically add new host keys to the user’s

file, but will not permit connections to hosts with changed host keys. If this flag is set to

ssh will automatically add new host keys to the user known hosts files and allow connections to hosts with changed hostkeys to proceed, subject to some restrictions. If this flag is set to

(the default), new host keys will be added to the user known host files only after the user has confirmed that is what they really want to do, and ssh will refuse to connect to hosts whose host key has changed. The host keys of known hosts will be verified automatically in all cases.

Gives the facility code that is used when logging messages from

The possible values are: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. The default is USER.

Specifies whether the system should send TCP keepalive messages to the other side. If they are sent, death of the connection or crash of one of the machines will be properly noticed. This option only uses TCP keepalives (as opposed to using ssh level keepalives), so takes a long time to notice when the connection dies. As such, you probably want the

option as well. However, this means that connections will die if the route is down temporarily, and some people find it annoying.

The default is

(to send TCP keepalive messages), and the client will notice if the network goes down or the remote host dies. This is important in scripts, and many users want it too.

To disable TCP keepalive messages, the value should be set to

269 - Linux cli command console-setup

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command console-setup and provides detailed information about the command console-setup, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the console-setup.

NAME 🖥️ console-setup 🖥️

setup - configuration file for setupcon

DESCRIPTION

The file console-setup specifies the encoding and the font to be used by setupcon(1) in order to setup the console. It can be used also to specify the keyboard layout but it is not recommended to do so, use keyboard(5) instead.

The font specification consists of three parameters - codeset, font face and font size. The codeset specifies what characters will be supported by the font. There isn’t one-to-one correspondence between codeset and encoding, for example the codeset Lat15 is suitable for ISO 8859-1, ISO 8859-9 and ISO 8859-15. The codesets are two kinds - small and big. Only small codesets are supported on FreeBSD.

The font face determines the general look of the font. Each font face is available in certain possible sizes. On FreeBSD only 8x16, 8x14 and 8x8 are valid sizes. On Linux if framebuffer is not used or consolechars(1) is installed instead of setfont(1), then the permitted sizes have the form 8xNUMBER.

The console driver of FreeBSD permits fonts in different sizes to be simultaneously loaded. Which one of them will be actually used depends on the current video mode. Therefore, on this platform the font size specification will be ignored and setupcon(1) will load the selected font face in all available sizes.

The file console-setup consists of variable settings in

format:

VARIABLE=’VALUE'

Only one assignment is allowed per line. Comments (starting with ‘#’) are also allowed.

OPTIONS

The following variables can be set.

ACTIVE_CONSOLES
Specifies the device files in /dev of the virtual terminals to be configured. File name wild-cards (*, ?) are allowed. On Linux usually you can set this to /dev/tty[1-6] and on FreeBSD a sensible value is /dev/ttyv[0-8]. You can assign to this variable also the special value guess. It will cause setupcon(1) to attempt to guess the active virtual consoles by looking in configuration files such as /etc/inittab and /etc/ttys. This guessing is not always reliable.

CHARMAP
Specifies the desired encoding on the console. Valid values are:

UTF-8, ARMSCII-8, CP1251, CP1255, CP1256, GEORGIAN-ACADEMY, GEORGIAN-PS, IBM1133, ISIRI-3342, ISO-8859-1, ISO-8859-2, ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-11, ISO-8859-13, ISO-8859-14, ISO-8859-15, ISO-8859-16, KOI8-R, KOI8-U, TIS-620 and VISCII.

The special value guess is also recognized in which case the system command locale(1) will be used to guess the desired encoding (currently this works reliably only with

libc).

CODESET
In most cases the special value guess can be used here in which case a suitable codeset will be guessed. The codeset determines which symbols are supported by the font. Valid small codesets are:

Armenian, CyrAsia, CyrKoi, CyrSlav, Georgian, Greek, Hebrew, Lao, Lat15, Lat2, Lat38, Lat7 and Thai.

Valid big codesets are:

Arabic, Ethiopian, Uni1, Uni2, Uni3 and Vietnamese.

Only small codesets can be used on FreeBSD. See below the section entitled “CODESETS” for detailed description of each of these codesets.

FONTFACE and FONTSIZE
Valid font faces are:

VGA (sizes 8x8, 8x14, 8x16, 16x28 and 16x32), Terminus (sizes 6x12, 8x14, 8x16, 10x20, 12x24, 14x28 and 16x32), TerminusBold (sizes 8x14, 8x16, 10x20, 12x24, 14x28 and 16x32), TerminusBoldVGA (sizes 8x14 and 8x16), and Fixed (sizes 8x13, 8x14, 8x15, 8x16 and 8x18). If however CODESET=Ethiopian, then the available font faces are Goha and GohaClassic, each in sizes 8x12, 8x14 and 8x16.

Set FONTFACE and FONTSIZE to empty strings if you want to configure only the keyboard and to leave the console font unchanged.

VIDEOMODE
Set VIDEOMODE to an empty string to avoid setting up the video mode. On FreeBSD you can run

vidcontrol -i mode

in order to see all possible video modes. On Linux fbset(1) is used to configure the video mode but very often this doesn’t work because the default framebuffer driver (VesaFB) is rather limited and doesn’t allow changes of the video mode.

FONT, FONT_MAP and CONSOLE_MAP
If set, specify that a non standard font is to be used. The value of the variable FONT consists of one or more space separated font file names. On Linux, when the font doesn’t contain embedded Unicode map, an external map can be specified with the variable FONT_MAP. The value of CONSOLE_MAP is a file that specifies a translation map from the user’s 8-bit encoding to Unicode (Linux only) or directly to font positions.

SCREEN_WIDTH and SCREEN_HEIGHT
If set, these variables specify a screen size that setupcon(1) will enforce with stty(1). This can be useful with some braille devices that are only 40 cells wide. The screen size can not exceed what the current screen resolution can display according to the size of the loaded font.

BEEP
This variable controls the style of the system beep on the console. When unset or when BEEP=default no changes to the system beep will be made. Other possible values of BEEP are: standard - set a standard beep; short - like the standard beep but somewhat shorter; shortest - even more short, suitable when your work generates lots of beeps; polite - a very short beep with low frequency, suitable when there are other people in the room; attention - a very long beep, suitable when you want to warn yourself about an occurring event; annoying - also a long beep, suitable when you want to warn somebody else about an occurring event; and off - disable the system beep on the console.

CODESETS

There are two kinds of codesets - small (up to 256 symbols) and big (up to 512 symbols). Only small codesets can be used on FreeBSD. When the screen is in text mode (i.e. framebuffer is not used) then fonts covering big codesets will reduce the number of available foreground colors.

Arabic (a big codeset)

Supported languages: Arabic, Kurdish in Iran, Pashto, Persian and Urdu.

Completely covered by the following font faces: Fixed (size 8x16) and VGA (sizes 8x16 and 16x32).

Armenian

Supported language: Armenian.

Completely covered by the following font faces: Fixed (all sizes).

CyrAsia

This codeset supports some of the non-Slavic Cyrillic languages - Abkhazia, Avaric, Azerbaijani, Bashkir, Buryat, Chechen, Chuvash, Inupiaq (Eskimo), Kara-Kalpak, Kazakh, Kirgiz, Komi, Kumyk, Kurdish, Lezghian, Mari (Cheremis), Mongolian, Ossetic, Selkup (Ostyak-Samoyed), Tajik, Tatar, Turkmen, Tuvinian, Uzbek and Yakut.

Completely supported by the following font faces: Fixed (all sizes).

CyrKoi

Supports entirely the 8-bit encodings KOI8-R and KOI8-U. Suitable for Russian and Ukrainian when one of these two encodings is used.

Completely covered by the following font faces (in all sizes): Fixed, Terminus, TerminusBold, TerminusBoldVGA and VGA.

CyrSlav

Supports entirely the 8-bit encodings ISO-8859-5 and CP1251. Suitable the Slavic Cyrillic languages - Belarusian, Bulgarian, Macedonian, Russian, Serbian and Ukrainian. For Serbian both the Cyrillic and the Latin alphabets are supported.

Completely covered by the following font faces: Fixed (all sizes), Terminus (all sizes), TerminusBold (all sizes), TerminusBoldVGA (all sizes), VGA (sizes 8x16 and 16x32).

Ethiopian (a big codeset)

Supports Amharic, Ethiopic (Geez), Tigre and Tigrinya.

This codeset is partially covered by the following font faces: Fixed (sizes 8x15 and 8x18), Goha (all sizes) and GohaClassic (all sizes).

Georgian

Supported language: Georgian.

Completely covered by the following font faces: Fixed (all sizes).

Greek

Supported language: Greek.

Completely covered by the following font faces: Fixed (all sizes) and VGA (sizes 8x16 and 16x32).

Hebrew

Supported languages: Hebrew and Yiddish.

Completely covered by the following font faces: Fixed (sizes 8x13, 8x15, 8x16 and 8x18) and VGA (sizes 8x16 and 16x32).

Lao

Supported languages: Lao.

Completely covered by the following font faces: Fixed (sizes 8x15 and 8x16).

Lat15

Covers entirely ISO-8859-1, ISO-8859-9 and ISO-8859-15. Suitable for the so called Latin1 and Latin5 languages - Afar, Afrikaans, Albanian, Aragonese, Asturian, Aymara, Basque, Bislama, Breton, Catalan, Chamorro, Danish, Dutch, English, Estonian, Faroese, Fijian, Finnish, French, Frisian, Friulian, Galician, German, Hiri Motu, Icelandic, Ido, Indonesian, Interlingua, Interlingue, Italian, Low Saxon, Lule Sami, Luxembourgish, Malagasy, Manx Gaelic, Norwegian Bokmal, Norwegian Nynorsk, Occitan, Oromo or Galla, Portuguese, Rhaeto-Romance (Romansch), Scots Gaelic, Somali, South Sami, Spanish, Swahili, Swedish, Tswana, Turkish, Volapuk, Votic, Walloon, Xhosa, Yapese and Zulu.

Completely covered by the following font faces: Fixed (all sizes), Terminus (all sizes), TerminusBold (all sizes), TerminusBoldVGA (all sizes), VGA (sizes 8x16 and 16x32).

Lat2

Covers entirely ISO-8859-2. The Euro sign and the Romanian letters with comma below are also supported. Suitable for the so called Latin2 languages - Bosnian, Croatian, Czech, Hungarian, Polish, Romanian, Slovak, Slovenian and Sorbian (lower and upper).

Completely covered by the following font faces: Fixed (all sizes), Terminus (all sizes), TerminusBold (all sizes), TerminusBoldVGA (all sizes), VGA (sizes 8x16 and 16x32).

Lat38

Covers entirely ISO-8859-3 and ISO-8859-14. Suitable for Chichewa Esperanto, Irish, Maltese and Welsh.

Completely covered by the following font faces: Fixed (all sizes) and VGA (sizes 8x16 and 16x32).

Lat7

Covers entirely ISO-8859-13. Suitable for Lithuanian, Latvian, Maori and Marshallese.

Completely covered by the following font faces: Fixed (all sizes), Terminus (all sizes), TerminusBold (all sizes), TerminusBoldVGA (all sizes), VGA (sizes 8x16 and 16x32).

Thai

Supported language: Thai.

Completely covered by the following font faces: Fixed (all sizes).

Uni1 (a big codeset)

Supports most of the Latin languages, the Slavic Cyrillic languages, Hebrew and barely Arabic.

Completely covered by the following font faces: Fixed (sizes 8x15 and 8x16) and VGA (all sizes).

Uni2 (a big codeset)

Supports most of the Latin languages, the Slavic Cyrillic languages and Greek.

Completely covered by the following font faces: Fixed (all sizes) and VGA (sizes 8x16 and 16x32).

Uni3 (a big codeset)

Supports most of the Latin and Cyrillic languages.

Completely covered by the following font faces: Fixed (all sizes).

Vietnamese (a big codeset)

Supported language: Vietnamese.

Completely covered by the following font faces: Fixed (sizes 8x13, 8x15, 8x16 and 8x18).

FILES

The standard location of the console-setup configuration file is /etc/default/console-setup. The keyboard configuration is in /etc/default/keyboard. Fonts that can be used with the variable FONT are usually installed in /usr/share/consolefonts/ or /usr/share/syscons/fonts/. Translation maps that can be used with the variable CONSOLE_MAP are usually installed in /usr/share/consoletrans/ or /usr/share/syscons/scrnmaps/.

NOTES

The aim of the Terminus font is to reduce the eyes-fatigue when one has to read a lot. Currently this font supports only the Latin, the Cyrillic and the Greek scripts (the Lat15, Lat2, Lat7, CyrAsia, CyrKoi, CyrSlav, Greek, Uni2 and Uni3 codesets).

The fonts with font face TerminusBoldVGA are optimized for use with regular text video modes. They should not be used with framebuffer video modes. The fonts with font face TerminusBold are optimized for use with the framebuffer video modes. The fonts with font face Terminus can be used in all video modes.

270 - Linux cli command networks

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command networks and provides detailed information about the command networks, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the networks.

NAME 🖥️ networks 🖥️

network name information

DESCRIPTION

The file /etc/networks is a plain ASCII file that describes known DARPA networks and symbolic names for these networks. Each line represents a network and has the following structure:

name number aliases . . .

where the fields are delimited by spaces or tabs. Empty lines are ignored. The hash character (#) indicates the start of a comment: this character, and the remaining characters up to the end of the current line, are ignored by library functions that process the file.

The field descriptions are:

name
The symbolic name for the network. Network names can contain any printable characters except white-space characters or the comment character.

number
The official number for this network in numbers-and-dots notation (see inet(3)). The trailing “.0” (for the host component of the network address) may be omitted.

aliases
Optional aliases for the network.

This file is read by the route(8) and netstat(8) utilities. Only Class A, B, or C networks are supported, partitioned networks (i.e., network/26 or network/28) are not supported by this file.

FILES

/etc/networks
The networks definition file.

271 - Linux cli command org.bluez.BatteryProvider

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.BatteryProvider and provides detailed information about the command org.bluez.BatteryProvider, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.BatteryProvider.

NAME 🖥️ org.bluez.BatteryProvider 🖥️

BlueZ D-Bus BatteryProvider API documentation

INTERFACE

Service
<client D-Bus address>
Interface
org.bluez.BatteryProvider1
Object path
{provider_root}/{unique battery object path}

Properties

Objects provided on this interface contain the same properties as org.bluez.Battery(5) interface. Additionally, this interface needs to have the Device property indicating the object path of the device this battery provides.

object Device [readonly]

The object path of the device that has this battery.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

272 - Linux cli command proc_execdomains

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_execdomains and provides detailed information about the command proc_execdomains, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_execdomains.

NAME 🖥️ proc_execdomains 🖥️

ABI personalities (obsolete)

DESCRIPTION

/proc/execdomains
Used to list ABI personalities before Linux 4.1; now contains a constant string for userspace compatibility.

273 - Linux cli command deb-origin

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command deb-origin and provides detailed information about the command deb-origin, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the deb-origin.

NAME 🖥️ deb-origin 🖥️

origin - Vendor-specific information files

SYNOPSIS

**/etc/dpkg/origins/**filename

DESCRIPTION

The files in /etc/dpkg/origins can provide information about various vendors who are providing Debian packages.

They contain a number of fields, or comments when the line starts with ‘#’. Each field begins with a tag, such as Vendor or Parent, followed by a colon and the body of the field. Fields are delimited only by field tags. In other words, field text may be multiple lines in length, but the tools will join lines when processing the body of the field.

The file should be named according to the vendor name. The usual convention is to name the vendor file using the vendor name in all lowercase, but some variation is permitted.

Namely (since dpkg 1.21.10), first, non-alphanumeric characters (‘[^A-Za-z0-9]’) are mapped to dashes (‘-’), then the resulting name will be tried in sequence by lower-casing it, keeping it as is, lower-casing then capitalizing it (that is upper-casing the first character), and only capitalizing it.

In addition, for historical and backwards compatibility, the name will be tried keeping it as is without non-alphanumeric characters remapping, then the resulting name will be tried in sequence by lower-casing it, keeping it as is, lower-casing then capitalizing it, and only capitalizing it. And finally the name will be tried by remapping spaces to dashes (‘-’), then the resulting name will be tried in sequence by lower-casing it, keeping it as is, lower-casing then capitalizing it, and only capitalizing it.

But these backwards compatible module lookups will be removed during the dpkg 1.22.x release cycle.

FIELDS

Vendor: vendor-name (required)
The value of this field determines the vendor name.

Vendor-URL: vendor-url
The value of this field determines the vendor URL.

Bugs: bug-url
The value of this field determines the type and address of the bug tracking system used by this vendor. It can be a mailto URL or a debbugs URL (e.g., debbugs://bugs.debian.org/).

Parent: vendor-name
The value of this field determines the vendor name of the vendor that this vendor derives from.

EXAMPLE

Vendor: Debian Vendor-URL: https://www.debian.org/ Bugs: debbugs://bugs.debian.org

274 - Linux cli command user_clusters

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command user_clusters and provides detailed information about the command user_clusters, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the user_clusters.

NAME 🖥️ user_clusters 🖥️

File linking users to PostgreSQL clusters

DESCRIPTION

The file /etc/postgresql-common/user_clusters maps users against the database clusters to which they will connect by default. However, every user can override these settings in ~/.postgresqlrc.

When scanning this file, the first matching line will be used. It is a good idea to provide a default explicitly, with a final line where both user and group are set to *.

If there is no default, the implicit default is to connect to the cluster listening on port 5432 and to the database matching the user’s login name.

FORMAT

Comments are introduced by the character #. Comments may follow data on a line; the first comment character terminates the data. Leading whitespace and blank lines are ignored.

Each uncommented, non-blank line must describe a user, group or the default (where both user and group are set to *).

Fields must be given in the following order, separated by white space:

USER
The login id of the Unix user to whom this line applies. The wildcard character * means any user.

GROUP
The group name of the Unix group to which this line applies. The wildcard character * means any group.

VERSION
The major PostgreSQL version of the cluster to connect to.

CLUSTER
The name of a cluster to connect to. A remote cluster is specified with host:port. If port is empty, it defaults to 5432.

DATABASE
Within the cluster, the database to which the user will connect by default if he does not specify a database on the command line. If this is *, the default database will be the one named by the user’s login id.

NOTES

Since the first matching line is used, the default line must come last.

275 - Linux cli command hosts

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command hosts and provides detailed information about the command hosts, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the hosts.

NAME 🖥️ hosts 🖥️

static table lookup for hostnames

SYNOPSIS

/etc/hosts

DESCRIPTION

This manual page describes the format of the /etc/hosts file. This file is a simple text file that associates IP addresses with hostnames, one line per IP address. For each host a single line should be present with the following information:

IP_address canonical_hostname [aliases…]

The IP address can conform to either IPv4 or IPv6. Fields of the entry are separated by any number of blanks and/or tab characters. Text from a “#” character until the end of the line is a comment, and is ignored. Host names may contain only alphanumeric characters, minus signs ("-"), and periods ("."). They must begin with an alphabetic character and end with an alphanumeric character. Optional aliases provide for name changes, alternate spellings, shorter hostnames, or generic hostnames (for example, localhost). If required, a host may have two separate entries in this file; one for each version of the Internet Protocol (IPv4 and IPv6).

The Berkeley Internet Name Domain (BIND) Server implements the Internet name server for UNIX systems. It augments or replaces the /etc/hosts file or hostname lookup, and frees a host from relying on /etc/hosts being up to date and complete.

In modern systems, even though the host table has been superseded by DNS, it is still widely used for:

bootstrapping
Most systems have a small host table containing the name and address information for important hosts on the local network. This is useful when DNS is not running, for example during system bootup.

NIS
Sites that use NIS use the host table as input to the NIS host database. Even though NIS can be used with DNS, most NIS sites still use the host table with an entry for all local hosts as a backup.

isolated nodes
Very small sites that are isolated from the network use the host table instead of DNS. If the local information rarely changes, and the network is not connected to the Internet, DNS offers little advantage.

FILES

/etc/hosts

NOTES

Modifications to this file normally take effect immediately, except in cases where the file is cached by applications.

Historical notes

RFC 952 gave the original format for the host table, though it has since changed.

Before the advent of DNS, the host table was the only way of resolving hostnames on the fledgling Internet. Indeed, this file could be created from the official host data base maintained at the Network Information Control Center (NIC), though local changes were often required to bring it up to date regarding unofficial aliases and/or unknown hosts. The NIC no longer maintains the hosts.txt files, though looking around at the time of writing (circa 2000), there are historical hosts.txt files on the WWW. I just found three, from 92, 94, and 95.

EXAMPLES

# The following lines are desirable for IPv4 capable hosts
127.0.0.1       localhost
# 127.0.1.1 is often used for the FQDN of the machine
127.0.1.1       thishost.example.org   thishost
192.168.1.10    foo.example.org        foo
192.168.1.13    bar.example.org        bar
146.82.138.7    master.debian.org      master
209.237.226.90  www.opensource.org
# The following lines are desirable for IPv6 capable hosts
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

276 - Linux cli command deb-src-rules

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command deb-src-rules and provides detailed information about the command deb-src-rules, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the deb-src-rules.

NAME 🖥️ deb-src-rules 🖥️

src-rules - Debian source package rules file

SYNOPSIS

debian/rules

DESCRIPTION

This file contains the instructions necessary to build the binary packages from the source package.

The debian/rules file is an executable Makefile, with a shebang that is usually set to “#!/usr/bin/make -f”.

It must support the following make targets:

clean
Clean up the source tree, by undoing any change done by any of the build and binary targets. This target will be called with root privileges.

build-indep
Build architecture independent files required to build any architecture independent binary package. If there are no architecture independent binary packages to generate, the target must still exist but do nothing. This target must not require root privileges.

build-arch
Build architecture dependent files required to build any architecture dependent binary package. If there are no architecture dependent binary packages to generate, the target must still exist but do nothing. This target must not require root privileges.

build
Build architecture independent and dependent files, either by depending (at least transitively) on build-indep and/or build-arch or by inlining what those targets would do. This target must not require root privileges.

binary-indep
Build architecture independent binary packages. This target must depend (at least transitively) on either build-indep or build. This target will be called with root privileges.

binary-arch
Build architecture dependent binary packages. This target must depend (at least transitively) on either build-arch or build. This target will be called with root privileges.

binary
Build architecture independent and dependent binary packages, either by depending (at least transitively) on binary-indep and/or binary-arch or by inlining what those targets would do. This target will be called with root privileges.

277 - Linux cli command hosts.equiv

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command hosts.equiv and provides detailed information about the command hosts.equiv, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the hosts.equiv.

NAME 🖥️ hosts.equiv 🖥️

list of hosts and users that are granted “trusted” r command access to your system

DESCRIPTION

The file /etc/hosts.equiv allows or denies hosts and users to use the r-commands (e.g., rlogin, rsh, or rcp) without supplying a password.

The file uses the following format:

The hostname is the name of a host which is logically equivalent to the local host. Users logged into that host are allowed to access like-named user accounts on the local host without supplying a password. The hostname may be (optionally) preceded by a plus (+) sign. If the plus sign is used alone, it allows any host to access your system. You can explicitly deny access to a host by preceding the hostname by a minus (-) sign. Users from that host must always supply additional credentials, including possibly a password. For security reasons you should always use the FQDN of the hostname and not the short hostname.

The username entry grants a specific user access to all user accounts (except root) without supplying a password. That means the user is NOT restricted to like-named accounts. The username may be (optionally) preceded by a plus (+) sign. You can also explicitly deny access to a specific user by preceding the username with a minus (-) sign. This says that the user is not trusted no matter what other entries for that host exist.

Netgroups can be specified by preceding the netgroup by an @ sign.

Be extremely careful when using the plus (+) sign. A simple typographical error could result in a standalone plus sign. A standalone plus sign is a wildcard character that means “any host”!

FILES

/etc/hosts.equiv

NOTES

Some systems will honor the contents of this file only when it has owner root and no write permission for anybody else. Some exceptionally paranoid systems even require that there be no other hard links to the file.

Modern systems use the Pluggable Authentication Modules library (PAM). With PAM a standalone plus sign is considered a wildcard character which means “any host” only when the word promiscuous is added to the auth component line in your PAM file for the particular service (e.g., rlogin).

EXAMPLES

Below are some example /etc/host.equiv or ~/.rhosts files.

Allow any user to log in from any host:

Allow any user from host with a matching local account to log in:

host

Note: the use of +host is never a valid syntax, including attempting to specify that any user from the host is allowed.

Allow any user from host to log in:

host +

Note: this is distinct from the previous example since it does not require a matching local account.

Allow user from host to log in as any non-root user:

host user

Allow all users with matching local accounts from host to log in except for baduser:

host -baduser
host

Deny all users from host:

-host

Note: the use of -host -user is never a valid syntax, including attempting to specify that a particular user from the host is not trusted.

Allow all users with matching local accounts on all hosts in a netgroup:

+@netgroup

Disallow all users on all hosts in a netgroup:

-@netgroup

Allow all users in a netgroup to log in from host as any non-root user:

host +@netgroup

Allow all users with matching local accounts on all hosts in a netgroup except baduser:

+@netgroup -baduser
+@netgroup

Note: the deny statements must always precede the allow statements because the file is processed sequentially until the first matching rule is found.

278 - Linux cli command deb-override

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command deb-override and provides detailed information about the command deb-override, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the deb-override.

NAME 🖥️ deb-override 🖥️

override - Debian archive override file

SYNOPSIS

override

DESCRIPTION

While most information about a package can be found in the control file, some is managed centrally by the distribution czars rather than by the maintainer in order to offer some global consistency. This information is found in the override file.

The override file has a simple whitespace-delimited format. Comments are allowed (denoted with a #).

package priority section [maintainer-info]

package is the name of the package. Entries in the override file for packages not found in the tree of binary packages are ignored.

priority and section correspond to the respective control fields available in the .deb. The allowed values are specific to each distribution archive.

maintainer-info, if present, can be either the name of a maintainer for an unconditional override, or else old-maintainer => new-maintainer to perform a substitution.

The override files used to make the official Packages lists may be found in the indices directory on any Debian mirror.

279 - Linux cli command resolv.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command resolv.conf and provides detailed information about the command resolv.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the resolv.conf.

NAME 🖥️ resolv.conf 🖥️

resolver configuration file

SYNOPSIS

/etc/resolv.conf

DESCRIPTION

The resolver is a set of routines in the C library that provide access to the Internet Domain Name System (DNS). The resolver configuration file contains information that is read by the resolver routines the first time they are invoked by a process. The file is designed to be human readable and contains a list of keywords with values that provide various types of resolver information. The configuration file is considered a trusted source of DNS information; see the trust-ad option below for details.

If this file does not exist, only the name server on the local machine will be queried, and the search list contains the local domain name determined from the hostname.

The different configuration options are:

nameserver Name server IP address
Internet address of a name server that the resolver should query, either an IPv4 address (in dot notation), or an IPv6 address in colon (and possibly dot) notation as per RFC 2373. Up to MAXNS (currently 3, see <resolv.h>) name servers may be listed, one per keyword. If there are multiple servers, the resolver library queries them in the order listed. If no nameserver entries are present, the default is to use the name server on the local machine. (The algorithm used is to try a name server, and if the query times out, try the next, until out of name servers, then repeat trying all the name servers until a maximum number of retries are made.)

search Search list for host-name lookup.
By default, the search list contains one entry, the local domain name. It is determined from the local hostname returned by gethostname(2); the local domain name is taken to be everything after the first ‘.’. Finally, if the hostname does not contain a ‘.’, the root domain is assumed as the local domain name.

This may be changed by listing the desired domain search path following the search keyword with spaces or tabs separating the names. Resolver queries having fewer than ndots dots (default is 1) in them will be attempted using each component of the search path in turn until a match is found. For environments with multiple subdomains please read **options ndots:**n below to avoid man-in-the-middle attacks and unnecessary traffic for the root-dns-servers. Note that this process may be slow and will generate a lot of network traffic if the servers for the listed domains are not local, and that queries will time out if no server is available for one of the domains.

If there are multiple search directives, only the search list from the last instance is used.

In glibc 2.25 and earlier, the search list is limited to six domains with a total of 256 characters. Since glibc 2.26, the search list is unlimited.

The domain directive is an obsolete name for the search directive that handles one search list entry only.

sortlist
This option allows addresses returned by gethostbyname(3) to be sorted. A sortlist is specified by IP-address-netmask pairs. The netmask is optional and defaults to the natural netmask of the net. The IP address and optional network pairs are separated by slashes. Up to 10 pairs may be specified. Here is an example:

sortlist 130.155.160.0/255.255.240.0 130.155.0.0

options
Options allows certain internal resolver variables to be modified. The syntax is

options option …

where option is one of the following:

debug
Sets RES_DEBUG in _res.options (effective only if glibc was built with debug support; see resolver(3)).

**ndots:**n
Sets a threshold for the number of dots which must appear in a name given to res_query(3) (see resolver(3)) before an initial absolute query will be made. The default for n is 1, meaning that if there are any dots in a name, the name will be tried first as an absolute name before any search list elements are appended to it. The value for this option is silently capped to 15.

**timeout:**n
Sets the amount of time the resolver will wait for a response from a remote name server before retrying the query via a different name server. This may not be the total time taken by any resolver API call and there is no guarantee that a single resolver API call maps to a single timeout. Measured in seconds, the default is RES_TIMEOUT (currently 5, see <resolv.h>). The value for this option is silently capped to 30.

**attempts:**n
Sets the number of times the resolver will send a query to its name servers before giving up and returning an error to the calling application. The default is RES_DFLRETRY (currently 2, see <resolv.h>). The value for this option is silently capped to 5.

rotate
Sets RES_ROTATE in _res.options, which causes round-robin selection of name servers from among those listed. This has the effect of spreading the query load among all listed servers, rather than having all clients try the first listed server first every time.

no-aaaa (since glibc 2.36)
Sets RES_NOAAAA in _res.options, which suppresses AAAA queries made by the stub resolver, including AAAA lookups triggered by NSS-based interfaces such as getaddrinfo(3). Only DNS lookups are affected: IPv6 data in hosts(5) is still used, getaddrinfo(3) with AI_PASSIVE will still produce IPv6 addresses, and configured IPv6 name servers are still used. To produce correct Name Error (NXDOMAIN) results, AAAA queries are translated to A queries. This option is intended preliminary for diagnostic purposes, to rule out that AAAA DNS queries have adverse impact. It is incompatible with EDNS0 usage and DNSSEC validation by applications.

no-check-names
Sets RES_NOCHECKNAME in _res.options, which disables the modern BIND checking of incoming hostnames and mail names for invalid characters such as underscore (_), non-ASCII, or control characters.

inet6
Sets RES_USE_INET6 in _res.options. This has the effect of trying an AAAA query before an A query inside the gethostbyname(3) function, and of mapping IPv4 responses in IPv6 “tunneled form” if no AAAA records are found but an A record set exists. Since glibc 2.25, this option is deprecated; applications should use getaddrinfo(3), rather than gethostbyname(3).

Some programs behave strangely when this option is turned on.

ip6-bytestring (since glibc 2.3.4 to glibc 2.24)
Sets RES_USEBSTRING in _res.options. This causes reverse IPv6 lookups to be made using the bit-label format described in RFC 2673; if this option is not set (which is the default), then nibble format is used. This option was removed in glibc 2.25, since it relied on a backward-incompatible DNS extension that was never deployed on the Internet.

ip6-dotint/no-ip6-dotint (glibc 2.3.4 to glibc 2.24)
Clear/set RES_NOIP6DOTINT in _res.options. When this option is clear (ip6-dotint), reverse IPv6 lookups are made in the (deprecated) ip6.int zone; when this option is set (no-ip6-dotint), reverse IPv6 lookups are made in the ip6.arpa zone by default. These options are available up to glibc 2.24, where no-ip6-dotint is the default. Since ip6-dotint support long ago ceased to be available on the Internet, these options were removed in glibc 2.25.

edns0 (since glibc 2.6)
Sets RES_USE_EDNS0 in _res.options. This enables support for the DNS extensions described in RFC 2671.

single-request (since glibc 2.10)
Sets RES_SNGLKUP in _res.options. By default, glibc performs IPv4 and IPv6 lookups in parallel since glibc 2.9. Some appliance DNS servers cannot handle these queries properly and make the requests time out. This option disables the behavior and makes glibc perform the IPv6 and IPv4 requests sequentially (at the cost of some slowdown of the resolving process).

single-request-reopen (since glibc 2.9)
Sets RES_SNGLKUPREOP in _res.options. The resolver uses the same socket for the A and AAAA requests. Some hardware mistakenly sends back only one reply. When that happens the client system will sit and wait for the second reply. Turning this option on changes this behavior so that if two requests from the same port are not handled correctly it will close the socket and open a new one before sending the second request.

no-tld-query (since glibc 2.14)
Sets RES_NOTLDQUERY in _res.options. This option causes res_nsearch() to not attempt to resolve an unqualified name as if it were a top level domain (TLD). This option can cause problems if the site has ``localhost’’ as a TLD rather than having localhost on one or more elements of the search list. This option has no effect if neither RES_DEFNAMES or RES_DNSRCH is set.

use-vc (since glibc 2.14)
Sets RES_USEVC in _res.options. This option forces the use of TCP for DNS resolutions.

no-reload (since glibc 2.26)
Sets RES_NORELOAD in _res.options. This option disables automatic reloading of a changed configuration file.

trust-ad (since glibc 2.31)
Sets RES_TRUSTAD in _res.options. This option controls the AD bit behavior of the stub resolver. If a validating resolver sets the AD bit in a response, it indicates that the data in the response was verified according to the DNSSEC protocol. In order to rely on the AD bit, the local system has to trust both the DNSSEC-validating resolver and the network path to it, which is why an explicit opt-in is required. If the trust-ad option is active, the stub resolver sets the AD bit in outgoing DNS queries (to enable AD bit support), and preserves the AD bit in responses. Without this option, the AD bit is not set in queries, and it is always removed from responses before they are returned to the application. This means that applications can trust the AD bit in responses if the trust-ad option has been set correctly.

In glibc 2.30 and earlier, the AD is not set automatically in queries, and is passed through unchanged to applications in responses.

The search keyword of a system’s resolv.conf file can be overridden on a per-process basis by setting the environment variable LOCALDOMAIN to a space-separated list of search domains.

The options keyword of a system’s resolv.conf file can be amended on a per-process basis by setting the environment variable RES_OPTIONS to a space-separated list of resolver options as explained above under options.

The keyword and value must appear on a single line, and the keyword (e.g., nameserver) must start the line. The value follows the keyword, separated by white space.

Lines that contain a semicolon (;) or hash character (#) in the first column are treated as comments.

FILES

/etc/resolv.conf, <resolv.h>

280 - Linux cli command logind.conf.d

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command logind.conf.d and provides detailed information about the command logind.conf.d, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the logind.conf.d.

NAME 🖥️ logind.conf.d 🖥️

SYNOPSIS

/etc/systemd/logind.conf

/run/systemd/logind.conf

/usr/local/lib/systemd/logind.conf

/usr/lib/systemd/logind.conf

/etc/systemd/logind.conf.d/*.conf

/run/systemd/logind.conf.d/*.conf

/usr/local/lib/systemd/logind.conf.d/*.conf

/usr/lib/systemd/logind.conf.d/*.conf

DESCRIPTION

These files configure various parameters of the systemd login manager, systemd-logind.service(8). See systemd.syntax(7) for a general description of the syntax.

CONFIGURATION DIRECTORIES AND PRECEDENCE

OPTIONS

All options are configured in the [Login] section:

NAutoVTs=

Takes a positive integer. Configures how many virtual terminals (VTs) to allocate by default that, when switched to and are previously unused, “autovt” services are automatically spawned on. These services are instantiated from the template unit [email protected] for the respective VT TTY name, for example, [email protected]. By default, [email protected] is linked to [email protected]. In other words, login prompts are started dynamically as the user switches to unused virtual terminals. Hence, this parameter controls how many login “gettys” are available on the VTs. If a VT is already used by some other subsystem (for example, a graphical login), this kind of activation will not be attempted. Note that the VT configured in ReserveVT= is always subject to this kind of activation, even if it is not one of the VTs configured with the NAutoVTs= directive. Defaults to 6. When set to 0, automatic spawning of “autovt” services is disabled.

ReserveVT=

Takes a positive integer. Identifies one virtual terminal that shall unconditionally be reserved for [email protected] activation (see above). The VT selected with this option will be marked busy unconditionally, so that no other subsystem will allocate it. This functionality is useful to ensure that, regardless of how many VTs are allocated by other subsystems, one login “getty” is always available. Defaults to 6 (in other words, there will always be a “getty” available on Alt-F6.). When set to 0, VT reservation is disabled.
Added in version 190.

KillUserProcesses=

Takes a boolean argument. Configures whether the processes of a user should be killed when the user logs out. If true, the scope unit corresponding to the session and all processes inside that scope will be terminated. If false, the scope is “abandoned”, see systemd.scope(5), and processes are not killed. Defaults to “no”, but see the options KillOnlyUsers= and KillExcludeUsers= below.
In addition to session processes, user process may run under the user manager unit [email protected]. Depending on the linger settings, this may allow users to run processes independent of their login sessions. See the description of enable-linger in loginctl(1).
Note that setting KillUserProcesses=yes will break tools like screen(1) and tmux(1), unless they are moved out of the session scope. See example in systemd-run(1).

KillOnlyUsers=, KillExcludeUsers=

These settings take space-separated lists of usernames that override the KillUserProcesses= setting. A user name may be added to KillExcludeUsers= to exclude the processes in the session scopes of that user from being killed even if KillUserProcesses=yes is set. If KillExcludeUsers= is not set, the “root” user is excluded by default. KillExcludeUsers= may be set to an empty value to override this default. If a user is not excluded, KillOnlyUsers= is checked next. If this setting is specified, only the processes in the session scopes of those users will be killed. Otherwise, users are subject to the KillUserProcesses=yes setting.

IdleAction=

Configures the action to take when the system is idle. Takes one of “ignore”, “poweroff”, “reboot”, “halt”, “kexec”, “suspend”, “hibernate”, “hybrid-sleep”, “suspend-then-hibernate”, “sleep”, and “lock”. Defaults to “ignore”.
Note that this requires that user sessions correctly report the idle status to the system. The system will execute the action after all sessions report that they are idle, no idle inhibitor lock is active, and subsequently, the time configured with IdleActionSec= (see below) has expired.
Added in version 198.

IdleActionSec=

Configures the delay after which the action configured in IdleAction= (see above) is taken after the system is idle.
Added in version 198.

InhibitDelayMaxSec=

Specifies the maximum time a system shutdown or sleep request is delayed due to an inhibitor lock of type “delay” being active before the inhibitor is ignored and the operation executes anyway. Defaults to 5.

UserStopDelaySec=

Specifies how long to keep the user record and per-user service [email protected] around for a user after they logged out fully. If set to zero, the per-user service is terminated immediately when the last session of the user has ended. If this option is configured to non-zero rapid logout/login cycles are sped up, as the users service manager is not constantly restarted. If set to “infinity” the per-user service for a user is never terminated again after first login, and continues to run until system shutdown. Defaults to 10s.
Added in version 240.

SleepOperation=

Takes a list of sleep operations. Possible values are “suspend”, “hibernate”, “hybrid-sleep”, and “suspend-then-hibernate”. Controls the candidate sleep operations for the “sleep” action. When “sleep” action is performed, the specified sleep operations are checked in a fixed order (“suspend-then-hibernate” → “hybrid-sleep” → “suspend” → “hibernate”), and the first one supported by the machine is used to put the system into sleep. Defaults to “suspend-then-hibernate suspend hibernate”.
Added in version 256.

HandlePowerKey=, HandlePowerKeyLongPress=, HandleRebootKey=, HandleRebootKeyLongPress=, HandleSuspendKey=, HandleSuspendKeyLongPress=, HandleHibernateKey=, HandleHibernateKeyLongPress=, HandleLidSwitch=, HandleLidSwitchExternalPower=, HandleLidSwitchDocked=

Controls how logind shall handle the system power, reboot and sleep keys and the lid switch to trigger actions such as system power-off, reboot or suspend. Can be one of “ignore”, “poweroff”, “reboot”, “halt”, “kexec”, “suspend”, “hibernate”, “hybrid-sleep”, “suspend-then-hibernate”, “sleep”, “lock”, and “factory-reset”. If “ignore”, systemd-logind will never handle these keys. If “lock”, all running sessions will be screen-locked; otherwise, the specified action will be taken in the respective event. Only input devices with the “power-switch” udev tag will be watched for key/lid switch events.
HandlePowerKey= defaults to “poweroff”, HandleRebootKey= defaults to “reboot”, HandleSuspendKey= defaults to “suspend”, HandleHibernateKey= defaults to “hibernate”, HandlePowerKeyLongPress= defaults to “ignore”, HandleRebootKeyLongPress= defaults to “poweroff”, HandleSuspendKeyLongPress= defaults to “hibernate”, HandleHibernateKeyLongPress= defaults to “ignore”. HandleLidSwitch= defaults to “suspend”. HandleLidSwitchExternalPower= is completely ignored by default (for backwards compatibility) — an explicit value must be set before it will be used to determine behaviour. HandleLidSwitchDocked= defaults to “ignore”. If the system is inserted in a docking station, or if more than one display is connected, the action specified by HandleLidSwitchDocked= occurs; if the system is on external power the action (if any) specified by HandleLidSwitchExternalPower= occurs; otherwise the HandleLidSwitch= action occurs.
A different application may disable loginds handling of system power and sleep keys and the lid switch by taking a low-level inhibitor lock (“handle-power-key”, “handle-suspend-key”, “handle-hibernate-key”, “handle-lid-switch”, “handle-reboot-key”). This is most commonly used by graphical desktop environments to take over suspend and hibernation handling, and to use their own configuration mechanisms. If a low-level inhibitor lock is taken, logind will not take any action when that key or switch is triggered and the Handle*= settings are irrelevant.
Added in version 184.

PowerKeyIgnoreInhibited=, SuspendKeyIgnoreInhibited=, HibernateKeyIgnoreInhibited=, LidSwitchIgnoreInhibited=, RebootKeyIgnoreInhibited=

Controls whether actions that systemd-logind takes when the power, reboot and sleep keys and the lid switch are triggered are subject to high-level inhibitor locks (“shutdown”, “reboot”, “sleep”, “idle”). Low level inhibitor locks (“handle-power-key”, “handle-suspend-key”, “handle-hibernate-key”, “handle-lid-switch”, “handle-reboot-key”), are always honored, irrespective of this setting.
These settings take boolean arguments. If “no”, the inhibitor locks taken by applications are respected. If “yes”, “shutdown”, “reboot” “sleep”, and “idle” inhibitor locks are ignored. PowerKeyIgnoreInhibited=, SuspendKeyIgnoreInhibited=, HibernateKeyIgnoreInhibited= and RebootKeyIgnoreInhibited= default to “no”. LidSwitchIgnoreInhibited= defaults to “yes”. This means that when systemd-logind is handling events by itself (no low level inhibitor locks are taken by another application), the lid switch does not respect suspend blockers by default, but the power and sleep keys do.
Added in version 190.

HoldoffTimeoutSec=

Specifies a period of time after system startup or system resume in which systemd will hold off on reacting to lid events. This is required for the system to properly detect any hotplugged devices so systemd can ignore lid events if external monitors, or docks, are connected. If set to 0, systemd will always react immediately, possibly before the kernel fully probed all hotplugged devices. This is safe, as long as you do not care for systemd to account for devices that have been plugged or unplugged while the system was off. Defaults to 30s.
Added in version 220.

RuntimeDirectorySize=

Sets the size limit on the $XDG_RUNTIME_DIR runtime directory for each user who logs in. Takes a size in bytes, optionally suffixed with the usual K, G, M, and T suffixes, to the base 1024 (IEC). Alternatively, a numerical percentage suffixed by “%” may be specified, which sets the size limit relative to the amount of physical RAM. Defaults to 10%. Note that this size is a safety limit only. As each runtime directory is a tmpfs file system, it will only consume as much memory as is needed.
Added in version 211.

RuntimeDirectoryInodesMax=

Sets the limit on number of inodes for the $XDG_RUNTIME_DIR runtime directory for each user who logs in. Takes a number, optionally suffixed with the usual K, G, M, and T suffixes, to the base 1024 (IEC). Defaults to RuntimeDirectorySize= divided by 4096. Note that this size is a safety limit only. As each runtime directory is a tmpfs file system, it will only consume as much memory as is needed.
Added in version 246.

InhibitorsMax=

Controls the maximum number of concurrent inhibitors to permit. Defaults to 8192 (8K).
Added in version 230.

SessionsMax=

Controls the maximum number of concurrent user sessions to manage. Defaults to 8192 (8K). Depending on how the pam_systemd.so module is included in the PAM stack configuration, further login sessions will either be refused, or permitted but not tracked by systemd-logind.
Added in version 230.

RemoveIPC=

Controls whether System V and POSIX IPC objects belonging to the user shall be removed when the user fully logs out. Takes a boolean argument. If enabled, the user may not consume IPC resources after the last of the users sessions terminated. This covers System V semaphores, shared memory and message queues, as well as POSIX shared memory and message queues. Note that IPC objects of the root user and other system users are excluded from the effect of this setting. Defaults to “yes”.
Added in version 212.

StopIdleSessionSec=

Specifies a timeout in seconds, or a time span value after which systemd-logind checks the idle state of all sessions. Every session that is idle for longer than the timeout will be stopped. Note that this option doesnt apply to “greeter” or “lock-screen” sessions. Defaults to “infinity” (systemd-logind is not checking the idle state of sessions). For details about the syntax of time spans, see systemd.time(7).
Added in version 252.

NOTES

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

281 - Linux cli command dhcp-eval

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command dhcp-eval and provides detailed information about the command dhcp-eval, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the dhcp-eval.

NAME 🖥️ dhcp-eval 🖥️

eval - ISC DHCP conditional evaluation

DESCRIPTION

The Internet Systems Consortium DHCP client and server both provide the ability to perform conditional behavior depending on the contents of packets they receive. The syntax for specifying this conditional behaviour is documented here.

REFERENCE: CONDITIONAL BEHAVIOUR

Conditional behaviour may be specified using the if statement and the else or elsif statements or the switch and case statements. A conditional statement can appear anywhere that a regular statement (e.g., an option statement) can appear, and can enclose one or more such statements.

CONDITIONAL BEHAVIOUR: IF

A typical conditional if statement in a server might be:

if option dhcp-user-class = "accounting" {
  max-lease-time 17600;
  option domain-name "accounting.example.org";
  option domain-name-servers ns1.accounting.example.org,
			     ns2.accounting.example.org;
} elsif option dhcp-user-class = "sales" {
  max-lease-time 17600;
  option domain-name "sales.example.org";
  option domain-name-servers ns1.sales.example.org,
			     ns2.sales.example.org;
} elsif option dhcp-user-class = "engineering" {
  max-lease-time 17600;
  option domain-name "engineering.example.org";
  option domain-name-servers ns1.engineering.example.org,
			     ns2.engineering.example.org;
} else {
  max-lease-time 600;
  option domain-name "misc.example.org";
  option domain-name-servers ns1.misc.example.org,
			     ns2.misc.example.org;
}

On the client side, an example of conditional evaluation might be:

# example.org filters DNS at its firewall, so we have to use their DNS
# servers when we connect to their network.  If we are not at
# example.org, prefer our own DNS server.
if not option domain-name = "example.org" {
  prepend domain-name-servers 127.0.0.1;
}

The if statement and the elsif continuation statement both take boolean expressions as their arguments. That is, they take expressions that, when evaluated, produce a boolean result. If the expression evaluates to true, then the statements enclosed in braces following the if statement are executed, and all subsequent elsif and else clauses are skipped. Otherwise, each subsequent elsif clause’s expression is checked, until an elsif clause is encountered whose test evaluates to true. If such a clause is found, the statements in braces following it are executed, and then any subsequent elsif and else clauses are skipped. If all the if and elsif clauses are checked but none of their expressions evaluate true, then if there is an else clause, the statements enclosed in braces following the else are evaluated. Boolean expressions that evaluate to null are treated as false in conditionals.

CONDITIONAL BEHAVIOUR: SWITCH

The above example can be rewritten using a switch construct as well.

switch (option dhcp-user-class) {
  case "accounting":
    max-lease-time 17600;
    option domain-name "accounting.example.org";
    option domain-name-servers ns1.accounting.example.org,
			       ns2.accounting.example.org;
  case "sales":
    max-lease-time 17600;
    option domain-name "sales.example.org";
    option domain-name-servers ns1.sales.example.org,
			       ns2.sales.example.org;
    break;
  case "engineering":
    max-lease-time 17600;
    option domain-name "engineering.example.org";
    option domain-name-servers ns1.engineering.example.org,
			       ns2.engineering.example.org;
    break;
  default:
    max-lease-time 600;
    option domain-name "misc.example.org";
    option domain-name-servers ns1.misc.example.org,
			       ns2.misc.example.org;
    break;
}

The switch statement and the case statements can both be data expressions or numeric expressions. Within a switch statement they all must be the same type. The server evaluates the expression from the switch statement and then it evaluates the expressions from the case statements until it finds a match.

If it finds a match it starts executing statements from that case until the next break statement. If it doesn’t find a match it starts from the default statement and again proceeds to the next break statement. If there is no match and no default it does nothing.

BOOLEAN EXPRESSIONS

The following is the current list of boolean expressions that are supported by the DHCP distribution.

data-expression-1 = data-expression-2

The = operator compares the values of two data expressions, returning true if they are the same, false if they are not. If either the left-hand side or the right-hand side are null, the result is also null.

data-expression-1 ~= data-expression-2 data-expression-1 ~~ data-expression-2

The ~= and ~~ operators (not available on all systems) perform extended regex(7) matching of the values of two data expressions, returning true if data-expression-1 matches against the regular expression evaluated by data-expression-2, or false if it does not match or encounters some error. If either the left-hand side or the right-hand side are null or empty strings, the result is also false. The ~~ operator differs from the ~= operator in that it is case-insensitive.

boolean-expression-1 and boolean-expression-2

The and operator evaluates to true if the boolean expression on the left-hand side and the boolean expression on the right-hand side both evaluate to true. Otherwise, it evaluates to false. If either the expression on the left-hand side or the expression on the right-hand side are null, the result is null.

boolean-expression-1 or boolean-expression-2

The or operator evaluates to true if either the boolean expression on the left-hand side or the boolean expression on the right-hand side evaluate to true. Otherwise, it evaluates to false. If either the expression on the left-hand side or the expression on the right-hand side are null, the result is null.

not boolean-expression

The not operator evaluates to true if boolean-expression evaluates to false, and returns false if boolean-expression evaluates to true. If boolean-expression evaluates to null, the result is also null.

exists option-name

The exists expression returns true if the specified option exists in the incoming DHCP packet being processed.

known

The known expression returns true if the client whose request is currently being processed is known - that is, if there’s a host declaration for it.

static

The static expression returns true if the lease assigned to the client whose request is currently being processed is derived from a static address assignment.

DATA EXPRESSIONS

Several of the boolean expressions above depend on the results of evaluating data expressions. A list of these expressions is provided here.

substring (data-expr,** offset**,** length**)****

The substring operator evaluates the data expression and returns the substring of the result of that evaluation that starts offset bytes from the beginning, continuing for length bytes. Offset and length are both numeric expressions. If data-expr, offset or length evaluate to null, then the result is also null. If offset is greater than or equal to the length of the evaluated data, then a zero-length data string is returned. If length is greater then the remaining length of the evaluated data after offset, then a data string containing all data from offset to the end of the evaluated data is returned.

suffix (data-expr,** length**)****

The suffix operator evaluates data-expr and returns the last length bytes of the result of that evaluation. Length is a numeric expression. If data-expr or length evaluate to null, then the result is also null. If suffix evaluates to a number greater than the length of the evaluated data, then the evaluated data is returned.

lcase (data-expr)****

The lcase function returns the result of evaluating data-expr converted to lower case. If data-expr evaluates to null, then the result is also null.

ucase (data-expr)****

The ucase function returns the result of evaluating data-expr converted to upper case. If data-expr evaluates to null, then the result is also null.

option option-name

The option operator returns the contents of the specified option in the packet to which the server is responding.

config-option option-name

The config-option operator returns the value for the specified option that the DHCP client or server has been configured to send.

gethostname()

The gethostname() function returns a data string whose contents are a character string, the results of calling gethostname() on the local system with a size limit of 255 bytes (not including NULL terminator). This can be used for example to configure dhclient to send the local hostname without knowing the local hostname at the time dhclient.conf is written.

hardware

The hardware operator returns a data string whose first element is the type of network interface indicated in packet being considered, and whose subsequent elements are client’s link-layer address. If there is no packet, or if the RFC2131 hlen field is invalid, then the result is null. Hardware types include ethernet (1), token-ring (6), and fddi (8). Hardware types are specified by the IETF, and details on how the type numbers are defined can be found in RFC2131 (in the ISC DHCP distribution, this is included in the doc/ subdirectory).

packet (offset,** length**)****

The packet operator returns the specified portion of the packet being considered, or null in contexts where no packet is being considered. Offset and length are applied to the contents packet as in the substring operator.

string

A string, enclosed in quotes, may be specified as a data expression, and returns the text between the quotes, encoded in ASCII. The backslash (’) character is treated specially, as in C programming: ’ ’ means TAB, ’ ’ means carriage return, ' ’ means newline, and ‘’ means bell. Any octal value can be specified with ' nn’, where nnn is any positive octal number less than 0400. Any hexadecimal value can be specified with ‘\xnn’, where nn is any positive hexadecimal number less than or equal to 0xff.

colon-separated hexadecimal list

A list of hexadecimal octet values, separated by colons, may be specified as a data expression.

concat (data-expr1,** …, data-exprN**)****

The expressions are evaluated, and the results of each evaluation are concatenated in the sequence that the subexpressions are listed. If any subexpression evaluates to null, the result of the concatenation is null.

reverse (numeric-expr1,** data-expr2**)****

The two expressions are evaluated, and then the result of evaluating the data expression is reversed in place, using hunks of the size specified in the numeric expression. For example, if the numeric expression evaluates to four, and the data expression evaluates to twelve bytes of data, then the reverse expression will evaluate to twelve bytes of data, consisting of the last four bytes of the input data, followed by the middle four bytes, followed by the first four bytes.

leased-address

In any context where the client whose request is being processed has been assigned an IP address, this data expression returns that IP address. In any context where the client whose request is being processed has not been assigned an ip address, if this data expression is found in executable statements executed on that client’s behalf, a log message indicating “there is no lease associated with this client” is syslogged to the debug level (this is considered dhcpd.conf debugging information).

binary-to-ascii (numeric-expr1,** numeric-expr2**,**** data-expr1,** data-expr2**)****

Converts the result of evaluating data-expr2 into a text string containing one number for each element of the result of evaluating data-expr2. Each number is separated from the other by the result of evaluating data-expr1. The result of evaluating numeric-expr1 specifies the base (2 through 16) into which the numbers should be converted. The result of evaluating numeric-expr2 specifies the width in bits of each number, which may be either 8, 16 or 32.
As an example of the preceding three types of expressions, to produce the name of a PTR record for the IP address being assigned to a client, one could write the following expression:

        concat (binary-to-ascii (10, 8, ".",
                                 reverse (1, leased-address)),
                ".in-addr.arpa.");

encode-int (numeric-expr,** width**)****

Numeric-expr is evaluated and encoded as a data string of the specified width, in network byte order (most significant byte first). If the numeric expression evaluates to the null value, the result is also null.

pick-first-value (data-expr1 [ … exprn ] )

The pick-first-value function takes any number of data expressions as its arguments. Each expression is evaluated, starting with the first in the list, until an expression is found that does not evaluate to a null value. That expression is returned, and none of the subsequent expressions are evaluated. If all expressions evaluate to a null value, the null value is returned.

host-decl-name

The host-decl-name function returns the name of the host declaration that matched the client whose request is currently being processed, if any. If no host declaration matched, the result is the null value.

NUMERIC EXPRESSIONS

Numeric expressions are expressions that evaluate to an integer. In general, the maximum size of such an integer should not be assumed to be representable in fewer than 32 bits, but the precision of such integers may be more than 32 bits.

In addition to the following operators several standard math functions are available. They are:

operation    symbol
add            +
subtract       -
divide         /
multiply       *
modulus        %
bitwise and    &
bitwise or     |
bitwise xor    ^

extract-int (data-expr,** width**)****

The extract-int operator extracts an integer value in network byte order from the result of evaluating the specified data expression. Width is the width in bits of the integer to extract. Currently, the only supported widths are 8, 16 and 32. If the evaluation of the data expression doesn’t provide sufficient bits to extract an integer of the specified size, the null value is returned.

lease-time

The duration of the current lease - that is, the difference between the current time and the time that the lease expires.

number

Any number between zero and the maximum representable size may be specified as a numeric expression.

client-state

The current state of the client instance being processed. This is only useful in DHCP client configuration files. Possible values are:
·
Booting - DHCP client is in the INIT state, and does not yet have an IP address. The next message transmitted will be a DHCPDISCOVER, which will be broadcast.
·
Reboot - DHCP client is in the INIT-REBOOT state. It has an IP address, but is not yet using it. The next message to be transmitted will be a DHCPREQUEST, which will be broadcast. If no response is heard, the client will bind to its address and move to the BOUND state.
·
Select - DHCP client is in the SELECTING state - it has received at least one DHCPOFFER message, but is waiting to see if it may receive other DHCPOFFER messages from other servers. No messages are sent in the SELECTING state.
·
Request - DHCP client is in the REQUESTING state - it has received at least one DHCPOFFER message, and has chosen which one it will request. The next message to be sent will be a DHCPREQUEST message, which will be broadcast.
·
Bound - DHCP client is in the BOUND state - it has an IP address. No messages are transmitted in this state.
·
Renew - DHCP client is in the RENEWING state - it has an IP address, and is trying to contact the server to renew it. The next message to be sent will be a DHCPREQUEST message, which will be unicast directly to the server.
·
Rebind - DHCP client is in the REBINDING state - it has an IP address, and is trying to contact any server to renew it. The next message to be sent will be a DHCPREQUEST, which will be broadcast.

REFERENCE: ACTION EXPRESSIONS

log (priority,** data-expr**)****

Logging statements may be used to send information to the standard logging channels. A logging statement includes an optional priority (fatal, error, info, or debug), and a data expression.
Logging statements take only a single data expression argument, so if you want to output multiple data values, you will need to use the concat operator to concatenate them.

execute (command-path [, data-expr1,** … data-exprN**]);****

The execute statement runs an external command. The first argument is a string literal containing the name or path of the command to run. The other arguments, if present, are either string literals or data- expressions which evaluate to text strings, to be passed as command-line arguments to the command.
execute is synchronous; the program will block until the external command being run has finished. Please note that lengthy program execution (for example, in an “on commit” in dhcpd.conf) may result in bad performance and timeouts. Only external applications with very short execution times are suitable for use.
Passing user-supplied data to an external application might be dangerous. Make sure the external application checks input buffers for validity. Non-printable ASCII characters will be converted into dhcpd.conf language octal escapes (" nn"), make sure your external command handles them as such.
It is possible to use the execute statement in any context, not only on events. If you put it in a regular scope in the configuration file you will execute that command every time a scope is evaluated.

parse-vendor-option;

The parse-vendor-option statement attempts to parse a vendor option (code 43). It is only useful while processing a packet on the server and requires that the administrator has already used the vendor-option-space statement to select a valid vendor space.
This functionality may be used if the server needs to take different actions depending on the values the client placed in the vendor option and the sub-options are not at fixed locations. It is handled as an action to allow an administrator to examine the incoming options and choose the correct vendor space.

REFERENCE: DYNAMIC DNS UPDATES

See the dhcpd.conf and dhclient.conf man pages for more information about DDNS.

AUTHOR

Information about Internet Systems Consortium can be found at https://www.isc.org.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

282 - Linux cli command dir_colors

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command dir_colors and provides detailed information about the command dir_colors, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the dir_colors.

NAME 🖥️ dir_colors 🖥️

configuration file for dircolors(1)

DESCRIPTION

The program ls(1) uses the environment variable LS_COLORS to determine the colors in which the filenames are to be displayed. This environment variable is usually set by a command like

eval `dircolors some_path/dir_colors`

found in a system default shell initialization file, like /etc/profile or /etc/csh.cshrc. (See also dircolors(1).) Usually, the file used here is /etc/DIR_COLORS and can be overridden by a .dir_colors file in one’s home directory.

This configuration file consists of several statements, one per line. Anything right of a hash mark (#) is treated as a comment, if the hash mark is at the beginning of a line or is preceded by at least one whitespace. Blank lines are ignored.

The global section of the file consists of any statement before the first TERM statement. Any statement in the global section of the file is considered valid for all terminal types. Following the global section is one or more terminal-specific sections, preceded by one or more TERM statements which specify the terminal types (as given by the TERM environment variable) the following declarations apply to. It is always possible to override a global declaration by a subsequent terminal-specific one.

The following statements are recognized; case is insignificant:

TERM terminal-type
Starts a terminal-specific section and specifies which terminal it applies to. Multiple TERM statements can be used to create a section which applies for several terminal types.

COLOR yes|all|no|none|tty
(Slackware only; ignored by GNU dircolors(1).) Specifies that colorization should always be enabled (yes or all), never enabled (no or none), or enabled only if the output is a terminal (tty). The default is no.

EIGHTBIT yes|no
(Slackware only; ignored by GNU dircolors(1).) Specifies that eight-bit ISO/IEC 8859 characters should be enabled by default. For compatibility reasons, this can also be specified as 1 for yes or 0 for no. The default is no.

OPTIONS options
(Slackware only; ignored by GNU dircolors(1).) Adds command-line options to the default ls command line. The options can be any valid ls command-line options, and should include the leading minus sign. Note that dircolors does not verify the validity of these options.

NORMAL color-sequence
Specifies the color used for normal (nonfilename) text.

Synonym: NORM.

FILE color-sequence
Specifies the color used for a regular file.

DIR color-sequence
Specifies the color used for directories.

LINK color-sequence
Specifies the color used for a symbolic link.

Synonyms: LNK, SYMLINK.

ORPHAN color-sequence
Specifies the color used for an orphaned symbolic link (one which points to a nonexistent file). If this is unspecified, ls will use the LINK color instead.

MISSING color-sequence
Specifies the color used for a missing file (a nonexistent file which nevertheless has a symbolic link pointing to it). If this is unspecified, ls will use the FILE color instead.

FIFO color-sequence
Specifies the color used for a FIFO (named pipe).

Synonym: PIPE.

SOCK color-sequence
Specifies the color used for a socket.

DOOR color-sequence
(Supported since fileutils 4.1) Specifies the color used for a door (Solaris 2.5 and later).

BLK color-sequence
Specifies the color used for a block device special file.

Synonym: BLOCK.

CHR color-sequence
Specifies the color used for a character device special file.

Synonym: CHAR.

EXEC color-sequence
Specifies the color used for a file with the executable attribute set.

SUID color-sequence
Specifies the color used for a file with the set-user-ID attribute set.

Synonym: SETUID.

SGID color-sequence
Specifies the color used for a file with the set-group-ID attribute set.

Synonym: SETGID.

STICKY color-sequence
Specifies the color used for a directory with the sticky attribute set.

STICKY_OTHER_WRITABLE color-sequence
Specifies the color used for an other-writable directory with the executable attribute set.

Synonym: OWT.

OTHER_WRITABLE color-sequence
Specifies the color used for an other-writable directory without the executable attribute set.

Synonym: OWR.

LEFTCODE color-sequence
Specifies the left code for non-ISO/IEC 6429 terminals (see below).

Synonym: LEFT.

RIGHTCODE color-sequence
Specifies the right code for non-ISO/IEC 6429 terminals (see below).

Synonym: RIGHT.

ENDCODE color-sequence
Specifies the end code for non-ISO/IEC 6429 terminals (see below).

Synonym: END.

*****extension color-sequence
Specifies the color used for any file that ends in extension.

**.**extension color-sequence
Same as *.extension. Specifies the color used for any file that ends in .extension. Note that the period is included in the extension, which makes it impossible to specify an extension not starting with a period, such as ~ for emacs backup files. This form should be considered obsolete.

ISO/IEC 6429 (ANSI) color sequences

Most color-capable ASCII terminals today use ISO/IEC 6429 (ANSI) color sequences, and many common terminals without color capability, including xterm and the widely used and cloned DEC VT100, will recognize ISO/IEC 6429 color codes and harmlessly eliminate them from the output or emulate them. ls uses ISO/IEC 6429 codes by default, assuming colorization is enabled.

ISO/IEC 6429 color sequences are composed of sequences of numbers separated by semicolons. The most common codes are:

0 to restore default color
1 for brighter colors
4 for underlined text
5 for flashing text
30 for black foreground
31 for red foreground
32 for green foreground
33 for yellow (or brown) foreground
34 for blue foreground
35 for purple foreground
36 for cyan foreground
37 for white (or gray) foreground
40 for black background
41 for red background
42 for green background
43 for yellow (or brown) background
44 for blue background
45 for purple background
46 for cyan background
47 for white (or gray) background

Not all commands will work on all systems or display devices.

ls uses the following defaults:

NORMAL	0	Normal (nonfilename) text
FILE	0	Regular file
DIR	32	Directory
LINK	36	Symbolic link
ORPHAN	undefined	Orphaned symbolic link
MISSING	undefined	Missing file
FIFO	31	Named pipe (FIFO)
SOCK	33	Socket
BLK	44;37	Block device
CHR	44;37	Character device
EXEC	35	Executable file

A few terminal programs do not recognize the default properly. If all text gets colorized after you do a directory listing, change the NORMAL and FILE codes to the numerical codes for your normal foreground and background colors.

Other terminal types (advanced configuration)

If you have a color-capable (or otherwise highlighting) terminal (or printer!) which uses a different set of codes, you can still generate a suitable setup. To do so, you will have to use the LEFTCODE, RIGHTCODE, and ENDCODE definitions.

When writing out a filename, ls generates the following output sequence: LEFTCODE typecode RIGHTCODE filename ENDCODE, where the typecode is the color sequence that depends on the type or name of file. If the ENDCODE is undefined, the sequence LEFTCODE NORMAL RIGHTCODE will be used instead. The purpose of the left- and rightcodes is merely to reduce the amount of typing necessary (and to hide ugly escape codes away from the user). If they are not appropriate for your terminal, you can eliminate them by specifying the respective keyword on a line by itself.

NOTE: If the ENDCODE is defined in the global section of the setup file, it cannot be undefined in a terminal-specific section of the file. This means any NORMAL definition will have no effect. A different ENDCODE can, however, be specified, which would have the same effect.

Escape sequences

To specify control- or blank characters in the color sequences or filename extensions, either C-style \escaped notation or stty-style ^-notation can be used. The C-style notation includes the following characters:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Bell (ASCII 7)
Backspace (ASCII 8)
Escape (ASCII 27)
Form feed (ASCII 12)
Newline (ASCII 10)
Carriage Return (ASCII 13)
Tab (ASCII 9)
Vertical Tab (ASCII 11)
\? Delete (ASCII 127)
\nnn Any character (octal notation)
\xnnn Any character (hexadecimal notation)
\_ Space
\ Backslash (\)
\^ Caret (^)
\# Hash mark (#)
Note that escapes are necessary to enter a space, backslash, caret, or any control character anywhere in the string, as well as a hash mark as the first character.
FILES
/etc/DIR_COLORS
System-wide configuration file. (Slackware, SuSE and RedHat only; ignored by GNU dircolors(1) and thus Debian.)
~/.dir_colors
(Slackware, SuSE and RedHat only; ignored by GNU dircolors(1) and thus Debian.) Per-user configuration file.
This page describes the dir_colors file format as used in the fileutils-4.1 package; other versions may differ slightly.
NOTES
The default LEFTCODE and RIGHTCODE definitions, which are used by ISO/IEC 6429 terminals are:
LEFTCODE [
RIGHTCODE m
The default ENDCODE is undefined.
SEE ALSO
dircolors(1), ls(1), stty(1), xterm(1)
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

283 - Linux cli command org.bluez.Device

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.Device and provides detailed information about the command org.bluez.Device, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.Device.

NAME 🖥️ org.bluez.Device 🖥️

BlueZ D-Bus Device API documentation

INTERFACE

Service
org.bluez
Interface
org.bluez.Device1
Object path
[variable prefix]/{hci0,hci1,…}/dev_XX_XX_XX_XX_XX_XX

Methods

void Connect()

Connects all profiles the remote device supports that can be connected to and have been flagged as auto-connectable. If only subset of profiles is already connected it will try to connect currently disconnected ones.
If at least one profile was connected successfully this method will indicate success.
For dual-mode devices only one bearer is connected at time, the conditions are in the following order:
Connect the disconnected bearer if already connected.
2. Connect first the bonded bearer. If no bearers are bonded or both are skip and check latest seen bearer.
3. Connect last seen bearer, in case the timestamps are the same BR/EDR takes precedence.
Possible errors:
org.bluez.Error.NotReady
org.bluez.Error.Failed
org.bluez.Error.InProgress
org.bluez.Error.AlreadyConnected

void Disconnect()

Disconnects all connected profiles and then terminates low-level ACL connection.
ACL connection will be terminated even if some profiles were not disconnected properly e.g. due to misbehaving device.
This method can be also used to cancel a preceding Connect call before a reply to it has been received.
For non-trusted devices connected over LE bearer calling this method will disable incoming connections until Connect method is called again.
Possible errors:
org.bluez.Error.NotConnected

void ConnectProfile(string uuid)

Connects a specific profile of this device. The UUID provided is the remote service UUID for the profile.
Possible errors:
org.bluez.Error.Failed
org.bluez.Error.InProgress
org.bluez.Error.InvalidArguments
org.bluez.Error.NotAvailable
org.bluez.Error.NotReady

void DisconnectProfile(string uuid)

Disconnects a specific profile of this device. The profile needs to be registered client profile.
There is no connection tracking for a profile, so as long as the profile is registered this will always succeed.
Possible errors:
org.bluez.Error.Failed
org.bluez.Error.InProgress
org.bluez.Error.InvalidArguments
org.bluez.Error.NotSupported

void Pair()

Connects to the remote device and initiate pairing procedure then proceed with service discovery.
If the application has registered its own agent, then that specific agent will be used. Otherwise it will use the default agent.
Only for applications like a pairing wizard it would make sense to have its own agent. In almost all other cases the default agent will handle this just fine.
In case there is no application agent and also no default agent present, this method will fail.
Possible errors:
org.bluez.Error.InvalidArguments
org.bluez.Error.Failed
org.bluez.Error.AlreadyExists
org.bluez.Error.AuthenticationCanceled
org.bluez.Error.AuthenticationFailed
org.bluez.Error.AuthenticationRejected
org.bluez.Error.AuthenticationTimeout
org.bluez.Error.ConnectionAttemptFailed

void CancelPairing()

Cancels a pairing operation initiated by the Pair method.
Possible errors:
org.bluez.Error.DoesNotExist
org.bluez.Error.Failed

Properties

string Address [readonly]

The Bluetooth device address of the remote device.

string AddressType [readonly]

The Bluetooth device Address Type. For dual-mode and BR/EDR only devices this defaults to “public”. Single mode LE devices may have either value. If remote device uses privacy than before pairing this represents address type used for connection and Identity Address after pairing.
Possible values:
“public”
Public address
“random”
Random address

string Name [readonly, optional]

The Bluetooth remote name.
This value is only present for completeness. It is better to always use the Alias property when displaying the devices name.
If the Alias property is unset, it will reflect this value which makes it more convenient.

string Icon [readonly, optional]

Proposed icon name according to the freedesktop.org icon naming specification.

uint32 Class [readonly, optional]

The Bluetooth class of device of the remote device.

uint16 Appearance [readonly, optional]

External appearance of device, as found on GAP service.

array{string} UUIDs [readonly, optional]

List of 128-bit UUIDs that represents the available remote services.

boolean Paired [readonly]

Indicates if the remote device is paired. Paired means the pairing process where devices exchange the information to establish an encrypted connection has been completed.

boolean Bonded [readonly]

Indicates if the remote device is bonded. Bonded means the information exchanged on pairing process has been stored and will be persisted.

boolean Connected [readonly]

Indicates if the remote device is currently connected. A PropertiesChanged signal indicate changes to this status.

boolean Trusted [readwrite]

Indicates if the remote is seen as trusted. This setting can be changed by the application.

boolean Blocked [readwrite]

If set to true any incoming connections from the device will be immediately rejected. Any device drivers will also be removed and no new ones will be probed as long as the device is blocked.

boolean WakeAllowed [readwrite]

If set to true this device will be allowed to wake the host from system suspend.

string Alias [readwrite]

The name alias for the remote device. The alias can be used to have a different friendly name for the remote device.
In case no alias is set, it will return the remote device name. Setting an empty string as alias will convert it back to the remote device name.
When resetting the alias with an empty string, the property will default back to the remote name.

object Adapter [readonly]

The object path of the adapter the device belongs to.

boolean LegacyPairing [readonly]

Set to true if the device only supports the pre-2.1 pairing mechanism. This property is useful during device discovery to anticipate whether legacy or simple pairing will occur if pairing is initiated.
Note that this property can exhibit false-positives in the case of Bluetooth 2.1 (or newer) devices that have disabled Extended Inquiry Response support.

string Modalias [readonly, optional]

Remote Device ID information in modalias format used by the kernel and udev.

int16 RSSI [readonly, optional]

Received Signal Strength Indicator of the remote device (inquiry or advertising).

int16 TxPower [readonly, optional]

Advertised transmitted power level (inquiry or advertising).

dict ManufacturerData [readonly, optional]

Manufacturer specific advertisement data. Keys are 16 bits Manufacturer ID followed by its byte array value.

dict ServiceData [readonly, optional]

Service advertisement data. Keys are the UUIDs in string format followed by its byte array value.

bool ServicesResolved [readonly]

Indicate whether or not service discovery has been resolved.

array{byte} AdvertisingFlags [readonly, experimental]

The Advertising Data Flags of the remote device.

dict AdvertisingData [readonly, experimental]

The Advertising Data of the remote device. Keys are 1 byte AD Type followed by data as byte array.
Note: Only types considered safe to be handled by application are exposed.
Possible values:
<type>
<byte array>
Example:
<Transport Discovery> <Organization Flags…> 0x26 0x01 0x01…

array{object, dict} Sets [readonly, experimental]

The object paths of the sets the device belongs to followed by a dictionary which can contain the following:
byte Rank
Rank of the device in the Set.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

284 - Linux cli command udev.conf.d

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command udev.conf.d and provides detailed information about the command udev.conf.d, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the udev.conf.d.

NAME 🖥️ udev.conf.d 🖥️

Configuration for device event managing daemon

SYNOPSIS

/etc/udev/udev.conf

/run/udev/udev.conf

/usr/local/lib/udev/udev.conf

/usr/lib/udev/udev.conf

/etc/udev/udev.conf.d/*.conf

/run/udev/udev.conf.d/*.conf

/usr/local/lib/udev/udev.conf.d/*.conf

/usr/lib/udev/udev.conf.d/*.conf

DESCRIPTION

The following options can be set:

udev_log=

The log level. Valid values are the numerical syslog priorities or their textual representations: err, info and debug.
Note
This option is also honored by udevadm(8).
Added in version 216.

children_max=

An integer. The maximum number of events executed in parallel. When unspecified or 0 is specified, the maximum is determined based on the system resources.
This is the same as the –children-max= option.
Added in version 240.

exec_delay=

An integer. Delay the execution of each RUN{program} parameter by the given number of seconds. This option might be useful when debugging system crashes during coldplug caused by loading non-working kernel modules.
This is the same as the –exec-delay= option.
Added in version 240.

event_timeout=

An integer. The number of seconds to wait for events to finish. After this time, the event will be terminated. The default is 180 seconds.
This is the same as the –event-timeout= option.
Added in version 240.

resolve_names=

Specifies when systemd-udevd should resolve names of users and groups. When set to early (the default), names will be resolved when the rules are parsed. When set to late, names will be resolved for every event. When set to never, names will never be resolved and all devices will be owned by root.
This is the same as the –resolve-names= option.
Added in version 240.

timeout_signal=

Specifies a signal that systemd-udevd will send on worker timeouts. Note that both workers and spawned processes will be killed using this signal. Defaults to SIGKILL.
Added in version 246.

In addition, systemd-udevd can be configured by command line options and the kernel command line (see systemd-udevd(8)).

285 - Linux cli command utmpx

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command utmpx and provides detailed information about the command utmpx, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the utmpx.

NAME 🖥️ utmpx 🖥️

SYNOPSIS

#include <utmp.h>

DESCRIPTION

The utmp file allows one to discover information about who is currently using the system. There may be more users currently using the system, because not all programs use utmp logging.

The file is a sequence of utmp structures, declared as follows in <utmp.h> (note that this is only one of several definitions around; details depend on the version of libc):

/* Values for ut_type field, below */
#define EMPTY         0 /* Record does not contain valid info
                           (formerly known as UT_UNKNOWN on Linux) */
#define RUN_LVL       1 /* Change in system run-level (see
                           init(1)) */
#define BOOT_TIME     2 /* Time of system boot (in ut_tv) */
#define NEW_TIME      3 /* Time after system clock change
                           (in ut_tv) */
#define OLD_TIME      4 /* Time before system clock change
                           (in ut_tv) */
#define INIT_PROCESS  5 /* Process spawned by init(1) */
#define LOGIN_PROCESS 6 /* Session leader process for user login */
#define USER_PROCESS  7 /* Normal process */
#define DEAD_PROCESS  8 /* Terminated process */
#define ACCOUNTING    9 /* Not implemented */
#define UT_LINESIZE      32
#define UT_NAMESIZE      32
#define UT_HOSTSIZE     256
struct exit_status {              /* Type for ut_exit, below */
    short e_termination;          /* Process termination status */
    short e_exit;                 /* Process exit status */
};
struct utmp {
    short   ut_type;              /* Type of record */
    pid_t   ut_pid;               /* PID of login process */
    char    ut_line[UT_LINESIZE]; /* Device name of tty - "/dev/" */
    char    ut_id[4];             /* Terminal name suffix,
                                     or inittab(5) ID */
    char    ut_user[UT_NAMESIZE]; /* Username */
    char    ut_host[UT_HOSTSIZE]; /* Hostname for remote login, or
                                     kernel version for run-level
                                     messages */
    struct  exit_status ut_exit;  /* Exit status of a process
                                     marked as DEAD_PROCESS; not
                                     used by Linux init(1) */
    /* The ut_session and ut_tv fields must be the same size when
       compiled 32- and 64-bit.  This allows data files and shared
       memory to be shared between 32- and 64-bit applications. */
#if __WORDSIZE == 64 && defined __WORDSIZE_COMPAT32
    int32_t ut_session;           /* Session ID (getsid(2)),
                                     used for windowing */
    struct {
        int32_t tv_sec;           /* Seconds */
        int32_t tv_usec;          /* Microseconds */
    } ut_tv;                      /* Time entry was made */
#else
     long   ut_session;           /* Session ID */
     struct timeval ut_tv;        /* Time entry was made */
#endif
    int32_t ut_addr_v6[4];        /* Internet address of remote
                                     host; IPv4 address uses
                                     just ut_addr_v6[0] */
    char __unused[20];            /* Reserved for future use */
};
/* Backward compatibility hacks */
#define ut_name ut_user
#ifndef _NO_UT_TIME
#define ut_time ut_tv.tv_sec
#endif
#define ut_xtime ut_tv.tv_sec
#define ut_addr ut_addr_v6[0]

When init(1) finds that a process has exited, it locates its utmp entry by ut_pid, sets ut_type to DEAD_PROCESS, and clears ut_user, ut_host, and ut_time with null bytes.

telnetd(8) sets up a LOGIN_PROCESS entry and leaves the rest to login(1) as usual. After the telnet session ends, telnetd(8) cleans up utmp in the described way.

FILES

/var/run/utmp
/var/log/wtmp

VERSIONS

Linux defines the utmpx structure to be the same as the utmp structure.

STANDARDS

Linux.

HISTORY

Linux utmp entries conform neither to v7/BSD nor to System V; they are a mix of the two.

System V has no ut_host or ut_addr_v6 fields.

NOTES

Unlike various other systems, where utmp logging can be disabled by removing the file, utmp must always exist on Linux. If you want to disable who(1), then do not make utmp world readable.

The file format is machine-dependent, so it is recommended that it be processed only on the machine architecture where it was created.

gettimeofday((struct timeval *) &ut.ut_tv, NULL);

the following method of setting this field is recommended:

struct utmp ut;
struct timeval tv;
gettimeofday(&tv, NULL);
ut.ut_tv.tv_sec = tv.tv_sec;
ut.ut_tv.tv_usec = tv.tv_usec;

286 - Linux cli command org.bluez.obex.ObjectPush

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.obex.ObjectPush and provides detailed information about the command org.bluez.obex.ObjectPush, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.obex.ObjectPush.

NAME 🖥️ org.bluez.obex.ObjectPush 🖥️

BlueZ D-Bus OBEX ObjectPush API documentation

INTERFACE

Service
org.bluez.obex
Interface
org.bluez.obex.ObjectPush1
Object path
[Session object path]

Methods

object, dict SendFile(string sourcefile)

Sends local file to the remote device.
The returned path represents the newly created transfer, which should be used to find out if the content has been successfully transferred or if the operation fails.
The properties of this transfer are also returned along with the object path, to avoid a call to GetProperties, see org.bluez.obex.Transfer(5) for the possible list of properties.
Possible errors:
org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Error.Failed

object, dict PullBusinessCard(string targetfile)

Request the business card from a remote device and store it in the local file.
If an empty target file is given, a name will be automatically generated for the temporary file.
The returned path represents the newly created transfer, which should be used to find out if the content has been successfully transferred or if the operation fails.
The properties of this transfer are also returned along with the object path, to avoid a call to GetProperties, see org.bluez.obex.Transfer(5) for the possible list of properties.
Possible errors:
org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Error.Failed

object, dict ExchangeBusinessCards(string clientfile, string targetfile)

Push the client’s business card to the remote device and then retrieve the remote business card and store it in a local file.
If an empty target file is given, a name will be automatically generated for the temporary file.
The returned path represents the newly created transfer, which should be used to find out if the content has been successfully transferred or if the operation fails.
The properties of this transfer are also returned along with the object path, to avoid a call to GetProperties, see org.bluez.obex.Transfer(5) for the possible list of properties.
Possible errors:
org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Error.Failed

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

287 - Linux cli command e2fsck.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command e2fsck.conf and provides detailed information about the command e2fsck.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the e2fsck.conf.

NAME 🖥️ e2fsck.conf 🖥️

Configuration file for e2fsck

DESCRIPTION

e2fsck.conf is the configuration file for e2fsck(8). It controls the default behavior of e2fsck(8) while it is checking ext2, ext3, or ext4 file systems.

The e2fsck.conf file uses an INI-style format. Stanzas, or top-level sections, are delimited by square braces: [ ]. Within each section, each line defines a relation, which assigns tags to values, or to a subsection, which contains further relations or subsections. An example of the INI-style format used by this configuration file follows below:

[section1]
tag1 = value_a
tag1 = value_b
tag2 = value_c

[section 2]
tag3 = {
subtag1 = subtag_value_a
subtag1 = subtag_value_b
subtag2 = subtag_value_c
}
tag1 = value_d
tag2 = value_e
}

Comments are delimited by a semicolon (’;’) or a hash (’#’) character at the beginning of the comment, and are terminated by the end of line character.

The following stanzas are used in the e2fsck.conf file. They will be described in more detail in future sections of this document.

[options]
This stanza contains general configuration parameters for e2fsck’s behavior.

[defaults]
Contains relations which define the default parameters used by e2fsck(8). In general, these defaults may be overridden by command-line options provided by the user.

[problems]
This stanza allows the administrator to reconfigure how e2fsck handles various file system inconsistencies.

[scratch_files]
This stanza controls when e2fsck will attempt to use scratch files to reduce the need for memory.

THE [options] STANZA

The following relations are defined in the [options] stanza.

allow_cancellation
If this relation is set to a boolean value of true, then if the user interrupts e2fsck using ^C, and the file system is not explicitly flagged as containing errors, e2fsck will exit with an exit status of 0 instead of 32. This setting defaults to false.

accept_time_fudge
Unfortunately, due to Windows’ unfortunate design decision to configure the hardware clock to tick localtime, instead of the more proper and less error-prone UTC time, many users end up in the situation where the system clock is incorrectly set at the time when e2fsck is run.

Historically this was usually due to some distributions having buggy init scripts and/or installers that didn’t correctly detect this case and take appropriate countermeasures. Unfortunately, this is occasionally true even today, usually due to a buggy or misconfigured virtualization manager or the installer not having access to a network time server during the installation process. So by default, we allow the superblock times to be fudged by up to 24 hours. This can be disabled by setting accept_time_fudge to the boolean value of false. This setting defaults to true.

broken_system_clock
The e2fsck(8) program has some heuristics that assume that the system clock is correct. In addition, many system programs make similar assumptions. For example, the UUID library depends on time not going backwards in order for it to be able to make its guarantees about issuing universally unique ID’s. Systems with broken system clocks, are well, broken. However, broken system clocks, particularly in embedded systems, do exist. E2fsck will attempt to use heuristics to determine if the time can not be trusted; and to skip time-based checks if this is true. If this boolean is set to true, then e2fsck will always assume that the system clock can not be trusted.

buggy_init_scripts
This boolean relation is an alias for accept_time_fudge for backwards compatibility; it used to be that the behavior defined by accept_time_fudge above defaulted to false, and buggy_init_scripts would enable superblock time field to be wrong by up to 24 hours. When we changed the default, we also renamed this boolean relation to accept_time_fudge.

clear_test_fs_flag
This boolean relation controls whether or not e2fsck(8) will offer to clear the test_fs flag if the ext4 file system is available on the system. It defaults to true.

defer_check_on_battery
This boolean relation controls whether or not the interval between file system checks (either based on time or number of mounts) should be doubled if the system is running on battery. This setting defaults to true.

indexed_dir_slack_percentage
When e2fsck(8) repacks a indexed directory, reserve the specified percentage of empty space in each leaf nodes so that a few new entries can be added to the directory without splitting leaf nodes, so that the average fill ratio of directories can be maintained at a higher, more efficient level. This relation defaults to 20 percent.

inode_count_fullmap
If this boolean relation is true, trade off using memory for speed when checking a file system with a large number of hard-linked files. The amount of memory required is proportional to the number of inodes in the file system. For large file systems, this can be gigabytes of memory. (For example a 40TB file system with 2.8 billion inodes will consume an additional 5.7 GB memory if this optimization is enabled.) This setting defaults to false.

log_dir
If the log_filename or problem_log_filename relations contains a relative pathname, then the log file will be placed in the directory named by the log_dir relation.

log_dir_fallback
This relation contains an alternate directory that will be used if the directory specified by log_dir is not available or is not writable.

log_dir_wait
If this boolean relation is true, them if the directories specified by log_dir or log_dir_fallback are not available or are not yet writable, e2fsck will save the output in a memory buffer, and a child process will periodically test to see if the log directory has become available after the boot sequence has mounted the requested file system for reading/writing. This implements the functionality provided by logsave(8) for e2fsck log files.

log_filename
This relation specifies the file name where a copy of e2fsck’s output will be written. If certain problem reports are suppressed using the max_count_problems relation, (or on a per-problem basis using the max_count relation), the full set of problem reports will be written to the log file. The filename may contain various percent-expressions (%D, %T, %N, etc.) which will be expanded so that the file name for the log file can include things like date, time, device name, and other run-time parameters. See the LOGGING section for more details.

max_count_problems
This relation specifies the maximum number of problem reports of a particular type will be printed to stdout before further problem reports of that type are squelched. This can be useful if the console is slow (i.e., connected to a serial port) and so a large amount of output could end up delaying the boot process for a long time (potentially hours).

no_optimize_extents
If this boolean relation is true, do not offer to optimize the extent tree by reducing the tree’s width or depth. This setting defaults to false.

problem_log_filename
This relation specifies the file name where a log of problem codes found by e2fsck be written. The filename may contain various percent-expressions (%D, %T, %N, etc.) which will be expanded so that the file name for the log file can include things like date, time, device name, and other run-time parameters. See the LOGGING section for more details.

readahead_mem_pct
Use this percentage of memory to try to read in metadata blocks ahead of the main e2fsck thread. This should reduce run times, depending on the speed of the underlying storage and the amount of free memory. There is no default, but see readahead_kb for more details.

readahead_kb
Use this amount of memory to read in metadata blocks ahead of the main checking thread. Setting this value to zero disables readahead entirely. By default, this is set the size of two block groups’ inode tables (typically 4MiB on a regular ext4 file system); if this amount is more than 1/50th of total physical memory, readahead is disabled.

report_features
If this boolean relation is true, e2fsck will print the file system features as part of its verbose reporting (i.e., if the -v option is specified)

report_time
If this boolean relation is true, e2fsck will run as if the options -tt are always specified. This will cause e2fsck to print timing statistics on a pass by pass basis for full file system checks.

report_verbose
If this boolean relation is true, e2fsck will run as if the option -v is always specified. This will cause e2fsck to print some additional information at the end of each full file system check.

THE [defaults] STANZA

The following relations are defined in the [defaults] stanza.

THE [problems] STANZA

Each tag in the [problems] stanza names a problem code specified with a leading “0x” followed by six hex digits. The value of the tag is a subsection where the relations in that subsection override the default treatment of that particular problem code.

Note that inappropriate settings in this stanza may cause e2fsck to behave incorrectly, or even crash. Most system administrators should not be making changes to this section without referring to source code.

Within each problem code’s subsection, the following tags may be used:

description
This relation allows the message which is printed when this file system inconsistency is detected to be overridden.

preen_ok
This boolean relation overrides the default behavior controlling whether this file system problem should be automatically fixed when e2fsck is running in preen mode.

max_count
This integer relation overrides the max_count_problems parameter (set in the options section) for this particular problem.

no_ok
This boolean relation overrides the default behavior determining whether or not the file system will be marked as inconsistent if the user declines to fix the reported problem.

no_default
This boolean relation overrides whether the default answer for this problem (or question) should be “no”.

preen_nomessage
This boolean relation overrides the default behavior controlling whether or not the description for this file system problem should be suppressed when e2fsck is running in preen mode.

no_nomsg
This boolean relation overrides the default behavior controlling whether or not the description for this file system problem should be suppressed when a problem forced not to be fixed, either because e2fsck is run with the -n option or because the force_no flag has been set for the problem.

force_no
This boolean option, if set to true, forces a problem to never be fixed. That is, it will be as if the user problem responds ’no’ to the question of ‘should this problem be fixed?’. The force_no option even overrides the -y option given on the command-line (just for the specific problem, of course).

not_a_fix
This boolean option, it set to true, marks the problem as one where if the user gives permission to make the requested change, it does not mean that the file system had a problem which has since been fixed. This is used for requests to optimize the file system’s data structure, such as pruning an extent tree.

THE [scratch_files] STANZA

The following relations are defined in the [scratch_files] stanza.

directory
If the directory named by this relation exists and is writeable, then e2fsck will attempt to use this directory to store scratch files instead of using in-memory data structures.

numdirs_threshold
If this relation is set, then in-memory data structures will be used if the number of directories in the file system are fewer than amount specified.

dirinfo
This relation controls whether or not the scratch file directory is used instead of an in-memory data structure for directory information. It defaults to true.

icount
This relation controls whether or not the scratch file directory is used instead of an in-memory data structure when tracking inode counts. It defaults to true.

LOGGING

E2fsck has the facility to save the information from an e2fsck run in a directory so that a system administrator can review its output at their leisure. This allows information captured during the automatic e2fsck preen run, as well as a manually started e2fsck run, to be saved for posterity. This facility is controlled by the log_filename, log_dir, log_dir_fallback, and log_dir_wait relations in the [options] stanza.

The filename in log_filename may contain the following percent-expressions that will be expanded as follows.

%d
The current day of the month

%D
The current date; this is a equivalent of %Y%m%d

%h
The hostname of the system.

%H
The current hour in 24-hour format (00..23)

%m
The current month as a two-digit number (01..12)

%M
The current minute (00..59)

%N
The name of the block device containing the file system, with any directory pathname stripped off.

%p
The pid of the e2fsck process

%s
The current time expressed as the number of seconds since 1970-01-01 00:00:00 UTC

%S
The current second (00..59)

%T
The current time; this is equivalent of %H%M%S

%u
The name of the user running e2fsck.

%U
This percent expression does not expand to anything, but it signals that any following date or time expressions should be expressed in UTC time instead of the local timezone.

%y
The last two digits of the current year (00..99)

%Y
The current year (i.e., 2012).

EXAMPLES

The following recipe will prevent e2fsck from aborting during the boot process when a file system contains orphaned files. (Of course, this is not always a good idea, since critical files that are needed for the security of the system could potentially end up in lost+found, and starting the system without first having a system administrator check things out may be dangerous.)

[problems]
0x040002 = {
preen_ok = true
description = “@u @i %i. "
}

The following recipe will cause an e2fsck logfile to be written to the directory /var/log/e2fsck, with a filename that contains the device name, the hostname of the system, the date, and time: e.g., “e2fsck-sda3.server.INFO.20120314-112142”. If the directory containing /var/log is located on the root file system which is initially mounted read-only, then the output will be saved in memory and written out once the root file system has been remounted read/write. To avoid too much detail from being written to the serial console (which could potentially slow down the boot sequence), only print no more than 16 instances of each type of file system corruption.

[options]
max_count_problems = 16
log_dir = /var/log/e2fsck
log_filename = e2fsck-%N.%h.INFO.%D-%T
log_dir_wait = true

FILES

/etc/e2fsck.conf
The configuration file for e2fsck(8).

288 - Linux cli command locale

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command locale and provides detailed information about the command locale, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the locale.

NAME 🖥️ locale 🖥️

describes a locale definition file

DESCRIPTION

The locale definition file contains all the information that the localedef(1) command needs to convert it into the binary locale database.

The definition files consist of sections which each describe a locale category in detail. See locale(7) for additional details for these categories.

Syntax

The locale definition file starts with a header that may consist of the following keywords:

escape_char
is followed by a character that should be used as the escape-character for the rest of the file to mark characters that should be interpreted in a special way. It defaults to the backslash (.

comment_char
is followed by a character that will be used as the comment-character for the rest of the file. It defaults to the number sign (#).

The locale definition has one part for each locale category. Each part can be copied from another existing locale or can be defined from scratch. If the category should be copied, the only valid keyword in the definition is copy followed by the name of the locale in double quotes which should be copied. The exceptions for this rule are LC_COLLATE and LC_CTYPE where a copy statement can be followed by locale-specific rules and selected overrides.

When defining a locale or a category from scratch, an existing system- provided locale definition file should be used as a reference to follow common glibc conventions.

Locale category sections

The following category sections are defined by POSIX:

LC_CTYPE
LC_COLLATE
LC_MESSAGES
LC_MONETARY
LC_NUMERIC
LC_TIME

In addition, since glibc 2.2, the GNU C library supports the following nonstandard categories:

LC_ADDRESS
LC_IDENTIFICATION
LC_MEASUREMENT
LC_NAME
LC_PAPER
LC_TELEPHONE

See locale(7) for a more detailed description of each category.

LC_ADDRESS

The definition starts with the string LC_ADDRESS in the first column.

The following keywords are allowed:

postal_fmt
followed by a string containing field descriptors that define the format used for postal addresses in the locale. The following field descriptors are recognized:

%n
Person’s name, possibly constructed with the LC_NAME name_fmt keyword (since glibc 2.24).

%a
Care of person, or organization.

%f
Firm name.

%d
Department name.

%b
Building name.

%s
Street or block (e.g., Japanese) name.

%h
House number or designation.

%N
Insert an end-of-line if the previous descriptor’s value was not an empty string; otherwise ignore.

%t
Insert a space if the previous descriptor’s value was not an empty string; otherwise ignore.

%r
Room number, door designation.

%e
Floor number.

%C
Country designation, from the country_post keyword.

%l
Local township within town or city (since glibc 2.24).

%z
Zip number, postal code.

%T
Town, city.

%S
State, province, or prefecture.

%c
Country, as taken from data record.

Each field descriptor may have an ‘R’ after the ‘%’ to specify that the information is taken from a Romanized version string of the entity.

country_name
followed by the country name in the language of the current document (e.g., “Deutschland” for the de_DE locale).

country_post
followed by the abbreviation of the country (see CERT_MAILCODES).

country_ab2
followed by the two-letter abbreviation of the country (ISO 3166).

country_ab3
followed by the three-letter abbreviation of the country (ISO 3166).

country_num
followed by the numeric country code (ISO 3166).

country_car
followed by the international license plate country code.

country_isbn
followed by the ISBN code (for books).

lang_name
followed by the language name in the language of the current document.

lang_ab
followed by the two-letter abbreviation of the language (ISO 639).

lang_term
followed by the three-letter abbreviation of the language (ISO 639-2/T).

lang_lib
followed by the three-letter abbreviation of the language for library use (ISO 639-2/B). Applications should in general prefer lang_term over lang_lib.

The LC_ADDRESS definition ends with the string END LC_ADDRESS.

LC_CTYPE

The definition starts with the string LC_CTYPE in the first column.

The following keywords are allowed:

upper
followed by a list of uppercase letters. The letters A through Z are included automatically. Characters also specified as cntrl, digit, punct, or space are not allowed.

lower
followed by a list of lowercase letters. The letters a through z are included automatically. Characters also specified as cntrl, digit, punct, or space are not allowed.

alpha
followed by a list of letters. All character specified as either upper or lower are automatically included. Characters also specified as cntrl, digit, punct, or space are not allowed.

digit
followed by the characters classified as numeric digits. Only the digits 0 through 9 are allowed. They are included by default in this class.

space
followed by a list of characters defined as white-space characters. Characters also specified as upper, lower, alpha, digit, graph, or xdigit are not allowed. The characters <space>, <form-feed>, <newline>, <carriage-return>, <tab>, and <vertical-tab> are automatically included.

cntrl
followed by a list of control characters. Characters also specified as upper, lower, alpha, digit, punct, graph, print, or xdigit are not allowed.

punct
followed by a list of punctuation characters. Characters also specified as upper, lower, alpha, digit, cntrl, xdigit, or the <space> character are not allowed.

graph
followed by a list of printable characters, not including the <space> character. The characters defined as upper, lower, alpha, digit, xdigit, and punct are automatically included. Characters also specified as cntrl are not allowed.

print
followed by a list of printable characters, including the <space> character. The characters defined as upper, lower, alpha, digit, xdigit, punct, and the <space> character are automatically included. Characters also specified as cntrl are not allowed.

xdigit
followed by a list of characters classified as hexadecimal digits. The decimal digits must be included followed by one or more set of six characters in ascending order. The following characters are included by default: 0 through 9, a through f, A through F.

blank
followed by a list of characters classified as blank. The characters <space> and <tab> are automatically included.

charclass
followed by a list of locale-specific character class names which are then to be defined in the locale.

toupper
followed by a list of mappings from lowercase to uppercase letters. Each mapping is a pair of a lowercase and an uppercase letter separated with a , and enclosed in parentheses.

tolower
followed by a list of mappings from uppercase to lowercase letters. If the keyword tolower is not present, the reverse of the toupper list is used.

map totitle
followed by a list of mapping pairs of characters and letters to be used in titles (headings).

class
followed by a locale-specific character class definition, starting with the class name followed by the characters belonging to the class.

charconv
followed by a list of locale-specific character mapping names which are then to be defined in the locale.

outdigit
followed by a list of alternate output digits for the locale.

map to_inpunct
followed by a list of mapping pairs of alternate digits and separators for input digits for the locale.

map to_outpunct
followed by a list of mapping pairs of alternate separators for output for the locale.

translit_start
marks the start of the transliteration rules section. The section can contain the include keyword in the beginning followed by locale-specific rules and overrides. Any rule specified in the locale file will override any rule copied or included from other files. In case of duplicate rule definitions in the locale file, only the first rule is used.

A transliteration rule consist of a character to be transliterated followed by a list of transliteration targets separated by semicolons. The first target which can be presented in the target character set is used, if none of them can be used the default_missing character will be used instead.

include
in the transliteration rules section includes a transliteration rule file (and optionally a repertoire map file).

default_missing
in the transliteration rules section defines the default character to be used for transliteration where none of the targets cannot be presented in the target character set.

translit_end
marks the end of the transliteration rules.

The LC_CTYPE definition ends with the string END LC_CTYPE.

LC_COLLATE

Note that glibc does not support all POSIX-defined options, only the options described below are supported (as of glibc 2.23).

The definition starts with the string LC_COLLATE in the first column.

The following keywords are allowed:

coll_weight_max
followed by the number representing used collation levels. This keyword is recognized but ignored by glibc.

collating-element
followed by the definition of a collating-element symbol representing a multicharacter collating element.

collating-symbol
followed by the definition of a collating symbol that can be used in collation order statements.

define
followed by string to be evaluated in an ifdef string / else / endif construct.

reorder-after
followed by a redefinition of a collation rule.

reorder-end
marks the end of the redefinition of a collation rule.

reorder-sections-after
followed by a script name to reorder listed scripts after.

reorder-sections-end
marks the end of the reordering of sections.

script
followed by a declaration of a script.

symbol-equivalence
followed by a collating-symbol to be equivalent to another defined collating-symbol.

The collation rule definition starts with a line:

order_start
followed by a list of keywords chosen from forward, backward, or position. The order definition consists of lines that describe the collation order and is terminated with the keyword order_end.

The LC_COLLATE definition ends with the string END LC_COLLATE.

LC_IDENTIFICATION

The definition starts with the string LC_IDENTIFICATION in the first column.

The following keywords are allowed:

title
followed by the title of the locale document (e.g., “Maori language locale for New Zealand”).

source
followed by the name of the organization that maintains this document.

address
followed by the address of the organization that maintains this document.

contact
followed by the name of the contact person at the organization that maintains this document.

email
followed by the email address of the person or organization that maintains this document.

tel
followed by the telephone number (in international format) of the organization that maintains this document. As of glibc 2.24, this keyword is deprecated in favor of other contact methods.

fax
followed by the fax number (in international format) of the organization that maintains this document. As of glibc 2.24, this keyword is deprecated in favor of other contact methods.

language
followed by the name of the language to which this document applies.

territory
followed by the name of the country/geographic extent to which this document applies.

audience
followed by a description of the audience for which this document is intended.

application
followed by a description of any special application for which this document is intended.

abbreviation
followed by the short name for provider of the source of this document.

revision
followed by the revision number of this document.

date
followed by the revision date of this document.

In addition, for each of the categories defined by the document, there should be a line starting with the keyword category, followed by:

a string that identifies this locale category definition,
a semicolon, and
one of the LC_* identifiers.

The LC_IDENTIFICATION definition ends with the string END LC_IDENTIFICATION.

LC_MESSAGES

The definition starts with the string LC_MESSAGES in the first column.

The following keywords are allowed:

yesexpr
followed by a regular expression that describes possible yes-responses.

noexpr
followed by a regular expression that describes possible no-responses.

yesstr
followed by the output string corresponding to “yes”.

nostr
followed by the output string corresponding to “no”.

The LC_MESSAGES definition ends with the string END LC_MESSAGES.

LC_MEASUREMENT

The definition starts with the string LC_MEASUREMENT in the first column.

The following keywords are allowed:

measurement
followed by number identifying the standard used for measurement. The following values are recognized:

1
Metric.

2
US customary measurements.

The LC_MEASUREMENT definition ends with the string END LC_MEASUREMENT.

LC_MONETARY

The definition starts with the string LC_MONETARY in the first column.

The following keywords are allowed:

int_curr_symbol
followed by the international currency symbol. This must be a 4-character string containing the international currency symbol as defined by the ISO 4217 standard (three characters) followed by a separator.

currency_symbol
followed by the local currency symbol.

mon_decimal_point
followed by the single-character string that will be used as the decimal delimiter when formatting monetary quantities.

mon_thousands_sep
followed by the single-character string that will be used as a group separator when formatting monetary quantities.

mon_grouping
followed by a sequence of integers separated by semicolons that describe the formatting of monetary quantities. See grouping below for details.

positive_sign
followed by a string that is used to indicate a positive sign for monetary quantities.

negative_sign
followed by a string that is used to indicate a negative sign for monetary quantities.

int_frac_digits
followed by the number of fractional digits that should be used when formatting with the int_curr_symbol.

frac_digits
followed by the number of fractional digits that should be used when formatting with the currency_symbol.

p_cs_precedes
followed by an integer that indicates the placement of currency_symbol for a nonnegative formatted monetary quantity:

0
the symbol succeeds the value.

1
the symbol precedes the value.

p_sep_by_space
followed by an integer that indicates the separation of currency_symbol, the sign string, and the value for a nonnegative formatted monetary quantity. The following values are recognized:

0
No space separates the currency symbol and the value.

1
If the currency symbol and the sign string are adjacent, a space separates them from the value; otherwise a space separates the currency symbol and the value.

2
If the currency symbol and the sign string are adjacent, a space separates them from the value; otherwise a space separates the sign string and the value.

n_cs_precedes
followed by an integer that indicates the placement of currency_symbol for a negative formatted monetary quantity. The same values are recognized as for p_cs_precedes.

n_sep_by_space
followed by an integer that indicates the separation of currency_symbol, the sign string, and the value for a negative formatted monetary quantity. The same values are recognized as for p_sep_by_space.

p_sign_posn
followed by an integer that indicates where the positive_sign should be placed for a nonnegative monetary quantity:

0
Parentheses enclose the quantity and the currency_symbol or int_curr_symbol.

1
The sign string precedes the quantity and the currency_symbol or the int_curr_symbol.

2
The sign string succeeds the quantity and the currency_symbol or the int_curr_symbol.

3
The sign string precedes the currency_symbol or the int_curr_symbol.

4
The sign string succeeds the currency_symbol or the int_curr_symbol.

n_sign_posn
followed by an integer that indicates where the negative_sign should be placed for a negative monetary quantity. The same values are recognized as for p_sign_posn.

int_p_cs_precedes
followed by an integer that indicates the placement of int_curr_symbol for a nonnegative internationally formatted monetary quantity. The same values are recognized as for p_cs_precedes.

int_n_cs_precedes
followed by an integer that indicates the placement of int_curr_symbol for a negative internationally formatted monetary quantity. The same values are recognized as for p_cs_precedes.

int_p_sep_by_space
followed by an integer that indicates the separation of int_curr_symbol, the sign string, and the value for a nonnegative internationally formatted monetary quantity. The same values are recognized as for p_sep_by_space.

int_n_sep_by_space
followed by an integer that indicates the separation of int_curr_symbol, the sign string, and the value for a negative internationally formatted monetary quantity. The same values are recognized as for p_sep_by_space.

int_p_sign_posn
followed by an integer that indicates where the positive_sign should be placed for a nonnegative internationally formatted monetary quantity. The same values are recognized as for p_sign_posn.

int_n_sign_posn
followed by an integer that indicates where the negative_sign should be placed for a negative internationally formatted monetary quantity. The same values are recognized as for p_sign_posn.

The LC_MONETARY definition ends with the string END LC_MONETARY.

LC_NAME

The definition starts with the string LC_NAME in the first column.

Various keywords are allowed, but only name_fmt is mandatory. Other keywords are needed only if there is common convention to use the corresponding salutation in this locale. The allowed keywords are as follows:

name_fmt
followed by a string containing field descriptors that define the format used for names in the locale. The following field descriptors are recognized:

%f
Family name(s).

%F
Family names in uppercase.

%g
First given name.

%G
First given initial.

%l
First given name with Latin letters.

%o
Other shorter name.

%m
Additional given name(s).

%M
Initials for additional given name(s).

%p
Profession.

%s
Salutation, such as “Doctor”.

%S
Abbreviated salutation, such as “Mr.” or “Dr.”.

%d
Salutation, using the FDCC-sets conventions.

%t
If the preceding field descriptor resulted in an empty string, then the empty string, otherwise a space character.

name_gen
followed by the general salutation for any gender.

name_mr
followed by the salutation for men.

name_mrs
followed by the salutation for married women.

name_miss
followed by the salutation for unmarried women.

name_ms
followed by the salutation valid for all women.

The LC_NAME definition ends with the string END LC_NAME.

LC_NUMERIC

The definition starts with the string LC_NUMERIC in the first column.

The following keywords are allowed:

decimal_point
followed by the single-character string that will be used as the decimal delimiter when formatting numeric quantities.

thousands_sep
followed by the single-character string that will be used as a group separator when formatting numeric quantities.

grouping
followed by a sequence of integers separated by semicolons that describe the formatting of numeric quantities.

Each integer specifies the number of digits in a group. The first integer defines the size of the group immediately to the left of the decimal delimiter. Subsequent integers define succeeding groups to the left of the previous group. If the last integer is not -1, then the size of the previous group (if any) is repeatedly used for the remainder of the digits. If the last integer is -1, then no further grouping is performed.

The LC_NUMERIC definition ends with the string END LC_NUMERIC.

LC_PAPER

The definition starts with the string LC_PAPER in the first column.

The following keywords are allowed:

height
followed by the height, in millimeters, of the standard paper format.

width
followed by the width, in millimeters, of the standard paper format.

The LC_PAPER definition ends with the string END LC_PAPER.

LC_TELEPHONE

The definition starts with the string LC_TELEPHONE in the first column.

The following keywords are allowed:

tel_int_fmt
followed by a string that contains field descriptors that identify the format used to dial international numbers. The following field descriptors are recognized:

%a
Area code without nationwide prefix (the prefix is often “00”).

%A
Area code including nationwide prefix.

%l
Local number (within area code).

%e
Extension (to local number).

%c
Country code.

%C
Alternate carrier service code used for dialing abroad.

%t
If the preceding field descriptor resulted in an empty string, then the empty string, otherwise a space character.

tel_dom_fmt
followed by a string that contains field descriptors that identify the format used to dial domestic numbers. The recognized field descriptors are the same as for tel_int_fmt.

int_select
followed by the prefix used to call international phone numbers.

int_prefix
followed by the prefix used from other countries to dial this country.

The LC_TELEPHONE definition ends with the string END LC_TELEPHONE.

LC_TIME

The definition starts with the string LC_TIME in the first column.

The following keywords are allowed:

abday
followed by a list of abbreviated names of the days of the week. The list starts with the first day of the week as specified by week (Sunday by default). See NOTES.

day
followed by a list of names of the days of the week. The list starts with the first day of the week as specified by week (Sunday by default). See NOTES.

abmon
followed by a list of abbreviated month names.

mon
followed by a list of month names.

d_t_fmt
followed by the appropriate date and time format (for syntax, see strftime(3)).

d_fmt
followed by the appropriate date format (for syntax, see strftime(3)).

t_fmt
followed by the appropriate time format (for syntax, see strftime(3)).

am_pm
followed by the appropriate representation of the am and pm strings. This should be left empty for locales not using AM/PM convention.

t_fmt_ampm
followed by the appropriate time format (for syntax, see strftime(3)) when using 12h clock format. This should be left empty for locales not using AM/PM convention.

era
followed by semicolon-separated strings that define how years are counted and displayed for each era in the locale. Each string has the following format:

direction:offset:start_date:end_date:era_name:era_format

The fields are to be defined as follows:

direction
Either + or -. + means the years closer to start_date have lower numbers than years closer to end_date. - means the opposite.

offset
The number of the year closest to start_date in the era, corresponding to the %Ey descriptor (see strptime(3)).

start_date
The start of the era in the form of yyyy/mm/dd. Years prior AD 1 are represented as negative numbers.

end_date
The end of the era in the form of yyyy/mm/dd, or one of the two special values of -* or +*. -* means the ending date is the beginning of time. +* means the ending date is the end of time.

era_name
The name of the era corresponding to the %EC descriptor (see strptime(3)).

era_format
The format of the year in the era corresponding to the %EY descriptor (see strptime(3)).

era_d_fmt
followed by the format of the date in alternative era notation, corresponding to the %Ex descriptor (see strptime(3)).

era_t_fmt
followed by the format of the time in alternative era notation, corresponding to the %EX descriptor (see strptime(3)).

era_d_t_fmt
followed by the format of the date and time in alternative era notation, corresponding to the %Ec descriptor (see strptime(3)).

alt_digits
followed by the alternative digits used for date and time in the locale.

week
followed by a list of three values separated by semicolons: The number of days in a week (by default 7), a date of beginning of the week (by default corresponds to Sunday), and the minimal length of the first week in year (by default 4). Regarding the start of the week, 19971130 shall be used for Sunday and 19971201 shall be used for Monday. See NOTES.

first_weekday (since glibc 2.2)
followed by the number of the day from the day list to be shown as the first day of the week in calendar applications. The default value of 1 corresponds to either Sunday or Monday depending on the value of the second week list item. See NOTES.

first_workday (since glibc 2.2)
followed by the number of the first working day from the day list. The default value is 2. See NOTES.

cal_direction
followed by a number value that indicates the direction for the display of calendar dates, as follows:

1
Left-right from top.

2
Top-down from left.

3
Right-left from top.

date_fmt
followed by the appropriate date representation for date(1) (for syntax, see strftime(3)).

The LC_TIME definition ends with the string END LC_TIME.

FILES

/usr/lib/locale/locale-archive
Usual default locale archive location.

/usr/share/i18n/locales
Usual default path for locale definition files.

STANDARDS

POSIX.2.

NOTES

The collective GNU C library community wisdom regarding abday, day, week, first_weekday, and first_workday states at https://sourceware.org/glibc/wiki/Locales the following:

The value of the second week list item specifies the base of the abday and day lists.
first_weekday specifies the offset of the first day-of-week in the abday and day lists.
For compatibility reasons, all glibc locales should set the value of the second week list item to 19971130 (Sunday) and base the abday and day lists appropriately, and set first_weekday and first_workday to 1 or 2, depending on whether the week and work week actually starts on Sunday or Monday for the locale.

289 - Linux cli command namespace.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command namespace.conf and provides detailed information about the command namespace.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the namespace.conf.

NAME 🖥️ namespace.conf 🖥️

the namespace configuration file

DESCRIPTION

The pam_namespace.so module allows setup of private namespaces with polyinstantiated directories. Directories can be polyinstantiated based on user name or, in the case of SELinux, user name, sensitivity level or complete security context. If an executable script /etc/security/namespace.init exists, it is used to initialize the namespace every time an instance directory is set up and mounted. The script receives the polyinstantiated directory path and the instance directory path as its arguments.

The /etc/security/namespace.conf file specifies which directories are polyinstantiated, how they are polyinstantiated, how instance directories would be named, and any users for whom polyinstantiation would not be performed.

When someone logs in, the file namespace.conf is scanned. Comments are marked by # characters. Each non comment line represents one polyinstantiated directory. The fields are separated by spaces but can be quoted by " characters also escape sequences , * *, and * * are recognized. The fields are as follows:

polydir instance_prefix method list_of_uids

The first field, polydir, is the absolute pathname of the directory to polyinstantiate. The special string $HOME is replaced with the users home directory, and $USER with the username. This field cannot be blank.

The second field, instance_prefix is the string prefix used to build the pathname for the instantiation of <polydir>. Depending on the polyinstantiation method it is then appended with “instance differentiation string” to generate the final instance directory path. This directory is created if it did not exist already, and is then bind mounted on the <polydir> to provide an instance of <polydir> based on the <method> column. The special string $HOME is replaced with the users home directory, and $USER with the username. This field cannot be blank.

The third field, method, is the method used for polyinstantiation. It can take these values; “user” for polyinstantiation based on user name, “level” for polyinstantiation based on process MLS level and user name, “context” for polyinstantiation based on process security context and user name, “tmpfs” for mounting tmpfs filesystem as an instance dir, and “tmpdir” for creating temporary directory as an instance dir which is removed when the users session is closed. Methods “context” and “level” are only available with SELinux. This field cannot be blank.

The fourth field, list_of_uids, is a comma separated list of user names for whom the polyinstantiation is not performed. If left blank, polyinstantiation will be performed for all users. If the list is preceded with a single “~” character, polyinstantiation is performed only for users in the list.

The method field can contain also following optional flags separated by : characters.

create=mode,owner,group - create the polyinstantiated directory. The mode, owner and group parameters are optional. The default for mode is determined by umask, the default owner is the user whose session is opened, the default group is the primary group of the user.

iscript=path - path to the instance directory init script. The base directory for relative paths is /etc/security/namespace.d.

noinit - instance directory init script will not be executed.

shared - the instance directories for “context” and “level” methods will not contain the user name and will be shared among all users.

mntopts=value - value of this flag is passed to the mount call when the tmpfs mount is done. It allows for example the specification of the maximum size of the tmpfs instance that is created by the mount call. In addition to options specified in the tmpfs(5) manual the nosuid, noexec, and nodev flags can be used to respectively disable setuid bit effect, disable running executables, and disable devices to be interpreted on the mounted tmpfs filesystem.

The directory where polyinstantiated instances are to be created, must exist and must have, by default, the mode of 0000. The requirement that the instance parent be of mode 0000 can be overridden with the command line option ignore_instance_parent_mode

In case of context or level polyinstantiation the SELinux context which is used for polyinstantiation is the context used for executing a new process as obtained by getexeccon. This context must be set by the calling application or pam_selinux.so module. If this context is not set the polyinstatiation will be based just on user name.

The “instance differentiation string” is <user name> for “user” method and <user name>_<raw directory context> for “context” and “level” methods. If the whole string is too long the end of it is replaced with md5sum of itself. Also when command line option gen_hash is used the whole string is replaced with md5sum of itself.

EXAMPLES

These are some example lines which might be specified in /etc/security/namespace.conf.

  # The following three lines will polyinstantiate /tmp,
      # /var/tmp and users home directories. /tmp and /var/tmp
      # will be polyinstantiated based on the security level
      # as well as user name, whereas home directory will be
      # polyinstantiated based on the full security context and user name.
      # Polyinstantiation will not be performed for user root
      # and adm for directories /tmp and /var/tmp, whereas home
      # directories will be polyinstantiated for all users.
      #
      # Note that instance directories do not have to reside inside
      # the polyinstantiated directory. In the examples below,
      # instances of /tmp will be created in /tmp-inst directory,
      # where as instances of /var/tmp and users home directories
      # will reside within the directories that are being
      # polyinstantiated.
      #
      /tmp     /tmp-inst/               level      root,adm
      /var/tmp /var/tmp/tmp-inst/   	level      root,adm
      $HOME    $HOME/$USER.inst/inst- context

For the <service>s you need polyinstantiation (login for example) put the following line in /etc/pam.d/<service> as the last line for session group:

session required pam_namespace.so [arguments]

This module also depends on pam_selinux.so setting the context.

AUTHORS

The namespace.conf manual page was written by Janak Desai <[email protected]>. More features added by Tomas Mraz <[email protected]>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

290 - Linux cli command apt_auth.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command apt_auth.conf and provides detailed information about the command apt_auth.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the apt_auth.conf.

NAME 🖥️ apt_auth.conf 🖥️

DESCRIPTION

APT configuration files like sources.list(5) or apt.conf(5) need to be accessible for everyone using apt tools on the system to have access to all package-related information like the available packages in a repository. Login information needed to connect to a proxy or to download data from a repository on the other hand shouldnt always be accessible by everyone and can hence not be placed in a file with world-readable file permissions.

The APT auth.conf file /etc/apt/auth.conf, and .conf files inside /etc/apt/auth.conf.d can be used to store login information in a netrc-like format with restrictive file permissions.

NETRC-LIKE FORMAT

The format defined here is similar to the format of the ~/.netrc file used by ftp(1) and similar programs interacting with servers. It is a simple token-based format with the following tokens being recognized; Unknown tokens will be ignored. Tokens may be separated by spaces, tabs or newlines.

machine [protocol://]hostname[:port][/path]

Entries are looked up by searching for the machine token matching the hostname of the URI apt needs login information for. Extending the netrc-format a portnumber can be specified. If no port is given the token matches for all ports. Similar the path is optional and only needed and useful if multiple repositories with different login information reside on the same server. A machine token with a path matches if the path in the URI starts with the path given in the token. Once a match is made, the subsequent tokens are processed, stopping when the end of file is reached or another machine token is encountered.
If protocol is not specified, the entry only matches https and tor+https.

The username to be used.

password string

The password to be used.

EXAMPLE

Supplying login information for a user named apt with the password debian for the sources.list(5) entry

deb https://example.org/debian bookworm main

could be done in the entry directly:

deb https://apt:[email protected]/debian bookworm main

Alternatively an entry like the following in the auth.conf file could be used:

machine example.org login apt password debian

Or alternatively within a single line:

machine example.org login apt password debian

If you need to be more specific all of these lines will also apply to the example entry:

machine example.org/deb login apt password debian machine example.org/debian login apt password debian machine example.org/debian/ login apt password debian

On the other hand neither of the following lines apply:

machine example.org:443 login apt password debian machine example.org/deb/ login apt password debian machine example.org/ubuntu login apt password debian machine example.orga login apt password debian machine example.net login apt password debian

NOTES

Basic support for this feature is present since version 0.7.25, but was undocumented for years. The documentation was added in version 1.5 changing also the implementation slightly. For maximum backward compatibility you should avoid multiple machine tokens with the same hostname, but if you need multiple they should all have a path specified in the machine token.

Login information in auth.conf are more flexible than those in sources.list. For example, login information can be specified for parts of a repository only, or if the sources.list entry redirects elsewhere, login information for the redirect destination can be supplied.

FILES

/etc/apt/auth.conf

Login information for APT sources and proxies in a netrc-like format. Configuration Item: Dir::Etc::netrc.

/etc/apt/auth.conf.d/*.conf

Login information for APT sources and proxies in a netrc-like format. Configuration Item: Dir::Etc::netrcparts.

BUGS

APT bug page[1]. If you wish to report a bug in APT, please see /usr/share/doc/debian/bug-reporting.txt or the reportbug(1) command.

AUTHOR

APT team

NOTES

APT bug page

https://bugs.debian.org/src:apt

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

291 - Linux cli command deb-buildinfo

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command deb-buildinfo and provides detailed information about the command deb-buildinfo, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the deb-buildinfo.

NAME 🖥️ deb-buildinfo 🖥️

buildinfo - Debian build information file format

SYNOPSIS

filename**.buildinfo**

DESCRIPTION

Each Debian source package build can record the build information in a .buildinfo control file, which contains a number of fields in deb822 (5) format.

Each field begins with a tag, such as Source or Binary (case insensitive), followed by a colon, and the body of the field (case sensitive unless stated otherwise). Fields are delimited only by field tags. In other words, field text may be multiple lines in length, but the installation tools will generally join lines when processing the body of the field (except in case of the multiline fields Binary-Only-Changes, Installed-Build-Depends, Environment, Checksums-Md5, Checksums-Sha1 and Checksums-Sha256, see below).

The control data might be enclosed in an OpenPGP ASCII Armored signature, as specified in RFC4880.

The name of the .buildinfo file will depend on the type of build and will be as specific as necessary but not more; the name will be:

source-name_binary-version_arch.buildinfo
for a build that includes any

source-name_binary-version_all.buildinfo
otherwise for a build that includes all

source-name_source-version_source.buildinfo
otherwise for a build that includes source

FIELDS

Format: format-version (required)
The value of this field declares the format version of the file. The syntax of the field value is a version number with a major and minor component. Backward incompatible changes to the format will bump the major version, and backward compatible changes (such as field additions) will bump the minor version. The current format version is 1.0.

Source: source-name [(source-version)] (required)
The name of the source package. If the source version differs from the binary version, then the source-name will be followed by a source-version in parenthesis. This can happen when the build is for a binary-only non-maintainer upload.

Binary: binary-package-list (required in context)
This folded field is a space-separated list of binary packages built. If the build is source-only, then the field is omitted (since dpkg 1.20.0).

Architecture: arch-list (required)
This space-separated field lists the architectures of the files currently being built. Common architectures are amd64, armel, i386, etc. Note that the all value is meant for packages that are architecture independent. If the source for the package is also being built, the special entry source is also present. Architecture wildcards must never be present in the list.

Binary-Only-Changes:

changelog-entry

This multiline field contains the concatenated text of the changelog entry for a binary-only non-maintainer upload (binNMU) if that is the case. To make this a valid multiline field empty lines are replaced with a single full stop (‘.’) and all lines are indented by one space character. The exact content depends on the changelog format.

Checksums-Md5: (required)

Checksums-Sha1: (required)

Checksums-Sha256: (required)

checksum size filename

These multiline fields contain a list of files with a checksum and size for each one. These fields have the same syntax and differ only in the checksum algorithm used: MD5 for Checksums-Md5, SHA-1 for Checksums-Sha1 and SHA-256 for Checksums-Sha256. The first line of the field value (the part on the same line as the field name followed by a colon) is always empty. The content of the field is expressed as continuation lines, one line per file. Each line consists of space-separated entries describing the file: the checksum, the file size, and the file name. These fields list all files that make up the build.

Build-Origin: name
The name of the distribution this package is originating from.

Build-Architecture: arch (required)
The Debian architecture for the installation the packages is being built in. Common architectures are amd64, armel, i386, etc.

Build-Date: build-date
The date the package was built. It must be in the same format as the date in a deb-changelog (5) entry.

Build-Kernel-Version: build-kernel-version
The release and version (in an unspecified format) of the kernel running on the build system. This field is only going to be present if the builder has explicitly requested it, to avoid leaking possibly sensitive information.

Build-Path: build-path
The absolute build path, which correspond to the unpacked source tree. This field is only going to be present if the vendor has allowed it via some pattern match to avoid leaking possibly sensitive information. On Debian and derivatives only build paths starting with /build/ will emit this field.

Build-Tainted-By:

taint-reason-list

This folded field contains a space-separated list of non-exhaustive reason tags (formed by alphanumeric and dash characters) which identify why the current build has been tainted (since dpkg 1.19.5). On Debian and derivatives the following reason tags can be emitted:

merged-usr-via-aliased-dirs
The system has a merged /usr via aliased directories (previously known as merged-usr-via-symlinks). This will confuse dpkg-query, dpkg-statoverride, dpkg-trigger, update-alternatives and any other tool using pathnames as keys into their databases, as it creates filesystem aliasing problems, and messes with the understanding of the filesystem that dpkg has recorded in its database. For build systems that hardcode pathnames to specific binaries or libraries on the resulting artifacts, it can also produce packages that will be incompatible with non-/usr-merged filesystems.
usr-local-has-configs
The system has configuration files under /usr/local/etc.
usr-local-has-includes
The system has header files under /usr/local/include.
usr-local-has-programs
The system has programs under /usr/local/bin or /usr/local/sbin.
usr-local-has-libraries
The system has libraries, either static or shared under /usr/local/lib.
can-execute-cross-built-programs
The system can execute cross built programs, either directly or via some emulation layer. Since dpkg 1.21.10.

Installed-Build-Depends: (required)

package-list

The list of installed and configured packages that might affect the package build process. The list consists of each package name, optionally arch-qualified for foreign architectures, with an exact version restriction, separated by commas. The list includes all essential packages, packages listed in Build-Depends, Build-Depends-Arch, Build-Depends-Indep source control fields, any vendor specific builtin dependencies, and all their recursive dependencies. On Debian and derivatives the dependency builtin is build-essential. For dependencies coming from the source control fields, all dependency alternatives and all providers of virtual packages depended on will be included.

Environment:

variable-list

The list of environment variables that are known to affect the package build process, with each environment variable followed by an equal sign (‘=’) and the variable’s quoted value, using double quotes (‘"’), and backslashes escaped (‘\’).

292 - Linux cli command org.freedesktop.locale1

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.freedesktop.locale1 and provides detailed information about the command org.freedesktop.locale1, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.freedesktop.locale1.

NAME 🖥️ org.freedesktop.locale1 🖥️

The D-Bus interface of systemd-localed

INTRODUCTION

systemd-localed.service(8) is a system service that can be used to control the system locale and keyboard mapping from user programs. This page describes the D-Bus interface.

THE D-BUS API

The service exposes the following interfaces on the bus:

node /org/freedesktop/locale1 { interface org.freedesktop.locale1 { methods: SetLocale(in as locale, in b interactive); SetVConsoleKeyboard(in s keymap, in s keymap_toggle, in b convert, in b interactive); SetX11Keyboard(in s layout, in s model, in s variant, in s options, in b convert, in b interactive); properties: readonly as Locale = […, …]; readonly s X11Layout = …; readonly s X11Model = …; readonly s X11Variant = …; readonly s X11Options = …; readonly s VConsoleKeymap = …; readonly s VConsoleKeymapToggle = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; };

Methods

If you set a new system locale all old system locale settings will be dropped and the new settings will be saved to disk. The locale will also be passed to the system manager, and subsequently started daemons will inherit the new system locale. Note that already running daemons will not learn about the new value.

The SetVConsoleKeyboard() method may be used to set the key mapping for the virtual console. Similarly, SetX11Keyboard() may be used to set the default key mapping of any X11 servers.

Note that SetVConsoleKeyboard() instantly applies the new key mapping to the console, while SetX11Keyboard() simply sets a default that may be used by later sessions.

The boolean argument convert may be set to optionally convert the console keyboard configuration to X11 keyboard mappings and vice versa. If true and SetVConsoleKeyboard() is used, the nearest X11 keyboard setting for the chosen console setting is set. If true and SetX11Keyboard() is used, the nearest console keyboard setting for the chosen X11 setting is set. Hence, it is usually sufficient to call only one of the two functions.

For graphical UIs that need to set the system keyboard mapping simply invoke SetX11Keyboard(), set convert=true and ignore SetVConsoleKeyboard().

Use the empty string for the keymap parameters you wish not to set.

The interactive boolean parameters can be used to control whether polkit[1] should interactively ask the user for authentication credentials if required.

Signals

Whenever the system locale or keymap is changed via the daemon, PropertyChanged signals are sent out to which clients can subscribe.

Properties

The system locale is shown in the Locale property. It is an array containing environment-variable-assignment-like strings. The following strings are known: LANG=, LC_CTYPE=, LC_NUMERIC=, LC_TIME=, LC_COLLATE=, LC_MONETARY=, LC_MESSAGES=, LC_PAPER=, LC_NAME=, LC_ADDRESS=, LC_TELEPHONE=, LC_MEASUREMENT=, LC_IDENTIFICATION=.

The X11Layout, X11Model, X11Variant, and X11Options properties show values configurable with SetX11Keyboard() described above (or SetVConsoleKeyboard() with convert=true). The VConsoleKeymap and VConsoleKeymapToggle properties show values configurable with SetVConsoleKeyboard() (or SetX11Keyboard() with convert=true).

Security

Changing the system locale or keymap using this interface is authenticated via polkit. The polkit action for SetLocale() is org.freedesktop.locale1.set-locale. The polkit action for SetX11Keyboard() and SetVConsoleKeyboard() is org.freedesktop.locale1.set-keyboard.

EXAMPLES

Example 1. Introspect org.freedesktop.locale1 on the bus

$ gdbus introspect –system
–dest org.freedesktop.locale1
–object-path /org/freedesktop/locale1

VERSIONING

These D-Bus interfaces follow the usual interface versioning guidelines[2].

NOTES

polkit

https://www.freedesktop.org/software/polkit/docs/latest/

the usual interface versioning guidelines

https://0pointer.de/blog/projects/versioning-dbus.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

293 - Linux cli command gemfile

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gemfile and provides detailed information about the command gemfile, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gemfile.

NAME 🖥️ gemfile 🖥️

A format for describing gem dependencies for Ruby programs

SYNOPSIS

A Gemfile describes the gem dependencies required to execute associated Ruby code.

Place the Gemfile in the root of the directory containing the associated code. For instance, in a Rails application, place the Gemfile in the same directory as the Rakefile.

SYNTAX

A Gemfile is evaluated as Ruby code, in a context which makes available a number of methods used to describe the gem requirements.

GLOBAL SOURCE

At the top of the Gemfile, add a single line for the RubyGems source that contains the gems listed in the Gemfile.

source "https://rubygems.org"

You can add only one global source. In Bundler 1.13, adding multiple global sources was deprecated. The source MUST be a valid RubyGems repository.

To use more than one source of RubyGems, you should use source block.

A source is checked for gems following the heuristics described in SOURCE PRIORITY.

Note about a behavior of the feature deprecated in Bundler 1.13: If a gem is found in more than one global source, Bundler will print a warning after installing the gem indicating which source was used, and listing the other sources where the gem is available. A specific source can be selected for gems that need to use a non-standard repository, suppressing this warning, by using the :source option or source block.

CREDENTIALS

Some gem sources require a username and password. Use bundle config(1) bundle-config.1.html to set the username and password for any of the sources that need it. The command must be run once on each computer that will install the Gemfile, but this keeps the credentials from being stored in plain text in version control.

bundle config gems.example.com user:password

For some sources, like a company Gemfury account, it may be easier to include the credentials in the Gemfile as part of the source URL.

source "https://user:[email protected]"

Credentials in the source URL will take precedence over credentials set using config.

RUBY

If your application requires a specific Ruby version or engine, specify your requirements using the ruby method, with the following arguments. All parameters are OPTIONAL unless otherwise specified.

VERSION (required)

The version of Ruby that your application requires. If your application requires an alternate Ruby engine, such as JRuby, TruffleRuby, etc., this should be the Ruby version that the engine is compatible with.

ruby "3.1.2"

If you wish to derive your Ruby version from a version file (ie .ruby-version), you can use the file option instead.

ruby file: ".ruby-version"

The version file should conform to any of the following formats:

3.1.2 (.ruby-version)
ruby 3.1.2 (.tool-versions, read: https://asdf-vm.com/manage/configuration.html#tool-versions)

ENGINE

Each application may specify a Ruby engine. If an engine is specified, an engine version must also be specified.

What exactly is an Engine? - A Ruby engine is an implementation of the Ruby language.

For background: the reference or original implementation of the Ruby programming language is called Matz’s Ruby Interpreter https://en.wikipedia.org/wiki/Ruby_MRI, or MRI for short. This is named after Ruby creator Yukihiro Matsumoto, also known as Matz. MRI is also known as CRuby, because it is written in C. MRI is the most widely used Ruby engine.
Other implementations https://www.ruby-lang.org/en/about/ of Ruby exist. Some of the more well-known implementations include JRuby http://jruby.org/ and TruffleRuby https://www.graalvm.org/ruby/. Rubinius is an alternative implementation of Ruby written in Ruby. JRuby is an implementation of Ruby on the JVM, short for Java Virtual Machine. TruffleRuby is a Ruby implementation on the GraalVM, a language toolkit built on the JVM.

ENGINE VERSION

Each application may specify a Ruby engine version. If an engine version is specified, an engine must also be specified. If the engine is “ruby” the engine version specified must match the Ruby version.

ruby "2.6.8", engine: "jruby", engine_version: "9.3.8.0"

PATCHLEVEL

Each application may specify a Ruby patchlevel. Specifying the patchlevel has been meaningless since Ruby 2.1.0 was released as the patchlevel is now uniquely determined by a combination of major, minor, and teeny version numbers.

This option was implemented in Bundler 1.4.0 for Ruby 2.0 or earlier.

ruby "3.1.2", patchlevel: "20"

GEMS

Specify gem requirements using the gem method, with the following arguments. All parameters are OPTIONAL unless otherwise specified.

NAME (required)

For each gem requirement, list a single gem line.

gem "nokogiri"

VERSION

Each gem MAY have one or more version specifiers.

gem "nokogiri", ">= 1.4.2"
gem "RedCloth", ">= 4.1.0", "< 4.2.0"

REQUIRE AS

Each gem MAY specify files that should be used when autorequiring via Bundler.require. You may pass an array with multiple files or true if the file you want required has the same name as gem or false to prevent any file from being autorequired.

gem "redis", require: ["redis/connection/hiredis", "redis"]
gem "webmock", require: false
gem "byebug", require: true

The argument defaults to the name of the gem. For example, these are identical:

gem "nokogiri"
gem "nokogiri", require: "nokogiri"
gem "nokogiri", require: true

GROUPS

Each gem MAY specify membership in one or more groups. Any gem that does not specify membership in any group is placed in the default group.

gem "rspec", group: :test
gem "wirble", groups: [:development, :test]

The Bundler runtime allows its two main methods, Bundler.setup and Bundler.require, to limit their impact to particular groups.

# setup adds gems to Ruby's load path
Bundler.setup                    # defaults to all groups
require "bundler/setup"          # same as Bundler.setup
Bundler.setup(:default)          # only set up the _default_ group
Bundler.setup(:test)             # only set up the _test_ group (but `not` _default_)
Bundler.setup(:default, :test)   # set up the _default_ and _test_ groups, but no others

# require requires all of the gems in the specified groups
Bundler.require                  # defaults to the _default_ group
Bundler.require(:default)        # identical
Bundler.require(:default, :test) # requires the _default_ and _test_ groups
Bundler.require(:test)           # requires the _test_ group

The Bundler CLI allows you to specify a list of groups whose gems bundle install should not install with the without configuration.

To specify multiple groups to ignore, specify a list of groups separated by spaces.

bundle config set --local without test
bundle config set --local without development test

Also, calling Bundler.setup with no parameters, or calling require “bundler/setup” will setup all groups except for the ones you excluded via –without (since they are not available).

Note that on bundle install, bundler downloads and evaluates all gems, in order to create a single canonical list of all of the required gems and their dependencies. This means that you cannot list different versions of the same gems in different groups. For more details, see Understanding Bundler https://bundler.io/rationale.html.

PLATFORMS

If a gem should only be used in a particular platform or set of platforms, you can specify them. Platforms are essentially identical to groups, except that you do not need to use the –without install-time flag to exclude groups of gems for other platforms.

There are a number of Gemfile platforms:

ruby
C Ruby (MRI), Rubinius, or TruffleRuby, but not Windows

mri
C Ruby (MRI) only, but not Windows

windows
Windows C Ruby (MRI), including RubyInstaller 32-bit and 64-bit versions

mswin
Windows C Ruby (MRI), including RubyInstaller 32-bit versions

mswin64
Windows C Ruby (MRI), including RubyInstaller 64-bit versions

rbx
Rubinius

jruby
JRuby

truffleruby
TruffleRuby

On platforms ruby, mri, mswin, mswin64, and windows, you may additionally specify a version by appending the major and minor version numbers without a delimiter. For example, to specify that a gem should only be used on platform ruby version 3.1, use:

ruby_31

As with groups (above), you may specify one or more platforms:

gem "weakling",   platforms: :jruby
gem "ruby-debug", platforms: :mri_31
gem "nokogiri",   platforms: [:windows_31, :jruby]

All operations involving groups (bundle install bundle-install.1.html, Bundler.setup, Bundler.require) behave exactly the same as if any groups not matching the current platform were explicitly excluded.

FORCE_RUBY_PLATFORM

If you always want the pure ruby variant of a gem to be chosen over platform specific variants, you can use the force_ruby_platform option:

gem "ffi", force_ruby_platform: true

This can be handy (assuming the pure ruby variant works fine) when:

You’re having issues with the platform specific variant.
The platform specific variant does not yet support a newer ruby (and thus has a required_ruby_version upper bound), but you still want your Gemfile{.lock} files to resolve under that ruby.

SOURCE

You can select an alternate RubyGems repository for a gem using the ‘:source’ option.

gem "some_internal_gem", source: "https://gems.example.com"

This forces the gem to be loaded from this source and ignores the global source declared at the top level of the file. If the gem does not exist in this source, it will not be installed.

Bundler will search for child dependencies of this gem by first looking in the source selected for the parent, but if they are not found there, it will fall back on the global source.

Note about a behavior of the feature deprecated in Bundler 1.13: Selecting a specific source repository this way also suppresses the ambiguous gem warning described above in GLOBAL SOURCE.

Using the :source option for an individual gem will also make that source available as a possible global source for any other gems which do not specify explicit sources. Thus, when adding gems with explicit sources, it is recommended that you also ensure all other gems in the Gemfile are using explicit sources.

GIT

If necessary, you can specify that a gem is located at a particular git repository using the :git parameter. The repository can be accessed via several protocols:

HTTP(S)
gem “rails”, git: “https://github.com/rails/rails.git"

SSH
gem “rails”, git: “[email protected]:rails/rails.git”

git
gem “rails”, git: “git://github.com/rails/rails.git”

If using SSH, the user that you use to run bundle install MUST have the appropriate keys available in their $HOME/.ssh.

NOTE: http:// and git:// URLs should be avoided if at all possible. These protocols are unauthenticated, so a man-in-the-middle attacker can deliver malicious code and compromise your system. HTTPS and SSH are strongly preferred.

The group, platforms, and require options are available and behave exactly the same as they would for a normal gem.

A git repository SHOULD have at least one file, at the root of the directory containing the gem, with the extension .gemspec. This file MUST contain a valid gem specification, as expected by the gem build command.

If a git repository does not have a .gemspec, bundler will attempt to create one, but it will not contain any dependencies, executables, or C extension compilation instructions. As a result, it may fail to properly integrate into your application.

If a git repository does have a .gemspec for the gem you attached it to, a version specifier, if provided, means that the git repository is only valid if the .gemspec specifies a version matching the version specifier. If not, bundler will print a warning.

gem "rails", "2.3.8", git: "https://github.com/rails/rails.git"
# bundle install will fail, because the .gemspec in the rails
# repository's master branch specifies version 3.0.0

If a git repository does not have a .gemspec for the gem you attached it to, a version specifier MUST be provided. Bundler will use this version in the simple .gemspec it creates.

Git repositories support a number of additional options.

branch, tag, and ref
You MUST only specify at most one of these options. The default is branch: “master”. For example:

gem “rails”, git: “https://github.com/rails/rails.git", branch: “5-0-stable”

gem “rails”, git: “https://github.com/rails/rails.git", tag: “v5.0.0”

gem “rails”, git: “https://github.com/rails/rails.git", ref: “4aded”

submodules
For reference, a git submodule https://git-scm.com/book/en/v2/Git-Tools-Submodules lets you have another git repository within a subfolder of your repository. Specify submodules: true to cause bundler to expand any submodules included in the git repository

If a git repository contains multiple .gemspecs, each .gemspec represents a gem located at the same place in the file system as the .gemspec.

|~rails                   [git root]
| |-rails.gemspec         [rails gem located here]
|~actionpack
| |-actionpack.gemspec    [actionpack gem located here]
|~activesupport
| |-activesupport.gemspec [activesupport gem located here]
|...

To install a gem located in a git repository, bundler changes to the directory containing the gemspec, runs gem build name.gemspec and then installs the resulting gem. The gem build command, which comes standard with Rubygems, evaluates the .gemspec in the context of the directory in which it is located.

GIT SOURCE

A custom git source can be defined via the git_source method. Provide the source’s name as an argument, and a block which receives a single argument and interpolates it into a string to return the full repo address:

git_source(:stash){ |repo_name| "https://stash.corp.acme.pl/#{repo_name}.git" }
gem 'rails', stash: 'forks/rails'

In addition, if you wish to choose a specific branch:

gem "rails", stash: "forks/rails", branch: "branch_name"

GITHUB

NOTE: This shorthand should be avoided until Bundler 2.0, since it currently expands to an insecure git:// URL. This allows a man-in-the-middle attacker to compromise your system.

If the git repository you want to use is hosted on GitHub and is public, you can use the :github shorthand to specify the github username and repository name (without the trailing “.git”), separated by a slash. If both the username and repository name are the same, you can omit one.

gem "rails", github: "rails/rails"
gem "rails", github: "rails"

Are both equivalent to

gem "rails", git: "https://github.com/rails/rails.git"

Since the github method is a specialization of git_source, it accepts a :branch named argument.

You can also directly pass a pull request URL:

gem "rails", github: "https://github.com/rails/rails/pull/43753"

Which is equivalent to:

gem "rails", github: "rails/rails", branch: "refs/pull/43753/head"

GIST

If the git repository you want to use is hosted as a GitHub Gist and is public, you can use the :gist shorthand to specify the gist identifier (without the trailing “.git”).

gem "the_hatch", gist: "4815162342"

Is equivalent to:

gem "the_hatch", git: "https://gist.github.com/4815162342.git"

Since the gist method is a specialization of git_source, it accepts a :branch named argument.

BITBUCKET

If the git repository you want to use is hosted on Bitbucket and is public, you can use the :bitbucket shorthand to specify the bitbucket username and repository name (without the trailing “.git”), separated by a slash. If both the username and repository name are the same, you can omit one.

gem "rails", bitbucket: "rails/rails"
gem "rails", bitbucket: "rails"

Are both equivalent to

gem "rails", git: "https://[email protected]/rails/rails.git"

Since the bitbucket method is a specialization of git_source, it accepts a :branch named argument.

PATH

You can specify that a gem is located in a particular location on the file system. Relative paths are resolved relative to the directory containing the Gemfile.

Similar to the semantics of the :git option, the :path option requires that the directory in question either contains a .gemspec for the gem, or that you specify an explicit version that bundler should use.

Unlike :git, bundler does not compile C extensions for gems specified as paths.

gem "rails", path: "vendor/rails"

If you would like to use multiple local gems directly from the filesystem, you can set a global path option to the path containing the gem’s files. This will automatically load gemspec files from subdirectories.

path 'components' do
  gem 'admin_ui'
  gem 'public_ui'
end

BLOCK FORM OF SOURCE, GIT, PATH, GROUP and PLATFORMS

The :source, :git, :path, :group, and :platforms options may be applied to a group of gems by using block form.

source "https://gems.example.com" do
  gem "some_internal_gem"
  gem "another_internal_gem"
end

git "https://github.com/rails/rails.git" do
  gem "activesupport"
  gem "actionpack"
end

platforms :ruby do
  gem "ruby-debug"
  gem "sqlite3"
end

group :development, optional: true do
  gem "wirble"
  gem "faker"
end

In the case of the group block form the :optional option can be given to prevent a group from being installed unless listed in the –with option given to the bundle install command.

In the case of the git block form, the :ref, :branch, :tag, and :submodules options may be passed to the git method, and all gems in the block will inherit those options.

The presence of a source block in a Gemfile also makes that source available as a possible global source for any other gems which do not specify explicit sources. Thus, when defining source blocks, it is recommended that you also ensure all other gems in the Gemfile are using explicit sources, either via source blocks or :source directives on individual gems.

INSTALL_IF

The install_if method allows gems to be installed based on a proc or lambda. This is especially useful for optional gems that can only be used if certain software is installed or some other conditions are met.

install_if -> { RUBY_PLATFORM =~ /darwin/ } do
  gem "pasteboard"
end

GEMSPEC

The .gemspec http://guides.rubygems.org/specification-reference/ file is where you provide metadata about your gem to Rubygems. Some required Gemspec attributes include the name, description, and homepage of your gem. This is also where you specify the dependencies your gem needs to run.

If you wish to use Bundler to help install dependencies for a gem while it is being developed, use the gemspec method to pull in the dependencies listed in the .gemspec file.

The gemspec method adds any runtime dependencies as gem requirements in the default group. It also adds development dependencies as gem requirements in the development group. Finally, it adds a gem requirement on your project (path: ‘.’). In conjunction with Bundler.setup, this allows you to require project files in your test code as you would if the project were installed as a gem; you need not manipulate the load path manually or require project files via relative paths.

The gemspec method supports optional :path, :glob, :name, and :development_group options, which control where bundler looks for the .gemspec, the glob it uses to look for the gemspec (defaults to: {,*,*/*}.gemspec), what named .gemspec it uses (if more than one is present), and which group development dependencies are included in.

When a gemspec dependency encounters version conflicts during resolution, the local version under development will always be selected – even if there are remote versions that better match other requirements for the gemspec gem.

SOURCE PRIORITY

When attempting to locate a gem to satisfy a gem requirement, bundler uses the following priority order:

The source explicitly attached to the gem (using :source, :path, or :git)
For implicit gems (dependencies of explicit gems), any source, git, or path repository declared on the parent. This results in bundler prioritizing the ActiveSupport gem from the Rails git repository over ones from rubygems.org
If neither of the above conditions are met, the global source will be used. If multiple global sources are specified, they will be prioritized from last to first, but this is deprecated since Bundler 1.13, so Bundler prints a warning and will abort with an error in the future.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

294 - Linux cli command proc_net

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_net and provides detailed information about the command proc_net, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_net.

NAME 🖥️ proc_net 🖥️

network layer information

DESCRIPTION

/proc/pid/net/ (since Linux 2.6.25)
See the description of /proc/net.

/proc/net/
This directory contains various files and subdirectories containing information about the networking layer. The files contain ASCII structures and are, therefore, readable with cat(1). However, the standard netstat(8) suite provides much cleaner access to these files.

With the advent of network namespaces, various information relating to the network stack is virtualized (see network_namespaces(7)). Thus, since Linux 2.6.25, /proc/net is a symbolic link to the directory /proc/self/net, which contains the same files and directories as listed below. However, these files and directories now expose information for the network namespace of which the process is a member.

/proc/net/arp
This holds an ASCII readable dump of the kernel ARP table used for address resolutions. It will show both dynamically learned and preprogrammed ARP entries. The format is:

IP address     HW type   Flags     HW address          Mask   Device
192.168.0.50   0x1       0x2       00:50:BF:25:68:F3   *      eth0
192.168.0.250  0x1       0xc       00:00:00:00:00:00   *      eth0

Here “IP address” is the IPv4 address of the machine and the “HW type” is the hardware type of the address from RFC 826. The flags are the internal flags of the ARP structure (as defined in /usr/include/linux/if_arp.h) and the “HW address” is the data link layer mapping for that IP address if it is known.

/proc/net/dev
The dev pseudo-file contains network device status information. This gives the number of received and sent packets, the number of errors and collisions and other basic statistics. These are used by the ifconfig(8) program to report device status. The format is:

Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
    lo: 2776770   11307    0    0    0     0          0         0  2776770   11307    0    0    0     0       0          0
  eth0: 1215645    2751    0    0    0     0          0         0  1782404    4324    0    0    0   427       0          0
  ppp0: 1622270    5552    1    0    0     0          0         0   354130    5669    0    0    0     0       0          0
  tap0:    7714      81    0    0    0     0          0         0     7714      81    0    0    0     0       0          0

/proc/net/dev_mcast
Defined in /usr/src/linux/net/core/dev_mcast.c:

indx interface_name  dmi_u dmi_g dmi_address
2    eth0            1     0     01005e000001
3    eth1            1     0     01005e000001
4    eth2            1     0     01005e000001

/proc/net/igmp
Internet Group Management Protocol. Defined in /usr/src/linux/net/core/igmp.c.

/proc/net/rarp
This file uses the same format as the arp file and contains the current reverse mapping database used to provide rarp(8) reverse address lookup services. If RARP is not configured into the kernel, this file will not be present.

/proc/net/raw
Holds a dump of the RAW socket table. Much of the information is not of use apart from debugging. The “sl” value is the kernel hash slot for the socket, the “local_address” is the local address and protocol number pair. “St” is the internal status of the socket. The “tx_queue” and “rx_queue” are the outgoing and incoming data queue in terms of kernel memory usage. The “tr”, “tm->when”, and “rexmits” fields are not used by RAW. The “uid” field holds the effective UID of the creator of the socket.

/proc/net/snmp
This file holds the ASCII data needed for the IP, ICMP, TCP, and UDP management information bases for an SNMP agent.

/proc/net/tcp
Holds a dump of the TCP socket table. Much of the information is not of use apart from debugging. The “sl” value is the kernel hash slot for the socket, the “local_address” is the local address and port number pair. The “rem_address” is the remote address and port number pair (if connected). “St” is the internal status of the socket. The “tx_queue” and “rx_queue” are the outgoing and incoming data queue in terms of kernel memory usage. The “tr”, “tm->when”, and “rexmits” fields hold internal information of the kernel socket state and are useful only for debugging. The “uid” field holds the effective UID of the creator of the socket.

/proc/net/udp
Holds a dump of the UDP socket table. Much of the information is not of use apart from debugging. The “sl” value is the kernel hash slot for the socket, the “local_address” is the local address and port number pair. The “rem_address” is the remote address and port number pair (if connected). “St” is the internal status of the socket. The “tx_queue” and “rx_queue” are the outgoing and incoming data queue in terms of kernel memory usage. The “tr”, “tm->when”, and “rexmits” fields are not used by UDP. The “uid” field holds the effective UID of the creator of the socket. The format is:

sl  local_address rem_address   st tx_queue rx_queue tr rexmits  tm->when uid
 1: 01642C89:0201 0C642C89:03FF 01 00000000:00000001 01:000071BA 00000000 0
 1: 00000000:0801 00000000:0000 0A 00000000:00000000 00:00000000 6F000100 0
 1: 00000000:0201 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0

/proc/net/unix
Lists the UNIX domain sockets present within the system and their status. The format is:

Num RefCount Protocol Flags    Type St Inode Path
 0: 00000002 00000000 00000000 0001 03    42
 1: 00000001 00000000 00010000 0001 01  1948 /dev/printer

The fields are as follows:

Num:
the kernel table slot number.

RefCount:
the number of users of the socket.

Protocol:
currently always 0.

Flags:
the internal kernel flags holding the status of the socket.

Type:
the socket type. For SOCK_STREAM sockets, this is 0001; for SOCK_DGRAM sockets, it is 0002; and for SOCK_SEQPACKET sockets, it is 0005.

St:
the internal state of the socket.

Inode:
the inode number of the socket.

Path:
the bound pathname (if any) of the socket. Sockets in the abstract namespace are included in the list, and are shown with a Path that commences with the character ‘@’.

/proc/net/netfilter/nfnetlink_queue
This file contains information about netfilter user-space queueing, if used. Each line represents a queue. Queues that have not been subscribed to by user space are not shown.

   1   4207     0  2 65535     0     0        0  1
  (1)   (2)    (3)(4)  (5)    (6)   (7)      (8)

The fields in each line are:

(1)
The ID of the queue. This matches what is specified in the –queue-num or –queue-balance options to the iptables(8) NFQUEUE target. See iptables-extensions(8) for more information.

(2)
The netlink port ID subscribed to the queue.

(3)
The number of packets currently queued and waiting to be processed by the application.

(4)
The copy mode of the queue. It is either 1 (metadata only) or 2 (also copy payload data to user space).

(5)
Copy range; that is, how many bytes of packet payload should be copied to user space at most.

(6)
queue dropped. Number of packets that had to be dropped by the kernel because too many packets are already waiting for user space to send back the mandatory accept/drop verdicts.

(7)
queue user dropped. Number of packets that were dropped within the netlink subsystem. Such drops usually happen when the corresponding socket buffer is full; that is, user space is not able to read messages fast enough.

(8)
sequence number. Every queued packet is associated with a (32-bit) monotonically increasing sequence number. This shows the ID of the most recent packet queued.

The last number exists only for compatibility reasons and is always 1.

295 - Linux cli command systemd-user-runtime-dir

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd-user-runtime-dir and provides detailed information about the command systemd-user-runtime-dir, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd-user-runtime-dir.

NAME 🖥️ systemd-user-runtime-dir 🖥️

[email protected], systemd-user-runtime-dir - System units to start the user manager

SYNOPSIS

user@UID.service

user-runtime-dir@UID.service

/usr/lib/systemd/systemd-user-runtime-dir

user-UID.slice

DESCRIPTION

Individual user-UID.slice slices are collected under user.slice, see systemd.special(7).

CONTROLLING RESOURCES FOR LOGGED-IN USERS

In general any resources that apply to units may be set for user@UID.service and the slice units discussed above, see systemd.resource-control(5) for an overview.

EXAMPLES

Example 1. Hierarchy of control groups with two logged in users

$ systemd-cgls Control group /: -.slice ├─user.slice │ ├─user-1000.slice │ │ ├─[email protected] │ │ │ ├─pulseaudio.service │ │ │ │ └─2386 /usr/bin/pulseaudio –daemonize=no │ │ │ └─gnome-terminal-server.service │ │ │ └─init.scope │ │ │ ├─ 4127 /usr/libexec/gnome-terminal-server │ │ │ └─ 4198 zsh │ │ … │ │ └─session-4.scope │ │ ├─ 1264 gdm-session-worker [pam/gdm-password] │ │ ├─ 2339 /usr/bin/gnome-shell │ │ … │ │ ├─session-19.scope │ │ ├─6497 sshd: zbyszek [priv] │ │ ├─6502 sshd: zbyszek@pts/6 │ │ ├─6509 -zsh │ │ └─6602 systemd-cgls –no-pager │ … │ └─user-1001.slice │ ├─session-20.scope │ │ ├─6675 sshd: guest [priv] │ │ ├─6708 sshd: guest@pts/6 │ │ └─6717 -bash │ └─[email protected] │ ├─init.scope │ │ ├─6680 /usr/lib/systemd/systemd –user │ │ └─6688 (sd-pam) │ └─sleep.service │ └─6706 /usr/bin/sleep 30 …

Example 2. Default user resource limits

$ systemctl cat user-1000.slice # /usr/lib/systemd/system/user-.slice.d/10-defaults.conf # … [Unit] Description=User Slice of UID %j After=systemd-user-sessions.service
[Slice]
TasksMax=33%

296 - Linux cli command protocols

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command protocols and provides detailed information about the command protocols, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the protocols.

NAME 🖥️ protocols 🖥️

protocols definition file

DESCRIPTION

This file is a plain ASCII file, describing the various DARPA internet protocols that are available from the TCP/IP subsystem. It should be consulted instead of using the numbers in the ARPA include files, or, even worse, just guessing them. These numbers will occur in the protocol field of any IP header.

Keep this file untouched since changes would result in incorrect IP packages. Protocol numbers and names are specified by the IANA (Internet Assigned Numbers Authority).

Each line is of the following format:

protocol number aliases . . .

where the fields are delimited by spaces or tabs. Empty lines are ignored. If a line contains a hash mark (#), the hash mark and the part of the line following it are ignored.

The field descriptions are:

protocol
the native name for the protocol. For example ip, tcp, or udp.

number
the official number for this protocol as it will appear within the IP header.

aliases
optional aliases for the protocol.

This file might be distributed over a network using a network-wide naming service like Yellow Pages/NIS or BIND/Hesiod.

FILES

/etc/protocols
The protocols definition file.

297 - Linux cli command subgid

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command subgid and provides detailed information about the command subgid, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the subgid.

NAME 🖥️ subgid 🖥️

the configuration for subordinate group ids

DESCRIPTION

Subgid authorizes a group id to map ranges of group ids from its namespace into child namespaces.

The delegation of the subordinate gids can be configured via the subid field in /etc/nsswitch.conf file. Only one value can be set as the delegation source. Setting this field to files configures the delegation of gids to /etc/subgid. Setting any other value treats the delegation as a plugin following with a name of the form libsubid_$value.so. If the value or plugin is missing, then the subordinate gid delegation falls back to files.

Note, that groupadd will only create entries in /etc/subgid if subid delegation is managed via subid files.

LOCAL SUBORDINATE DELEGATION

Each line in /etc/subgid contains a user name and a range of subordinate group ids that user is allowed to use. This is specified with three fields delimited by colons (“:”). These fields are:

·
login name or UID

·
numerical subordinate group ID

·
numerical subordinate group ID count

This file specifies the group IDs that ordinary users can use, with the newgidmap command, to configure gid mapping in a user namespace.

Multiple ranges may be specified per user.

When large number of entries (10000-100000 or more) are defined in /etc/subgid, parsing performance penalty will become noticeable. In this case it is recommended to use UIDs instead of login names. Benchmarks have shown speed-ups up to 20x.

FILES

/etc/subgid

Per user subordinate group IDs.

/etc/subgid-

Backup file for /etc/subgid.

298 - Linux cli command nanorc

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command nanorc and provides detailed information about the command nanorc, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the nanorc.

NAME 🖥️ nanorc 🖥️

GNU nano’s configuration file

DESCRIPTION

The nanorc files contain the default settings for nano, a small and friendly text editor. During startup, if –rcfile is not given, nano reads two files: first the system-wide settings, from /etc/nanorc (the exact path might be different on your system), and then the user-specific settings, either from ~/.nanorc or from $XDG_CONFIG_HOME/nano/nanorc or from ~/.config/nano/nanorc, whichever is encountered first. If –rcfile is given, nano reads just the specified settings file.

NOTICE

Since version 8.0, to be newcomer friendly, ^F starts a forward search, ^B starts a backward search, M-F searches the next occurrence forward, and M-B searches the next occurrence backward. If you want those keystrokes to do what they did before version 8.0, add the following lines at the end of your nanorc file:

bind ^F forward main
bind ^B back main
bind M-F formatter main
bind M-B linter main

OPTIONS

The configuration file accepts a series of set and unset commands, which can be used to configure nano on startup without using command-line options. Additionally, there are some commands to define syntax highlighting and to rebind keys – see the two separate sections on those. nano reads one command per line. All commands and keywords should be written in lowercase.

Options in nanorc files take precedence over nano’s defaults, and command-line options override nanorc settings. Also, options that do not take an argument are unset by default. So using the unset command is only needed when wanting to override a setting of the system’s nanorc file in your own nanorc. Options that take an argument cannot be unset.

Quotes inside the characters parameters below should not be escaped. The last double quote on the line will be seen as the closing quote.

The supported commands and arguments are:

set afterends
Make Ctrl+Right and Ctrl+Delete stop at word ends instead of beginnings.

set allow_insecure_backup
When backing up files, allow the backup to succeed even if its permissions can’t be (re)set due to special OS considerations. You should NOT enable this option unless you are sure you need it.

set atblanks
When soft line wrapping is enabled, make it wrap lines at blank characters (tabs and spaces) instead of always at the edge of the screen.

set autoindent
Automatically indent a newly created line to the same number of tabs and/or spaces as the previous line (or as the next line if the previous line is the beginning of a paragraph).

set backup
When saving a file, create a backup file by adding a tilde (~) to the file’s name.

set backupdir directory
Make and keep not just one backup file, but make and keep a uniquely numbered one every time a file is saved – when backups are enabled with set backup or –backup or -B. The uniquely numbered files are stored in the specified directory.

set boldtext
Use bold instead of reverse video for the title bar, status bar, prompt bar, mini bar, key combos, line numbers, and selected text. This can be overridden by setting the options titlecolor, statuscolor, promptcolor, minicolor, keycolor, numbercolor, and/or selectedcolor.

set bookstyle
When justifying, treat any line that starts with whitespace as the beginning of a paragraph (unless auto-indenting is on).

set brackets “characters”""
Set the characters treated as closing brackets when justifying paragraphs. This may not include blank characters. Only closing punctuation (see set punct), optionally followed by the specified closing brackets, can end sentences. The default value is “”’)>]}".

set breaklonglines
Automatically hard-wrap the current line when it becomes overlong.

set casesensitive
Do case-sensitive searches by default.

set colonparsing
When a filename given on the command line ends in a colon plus digits and this filename does not exist, then snip the colon plus digits and understand the digits as a line number. If the trimmed filename does not exist either, then repeat the process and understand the obtained two numbers as line and column number. But if the doubly trimmed filename does not exist either, then forget the trimming and accept the original filename as is. To disable this colon parsing for some file, use +1 or similar before the relevant filename.

set constantshow
Constantly display the cursor position in the status bar. This overrides the option quickblank.

set cutfromcursor
Use cut-from-cursor-to-end-of-line by default, instead of cutting the whole line.

set emptyline
Do not use the line below the title bar, leaving it entirely blank.

set errorcolor [bold,][italic,]fgcolor,bgcolor
Use this color combination for the status bar when an error message is displayed. The default value is bold,white,red. See set titlecolor for valid color names.

set fill number
Set the target width for justifying and automatic hard-wrapping at this number of columns. If the value is 0 or less, wrapping occurs at the width of the screen minus number columns, allowing the wrap point to vary along with the width of the screen if the screen is resized. The default value is -8.

set functioncolor [bold,][italic,]fgcolor,bgcolor
Use this color combination for the concise function descriptions in the two help lines at the bottom of the screen. See set titlecolor for more details.

set guidestripe number
Draw a vertical stripe at the given column, to help judge the width of the text. (The color of the stripe can be changed with set stripecolor.)

set historylog
Save the last hundred search strings and replacement strings and executed commands, so they can be easily reused in later sessions.

set indicator
Display a “scrollbar” on the righthand side of the edit window. It shows the position of the viewport in the buffer and how much of the buffer is covered by the viewport.

set jumpyscrolling
Scroll the buffer contents per half-screen instead of per line.

set keycolor [bold,][italic,]fgcolor,bgcolor
Use this color combination for the shortcut key combos in the two help lines at the bottom of the screen. See set titlecolor for more details.

set linenumbers
Display line numbers to the left of the text area. (Any line with an anchor additionally gets a mark in the margin.)

set locking
Enable vim-style lock-files for when editing files.

set magic
When neither the file’s name nor its first line give a clue, try using libmagic to determine the applicable syntax. (Calling libmagic can be relatively time consuming. It is therefore not done by default.)

set matchbrackets “characters”""
Specify the opening and closing brackets that can be found by bracket searches. This may not include blank characters. The opening set must come before the closing set, and the two sets must be in the same order. The default value is “(<[{)>]}”.

set minibar
Suppress the title bar and instead show information about the current buffer at the bottom of the screen, in the space for the status bar. In this “mini bar” the filename is shown on the left, followed by an asterisk if the buffer has been modified. On the right are displayed the current line and column number, the code of the character under the cursor (in Unicode format: U+xxxx), the same flags as are shown by set stateflags, and a percentage that expresses how far the cursor is into the file (linewise). When a file is loaded or saved, and also when switching between buffers, the number of lines in the buffer is displayed after the filename. This number is cleared upon the next keystroke, or replaced with an [i/n] counter when multiple buffers are open. The line plus column numbers and the character code are displayed only when set constantshow is used, and can be toggled on and off with M-C. The state flags are displayed only when set stateflags is used.

set minicolor [bold,][italic,]fgcolor,bgcolor
Use this color combination for the mini bar. (When this option is not specified, the colors of the title bar are used.) See set titlecolor for more details.

set mouse
Enable mouse support, if available for your system. When enabled, mouse clicks can be used to place the cursor, set the mark (with two clicks), and execute shortcuts. The mouse works in the X Window System, and on the console when gpm is running. Text can still be selected through dragging by holding down the Shift key.

set multibuffer
When reading in a file with ^R, insert it into a new buffer by default.

set noconvert
Don’t convert files from DOS/Mac format.

set nohelp
Don’t display the two help lines at the bottom of the screen.

set nonewlines
Don’t automatically add a newline when a text does not end with one. (This can cause you to save non-POSIX text files.)

set nowrap
Deprecated option since it has become the default setting. When needed, use unset breaklonglines instead.

set numbercolor [bold,][italic,]fgcolor,bgcolor
Use this color combination for line numbers. See set titlecolor for more details.

set operatingdir directory
nano only reads and writes files inside directory and its subdirectories. Also, the current directory is changed to here, so files are inserted from this directory. By default, the operating directory feature is turned off.

set positionlog
Save the cursor position of files between editing sessions. The cursor position is remembered for the 200 most-recently edited files.

set preserve
Preserve the XOFF and XON sequences (^S and ^Q) so that they are caught by the terminal (stopping and resuming the output).

set promptcolor [bold,][italic,]fgcolor,bgcolor
Use this color combination for the prompt bar. (When this option is not specified, the colors of the title bar are used.) See set titlecolor for more details.

set punct “characters”""
Set the characters treated as closing punctuation when justifying paragraphs. This may not include blank characters. Only the specified closing punctuation, optionally followed by closing brackets (see brackets), can end sentences. The default value is “!.?”.

set quickblank
Make status-bar messages disappear after 1 keystroke instead of after 20. Note that option constantshow overrides this. When option minibar or zero is in effect, quickblank makes a message disappear after 0.8 seconds instead of after the default 1.5 seconds.

set quotestr “regex”""
Set the regular expression for matching the quoting part of a line. The default value is “^([ ]*([!#%:;>|}]|//))+”. (Note that ** ** stands for an actual Tab character.) This makes it possible to rejustify blocks of quoted text when composing email, and to rewrap blocks of line comments when writing source code.

set rawsequences
Interpret escape sequences directly, instead of asking ncurses to translate them. (If you need this option to get some keys to work properly, it means that the terminfo terminal description that is used does not fully match the actual behavior of your terminal. This can happen when you ssh into a BSD machine, for example.) Using this option disables nano’s mouse support.

set rebinddelete
Interpret the Delete and Backspace keys differently so that both Backspace and Delete work properly. You should only use this option when on your system either Backspace acts like Delete or Delete acts like Backspace.

set regexp
Do regular-expression searches by default. Regular expressions in nano are of the extended type (ERE).

set saveonexit
Save a changed buffer automatically on exit (^X); don’t prompt.

set scrollercolor fgcolor,bgcolor
Use this color combination for the indicator alias “scrollbar”. See set titlecolor for more details.

set selectedcolor [bold,][italic,]fgcolor,bgcolor
Use this color combination for selected text. See set titlecolor for more details.

set showcursor
Put the cursor on the highlighted item in the file browser, and show the cursor in the help viewer, to aid braille users and people with poor vision.

set smarthome
Make the Home key smarter. When Home is pressed anywhere but at the very beginning of non-whitespace characters on a line, the cursor jumps to that beginning (either forwards or backwards). If the cursor is already at that position, it jumps to the true beginning of the line.

set softwrap
Display lines that exceed the screen’s width over multiple screen lines. (You can make this soft-wrapping occur at whitespace instead of rudely at the screen’s edge, by using also set atblanks.)

set speller “program [argument …]”****
Use the given program to do spell checking and correcting, instead of using the built-in corrector that calls hunspell(1) or spell(1).

set spotlightcolor [bold,][italic,]fgcolor,bgcolor
Use this color combination for highlighting a search match. The default value is black,lightyellow. See set titlecolor for valid color names.

set stateflags
Use the top-right corner of the screen for showing some state flags: I when auto-indenting, M when the mark is on, L when hard-wrapping (breaking long lines), R when recording a macro, and S when soft-wrapping. When the buffer is modified, a star (*) is shown after the filename in the center of the title bar.

set statuscolor [bold,][italic,]fgcolor,bgcolor
Use this color combination for the status bar. See set titlecolor for more details.

set stripecolor [bold,][italic,]fgcolor,bgcolor
Use this color combination for the vertical guiding stripe. See set titlecolor for more details.

set tabsize number
Use a tab size of number columns. The value of number must be greater than 0. The default value is 8.

set tabstospaces
Convert each typed tab to spaces – to the number of spaces that a tab at that position would take up. (Note: pasted tabs are not converted.)

set titlecolor [bold,][italic,]fgcolor,bgcolor
Use this color combination for the title bar. Valid names for the foreground and background colors are: red, green, blue, magenta, yellow, cyan, white, and black. Each of these eight names may be prefixed with the word light to get a brighter version of that color. The word grey or gray may be used as a synonym for lightblack. On a Linux console, light does not have any effect for a background color. On terminal emulators that can do at least 256 colors, other valid (but unprefixable) color names are: pink, purple, mauve, lagoon, mint, lime, peach, orange, latte, rosy, beet, plum, sea, sky, slate, teal, sage, brown, ocher, sand, tawny, brick, crimson, and normal – where normal means the default foreground or background color. On such emulators, the color may also be specified as a three-digit hexadecimal number prefixed with #, with the digits representing the amounts of red, green, and blue, respectively. This tells nano to select from the available palette the color that approximates the given values.

Either “fgcolor” or “**,**bgcolor” may be left out, and the pair may be preceded by bold and/or italic (separated by commas) to get a bold and/or slanting typeface, if your terminal can do those.

set trimblanks
Remove trailing whitespace from wrapped lines when automatic hard-wrapping occurs or when text is justified.

set unix
Save a file by default in Unix format. This overrides nano’s default behavior of saving a file in the format that it had. (This option has no effect when you also use set noconvert.)

set whitespace “characters”""
Set the two characters used to indicate the presence of tabs and spaces. They must be single-column characters. The default pair for a UTF-8 locale is “»⋅”, and for other locales “>.”.

set wordbounds
Detect word boundaries differently by treating punctuation characters as parts of words.

set wordchars “characters”""
Specify which other characters (besides the normal alphanumeric ones) should be considered as parts of words. When using this option, you probably want to unset wordbounds.

set zap
Let an unmodified Backspace or Delete erase the marked region (instead of a single character, and without affecting the cutbuffer).

set zero
Hide all elements of the interface (title bar, status bar, and help lines) and use all rows of the terminal for showing the contents of the buffer. The status bar appears only when there is a significant message, and disappears after 1.5 seconds or upon the next keystroke. With M-Z the title bar plus status bar can be toggled. With M-X the help lines.

SYNTAX HIGHLIGHTING

Coloring the different syntactic elements of a file is done via regular expressions (see the color command below). This is inherently imperfect, because regular expressions are not powerful enough to fully parse a file. Nevertheless, regular expressions can do a lot and are easy to make, so they are a good fit for a small editor like nano.

All regular expressions in nano are POSIX extended regular expressions. This means that ., ?, *, +, ^, $, and several other characters are special. The period . matches any single character, ? means the preceding item is optional, * means the preceding item may be matched zero or more times, + means the preceding item must be matched one or more times, ^ matches the beginning of a line, and $ the end, ** matches the start of a word, and ** the end, and \s matches a blank. It also means that lookahead and lookbehind are not possible. A complete explanation can be found in the manual page of GNU grep: man grep.

Each regular expression in a nanorc file should be wrapped in double quotes (""). Multiple regular expressions can follow each other on a line by separating them with blanks. This means that a regular expression cannot contain a double quote followed by a blank. When you need this combination inside a regular expression, then either the double quote or the blank should be put between square brackets ([]).

For each kind of file a separate syntax can be defined via the following commands:

syntax* name [***"fileregex" **…]
Start the definition of a syntax with this name. All subsequent color and other such commands are added to this syntax, until a new syntax command is encountered.

When nano is run, this syntax is automatically activated (for the relevant buffer) if the absolute filename matches the extended regular expression fileregex. Or the syntax can be explicitly activated (for all buffers) by using the -Y or –syntax command-line option followed by the name.

The syntax default is special: it takes no fileregex, and applies to files that don’t match any syntax’s regexes. The syntax none is reserved; specifying it on the command line is the same as not having a syntax at all.

header “regex”""…
If from all defined syntaxes no fileregex matched, then compare this regex (or regexes) against the first line of the current file, to determine whether this syntax should be used for it.

magic “regex”""…
If no fileregex matched and no header regex matched either, then compare this regex (or regexes) against the result of querying the magic database about the current file, to determine whether this syntax should be used for it. (This querying is done only when libmagic is actually installed on the system and –magic or set magic was given.)

formatter* program ***[***argument *…]
Run the given program on the full contents of the current buffer.

linter* program ***[***argument *…]
Use the given program to run a syntax check on the current buffer.

comment “string”""
Use the given string for commenting and uncommenting lines. If the string contains a vertical bar or pipe character (|), this designates bracket-style comments; for example, “/*|*/” for CSS files. The characters before the pipe are prepended to the line and the characters after the pipe are appended at the end of the line. If no pipe character is present, the full string is prepended; for example, “#” for Python files. If empty double quotes are specified, the comment/uncomment function is disabled; for example, "" for JSON. The default value is “#”.

tabgives “string”""
Make the <Tab> key produce the given string. Useful for languages like Python that want to see only spaces for indentation. This overrides the setting of the tabstospaces option.

**color [bold,][italic,]fgcolor,bgcolor “regex” **…
Paint all pieces of text that match the extended regular expression regex with the given foreground and background colors, at least one of which must be specified. Valid color names are: red, green, blue, magenta, yellow, cyan, white, and black. Each of these eight names may be prefixed with the word light to get a brighter version of that color. The word grey or gray may be used as a synonym for lightblack. On a Linux console, light does not have any effect for a background color. On terminal emulators that can do at least 256 colors, other valid (but unprefixable) color names are: pink, purple, mauve, lagoon, mint, lime, peach, orange, latte, rosy, beet, plum, sea, sky, slate, teal, sage, brown, ocher, sand, tawny, brick, crimson, and normal – where normal means the default foreground or background color. On such emulators, the color may also be specified as a three-digit hexadecimal number prefixed with #, with the digits representing the amounts of red, green, and blue, respectively. This tells nano to select from the available palette the color that approximates the given values.

The color pair may be preceded by bold and/or italic (separated by commas) to get a bold and/or slanting typeface, if your terminal can do those.

All coloring commands are applied in the order in which they are specified, which means that later commands can recolor stuff that was colored earlier.

**icolor [bold,][italic,]fgcolor,bgcolor “regex” **…
Same as above, except that the matching is case insensitive.

color [bold,][italic,]fgcolor,bgcolor start="fromrx" end="torx"""
Paint all pieces of text whose start matches extended regular expression fromrx and whose end matches extended regular expression torx with the given foreground and background colors, at least one of which must be specified. This means that, after an initial instance of fromrx, all text until the first instance of torx is colored. This allows syntax highlighting to span multiple lines.

icolor [bold,][italic,]fgcolor,bgcolor start="fromrx" end="torx"""
Same as above, except that the matching is case insensitive.

include “syntaxfile”""
Read in self-contained color syntaxes from syntaxfile. Note that syntaxfile may contain only the above commands, from syntax to icolor.

extendsyntax* name command argument *…
Extend the syntax previously defined as name with another command. This allows adding a new color, icolor, header, magic, formatter, linter, comment, or tabgives command to an already defined syntax – useful when you want to slightly improve a syntax defined in one of the system-installed files (which normally are not writable).

REBINDING KEYS

Key bindings can be changed via the following three commands:

bind* key function menu*
Rebinds the given key to the given function in the given menu (or in all menus where the function exists when all is used).
bind* key "string" menu*
Makes the given key produce the given string in the given menu (or in all menus where the key exists when all is used). Besides literal text and/or control codes, the string may contain function names between braces. These functions are invoked when the key is typed. To include a literal opening brace, use {{}.
unbind* key menu*
Unbinds the given key from the given menu (or from all menus where the key exists when all is used).

Note that bind key "{function}" menu is equivalent to bind key function menu, except that for the latter form nano checks the availability of the function in the given menu at startup time (and report an error if it does not exist there), whereas for the first form nano checks at execution time that the function exists but not whether it makes any sense in the current menu. The user has to take care that a function name between braces (or any sequence of them) is appropriate. Strange behavior can result when it is not.

The format of key should be one of:

**^**X
where X is a Latin letter, or one of several ASCII characters (@, ], \ ^, _), or the word “Space”. Example: ^C.
**M-**X
where X is any ASCII character except [, or the word “Space”. Example: M-8.
**Sh-M-**X
where X is a Latin letter. Example: Sh-M-U. By default, each Meta+letter keystroke does the same as the corresponding Shift+Meta+letter. But when any Shift+Meta bind is made, that will no longer be the case, for all letters.
FN
where N is a numeric value from 1 to 24. Example: F10. (Often, F13 to F24 can be typed as F1 to F12 with Shift.)
Ins or Del.
Rebinding ^M (Enter) or ^I (Tab) is probably not a good idea. Rebinding ^[ (Esc) is not possible, because its keycode is the starter byte of Meta keystrokes and escape sequences. Rebinding any of the dedicated cursor-moving keys (the arrows, Home, End, PageUp and PageDown) is not possible. On some terminals it’s not possible to rebind ^H (unless –raw is used) because its keycode is identical to that of the Backspace key.
Valid function names to be bound are:
help
Invokes the help viewer.
cancel
Cancels the current command.
exit
Exits from the program (or from the help viewer or file browser).
writeout
Writes the current buffer to disk, asking for a name.
savefile
Writes the current file to disk without prompting.
insert
Inserts a file into the current buffer (at the current cursor position), or into a new buffer when option multibuffer is set.
whereis
Starts a forward search for text in the current buffer – or for filenames matching a string in the current list in the file browser.
wherewas
Starts a backward search for text in the current buffer – or for filenames matching a string in the current list in the file browser.
findprevious
Searches the next occurrence in the backward direction.
findnext
Searches the next occurrence in the forward direction.
replace
Interactively replaces text within the current buffer.
cut
Cuts and stores the current line (or the marked region).
copy
Copies the current line (or the marked region) without deleting it.
paste
Pastes the currently stored text into the current buffer at the current cursor position.
zap
Throws away the current line (or the marked region). (This function is bound by default to <Meta+Delete>.)
chopwordleft
Deletes from the cursor position to the beginning of the preceding word. (This function is bound by default to <Shift+Ctrl+Delete>. If your terminal produces ^H for <Ctrl+Backspace>, you can make <Ctrl+Backspace> delete the word to the left of the cursor by rebinding ^H to this function.)
chopwordright
Deletes from the cursor position to the beginning of the next word. (This function is bound by default to <Ctrl+Delete>.)
cutrestoffile
Cuts all text from the cursor position till the end of the buffer.
mark
Sets the mark at the current position, to start selecting text. Or, when it is set, unsets the mark.
location
Reports the current position of the cursor in the buffer: the line, column, and character positions.
wordcount
Counts and reports on the status bar the number of lines, words, and characters in the current buffer (or in the marked region).
execute
Prompts for a program to execute. The program’s output is inserted into the current buffer (or into a new buffer when M-F is toggled).
speller
Invokes a spell-checking program, either the default hunspell(1) or GNU spell(1), or the one defined by –speller or set speller.
formatter
Invokes a full-buffer-processing program (if the active syntax defines one). (The current buffer is written out to a temporary file, the program is run on it, and then the temporary file is read back in, replacing the contents of the buffer.)
linter
Invokes a syntax-checking program (if the active syntax defines one). If this program produces lines of the form “filename:linenum:charnum: some message”, then the cursor is put at the indicated position in the mentioned file while showing “some message” on the status bar. You can move from message to message with <PgUp> and <PgDn>, and leave linting mode with ^C or <Enter>.
justify
Justifies the current paragraph (or the marked region). A paragraph is a group of contiguous lines that, apart from possibly the first line, all have the same indentation. The beginning of a paragraph is detected by either this lone line with a differing indentation or by a preceding blank line.
fulljustify
Justifies the entire current buffer (or the marked region).
indent
Indents (shifts to the right) the current line or the marked lines.
unindent
Unindents (shifts to the left) the current line or the marked lines.
comment
Comments or uncomments the current line or the marked lines, using the comment style specified in the active syntax.
complete
Completes (when possible) the fragment before the cursor to a full word found elsewhere in the current buffer.
left
Goes left one position (in the editor or browser).
right
Goes right one position (in the editor or browser).
up
Goes one line up (in the editor or browser).
down
Goes one line down (in the editor or browser).
scrollup
Scrolls the viewport up one row (meaning that the text slides down) while keeping the cursor in the same text position, if possible. (This function is bound by default to <Alt+Up>. If <Alt+Up> does nothing on your Linux console, see the FAQ: .)
scrolldown
Scrolls the viewport down one row (meaning that the text slides up) while keeping the cursor in the same text position, if possible. (This function is bound by default to <Alt+Down>.)
center
Scrolls the line with the cursor to the middle of the viewport.
cycle
Scrolls the line with the cursor first to the middle of the viewport, then to the top, then to the bottom.
prevword
Moves the cursor to the beginning of the previous word.
nextword
Moves the cursor to the beginning of the next word.
home
Moves the cursor to the beginning of the current line.
end
Moves the cursor to the end of the current line.
beginpara
Moves the cursor to the beginning of the current paragraph.
endpara
Moves the cursor to the end of the current paragraph.
prevblock
Moves the cursor to the beginning of the current or preceding block of text. (Blocks are separated by one or more blank lines.)
nextblock
Moves the cursor to the beginning of the next block of text.
toprow
Moves the cursor to the first row in the viewport.
bottomrow
Moves the cursor to the last row in the viewport.
pageup
Goes up one screenful.
pagedown
Goes down one screenful.
firstline
Goes to the first line of the file.
lastline
Goes to the last line of the file.
gotoline
Goes to a specific line (and column if specified). Negative numbers count from the end of the file (and end of the line).
findbracket
Moves the cursor to the bracket (or brace or parenthesis, etc.) that matches (pairs) with the one under the cursor. See set matchbrackets.
anchor
Places an anchor at the current line, or removes it when already present. (An anchor is visible when line numbers are activated.)
prevanchor
Goes to the first anchor before the current line.
nextanchor
Goes to the first anchor after the current line.
prevbuf
Switches to editing/viewing the previous buffer when multiple buffers are open.
nextbuf
Switches to editing/viewing the next buffer when multiple buffers are open.
verbatim
Inserts the next keystroke verbatim into the file, or begins Unicode input when a hexadecimal digit is typed.
tab
Inserts a tab at the current cursor location.
enter
Inserts a new line below the current one.
delete
Deletes the character under the cursor.
backspace
Deletes the character before the cursor.
recordmacro
Starts the recording of keystrokes – the keystrokes are stored as a macro. When already recording, the recording is stopped.
runmacro
Replays the keystrokes of the last recorded macro.
undo
Undoes the last performed text action (add text, delete text, etc).
redo
Redoes the last undone action (i.e., it undoes an undo).
refresh
Refreshes the screen.
suspend
Suspends the editor and returns control to the shell (until you tell the process to resume execution with fg).
casesens
Toggles whether searching/replacing ignores or respects the case of the given characters.
regexp
Toggles whether searching/replacing uses literal strings or regular expressions.
backwards
Toggles whether searching/replacing goes forward or backward.
older
Retrieves the previous (earlier) entry at a prompt.
newer
Retrieves the next (later) entry at a prompt.
flipreplace
Toggles between searching for something and replacing something.
flipgoto
Toggles between searching for text and targeting a line number.
flipexecute
Switches from inserting a file to executing a command.
flippipe
When executing a command, toggles whether the current buffer (or marked region) is piped to the command.
flipnewbuffer
Toggles between inserting into the current buffer and into a new empty buffer.
flipconvert
When reading in a file, toggles between converting and not converting it from DOS/Mac format. Converting is the default.
dosformat
When writing a file, switches to writing a DOS format (CR/LF).
macformat
When writing a file, switches to writing a Mac format.
append
When writing a file, appends to the end instead of overwriting.
prepend
When writing a file, ‘prepends’ (writes at the beginning) instead of overwriting.
backup
When writing a file, creates a backup of the current file.
discardbuffer
When about to write a file, discard the current buffer without saving. (This function is bound by default only when option –saveonexit is in effect.)
browser
Starts the file browser (in the Read File and Write Out menus), allowing to select a file from a list.
gotodir
Goes to a directory to be specified, allowing to browse anywhere in the filesystem.
firstfile
Goes to the first file in the list when using the file browser.
lastfile
Goes to the last file in the list when using the file browser.
nohelp
Toggles the presence of the two-line list of key bindings at the bottom of the screen. (This toggle is special: it is available in all menus except the help viewer and the linter. All further toggles are available in the main menu only.)
zero
Toggles the presence of title bar and status bar.
constantshow
Toggles the constant display of the current line, column, and character positions.
softwrap
Toggles the displaying of overlong lines on multiple screen lines.
linenumbers
Toggles the display of line numbers in front of the text.
whitespacedisplay
Toggles the showing of whitespace.
nosyntax
Toggles syntax highlighting.
smarthome
Toggles the smartness of the Home key.
autoindent
Toggles whether a newly created line will contain the same amount of leading whitespace as the preceding line – or as the next line if the preceding line is the beginning of a paragraph.
cutfromcursor
Toggles whether cutting text cuts the whole line or just from the current cursor position to the end of the line.
breaklonglines
Toggles whether the overlong part of a line is hard-wrapped to the next line.
tabstospaces
Toggles whether typed tabs are converted to spaces.
mouse
Toggles mouse support.
Valid menu sections are:
main
The main editor window where text is entered and edited.
help
The help-viewer menu.
search
The search menu (AKA whereis).
replace
The ‘search to replace’ menu.
replacewith
The ‘replace with’ menu, which comes up after ‘search to replace’.
yesno
The ‘yesno’ menu, where the Yes/No/All/Cancel question is asked.
gotoline
The ‘goto line (and column)’ menu.
writeout
The ‘write file’ menu.
insert
The ‘insert file’ menu.
browser
The ‘file browser’ menu, for selecting a file to be opened or inserted or written to.
whereisfile
The ‘search for a file’ menu in the file browser.
gotodir
The ‘go to directory’ menu in the file browser.
execute
The menu for inserting the output from an external command, or for filtering the buffer (or the marked region) through an external command, or for executing one of several tools.
spell
The menu of the integrated spell checker where the user can edit a misspelled word.
linter
The linter menu, which allows jumping through the linting messages.
all
A special name that encompasses all menus. For bind it means all menus where the specified function exists; for unbind it means all menus where the specified key exists.

EXAMPLES

To make Ctrl+Z suspend nano:

bind ^Z suspend main

To make Shift+Alt+C copy the marked region to the system’s clipboard:

bind Sh-M-C “{execute}| xsel -ib {enter}{undo}” main

FILES

/etc/nanorc
System-wide configuration file.

~/.nanorc or $XDG_CONFIG_HOME/nano/nanorc or ~/.config/nano/nanorc
Per-user configuration file.

/usr/share/nano/*
Syntax definitions for the syntax coloring of common file types (and for less common file types in the extra/ subdirectory).

299 - Linux cli command crypt

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command crypt and provides detailed information about the command crypt, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the crypt.

The hashing methods implemented by

are designed only to process user passphrases for storage and authentication; they are not suitable for use as general-purpose cryptographic hashes.

Passphrase hashing is not a replacement for strong passphrases. It is always possible for an attacker with access to the hashed passphrases to guess and check possible cleartext passphrases. However, with a strong hashing method, guessing will be too slow for the attacker to discover a strong passphrase.

All of the hashing methods use a

to perturb the hash function, so that the same passphrase may produce many possible hashes. Newer methods accept longer salt strings. The salt should be chosen at random for each user. Salt defeats a number of attacks:

It is not possible to hash a passphrase once and then test it against each account’s stored hash; the hash calculation must be repeated for each account.

It is not possible to tell whether two accounts use the same passphrase without successfully guessing one of the phrases.

Tables of precalculated hashes of commonly used passphrases must have an entry for each possible salt, which makes them impractically large.

All of the hashing methods are also deliberately engineered to be slow; they use many iterations of an underlying cryptographic primitive to increase the cost of each guess. The newer hashing methods allow the number of iterations to be adjusted, using the

parameter to

This makes it possible to keep the hash slow as hardware improves.

All of the hashing methods supported by

produce a hashed passphrase which consists of four components:

and

The prefix controls which hashing method is to be used, and is the appropriate string to pass to

to select that method. The contents of

and

are up to the method. Depending on the method, the

and

components may be empty.

The

argument to

must begin with the first three components of a valid hashed passphrase, but anything after that is ignored. This makes authentication simple: hash the input passphrase using the stored passphrase as the setting, and then compare the result to the stored passphrase.

Hashed passphrases are always entirely printable ASCII, and do not contain any whitespace or the characters

(These characters are used as delimiters and special markers in the

and

files.)

The syntax of each component of a hashed passphrase is up to the hashing method.

characters usually delimit components, and the salt and hash are usually encoded as numerals in base 64. The details of this base-64 encoding vary among hashing methods. The common

encoding specified by RFC 4648 is usually

used.

This is a list of

the hashing methods supported by

in decreasing order of strength. Many of the older methods are now considered too weak to use for new passphrases. The hashed passphrase format is expressed with extended regular expressions (see

and does not show the division into prefix, options, salt, and hash.

yescrypt is a scalable passphrase hashing scheme designed by Solar Designer, which is based on Colin Percival’s scrypt. Recommended for new hashes.

“$y$”

\y\[./A-Za-z0-9]+\[./A-Za-z0-9]{,86}\[./A-Za-z0-9]{43}

256 bits

up to 512 (128+ recommended) bits

1 to 11 (logarithmic)

gost-yescrypt uses the output from the yescrypt hashing method in place of a hmac message. Thus, the yescrypt crypto properties are superseded by the GOST R 34.11-2012 (Streebog) hash function with a 256 bit digest. This hashing method is useful in applications that need modern passphrase hashing methods, but require to rely on the cryptographic properties of GOST algorithms. The GOST R 34.11-2012 (Streebog) hash function has been published by the IETF as RFC 6986. Recommended for new hashes.

“$gy$”

\gy\[./A-Za-z0-9]+\[./A-Za-z0-9]{,86}\[./A-Za-z0-9]{43}

256 bits

up to 512 (128+ recommended) bits

1 to 11 (logarithmic)

scrypt is a password-based key derivation function created by Colin Percival, originally for the Tarsnap online backup service. The algorithm was specifically designed to make it costly to perform large-scale custom hardware attacks by requiring large amounts of memory. In 2016, the scrypt algorithm was published by IETF as RFC 7914.

“$7$”

\7\[./A-Za-z0-9]{11,97}\[./A-Za-z0-9]{43}

256 bits

up to 512 (128+ recommended) bits

6 to 11 (logarithmic)

A hash based on the Blowfish block cipher, modified to have an extra-expensive key schedule. Originally developed by Niels Provos and David Mazieres for OpenBSD and also supported on recent versions of FreeBSD and NetBSD, on Solaris 10 and newer, and on several GNU/*/Linux distributions.

“$2b$”

\2[abxy]\[0-9]{2}\[./A-Za-z0-9]{53}

184 bits

128 bits

4 to 31 (logarithmic)

The alternative prefix “$2y$” is equivalent to “$2b$”. It exists for historical reasons only. The alternative prefixes “$2a$” and “$2x$” provide bug-compatibility with crypt_blowfish 1.0.4 and earlier, which incorrectly processed characters with the 8th bit set.

A hash based on SHA-2 with 512-bit output, originally developed by Ulrich Drepper for GNU libc. Supported on Linux but not common elsewhere. Acceptable for new hashes. The default CPU time cost parameter is 5000, which is too low for modern hardware.

“$6$”

\6(rounds=[1-9][0-9]+)?[^$: ]{1,16}\[./0-9A-Za-z]{86}

512 bits

6 to 96 bits

1000 to 999,999,999

A hash based on SHA-2 with 256-bit output, originally developed by Ulrich Drepper for GNU libc. Supported on Linux but not common elsewhere. Acceptable for new hashes. The default CPU time cost parameter is 5000, which is too low for modern hardware.

“$5$”

\5(rounds=[1-9][0-9]+)?[^$: ]{1,16}\[./0-9A-Za-z]{43}

256 bits

6 to 96 bits

1000 to 999,999,999

A hash based on HMAC-SHA1. Originally developed by Simon Gerraty for NetBSD. Not as weak as the DES-based hashes below, but SHA1 is so cheap on modern hardware that it should not be used for new hashes.

“$sha1”

\sha1\[1-9][0-9]+\[./0-9A-Za-z]{1,64}\[./0-9A-Za-z]{8,64}[./0-9A-Za-z]{32}

160 bits

6 to 384 bits

4 to 4,294,967,295

A hash based on the MD5 algorithm, with additional cleverness to make precomputation difficult, originally developed by Alec David Muffet for Solaris. Not adopted elsewhere, to our knowledge. Not as weak as the DES-based hashes below, but MD5 is so cheap on modern hardware that it should not be used for new hashes.

“$md5”

\md5(,rounds=[1-9][0-9]+)?\[./0-9A-Za-z]{8}{1,2}[./0-9A-Za-z]{22}

128 bits

48 bits

4096 to 4,294,963,199

A hash based on the MD5 algorithm, originally developed by Poul-Henning Kamp for FreeBSD. Supported on most free Unixes and newer versions of Solaris. Not as weak as the DES-based hashes below, but MD5 is so cheap on modern hardware that it should not be used for new hashes. CPU time cost is not adjustable.

“$1$”

\1\[^$: ]{1,8}\[./0-9A-Za-z]{22}

128 bits

6 to 48 bits

1000

A weak extension of traditional DES, which eliminates the length limit, increases the salt size, and makes the time cost tunable. It originates with BSDI and is also available on at least NetBSD, OpenBSD, and FreeBSD due to the use of David Burren’s FreeSec library. It is better than bigcrypt and traditional DES, but still should not be used for new hashes.

“_”

_[./0-9A-Za-z]{19}

64 bits

24 bits

1 to 16,777,215 (must be odd)

A weak extension of traditional DES, available on some System V-derived Unixes. All it does is raise the length limit from 8 to 128 characters, and it does this in a crude way that allows attackers to guess chunks of a long passphrase in parallel. It should not be used for new hashes.

[./0-9A-Za-z]{13,178}

up to 1024 bits

12 bits

The original hashing method from Unix V7, based on the DES block cipher. Because DES is cheap on modern hardware, because there are only 4096 possible salts and 2**56 possible hashes, and because it truncates passphrases to 8 characters, it is feasible to discover

passphrase hashed with this method. It should only be used if you absolutely have to generate hashes that will work on an old operating system that supports nothing else.

[./0-9A-Za-z]{13}

64 bits

12 bits

The hashing method used for network authentication in some versions of the SMB/CIFS protocol. Available, for cross-compatibility’s sake, on FreeBSD. Based on MD4. Has no salt or tunable cost parameter. Like traditional DES, it is so weak that

passphrase hashed with this method is guessable. It should only be used if you absolutely have to generate hashes that will work on an old operating system that supports nothing else.

“$3$”

\3\[0-9a-f]{32}

256 bits

0 bits

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

300 - Linux cli command proc_loadavg

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_loadavg and provides detailed information about the command proc_loadavg, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_loadavg.

NAME 🖥️ proc_loadavg 🖥️

load average

DESCRIPTION

/proc/loadavg
The first three fields in this file are load average figures giving the number of jobs in the run queue (state R) or waiting for disk I/O (state D) averaged over 1, 5, and 15 minutes. They are the same as the load average numbers given by uptime(1) and other programs. The fourth field consists of two numbers separated by a slash (/). The first of these is the number of currently runnable kernel scheduling entities (processes, threads). The value after the slash is the number of kernel scheduling entities that currently exist on the system. The fifth field is the PID of the process that was most recently created on the system.

301 - Linux cli command exim4_local_sender_blacklist

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command exim4_local_sender_blacklist and provides detailed information about the command exim4_local_sender_blacklist, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the exim4_local_sender_blacklist.

NAME 🖥️ exim4_local_sender_blacklist 🖥️

config_files - Files in use by the Debian exim4 packages

SYNOPSIS

DESCRIPTION

This manual page describes the files that are in use by the Debian exim4 packages and which are not part of an exim installation done from source.

/etc/aliases

You should at least set up an alias for postmaster in the /etc/aliases file.

/etc/email-addresses

is used to rewrite the email addresses of users. This is particularly useful for users who use their ISP’s domain for email.

The file should contain lines of the form

user: [email protected]
otheruser: [email protected]

/etc/exim4/local_host_blacklist

In the blacklist, the trick is to read a line break as “or” if it follows a positive item, and as “and” if it follows a negative item.

For example, a /etc/exim4/local_host_blacklist

192.168.10.0/24
!172.16.10.128/26
172.16.10.0/24
10.0.0.0/8

Exim just evaluates left to right (or up-down in the file listing context), so you don’t get the same kind of operator binding as in a programming language.

/etc/exim4/host_local_deny_exceptions

/etc/exim4/local_sender_blacklist

In the blacklist, the trick is to read a line break as “or” if it follows a positive item, and as “and” if it follows a negative item.

For example, a /etc/exim4/local_sender_blacklist

domain1.example
[email protected]
domain2.example
domain3.example

Exim just evaluates left to right (or up-down in the file listing context), so you don’t get the same kind of operator binding as in a programming language.

/etc/exim4/sender_local_deny_exceptions

/etc/exim4/local_sender_callout

/etc/exim4/local_rcpt_callout

/etc/exim4/local_domain_dnsbl_whitelist

/etc/exim4/hubbed_hosts

The file should contain key-value pairs of domain pattern and route data of the form

domain: host-list options
dict.ref.example: mail-1.ref.example:mail-2.ref.example
foo.example: internal.mail.example.com
bar.example: 192.168.183.3

which will cause mail for foo.example to be sent to the host internal.mail.example (IP address derived from A record only), and mail to bar.example to be sent to 192.168.183.3.

See spec.txt chapter 20.3 through 20.7 for a more detailed explanation of host list format and available options.

/etc/exim4/passwd

contains account and password data for SMTP authentication when the local exim is SMTP server and clients authenticate to the local exim.

The file should contain lines of the form

username:crypted-password:clear-password

clear-password is only necessary if you want to offer CRAM-MD5 authentication. If you don’t plan on doing so, the third column can be omitted completely.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim 640.

/etc/exim4/passwd.client

contains account and password data for SMTP authentication when exim is authenticating as a client to some remote server.

The file should contain lines of the form

target.mail.server.example:login-user-name:password

This goes inevitably wrong if the host name of the mail server is a CNAME (a DNS alias), or the reverse lookup does not fit the forward one.

password is your SMTP password in clear text. If you do not know about your SMTP password, you can try using your POP3 password as a first guess.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim 640.

/etc/exim4/exim.crt

/etc/exim4/exim.key

/etc/mailname

The “mail name” of the system. See Debian policy Chapter Customized programs and exim4-base’s README.Debian for further details.

BUGS

Plenty. Please report them through the Debian BTS

This manual page needs a major re-work. If somebody knows better groff than us and has more experience in writing manual pages, any patches would be greatly appreciated.

NOTES

Unresolvable items in host lists

Adding or keeping items in the abovementioned host lists which are not resolvable by DNS has severe consequences.

notresolvable.example.com:rejectme.example.com

Starting the list with the special pattern +ignore_unknown as a safeguard against this behavior is strongly recommended if hostnames are used in hostlists.

AUTHOR

Marc Haber <[email protected]> with help from Ross Boylan.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

302 - Linux cli command proc_pid_io

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_io and provides detailed information about the command proc_pid_io, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_io.

NAME 🖥️ proc_pid_io 🖥️

I/O statistics

DESCRIPTION

/proc/pid/io (since Linux 2.6.20)
This file contains I/O statistics for the process and its waited-for children, for example:

# cat /proc/3828/io
rchar: 323934931
wchar: 323929600
syscr: 632687
syscw: 632675
read_bytes: 0
write_bytes: 323932160
cancelled_write_bytes: 0

The fields are as follows:

rchar: characters read
The number of bytes returned by successful read(2) and similar system calls.

wchar: characters written
The number of bytes returned by successful write(2) and similar system calls.

syscr: read syscalls
The number of “file read” system calls—those from the read(2) family, sendfile(2), copy_file_range(2), and ioctl(2) BTRFS_IOC_ENCODED_READ[_32] (including when invoked by the kernel as part of other syscalls).

syscw: write syscalls
The number of “file write” system calls—those from the write(2) family, sendfile(2), copy_file_range(2), and ioctl(2) BTRFS_IOC_ENCODED_WRITE[_32] (including when invoked by the kernel as part of other syscalls).

read_bytes: bytes read
The number of bytes really fetched from the storage layer. This is accurate for block-backed filesystems.

write_bytes: bytes written
The number of bytes really sent to the storage layer.

cancelled_write_bytes:
The above statistics fail to account for truncation: if a process writes 1 MB to a regular file and then removes it, said 1 MB will not be written, but will have nevertheless been accounted as a 1 MB write. This field represents the number of bytes “saved” from I/O writeback. This can yield to having done negative I/O if caches dirtied by another process are truncated. cancelled_write_bytes applies to I/O already accounted-for in write_bytes.

Permission to access this file is governed by ptrace(2) access mode PTRACE_MODE_READ_FSCREDS.

CAVEATS

These counters are not atomic: on systems where 64-bit integer operations may tear, a counter could be updated simultaneously with a read, yielding an incorrect intermediate value.

303 - Linux cli command systemd.path

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.path and provides detailed information about the command systemd.path, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.path.

NAME 🖥️ systemd.path 🖥️

Path unit configuration

SYNOPSIS

path.path

DESCRIPTION

A unit configuration file whose name ends in “.path” encodes information about a path monitored by systemd, for path-based activation.

This man page lists the configuration options specific to this unit type. See systemd.unit(5) for the common options of all unit configuration files. The common configuration items are configured in the generic [Unit] and [Install] sections. The path specific configuration options are configured in the [Path] section.

For each path file, a matching unit file must exist, describing the unit to activate when the path changes. By default, a service by the same name as the path (except for the suffix) is activated. Example: a path file foo.path activates a matching service foo.service. The unit to activate may be controlled by Unit= (see below).

Internally, path units use the inotify(7) API to monitor file systems. Due to that, it suffers by the same limitations as inotify, and for example cannot be used to monitor files or directories changed by other machines on remote NFS file systems.

When a service unit triggered by a path unit terminates (regardless whether it exited successfully or failed), monitored paths are checked immediately again, and the service accordingly restarted instantly. As protection against busy looping in this trigger/start cycle, a start rate limit is enforced on the service unit, see StartLimitIntervalSec= and StartLimitBurst= in systemd.unit(5). Unlike other service failures, the error condition that the start rate limit is hit is propagated from the service unit to the path unit and causes the path unit to fail as well, thus ending the loop.

AUTOMATIC DEPENDENCIES

Implicit Dependencies

The following dependencies are implicitly added:

·
If a path unit is beneath another mount unit in the file system hierarchy, both a requirement and an ordering dependency between both units are created automatically.

·
An implicit Before= dependency is added between a path unit and the unit it is supposed to activate.

Default Dependencies

The following dependencies are added unless DefaultDependencies=no is set:

·
Path units will automatically have dependencies of type Before= on paths.target, dependencies of type After= and Requires= on sysinit.target, and have dependencies of type Conflicts= and Before= on shutdown.target. These ensure that path units are terminated cleanly prior to system shutdown. Only path units involved with early boot or late system shutdown should disable DefaultDependencies= option.

OPTIONS

Path unit files may include [Unit] and [Install] sections, which are described in systemd.unit(5).

Path unit files must include a [Path] section, which carries information about the path or paths it monitors. The options specific to the [Path] section of path units are the following:

PathExists=, PathExistsGlob=, PathChanged=, PathModified=, DirectoryNotEmpty=

Defines paths to monitor for certain changes: PathExists= may be used to watch the mere existence of a file or directory. If the file specified exists, the configured unit is activated. PathExistsGlob= works similarly, but checks for the existence of at least one file matching the globbing pattern specified. PathChanged= may be used to watch a file or directory and activate the configured unit whenever it changes. It is not activated on every write to the watched file but it is activated if the file which was open for writing gets closed. PathModified= is similar, but additionally it is activated also on simple writes to the watched file. DirectoryNotEmpty= may be used to watch a directory and activate the configured unit whenever it contains at least one file.
The arguments of these directives must be absolute file system paths.
Multiple directives may be combined, of the same and of different types, to watch multiple paths. If the empty string is assigned to any of these options, the list of paths to watch is reset, and any prior assignments of these options will not have any effect.
If a path already exists (in case of PathExists= and PathExistsGlob=) or a directory already is not empty (in case of DirectoryNotEmpty=) at the time the path unit is activated, then the configured unit is immediately activated as well. Something similar does not apply to PathChanged= and PathModified=.
If the path itself or any of the containing directories are not accessible, systemd will watch for permission changes and notice that conditions are satisfied when permissions allow that.

Unit=

The unit to activate when any of the configured paths changes. The argument is a unit name, whose suffix is not “.path”. If not specified, this value defaults to a service that has the same name as the path unit, except for the suffix. (See above.) It is recommended that the unit name that is activated and the unit name of the path unit are named identical, except for the suffix.

MakeDirectory=

Takes a boolean argument. If true, the directories to watch are created before watching. This option is ignored for PathExists= settings. Defaults to false.

DirectoryMode=

If MakeDirectory= is enabled, use the mode specified here to create the directories in question. Takes an access mode in octal notation. Defaults to 0755.

TriggerLimitIntervalSec=, TriggerLimitBurst=

Configures a limit on how often this path unit may be activated within a specific time interval. The TriggerLimitIntervalSec= may be used to configure the length of the time interval in the usual time units “us”, “ms”, “s”, “min”, “h”, … and defaults to 2s. See systemd.time(7) for details on the various time units understood. The TriggerLimitBurst= setting takes a positive integer value and specifies the number of permitted activations per time interval, and defaults to 200. Set either to 0 to disable any form of trigger rate limiting. If the limit is hit, the unit is placed into a failure mode, and will not watch the paths anymore until restarted. Note that this limit is enforced before the service activation is enqueued.
Added in version 250.

Check systemd.unit(5), systemd.exec(5), and systemd.kill(5) for more settings.

304 - Linux cli command pkgconf-personality

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command pkgconf-personality and provides detailed information about the command pkgconf-personality, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the pkgconf-personality.

pkgconf cross-compile personality files provide a useful mechanism for storing various information about system toolchains. Information stored by

files include information about paths used by a cross-compile toolchain, such as the sysroot directory and default include and library paths. pkgconf uses this information to determine what information is necessary to use libraries.

The

There are three types of property:

The property will be set to the text of the value.

The property will be set to true if the value is one of: true, yes or 1. Otherwise it will be set to false.

The triplet used by the cross-compile toolchain. (mandatory; literal)

The directory used by the system root of the cross-compile toolchain. (mandatory; literal)

A list of directories to look for

files in. (mandatory; fragment list)

A list of directories that are included by default in the search path for include files. (mandatory; fragment list)

A list of directories that are included by default in the search path for libraries. (mandatory; fragment list)

If true, pkgconf will default to preferring a pure dependency graph. (optional; boolean; default is false)

If true, pkgconf will default to operating in static linking mode. (optional; boolean; default is false)

An example .personality file:

# This is a comment Triplet: x86_64-pc-linux-gnu SysrootDir: /home/kaniini/sysroot/x86_64-pc-linux-gnu DefaultSearchPaths: /home/kaniini/sysroot/x86_64-pc-linux-gnu/lib/pkgconfig:/home/kaniini/sysroot/x86_64-pc-linux-gnu/share/pkgconfig SystemIncludePaths: /home/kaniini/sysroot/x86_64-pc-linux-gnu/include SystemLibraryPaths: /home/kaniini/sysroot/x86_64-pc-linux-gnu/lib

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

305 - Linux cli command editrcedit

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command editrcedit and provides detailed information about the command editrcedit, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the editrcedit.

The

file defines various settings to be used by the

library.

The format of each line is:

is one of the

builtin commands. Refer to

for more information.

is the program name string that a program defines when it calls

to set up

which is usually

will be executed for any program which matches

may also be a

style regular expression, in which case

will be executed for any program that matches the regular expression.

is absent,

is executed for all programs.

The

library has some builtin commands, which affect the way that the line editing and history functions operate. These are based on similar named builtins present in the

shell.

The following builtin commands are available:

Without options and arguments, list all bound keys and macros, and the editor command or input string to which each one is bound. If only

is supplied, show the binding for that key or macro. If

is supplied, bind the editor

to that key or macro.

The options are as follows:

List or change key bindings in the

mode alternate (command mode) key map.

Bind all keys to the standard

Emacs-like bindings.

is interpreted as a symbolic arrow key name, which may be one of

List all editor commands and a short description of each.

Remove the binding of the key or macro

Define a keyboard macro rather than a key binding or command macro:

is taken as a literal string and appended to the input queue whenever

is typed. Bound keys and macros in

are themselves reinterpreted, and this continues for ten levels of interpretation.

Bind all keys to the standard

bindings.

The

manual documents all editor commands and contains more information about macros and the input queue.

and

can contain control characters of the form

e.g.

and the following backslashed escape sequences:

Bell

Backspace

Escape

Formfeed

Newline

Carriage return

Horizontal tab

Vertical tab

The

character corresponding to the octal number

nullifies the special meaning of the following character, if it has any, notably

and

Exercise terminal capabilities given in

the value of that capability is printed, with

indicating that the terminal does or does not have that capability.

returns an empty string for non-existent capabilities, rather than causing an error.

causes messages to be verbose.

Enable or disable the

functionality in a program.

The

command lists all entries in the history. The

command sets the history size to

entries. The

command controls if history should keep duplicate entries. If

is non zero, only keep unique history entries. If

is zero, then keep all entries (the default).

Set the terminal capability

as defined in

No sanity checking is done.

Control which tty modes that

won’t allow the user to change.

tells

to act on the

set of tty modes respectively; defaulting to

Without other arguments,

lists the modes in the chosen set which are fixed on

or off

lists all tty modes in the chosen set regardless of the setting. With

fixes

on or off or removes control of

in the chosen set.

can also be used to set tty characters to particular values using

is empty then the character is set to

List the values of all the terminal capabilities (see

Names the default configuration file for the

library.

Last resort user configuration file for the

library if no other file is specified.

The

library was written by

and this manual was written by

with some sections inspired by

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

306 - Linux cli command deb-changes

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command deb-changes and provides detailed information about the command deb-changes, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the deb-changes.

NAME 🖥️ deb-changes 🖥️

changes - Debian upload changes control file format

SYNOPSIS

filename**.changes**

DESCRIPTION

Each Debian upload is composed of a .changes control file, which contains a number of fields in deb822 (5) format.

Each field begins with a tag, such as Source or Binary (case insensitive), followed by a colon, and the body of the field (case sensitive unless stated otherwise). Fields are delimited only by field tags. In other words, field text may be multiple lines in length, but the installation tools will generally join lines when processing the body of the field (except in case of the multiline fields Description, Changes, Files, Checksums-Sha1 and Checksums-Sha256, see below).

The control data might be enclosed in an OpenPGP ASCII Armored signature, as specified in RFC4880.

FIELDS

Date: release-date (required)
The date the package was built or last edited. It must be in the same format as the date in a deb-changelog (5) entry. The value of this field is usually extracted from the debian/changelog file.

Binary: binary-package-list (required in context)
This folded field is a space-separated list of binary packages to upload. If the upload is source-only, then the field is omitted (since dpkg 1.19.3).

Architecture: arch-list
Lists the architectures of the files currently being uploaded. Common architectures are amd64, armel, i386, etc. Note that the all value is meant for packages that are architecture independent. If the source for the package is also being uploaded, the special entry source is also present. Architecture wildcards must never be present in the list.

Distribution: distributions (required)
Lists one or more space-separated distributions where this version should be installed when it is uploaded to the archive.

Urgency: urgency (recommended)
The urgency of the upload. The currently known values, in increasing order of urgency, are: low, medium, high, critical and emergency.

Maintainer: fullname-email (required)
Should be in the format “Joe Bloggs <[email protected]>”, and is typically the person who created the package, as opposed to the author of the software that was packaged.

Changed-By: fullname-email
Should be in the format “Joe Bloggs <[email protected]>”, and is typically the person who prepared the package changes for this release.

Description: (recommended)

binary-package-name - binary-package-summary

This multiline field contains a list of binary package names followed by a space, a dash (‘-’) and their possibly truncated short descriptions. If the upload is source-only, then the field is omitted (since dpkg 1.19.3).

Closes: bug-number-list
A space-separated list of bug report numbers for bug reports that have been resolved with this upload. The distribution archive software might use this field to automatically close the referred bug numbers in the distribution bug tracking system.

Binary-Only: yes
This field denotes that the upload is a binary-only non-maintainer build. It originates from the binary-only=yes key/value from the changelog metadata entry.

Built-For-Profiles: profile-list
This field specifies a whitespace separated list of build profiles that this upload was built with.

Changes: (required)

changelog-entries

This multiline field contains the concatenated text of all changelog entries that are part of the upload. To make this a valid multiline field empty lines are replaced with a single full stop (‘.’) and all lines are indented by one space character. The exact content depends on the changelog format.

Files: (required)

md5sum size section priority filename

This multiline field contains a list of files with an md5sum, size, section and priority for each one. The first line of the field value (the part on the same line as the field name followed by a colon) is always empty. The content of the field is expressed as continuation lines, one line per file. Each line consists of space-separated entries describing the file: the md5sum, the file size, the file section, the file priority, and the file name. This field lists all files that make up the upload. The list of files in this field must match the list of files in the other related Checksums fields.

Checksums-Sha1: (required)

Checksums-Sha256: (required)

checksum size filename

These multiline fields contain a list of files with a checksum and size for each one. These fields have the same syntax and differ only in the checksum algorithm used: SHA-1 for Checksums-Sha1 and SHA-256 for Checksums-Sha256. The first line of the field value (the part on the same line as the field name followed by a colon) is always empty. The content of the field is expressed as continuation lines, one line per file. Each line consists of space-separated entries describing the file: the checksum, the file size, and the file name. These fields list all files that make up the upload. The list of files in these fields must match the list of files in the Files field and the other related Checksums fields.

BUGS

The Files field is inconsistent with the other Checksums fields. The Changed-By and Maintainer fields have confusing names. The Distribution field contains information about what is commonly referred to as a suite.

307 - Linux cli command proc_pid_syscall

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_syscall and provides detailed information about the command proc_pid_syscall, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_syscall.

NAME 🖥️ proc_pid_syscall 🖥️

currently executed system call

DESCRIPTION

/proc/pid/syscall (since Linux 2.6.27)
This file exposes the system call number and argument registers for the system call currently being executed by the process, followed by the values of the stack pointer and program counter registers. The values of all six argument registers are exposed, although most system calls use fewer registers.

If the process is blocked, but not in a system call, then the file displays -1 in place of the system call number, followed by just the values of the stack pointer and program counter. If process is not blocked, then the file contains just the string “running”.

This file is present only if the kernel was configured with CONFIG_HAVE_ARCH_TRACEHOOK.

Permission to access this file is governed by a ptrace access mode PTRACE_MODE_ATTACH_FSCREDS check; see ptrace(2).

308 - Linux cli command sleep.conf.d

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command sleep.conf.d and provides detailed information about the command sleep.conf.d, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the sleep.conf.d.

NAME 🖥️ sleep.conf.d 🖥️

sleep.conf, sleep.conf.d - Suspend and hibernation configuration file

SYNOPSIS

/etc/systemd/sleep.conf

/run/systemd/sleep.conf

/usr/lib/systemd/sleep.conf

/etc/systemd/sleep.conf.d/*.conf

/run/systemd/sleep.conf.d/*.conf

/usr/lib/systemd/sleep.conf.d/*.conf

DESCRIPTION

systemd supports four general power-saving modes:

suspend

a low-power state where execution of the OS is paused, and complete power loss might result in lost data, and which is fast to enter and exit. This corresponds to suspend, standby, or freeze states as understood by the kernel.
Added in version 203.

hibernate

a low-power state where execution of the OS is paused, and complete power loss does not result in lost data, and which might be slow to enter and exit. This corresponds to the hibernation as understood by the kernel.
Added in version 203.

hybrid-sleep

a low-power state where execution of the OS is paused, which might be slow to enter, and on complete power loss does not result in lost data but might be slower to exit in that case. This mode is called suspend-to-both by the kernel.
Added in version 203.

suspend-then-hibernate

A low power state where the system is initially suspended (the state is stored in RAM). When the battery level is too low (less than 5%) or a certain timespan has passed, whichever happens first, the system is automatically woken up and then hibernated. This establishes a balance between speed and safety.
If the system has no battery, it would be hibernated after HibernateDelaySec= has passed. If not set, then defaults to “2h”.
If the system has battery and HibernateDelaySec= is not set, low-battery alarms (ACPI _BTP) are tried first for detecting battery percentage and wake up the system for hibernation. If not available, or HibernateDelaySec= is set, the system would regularly wake up to check the time and detect the battery percentage/discharging rate. The rate is used to schedule the next detection. If that is also not available, SuspendEstimationSec= is used as last resort.
Added in version 239.

Settings in these files determine what strings will be written to /sys/power/disk and /sys/power/state by systemd-sleep(8) when systemd(1) attempts to suspend or hibernate the machine. See systemd.syntax(7) for a general description of the syntax.

CONFIGURATION DIRECTORIES AND PRECEDENCE

OPTIONS

The following options can be configured in the [Sleep] section of /etc/systemd/sleep.conf or a sleep.conf.d file:

AllowSuspend=, AllowHibernation=, AllowHybridSleep=, AllowSuspendThenHibernate=

By default any power-saving mode is advertised if possible (i.e. the kernel supports that mode, the necessary resources are available). Those switches can be used to disable specific modes.
If AllowHibernation=no or AllowSuspend=no is used, this implies AllowSuspendThenHibernate=no and AllowHybridSleep=no, since those methods use both suspend and hibernation internally. AllowSuspendThenHibernate=yes and AllowHybridSleep=yes can be used to override and enable those specific modes.
Added in version 240.

SuspendState=

The string to be written to /sys/power/state by systemd-suspend.service(8). More than one value can be specified by separating multiple values with whitespace. They will be tried in turn, until one is written without error. If none of the writes succeed, the operation will be aborted.
The allowed set of values is determined by the kernel and is shown in the file itself (use cat /sys/power/state to display). See Basic sysfs Interfaces for System Suspend and Hibernation[2] for more details.
systemd-suspend-then-hibernate.service(8) uses this value when suspending.
Added in version 203.

HibernateMode=

The string to be written to /sys/power/disk by systemd-hibernate.service(8). More than one value can be specified by separating multiple values with whitespace. They will be tried in turn, until one is written without error. If none of the writes succeed, the operation will be aborted.
The allowed set of values is determined by the kernel and is shown in the file itself (use cat /sys/power/disk to display). See the kernel documentation page Basic sysfs Interfaces for System Suspend and Hibernation[2] for more details.
systemd-suspend-then-hibernate.service(8) uses the value of HibernateMode= when hibernating.
Added in version 203.

MemorySleepMode=

The string to be written to /sys/power/mem_sleep when SuspendState=mem or hybrid-sleep is used. More than one value can be specified by separating multiple values with whitespace. They will be tried in turn, until one is written without error. If none of the writes succeed, the operation will be aborted. Defaults to empty, i.e. the kernel default or kernel command line option mem_sleep_default= is respected.
The allowed set of values is determined by the kernel and is shown in the file itself (use cat /sys/power/mem_sleep to display). See the kernel documentation page Basic sysfs Interfaces for System Suspend and Hibernation[2] for more details.
Added in version 256.

HibernateDelaySec=

The amount of time the system spends in suspend mode before the system is automatically put into hibernate mode. Only used by systemd-suspend-then-hibernate.service(8). Refer to suspend-then-hibernate for details on how this option interacts with other options/system battery state.
Added in version 239.

SuspendEstimationSec=

The RTC alarm will wake the system after the specified timespan to measure the system battery capacity level and estimate battery discharging rate. Only used by systemd-suspend-then-hibernate.service(8). Refer to suspend-then-hibernate for details on how this option interacts with other options/system battery state.
Added in version 253.

EXAMPLE: FREEZE

Example: to exploit the “freeze” mode added in Linux 3.9, one can use systemctl suspend with

[Sleep] SuspendState=freeze

NOTES

Basic sysfs Interfaces for System Suspend and Hibernation

https://docs.kernel.org/admin-guide/pm/sleep-states.html#basic-sysfs-interfaces-for-system-suspend-and-hibernation

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

309 - Linux cli command systemd.scope

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.scope and provides detailed information about the command systemd.scope, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.scope.

NAME 🖥️ systemd.scope 🖥️

Scope unit configuration

SYNOPSIS

scope.scope

DESCRIPTION

Scope units are not configured via unit configuration files, but are only created programmatically using the bus interfaces of systemd. They are named similar to filenames. A unit whose name ends in “.scope” refers to a scope unit. Scopes units manage a set of system processes. Unlike service units, scope units manage externally created processes, and do not fork off processes on its own.

The main purpose of scope units is grouping worker processes of a system service for organization and for managing resources.

systemd-run –scope may be used to easily launch a command in a new scope unit from the command line.

See the New Control Group Interfaces[1] for an introduction on how to make use of scope units from programs.

Note that, unlike service units, scope units have no “main” process: all processes in the scope are equivalent. The lifecycle of the scope unit is thus not bound to the lifetime of one specific process, but to the existence of at least one process in the scope. This also means that the exit statuses of these processes are not relevant for the scope unit failure state. Scope units may still enter a failure state, for example due to resource exhaustion or stop timeouts being reached, but not due to programs inside of them terminating uncleanly. Since processes managed as scope units generally remain children of the original process that forked them off, it is also the job of that process to collect their exit statuses and act on them as needed.

AUTOMATIC DEPENDENCIES

Implicit Dependencies

Implicit dependencies may be added as result of resource control parameters as documented in systemd.resource-control(5).

Default Dependencies

The following dependencies are added unless DefaultDependencies=no is set:

·
Scope units will automatically have dependencies of type Conflicts= and Before= on shutdown.target. These ensure that scope units are removed prior to system shutdown. Only scope units involved with early boot or late system shutdown should disable DefaultDependencies= option.

OPTIONS

Scope files may include a [Unit] section, which is described in systemd.unit(5).

Scope files may include a [Scope] section, which carries information about the scope and the units it contains. A number of options that may be used in this section are shared with other unit types. These options are documented in systemd.kill(5) and systemd.resource-control(5). The options specific to the [Scope] section of scope units are the following:

OOMPolicy=

Configure the out-of-memory (OOM) killing policy for the kernel and the userspace OOM killer systemd-oomd.service(8). On Linux, when memory becomes scarce to the point that the kernel has trouble allocating memory for itself, it might decide to kill a running process in order to free up memory and reduce memory pressure. Note that systemd-oomd.service is a more flexible solution that aims to prevent out-of-memory situations for the userspace too, not just the kernel, by attempting to terminate services earlier, before the kernel would have to act.
This setting takes one of continue, stop or kill. If set to continue and a process in the unit is killed by the OOM killer, this is logged but the unit continues running. If set to stop the event is logged but the unit is terminated cleanly by the service manager. If set to kill and one of the units processes is killed by the OOM killer the kernel is instructed to kill all remaining processes of the unit too, by setting the memory.oom.group attribute to 1; also see kernel page Control Group v2[2].
Defaults to the setting DefaultOOMPolicy= in systemd-system.conf(5) is set to, except for units where Delegate= is turned on, where it defaults to continue.
Use the OOMScoreAdjust= setting to configure whether processes of the unit shall be considered preferred or less preferred candidates for process termination by the Linux OOM killer logic. See systemd.exec(5) for details.
This setting also applies to systemd-oomd.service(8). Similarly to the kernel OOM kills performed by the kernel, this setting determines the state of the unit after systemd-oomd kills a cgroup associated with it.
Added in version 253.

RuntimeMaxSec=

Configures a maximum time for the scope to run. If this is used and the scope has been active for longer than the specified time it is terminated and put into a failure state. Pass “infinity” (the default) to configure no runtime limit.
Added in version 244.

RuntimeRandomizedExtraSec=

This option modifies RuntimeMaxSec= by increasing the maximum runtime by an evenly distributed duration between 0 and the specified value (in seconds). If RuntimeMaxSec= is unspecified, then this feature will be disabled.
Added in version 250.

Check systemd.unit(5), systemd.exec(5), and systemd.kill(5) for more settings.

NOTES

New Control Group Interfaces

https://systemd.io/CONTROL_GROUP_INTERFACE

Control Group v2

https://docs.kernel.org/admin-guide/cgroup-v2.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

310 - Linux cli command netconfig

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command netconfig and provides detailed information about the command netconfig, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the netconfig.

The

file defines a list of

describing their semantics and protocol. In

this file is only used by the RPC library code.

Entries have the following format:

Entries consist of the following fields:

The name of the transport described.

Describes the semantics of the transport. This can be one of:

Connectionless transport.

Connection-oriented transport

Connection-oriented, ordered transport.

A raw connection.

This field is either blank (specified by

or contains a

meaning visible to the

function.

The protocol family of the transport. This is currently one of:

The IPv6

family of protocols.

The IPv4

family of protocols.

The

protocol family.

The name of the protocol used for this transport. Can currently be either

or empty.

This field is always empty in

The order of entries in this file will determine which transport will be preferred by the RPC library code, given a match on a specified network type. For example, if a sample network config file would look like this:

udp6 tpi_clts v inet6 udp - - tcp6 tpi_cots_ord v inet6 tcp - - udp tpi_clts v inet udp - - tcp tpi_cots_ord v inet tcp - - rawip tpi_raw - inet - - - local tpi_cots_ord - loopback - - -

then using the network type

in calls to the RPC library function (see

will make the code first try

and then

and associated functions will parse this file and return structures of the following format:

struct netconfig { char *nc_netid; /* Network ID */ unsigned long nc_semantics; /* Semantics (see below) */ unsigned long nc_flag; /* Flags (see below) */ char *nc_protofmly; /* Protocol family */ char *nc_proto; /* Protocol name */ char *nc_device; /* Network device pathname (unused) */ unsigned long nc_nlookups; /* Number of lookup libs (unused) */ char **nc_lookups; /* Names of the libraries (unused) */ unsigned long nc_unused[9]; /* reserved */ };

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

311 - Linux cli command systemd.automount

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.automount and provides detailed information about the command systemd.automount, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.automount.

NAME 🖥️ systemd.automount 🖥️

Automount unit configuration

SYNOPSIS

automount.automount

DESCRIPTION

A unit configuration file whose name ends in “.automount” encodes information about a file system automount point controlled and supervised by systemd. Automount units may be used to implement on-demand mounting as well as parallelized mounting of file systems.

This man page lists the configuration options specific to this unit type. See systemd.unit(5) for the common options of all unit configuration files. The common configuration items are configured in the generic [Unit] and [Install] sections. The automount specific configuration options are configured in the [Automount] section.

Automount units must be named after the automount directories they control. Example: the automount point /home/lennart must be configured in a unit file home-lennart.automount. For details about the escaping logic used to convert a file system path to a unit name see systemd.unit(5). Note that automount units cannot be templated, nor is it possible to add multiple names to an automount unit by creating symlinks to its unit file.

For each automount unit file a matching mount unit file (see systemd.mount(5) for details) must exist which is activated when the automount path is accessed. Example: if an automount unit home-lennart.automount is active and the user accesses /home/lennart the mount unit home-lennart.mount will be activated.

Note that automount units are separate from the mount itself, so you should not set After= or Requires= for mount dependencies here. For example, you should not set After=network-online.target or similar on network filesystems. Doing so may result in an ordering cycle.

Note that automount support on Linux is privileged, automount units are hence only available in the system service manager (and roots user service manager), but not in unprivileged users service managers.

Note that automount units should not be nested. (The establishment of the inner automount point would unconditionally pin the outer mount point, defeating its purpose.)

AUTOMATIC DEPENDENCIES

Implicit Dependencies

The following dependencies are implicitly added:

·
If an automount unit is beneath another mount unit in the file system hierarchy, a requirement and ordering dependencies are created to the on the unit higher in the hierarchy.

·
An implicit Before= dependency is created between an automount unit and the mount unit it activates.

Default Dependencies

The following dependencies are added unless DefaultDependencies=no is set:

·
Automount units acquire automatic Before= and Conflicts= on umount.target in order to be stopped during shutdown.

·
Automount units automatically gain an After= dependency on local-fs-pre.target, and a Before= dependency on local-fs.target.

FSTAB

Automount units may either be configured via unit files, or via /etc/fstab (see fstab(5) for details).

For details how systemd parses /etc/fstab see systemd.mount(5).

If an automount point is configured in both /etc/fstab and a unit file, the configuration in the latter takes precedence.

OPTIONS

Automount unit files may include [Unit] and [Install] sections, which are described in systemd.unit(5).

Automount unit files must include an [Automount] section, which carries information about the file system automount points it supervises. The options specific to the [Automount] section of automount units are the following:

Where=

Takes an absolute path of a directory of the automount point. If the automount point does not exist at time that the automount point is installed, it is created. This string must be reflected in the unit filename. (See above.) This option is mandatory.

ExtraOptions=

Extra mount options to use when creating the autofs mountpoint. This takes a comma-separated list of options. This setting is optional. Note that the usual specifier expansion is applied to this setting, literal percent characters should hence be written as “%%”.
Added in version 250.

DirectoryMode=

Directories of automount points (and any parent directories) are automatically created if needed. This option specifies the file system access mode used when creating these directories. Takes an access mode in octal notation. Defaults to 0755.

TimeoutIdleSec=

Configures an idle timeout. Once the mount has been idle for the specified time, systemd will attempt to unmount. Takes a unit-less value in seconds, or a time span value such as “5min 20s”. Pass 0 to disable the timeout logic. The timeout is disabled by default.
Added in version 220.

Check systemd.unit(5), systemd.exec(5), and systemd.kill(5) for more settings.

312 - Linux cli command interfaces

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command interfaces and provides detailed information about the command interfaces, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the interfaces.

NAME 🖥️ interfaces 🖥️

network interface configuration for ifup and ifdown

DESCRIPTION

/etc/network/interfaces contains network interface configuration information for the ifup(8) and ifdown(8) commands. This is where you configure how your system is connected to the network.

EXAMPLE

The following example configures two network interfaces: eth0 is brought up at boot, and uses DHCP for IPv4 and SLAAC for IPv6, whereas eth1 is brought up whenever the network hardware is detected, and is configured with static IPv4 and IPv6 addresses.

auto eth0 allow-hotplug eth1

iface eth0 inet dhcp

iface eth0 inet6 auto

iface eth1 inet static address 192.168.1.2/24 gateway 192.168.1.1

iface eth1 inet6 static address fec0:0:0:1::2/64 gateway fec0:0:0:1::1

FILE FORMAT

Lines starting with `#’ are ignored. Note that end-of-line comments are NOT supported, comments must be on a line of their own.

A line may be extended across multiple lines by making the last character a backslash.

The file consists of zero or more “iface”, “mapping”, “auto”, “allow-”, “rename”, “source” and “source-directory” stanzas. These will be described in more detail in the following sections.

INTERFACE SELECTION

Lines beginning with the word “auto” are used to identify the physical interfaces to be brought up when ifup is run with the -a option. (This option is also used by the system boot scripts, so interfaces marked “auto” are brought up at boot time.) Physical interface names should follow the word “auto” on the same line. There can be multiple “auto” stanzas. ifup brings the named interfaces up in the order listed.

Lines beginning with “allow-” are used to identify interfaces that should be brought up automatically by various subsystems. This may be done using a command such as “ifup –allow=hotplug eth0 eth1”, which will only bring up eth0 or eth1 if it is listed in an “allow-hotplug” line. Note that “allow-auto” and “auto” are synonyms. (Interfaces marked “allow-hotplug” are brought up when udev detects them. This can either be during boot if the interface is already present, or at a later time, for example when plugging in a USB network card. Please note that this does not have anything to do with detecting a network cable being plugged in.)

Lines beginning with “no-auto-down” are used to identify interfaces that should not be brought down by the command “ifdown -a”. Its main use is to prevent an interface from being brought down during system shutdown time, for example if the root filesystem is a network filesystem and the interface should stay up until the very end. Note that you can still bring down the interface by specifying the interface name explicitly.

Lines beginning with “no-scripts” are used to identify interfaces for which scripts in /etc/network/if-*.d/ should not be run when those interfaces are brought up or down. he above will match eth0 and eth1, and will bring up both interfaces using the “iface eth” stanza.

INTERFACE RENAMING

Lines beginning with “rename” are used to rename interfaces. It takes one or more arguments in the form of “CUR=NEW”, where CUR is the name of an existing interface, and NEW is the new name. This becomes very powerful when combined with pattern matching for the CUR interface.

Interfaces are renamed whenever “ifup” is called. Renaming logically happens before anything else is done. So if an interface is started with the name “foo”, and it has to be renamed to “bar” and brought up at boot time, then one should use the following /etc/network/interfaces file:

rename foo=bar auto bar iface bar …

However, if the interface is not renamed yet, it is possible to use both “ifup foo” and “ifup bar”. The former command will then automatically be converted to the latter. This is mainly useful when ifup is called automatically whenever an interface is hotplugged.

Interface renaming only works if the operating system supports it, if an interface is not renamed to another existing interface, and may require that the interface that is to be renamed has not been brought up yet. If ifup tries to rename an interface and it fails, it will exit with an error.

INCLUDING OTHER FILES

Lines beginning with “source” are used to include stanzas from other files, so configuration can be split into many files. The word “source” is followed by the path of file to be sourced. Shell wildcards can be used. (See wordexp(3) for details.)

Similarly, “source-directory” keyword is used to source multiple files at once, without specifying them individually or using shell globs. Additionally, when “source-directory” is used, names of the files are checked to match the following regular expression: ^[a-zA-Z0-9_-]+$. In other words, the names must consist entirely of ASCII upper- and lower-case letters, ASCII digits, ASCII underscores, and ASCII minus-hyphens. In the directory path, shell wildcards may be used as well.

When sourcing files or directories, if a path doesn’t have a leading slash, it’s considered relative to the directory containing the file in which the keyword is placed. In the example above, if the file is located at /etc/network/interfaces, paths to the included files are understood to be under /etc/network.

By default, on a freshly installed Debian system, the interfaces file includes a line to source files in the /etc/network/interfaces.d directory.

MAPPINGS

Stanzas beginning with the word “mapping” are used to determine how a logical interface name is chosen for a physical interface that is to be brought up. The first line of a mapping stanza consists of the word “mapping” followed by a pattern in shell glob syntax. Each mapping stanza must contain a script definition. The named script is run with the physical interface name as its argument and with the contents of all following “map” lines (without the leading “map”) in the stanza provided to it on its standard input. The script must print a string on its standard output before exiting. See /usr/share/doc/ifupdown/examples for examples of what the script must print.

Mapping a name consists of searching the remaining mapping patterns and running the script corresponding to the first match; the script outputs the name to which the original is mapped.

ifup is normally given a physical interface name as its first non-option argument. ifup also uses this name as the initial logical name for the interface unless it is accompanied by a suffix of the form =LOGICAL, in which case ifup chooses LOGICAL as the initial logical name for the interface. It then maps this name, possibly more than once according to successive mapping specifications, until no further mappings are possible. If the resulting name is the name of some defined logical interface then ifup attempts to bring up the physical interface as that logical interface. Otherwise ifup exits with an error.

INTERFACE DEFINITIONS

Stanzas defining logical interfaces start with a line consisting of the word “iface” followed by the name of the logical interface. In simple configurations without mapping stanzas this name should simply be the name of the physical interface to which it is to be applied. (The default mapping script is, in effect, the echo command.) The interface name is followed by the name of the address family that the interface uses. This will be “inet” for TCP/IP networking, but there is also some support for IPX networking (“ipx”), and IPv6 networking (“inet6”). Following that is the name of the method used to configure the interface.

Additional options can be given on subsequent lines in the stanza. Which options are available depends on the family and method, as described below. Additional options can be made available by other Debian packages. For example, the wireless-tools package makes available a number of options prefixed with “wireless-” which can be used to configure the interface using iwconfig(8). (See wireless(7) for details.) A list of packages providing additional options is mentioned in the section “OPTIONS PROVIDED BY OTHER PACKAGE”.

Options are usually indented for clarity (as in the example above) but are not required to be.

Multiple “iface” stanzas can be given for the same interface, in which case all of the configured addresses and options for that interface will be applied when bringing up that interface. This is useful to configure both IPv4 and IPv6 addresses on the same interface (although if no inet6 stanza is present, the kernel will normally still perform stateless address autoconfiguration if there is an IPv6 route advertisement daemon on the network). It can also be used to configure multiple addresses of the same type on a single interface.

INTERFACE TEMPLATES

It is possible to define interface definition templates and extend them using the inherits keyword:

iface ethernet inet static mtu 1500 hwaddress 11:22:33:44:55:66

iface eth0 inet static inherits ethernet address 192.168.1.2/24

This may be useful to separate link-level settings shared by multiple interfaces from, for example, IP address settings specific to every interface.

PATTERN MATCHING INTERFACES

It is possible to use patterns to match one or more real interfaces. These patterns can currently appear in lines beginning with “auto”, “allow-”, “rename” and on the command line. A pattern has the following format (see below for exceptions for GNU/Hurd):

[VARIABLE]/VALUE[/[OPTIONS]][=LOGICAL]

If no VARIABLE is given, this pattern will match interface names against the given VALUE. VALUE can contain wildcard patterns such as ? and *, see the fnmatch(3) function. When ifup or ifdown is run, patterns are replaces by all real interfaces that are currently known to the operating system kernel and whose names match the pattern. For example, given the following line:

auto /eth*

If the kernel knows about the interfaces with names lo, eth0 and eth1, then the above line is then interpreted as:

auto eth0 eth1

Note that there must still be valid “iface” stanzas for each matching interface. However, it is possible to combine a pattern with a mapping to a logical interface, like so:

auto /eth*=eth iface eth inet dhcp

Valid variable names are “mac”, in which case value is matched against the interface’s MAC address. On Linux, the variable name can also be any filename in /sys/class/net/<iface>/, in which case the value is matched against the contents of the corresponding file.

The OPTIONS field currently only supports a number. If given, only the n-th interface that has a matching value will actually be used, where n is the number given, starting at 1. So /eth*/1 will match the first interface whose name starts with eth.

On GNU/Hurd, interface names start with /dev/, and this obviously clashes with the format for patterns. To ensure an interface name like /dev/eth0 does not get interpreted as a pattern, any pattern that starts with /dev/ is ignored, and instead interpreted as a literal interface name. To make a pattern that matches interface names on GNU/Hurd, use something like:

auto /?dev?eth*=eth iface eth inet dhcp

VLAN INTERFACES

To ease the configuration of VLAN interfaces, interfaces having . (full stop character) in the name are configured as 802.1q tagged virtual LAN interface. For example, interface eth0.1 is a virtual interface with VLAN ID 1 having eth0 as its parent interface.

VLAN interfaces are mostly treated as independent interfaces. As such, a VLAN interface is normally not automatically brought up when its parent interface is brought up. The exception is when ifup is called with the –allow option, in which case all VLAN interfaces that are in the same allow class as the parent interface are brought up together with the parent interface. For example:

allow-hotplug eth0 eth0.1

iface eth0 inet static address …

iface eth0.1 inet static address …

iface eth0.2 inet static address …

In the above example, when “ifup –allow hotplug eth0” is called (either manually or because udev triggers this when a network device is hotplugged), the interface eth0 and the VLAN interface eth0.1 are brought up, but eth0.2 is not.

Keep in mind that pattern matching will only match interfaces the kernel knows about, so it is not possible to specify “auto /eth0.*” and have all VLAN interfaces for eth0 be brought up at boot time. Another way to ensure that a VLAN interface is brought up automatically when the parent interface is brought up, is to use a recursive call to ifup, like so:

iface eth0 inet manual up ifup eth0.3

iface eth0.3 inet static address …

Note that there is no need to add an explicit call to ifdown, since VLAN interfaces are automatically brought down whenever their parent interfaces are brought down.

IFACE OPTIONS

The following “command” options are available for every family and method. Each of these options can be given multiple times in a single stanza, in which case the commands are executed in the order in which they appear in the stanza. (You can ensure a command never fails by suffixing them with “|| true”.)

pre-up* command*
Run command before bringing the interface up. If this command fails then ifup aborts, refraining from marking the interface as configured, prints an error message, and exits with status 0. This behavior may change in the future.

up command, post-up command
Run command after bringing the interface up. If this command fails then ifup aborts, refraining from marking the interface as configured (even though it has really been configured), prints an error message, and exits with status 0. This behavior may change in the future.

down command, pre-down command
Run command before taking the interface down. If this command fails then ifdown aborts, marks the interface as deconfigured (even though it has not really been deconfigured), and exits with status 0. This behavior may change in the future.

post-down* command*
Run command after taking the interface down. If this command fails then ifdown aborts, marks the interface as deconfigured, and exits with status 0. This behavior may change in the future.

description* name*
Alias interface by name

HOOK SCRIPTS

There are four directories in which scripts can be placed which will always be run for any interface during certain phases of ifup and ifdown commands. These are:

/etc/network/if-pre-up.d/
Scripts in this directory are run before bringing the interface up.

/etc/network/if-up.d/
Scripts in this directory are run after bringing the interface up.

/etc/network/if-down.d/
Scripts in this directory are run before bringing the interface down.

/etc/network/if-post-down.d/
Scripts in this directory are run after bringing the interface down.

The scripts in which are run (with no arguments) using run-parts(8) after the corresponding pre-up, up, down and post-down options in the /etc/network/interfaces file itself have been processed. Please note that as post-up and pre-down are aliases, no files in the corresponding directories are processed. Please use if-up.d and if-down.d directories instead.

ENVIRONMENT VARIABLES

All hook scripts, and the commands executed by pre-up, up, post-up, pre-down, down and post-down have access to the following environment variables:

IFACE
The physical name of the interface being processed, or “–all” (see below).

LOGICAL
The logical name of the interface being processed, or “auto” (see below).

ADDRFAM
The address family of the interface, or “meta” (see below).

METHOD
The method of the interface (e.g., static), or “none” (see below).

CLASS
The class of interfaces being processed. This is a copy of the value given to the –allow option when running ifup or ifdown, otherwise it is set to “auto” when the –all option is used.

MODE
start if run from ifup, stop if run from ifdown*.*

PHASE
As per MODE, but with finer granularity, distinguishing the pre-up, post-up, pre-down and post-down phases.

VERBOSITY
Indicates whether –verbose was used; set to 1 if so, 0 if not.

PATH
The command search path: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Additionally, all options given in an interface definition stanza are exported to the environment in upper case with “IF_” prepended and with hyphens converted to underscores and non-alphanumeric characters discarded.

When ifupdown is being called with the –all option, before doing anything to interfaces, it calls all the hook scripts (pre-up or down) with IFACE set to “–all”, LOGICAL set to the current value of –allow parameter (or “auto” if it’s not set), ADDRFAM=“meta” and METHOD=“none”. After all the interfaces have been brought up or taken down, the appropriate scripts (up or post-down) are executed.

CONCURRENCY AND PARALLEL EXECUTION

Ifupdown uses per-interface locking to ensure that concurrent ifup and ifdown calls to the same interface are run in serial. However, calls to different interfaces will be able to run in parallel. It is therefore important that any hook scripts and pre-up, up, down and post-down commands are written with the possibility of parallel execution in mind.

It is allowed to recursively call ifup and ifdown from hook scripts and interface commands, as long as these calls refer to a different interface than the one that is already being (de)configured. Loops are detected and will result in the call failing instead of a deadlock, although it is best if one does not rely on that.

OPTIONS PROVIDED BY OTHER PACKAGES

This manual page documents the configuration options provided by the ifupdown package. However, other packages can make other options available for use in /etc/network/interfaces. Here is a list of packages that provide such extensions:

arping, avahi-autoipd, avahi-daemon, bind9, bridge-utils, clamav-freshclam, controlaula, epoptes-client, ethtool, guidedog, hostap-utils, hostapd, htpdate, ifenslave, ifmetric, ifupdown-extra, ifupdown-multi, ifupdown-scripts-zg2, initscripts, isatapd, linux-wlan-ng, lprng, macchanger, miredo, nslcd, ntpdate, openntpd, openresolv, openssh-server, openvpn, openvswitch-switch, postfix, resolvconf, sendmail-base, shorewall-init, slrn, slrnpull, tinc, ucarp, uml-utilities, uruk, vde2, vlan, vzctl, whereami, wide-dhcpv6-client, wireless-tools, wpasupplicant.

Please consult the documentation of those packages for information about how they extend ifupdown.

INET ADDRESS FAMILY

This section documents the methods available in the inet address family.

The loopback Method

This method may be used to define the IPv4 loopback interface.

Options

(No options)

The static Method

This method may be used to define Ethernet interfaces with statically allocated IPv4 addresses.

Options

address* address *
Address (dotted quad/netmask) required
netmask* mask *
Netmask (dotted quad or number of bits) deprecated
broadcast* broadcast_address*
Broadcast address (dotted quad, + or -) deprecated. Default value: “+”
metric* metric *
Routing metric for default gateway (integer)
gateway* address *
Default gateway (dotted quad)
pointopoint* address *
Address of other end point (dotted quad). Note the spelling of “point-to”.
hwaddress* address *
Link local address or “random”.
mtu* size *
MTU size
scope
Address validity scope. Possible values: global, link, host

The manual Method

This method may be used to define interfaces for which no configuration is done by default. Such interfaces can be configured manually by means of up and down commands or /etc/network/if-*.d scripts.

Options

hwaddress* address *
Link local address or “random”.
mtu* size *
MTU size

The dhcp Method

This method may be used to obtain an address via DHCP with any of the tools: dhclient, udhcpc, dhcpcd. (They have been listed in their order of precedence.) If you have a complicated DHCP setup you should note that some of these clients use their own configuration files and do not obtain their configuration information via ifup.

Options

hostname* hostname *
Hostname to be requested (dhcpcd, udhcpc)
metric* metric *
Metric for added routes (dhclient)
leasetime* leasetime *
Preferred lease time in seconds (dhcpcd)
vendor* vendor_id *
Vendor class identifier (dhcpcd)
client* client_id *
Client identifier (dhcpcd), or “no” (dhclient)
hwaddress* address *
Hardware address.

The bootp Method

This method may be used to obtain an address via bootp.

Options

bootfile* file *
Tell the server to use file as the bootfile.
server* address*
Use the IP address address to communicate with the server.
hwaddr* addr *
Use addr as the hardware address instead of whatever it really is.

The tunnel Method

This method is used to create GRE or IPIP tunnels. You need to have the ip binary from the iproute package. For GRE tunnels, you will need to load the ip_gre module and the ipip module for IPIP tunnels.

Options

address* address *
Local address (dotted quad) required
mode* type *
Tunnel type (either GRE or IPIP) required
endpoint* address *
Address of other tunnel endpoint required
dstaddr* address *
Remote address (remote address inside tunnel)
local* address *
Address of the local endpoint
metric* metric *
Routing metric for default gateway (integer)
gateway* address *
Default gateway
ttl* time *
TTL setting
mtu* size *
MTU size

The ppp Method

This method uses pon/poff to configure a PPP interface. See those commands for details.

Options

provider* name *
Use name as the provider (from /etc/ppp/peers).
unit* number *
Use number as the ppp unit number.
options* string*
Pass string as additional options to pon.

The wvdial Method

This method uses wvdial to configure a PPP interface. See that command for more details.

Options

provider* name *
Use name as the provider (from /etc/wvdial.conf).

The ipv4ll Method

This method uses avahi-autoipd to configure an interface with an IPv4 Link-Layer address (169.254.0.0/16 family). This method is also known as APIPA or IPAC, and often colloquially referred to as “Zeroconf address”.

Options

(No options)

IPX ADDRESS FAMILY

This section documents the methods available in the ipx address family.

The static Method

This method may be used to setup an IPX interface. It requires the ipx_interface command.

Options

frame* type *
type of Ethernet frames to use (e.g. 802.2)
netnum* id *
Network number

The dynamic Method

This method may be used to setup an IPX interface dynamically.

Options

frame* type *
type of Ethernet frames to use (e.g. 802.2)

INET6 ADDRESS FAMILY

This section documents the methods available in the inet6 address family.

The auto Method

This method may be used to define interfaces with automatically assigned IPv6 addresses. Using this method on its own doesn’t mean that RDNSS options will be applied, too. To make this happen, rdnssd daemon must be installed, properly configured and running. If stateless DHCPv6 support is turned on, then additional network configuration parameters such as DNS and NTP servers will be retrieved from a DHCP server. Please note that on ifdown, the lease is not currently released (a known bug).

Options

privext* int *
Privacy extensions (RFC4941) (0=off, 1=assign, 2=prefer)
accept_ra* int *
Accept router advertisements (0=off, 1=on, 2=on+forwarding). Default value: “2”
dhcp* int *
Use stateless DHCPv6 (0=off, 1=on)
request_prefix* int *
Request a prefix through DHCPv6 Prefix Delegation (0=off, 1=on). Default value: “0”
ll-attempts
Number of attempts to wait for a link-local address. Default value: “60”
ll-interval
Link-local address polling interval in seconds. Default value: “0.1”

The loopback Method

This method may be used to define the IPv6 loopback interface.

Options

(No options)

The static Method

This method may be used to define interfaces with statically assigned IPv6 addresses. By default, stateless autoconfiguration is disabled for this interface.

Options

address* address *
Address (colon delimited/netmask) required
netmask* mask *
Netmask (number of bits, eg 64) deprecated
metric* metric *
Routing metric for default gateway (integer)
gateway* address *
Default gateway (colon delimited)
media* type *
Medium type, driver dependent
hwaddress* address *
Hardware address or “random”
mtu* size *
MTU size
accept_ra* int *
Accept router advertisements (0=off, 1=on, 2=on+forwarding)
autoconf* int *
Perform stateless autoconfiguration (0=off, 1=on). Default value: “0”
privext* int *
Privacy extensions (RFC3041) (0=off, 1=assign, 2=prefer)
scope
Address validity scope. Possible values: global, site, link, host
preferred-lifetime* int*
Time that address remains preferred
dad-attempts
Number of attempts to settle DAD (0 to disable DAD). Default value: “60”
dad-interval
DAD state polling interval in seconds. Default value: “0.1”

The manual Method

Options

hwaddress* address *
Hardware address or “random”
mtu* size *
MTU size

The dhcp Method

This method may be used to obtain network interface configuration via stateful DHCPv6 with dhclient. In stateful DHCPv6, the DHCP server is responsible for assigning addresses to clients.

Options

hwaddress* address *
Hardware address or “random”
accept_ra* int *
Accept router advertisements (0=off, 1=on, 2=on+forwarding). Default value: “1”
autoconf* int *
Perform stateless autoconfiguration (0=off, 1=on)
request_prefix* int *
Request a prefix through DHCPv6 Prefix Delegation (0=off, 1=on). Default value: “0”
ll-attempts
Number of attempts to wait for a link-local address. Default value: “60”
ll-interval
Link-local address polling interval in seconds. Default value: “0.1”

The tunnel Method

This method is used to create IP6GRE, IP6IP6 or IPIP6 tunnels. You need to have the ip binary from the iproute package. For IP6GRE tunnels, you will need to load the ip6_gre module and the ip6_tunnel module for IP6IP6 or IPIP6 tunnels.

Options

address* address *
Local Address (colon delimited)
netmask* mask *
Netmask (number of bits, eg 64)
mode* type *
Tunnel type (either IP6GRE, IP6IP6 or IPIP6) required
endpoint* address *
Address of other tunnel endpoint (colon delimited) required
dstaddr* address *
Remote address (remote address inside tunnel)
local* address *
Address of the local endpoint (colon delimited)
metric* metric *
Routing metric for default gateway (integer)
gateway* address *
Default gateway (colon delimited)
ttl* time *
TTL setting
mtu* size *
MTU size
encaplimit* limit *
Encapsulation limit (“none” or integer)

The v4tunnel Method

This method may be used to setup an IPv6-over-IPv4 tunnel. It requires the ip command from the iproute package.

Options

address* address *
Address (colon delimited/netmask) required
netmask* mask *
Netmask (number of bits, eg 64) deprecated
endpoint* address *
Address of other tunnel endpoint (IPv4 dotted quad) required
local* address *
Address of the local endpoint (IPv4 dotted quad)
metric* metric *
Routing metric for default gateway (integer)
gateway* address *
Default gateway (colon delimited)
ttl* time *
TTL setting
mtu* size *
MTU size
preferred-lifetime* int*
Time that address remains preferred

The 6to4 Method

This method may be used to setup a 6to4 tunnel. It requires the ip command from the iproute package.

Options

local* address *
Address of the local endpoint (IPv4 dotted quad) required
metric* metric *
Routing metric for default gateway (integer)
ttl* time *
TTL setting
mtu* size *
MTU size
preferred-lifetime* int*
Time that address remains preferred

CAN ADDRESS FAMILY

This section documents the methods available in the can address family.

The static Method

This method may be used to setup a Controller Area Network (CAN) interface. It requires the the ip command from the iproute package.

Options

bitrate* bitrate *
bitrate (1..1000000) required
samplepoint* samplepoint*
sample point (0.000..0.999)
loopback* loopback *
loop back CAN Messages (on|off)
listenonly* listenonly*
listen only mode (on|off)
triple* triple *
activate triple sampling (on|off)
oneshot* oneshot *
one shot mode (on|off)
berr* berr *
activate berr reporting (on|off)
restart-ms* restart-ms*
restart-ms (0..)

KNOWN BUGS/LIMITATIONS

The ifup and ifdown programs work with so-called “physical” interface names. These names are assigned to hardware by the kernel. Unfortunately it can happen that the kernel assigns different physical interface names to the same hardware at different times; for example, what was called “eth0” last time you booted is now called “eth1” and vice versa. This creates a problem if you want to configure the interfaces appropriately. A way to deal with this problem is to use mapping scripts that choose logical interface names according to the properties of the interface hardware. See the get-mac-address.sh script in the examples directory for an example of such a mapping script. See also Debian bug #101728.

AUTHOR

The ifupdown suite was written by Anthony Towns <[email protected]>. This manpage was contributed by Joey Hess <[email protected]>.

313 - Linux cli command gitmodules

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitmodules and provides detailed information about the command gitmodules, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitmodules.

NAME 🖥️ gitmodules 🖥️

Defining submodule properties

SYNOPSIS

$GIT_WORK_TREE/.gitmodules

DESCRIPTION

The .gitmodules file, located in the top-level directory of a Git working tree, is a text file with a syntax matching the requirements of git-config(1).

The file contains one subsection per submodule, and the subsection value is the name of the submodule. The name is set to the path where the submodule has been added unless it was customized with the –name option of git submodule add. Each submodule section also contains the following required keys:

submodule.<name>.path

Defines the path, relative to the top-level directory of the Git working tree, where the submodule is expected to be checked out. The path name must not end with a /. All submodule paths must be unique within the .gitmodules file.

submodule.<name>.url

Defines a URL from which the submodule repository can be cloned. This may be either an absolute URL ready to be passed to git-clone(1) or (if it begins with ./ or ../) a location relative to the superproject’s origin repository.

In addition, there are a number of optional keys:

submodule.<name>.update

Defines the default update procedure for the named submodule, i.e. how the submodule is updated by the git submodule update command in the superproject. This is only used by git submodule init to initialize the configuration variable of the same name. Allowed values here are checkout, rebase, merge or none, but not !command (for security reasons). See the description of the update command in git-submodule(1) for more details.

submodule.<name>.branch

A remote branch name for tracking updates in the upstream submodule. If the option is not specified, it defaults to the remote HEAD. A special value of . is used to indicate that the name of the branch in the submodule should be the same name as the current branch in the current repository. See the –remote documentation in git-submodule(1) for details.

submodule.<name>.fetchRecurseSubmodules

This option can be used to control recursive fetching of this submodule. If this option is also present in the submodule’s entry in .git/config of the superproject, the setting there will override the one found in .gitmodules. Both settings can be overridden on the command line by using the –[no-]recurse-submodules option to git fetch and git pull.

submodule.<name>.ignore

Defines under what circumstances git status and the diff family show a submodule as modified. The following values are supported:
all
The submodule will never be considered modified (but will nonetheless show up in the output of status and commit when it has been staged).
dirty
All changes to the submodule’s work tree will be ignored, only committed differences between the HEAD of the submodule and its recorded state in the superproject are taken into account.
untracked
Only untracked files in submodules will be ignored. Committed differences and modifications to tracked files will show up.
none
No modifications to submodules are ignored, all of committed differences, and modifications to tracked and untracked files are shown. This is the default option.
If this option is also present in the submodule’s entry in .git/config of the superproject, the setting there will override the one found in .gitmodules.
Both settings can be overridden on the command line by using the –ignore-submodules option. The git submodule commands are not affected by this setting.

submodule.<name>.shallow

When set to true, a clone of this submodule will be performed as a shallow clone (with a history depth of 1) unless the user explicitly asks for a non-shallow clone.

NOTES

Git does not allow the .gitmodules file within a working tree to be a symbolic link, and will refuse to check out such a tree entry. This keeps behavior consistent when the file is accessed from the index or a tree versus from the filesystem, and helps Git reliably enforce security checks of the file contents.

EXAMPLES

Consider the following .gitmodules file:

[submodule “libfoo”] path = include/foo url = git://foo.com/git/lib.git
[submodule "libbar"]
        path = include/bar
        url = git://bar.com/git/lib.git

This defines two submodules, libfoo and libbar. These are expected to be checked out in the paths include/foo and include/bar, and for both submodules a URL is specified which can be used for cloning the submodules.

GIT

Part of the git(1) suite

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

314 - Linux cli command gitformat-pack

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitformat-pack and provides detailed information about the command gitformat-pack, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitformat-pack.

NAME 🖥️ gitformat-pack 🖥️

pack - Git pack format

SYNOPSIS

$GIT_DIR/objects/pack/pack-.{pack,idx}
$GIT_DIR/objects/pack/pack-.rev
$GIT_DIR/objects/pack/pack-*.mtimes
$GIT_DIR/objects/pack/multi-pack-index

DESCRIPTION

The Git pack format is how Git stores most of its primary repository data. Over the lifetime of a repository, loose objects (if any) and smaller packs are consolidated into larger pack(s). See git-gc(1) and git-pack-objects(1).

The pack format is also used over-the-wire, see e.g. gitprotocol-v2(5), as well as being a part of other container formats in the case of gitformat-bundle(5).

CHECKSUMS AND OBJECT IDS

In a repository using the traditional SHA-1, pack checksums, index checksums, and object IDs (object names) mentioned below are all computed using SHA-1. Similarly, in SHA-256 repositories, these values are computed using SHA-256.

PACK-*.PACK FILES HAVE THE FOLLOWING FORMAT:

·
A header appears at the beginning and consists of the following:
4-byte signature: The signature is: {P, A, C, K}
4-byte version number (network byte order): Git currently accepts version number 2 or 3 but generates version 2 only.
4-byte number of objects contained in the pack (network byte order)
Observation: we cannot have more than 4G versions ;-) and more than 4G objects in a pack.

·
The header is followed by a number of object entries, each of which looks like this:
(undeltified representation) n-byte type and length (3-bit type, (n-1)*7+4-bit length) compressed data
(deltified representation) n-byte type and length (3-bit type, (n-1)*7+4-bit length) base object name if OBJ_REF_DELTA or a negative relative offset from the delta objects position in the pack if this is an OBJ_OFS_DELTA object compressed delta data
Observation: the length of each object is encoded in a variable length format and is not constrained to 32-bit or anything.

·
The trailer records a pack checksum of all of the above.

Object types

Valid object types are:

·
OBJ_COMMIT (1)

·
OBJ_TREE (2)

·
OBJ_BLOB (3)

·
OBJ_TAG (4)

·
OBJ_OFS_DELTA (6)

·
OBJ_REF_DELTA (7)

Type 5 is reserved for future expansion. Type 0 is invalid.

Size encoding

This document uses the following “size encoding” of non-negative integers: From each byte, the seven least significant bits are used to form the resulting integer. As long as the most significant bit is 1, this process continues; the byte with MSB 0 provides the last seven bits. The seven-bit chunks are concatenated. Later values are more significant.

This size encoding should not be confused with the “offset encoding”, which is also used in this document.

Deltified representation

Conceptually there are only four object types: commit, tree, tag and blob. However to save space, an object could be stored as a “delta” of another “base” object. These representations are assigned new types ofs-delta and ref-delta, which is only valid in a pack file.

Both ofs-delta and ref-delta store the “delta” to be applied to another object (called base object) to reconstruct the object. The difference between them is, ref-delta directly encodes base object name. If the base object is in the same pack, ofs-delta encodes the offset of the base object in the pack instead.

The base object could also be deltified if it’s in the same pack. Ref-delta can also refer to an object outside the pack (i.e. the so-called “thin pack”). When stored on disk however, the pack should be self contained to avoid cyclic dependency.

The delta data starts with the size of the base object and the size of the object to be reconstructed. These sizes are encoded using the size encoding from above. The remainder of the delta data is a sequence of instructions to reconstruct the object from the base object. If the base object is deltified, it must be converted to canonical form first. Each instruction appends more and more data to the target object until it’s complete. There are two supported instructions so far: one for copying a byte range from the source object and one for inserting new data embedded in the instruction itself.

Each instruction has variable length. Instruction type is determined by the seventh bit of the first octet. The following diagrams follow the convention in RFC 1951 (Deflate compressed data format).

Instruction to copy from base object

+———-+———+———+———+———+——-+——-+——-+ | 1xxxxxxx | offset1 | offset2 | offset3 | offset4 | size1 | size2 | size3 | +———-+———+———+———+———+——-+——-+——-+
This is the instruction format to copy a byte range from the source object. It encodes the offset to copy from and the number of bytes to copy. Offset and size are in little-endian order.
All offset and size bytes are optional. This is to reduce the instruction size when encoding small offsets or sizes. The first seven bits in the first octet determine which of the next seven octets is present. If bit zero is set, offset1 is present. If bit one is set offset2 is present and so on.
Note that a more compact instruction does not change offset and size encoding. For example, if only offset2 is omitted like below, offset3 still contains bits 16-23. It does not become offset2 and contains bits 8-15 even if it’s right next to offset1.
+———-+———+———+ | 10000101 | offset1 | offset3 | +———-+———+———+
In its most compact form, this instruction only takes up one byte (0x80) with both offset and size omitted, which will have default values zero. There is another exception: size zero is automatically converted to 0x10000.

Instruction to add new data

+———-+============+ | 0xxxxxxx | data | +———-+============+
This is the instruction to construct the target object without the base object. The following data is appended to the target object. The first seven bits of the first octet determine the size of data in bytes. The size must be non-zero.

Reserved instruction

+———-+============ | 00000000 | +———-+============
This is the instruction reserved for future expansion.

ORIGINAL (VERSION 1) PACK-*.IDX FILES HAVE THE FOLLOWING FORMAT:

·
The header consists of 256 4-byte network byte order integers. N-th entry of this table records the number of objects in the corresponding pack, the first byte of whose object name is less than or equal to N. This is called the first-level fan-out table.

·
The header is followed by sorted 24-byte entries, one entry per object in the pack. Each entry is:
4-byte network byte order integer, recording where the object is stored in the packfile as the offset from the beginning.
one object name of the appropriate size.

·
The file is concluded with a trailer:
A copy of the pack checksum at the end of the corresponding packfile.
Index checksum of all of the above.

Pack Idx file:

    --  +--------------------------------+
fanout      | fanout[0] = 2 (for example)    |-.
table       +--------------------------------+ |
            | fanout[1]                      | |
            +--------------------------------+ |
            | fanout[2]                      | |
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
            | fanout[255] = total objects    |---.
        --  +--------------------------------+ | |
main        | offset                         | | |
index       | object name 00XXXXXXXXXXXXXXXX | | |
table       +--------------------------------+ | |
            | offset                         | | |
            | object name 00XXXXXXXXXXXXXXXX | | |
            +--------------------------------+<+ |
          .-| offset                         |   |
          | | object name 01XXXXXXXXXXXXXXXX |   |
          | +--------------------------------+   |
          | | offset                         |   |
          | | object name 01XXXXXXXXXXXXXXXX |   |
          | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   |
          | | offset                         |   |
          | | object name FFXXXXXXXXXXXXXXXX |   |
        --| +--------------------------------+<--+
trailer   | | packfile checksum              |
          | +--------------------------------+
          | | idxfile checksum               |
          | +--------------------------------+
          .-------.
                  |
Pack file entry: <+

packed object header: 1-byte size extension bit (MSB) type (next 3 bit) size0 (lower 4-bit) n-byte sizeN (as long as MSB is set, each 7-bit) size0..sizeN form 4+7+7+..+7 bit integer, size0 is the least significant part, and sizeN is the most significant part. packed object data: If it is not DELTA, then deflated bytes (the size above is the size before compression). If it is REF_DELTA, then base object name (the size above is the size of the delta data that follows). delta data, deflated. If it is OFS_DELTA, then n-byte offset (see below) interpreted as a negative offset from the type-byte of the header of the ofs-delta entry (the size above is the size of the delta data that follows). delta data, deflated.

offset encoding: n bytes with MSB set in all but the last one. The offset is then the number constructed by concatenating the lower 7 bit of each byte, and for n >= 2 adding 2^7 + 2^14 + … + 2^(7*(n-1)) to the result.

VERSION 2 PACK-*.IDX FILES SUPPORT PACKS LARGER THAN 4 GIB, AND

have some other reorganizations. They have the format:

·
A 4-byte magic number \377tOc which is an unreasonable fanout[0] value.

·
A 4-byte version number (= 2)

·
A 256-entry fan-out table just like v1.

·
A table of sorted object names. These are packed together without offset values to reduce the cache footprint of the binary search for a specific object name.

·
A table of 4-byte CRC32 values of the packed object data. This is new in v2 so compressed data can be copied directly from pack to pack during repacking without undetected data corruption.

·
A table of 4-byte offset values (in network byte order). These are usually 31-bit pack file offsets, but large offsets are encoded as an index into the next table with the msbit set.

·
A table of 8-byte offset entries (empty for pack files less than 2 GiB). Pack files are organized with heavily used objects toward the front, so most object references should not need to refer to this table.

·
The same trailer as a v1 pack file:
A copy of the pack checksum at the end of the corresponding packfile.
Index checksum of all of the above.

PACK-*.REV FILES HAVE THE FORMAT:

·
A 4-byte magic number 0x52494458 (RIDX).

·
A 4-byte version identifier (= 1).

·
A 4-byte hash function identifier (= 1 for SHA-1, 2 for SHA-256).

·
A table of index positions (one per packed object, num_objects in total, each a 4-byte unsigned integer in network order), sorted by their corresponding offsets in the packfile.

·
A trailer, containing a:
checksum of the corresponding packfile, and
a checksum of all of the above.

All 4-byte numbers are in network order.

PACK-*.MTIMES FILES HAVE THE FORMAT:

All 4-byte numbers are in network byte order.

·
A 4-byte magic number 0x4d544d45 (MTME).

·
A 4-byte version identifier (= 1).

·
A 4-byte hash function identifier (= 1 for SHA-1, 2 for SHA-256).

·
A table of 4-byte unsigned integers. The ith value is the modification time (mtime) of the ith object in the corresponding pack by lexicographic (index) order. The mtimes count standard epoch seconds.

·
A trailer, containing a checksum of the corresponding packfile, and a checksum of all of the above (each having length according to the specified hash function).

MULTI-PACK-INDEX (MIDX) FILES HAVE THE FOLLOWING FORMAT:

The multi-pack-index files refer to multiple pack-files and loose objects.

In order to allow extensions that add extra data to the MIDX, we organize the body into “chunks” and provide a lookup table at the beginning of the body. The header includes certain length values, such as the number of packs, the number of base MIDX files, hash lengths and types.

All 4-byte numbers are in network order.

HEADER:

4-byte signature: The signature is: {M, I, D, X}

1-byte version number: Git only writes or recognizes version 1.

1-byte Object Id Version We infer the length of object IDs (OIDs) from this value: 1 => SHA-1 2 => SHA-256 If the hash type does not match the repositorys hash algorithm, the multi-pack-index file should be ignored with a warning presented to the user.

1-byte number of “chunks”

1-byte number of base multi-pack-index files: This value is currently always zero.

4-byte number of pack files

CHUNK LOOKUP:

(C + 1) * 12 bytes providing the chunk offsets: First 4 bytes describe chunk id. Value 0 is a terminating label. Other 8 bytes provide offset in current file for chunk to start. (Chunks are provided in file-order, so you can infer the length using the next chunk position if necessary.)

The CHUNK LOOKUP matches the table of contents from the chunk-based file format, see linkgit:gitformat-chunk[5].

The remaining data in the body is described one chunk at a time, and these chunks may be given in any order. Chunks are required unless otherwise specified.

CHUNK DATA:

Packfile Names (ID: {P, N, A, M}) Store the names of packfiles as a sequence of NUL-terminated strings. There is no extra padding between the filenames, and they are listed in lexicographic order. The chunk itself is padded at the end with between 0 and 3 NUL bytes to make the chunk size a multiple of 4 bytes.

OID Fanout (ID: {O, I, D, F}) The ith entry, F[i], stores the number of OIDs with first byte at most i. Thus F[255] stores the total number of objects.

OID Lookup (ID: {O, I, D, L}) The OIDs for all objects in the MIDX are stored in lexicographic order in this chunk.

Object Offsets (ID: {O, O, F, F}) Stores two 4-byte values for every object. 1: The pack-int-id for the pack storing this object. 2: The offset within the pack. If all offsets are less than 2^32, then the large offset chunk will not exist and offsets are stored as in IDX v1. If there is at least one offset value larger than 2^32-1, then the large offset chunk must exist, and offsets larger than 2^31-1 must be stored in it instead. If the large offset chunk exists and the 31st bit is on, then removing that bit reveals the row in the large offsets containing the 8-byte offset of this object.

[Optional] Object Large Offsets (ID: {L, O, F, F}) 8-byte offsets into large packfiles.

[Optional] Bitmap pack order (ID: {R, I, D, X}) A list of MIDX positions (one per object in the MIDX, num_objects in total, each a 4-byte unsigned integer in network byte order), sorted according to their relative bitmap/pseudo-pack positions.

TRAILER:

Index checksum of the above contents.

MULTI-PACK-INDEX REVERSE INDEXES

Similar to the pack-based reverse index, the multi-pack index can also be used to generate a reverse index.

Instead of mapping between offset, pack-, and index position, this reverse index maps between an object’s position within the MIDX, and that object’s position within a pseudo-pack that the MIDX describes (i.e., the ith entry of the multi-pack reverse index holds the MIDX position of ith object in pseudo-pack order).

To clarify the difference between these orderings, consider a multi-pack reachability bitmap (which does not yet exist, but is what we are building towards here). Each bit needs to correspond to an object in the MIDX, and so we need an efficient mapping from bit position to MIDX position.

One solution is to let bits occupy the same position in the oid-sorted index stored by the MIDX. But because oids are effectively random, their resulting reachability bitmaps would have no locality, and thus compress poorly. (This is the reason that single-pack bitmaps use the pack ordering, and not the .idx ordering, for the same purpose.)

So we’d like to define an ordering for the whole MIDX based around pack ordering, which has far better locality (and thus compresses more efficiently). We can think of a pseudo-pack created by the concatenation of all of the packs in the MIDX. E.g., if we had a MIDX with three packs (a, b, c), with 10, 15, and 20 objects respectively, we can imagine an ordering of the objects like:

|a,0|a,1|…|a,9|b,0|b,1|…|b,14|c,0|c,1|…|c,19|

where the ordering of the packs is defined by the MIDX’s pack list, and then the ordering of objects within each pack is the same as the order in the actual packfile.

Given the list of packs and their counts of objects, you can naïvely reconstruct that pseudo-pack ordering (e.g., the object at position 27 must be (c,1) because packs “a” and “b” consumed 25 of the slots). But there’s a catch. Objects may be duplicated between packs, in which case the MIDX only stores one pointer to the object (and thus we’d want only one slot in the bitmap).

Callers could handle duplicates themselves by reading objects in order of their bit-position, but that’s linear in the number of objects, and much too expensive for ordinary bitmap lookups. Building a reverse index solves this, since it is the logical inverse of the index, and that index has already removed duplicates. But, building a reverse index on the fly can be expensive. Since we already have an on-disk format for pack-based reverse indexes, let’s reuse it for the MIDX’s pseudo-pack, too.

Objects from the MIDX are ordered as follows to string together the pseudo-pack. Let pack(o) return the pack from which o was selected by the MIDX, and define an ordering of packs based on their numeric ID (as stored by the MIDX). Let offset(o) return the object offset of o within pack(o). Then, compare o1 and o2 as follows:

·
If one of pack(o1) and pack(o2) is preferred and the other is not, then the preferred one sorts first.
(This is a detail that allows the MIDX bitmap to determine which pack should be used by the pack-reuse mechanism, since it can ask the MIDX for the pack containing the object at bit position 0).

·
If pack(o1) ≠ pack(o2), then sort the two objects in descending order based on the pack ID.

·
Otherwise, pack(o1) = pack(o2), and the objects are sorted in pack-order (i.e., o1 sorts ahead of o2 exactly when offset(o1) < offset(o2)).

In short, a MIDX’s pseudo-pack is the de-duplicated concatenation of objects in packs stored by the MIDX, laid out in pack order, and the packs arranged in MIDX order (with the preferred pack coming first).

The MIDX’s reverse index is stored in the optional RIDX chunk within the MIDX itself.

CRUFT PACKS

The cruft packs feature offer an alternative to Git’s traditional mechanism of removing unreachable objects. This document provides an overview of Git’s pruning mechanism, and how a cruft pack can be used instead to accomplish the same.

Background

To remove unreachable objects from your repository, Git offers git repack -Ad (see git-repack(1)). Quoting from the documentation:

[…] unreachable objects in a previous pack become loose, unpacked objects, instead of being left in the old pack. […] loose unreachable objects will be pruned according to normal expiry rules with the next git gc invocation.

Unreachable objects aren’t removed immediately, since doing so could race with an incoming push which may reference an object which is about to be deleted. Instead, those unreachable objects are stored as loose objects and stay that way until they are older than the expiration window, at which point they are removed by git-prune(1).

Git must store these unreachable objects loose in order to keep track of their per-object mtimes. If these unreachable objects were written into one big pack, then either freshening that pack (because an object contained within it was re-written) or creating a new pack of unreachable objects would cause the pack’s mtime to get updated, and the objects within it would never leave the expiration window. Instead, objects are stored loose in order to keep track of the individual object mtimes and avoid a situation where all cruft objects are freshened at once.

This can lead to undesirable situations when a repository contains many unreachable objects which have not yet left the grace period. Having large directories in the shards of .git/objects can lead to decreased performance in the repository. But given enough unreachable objects, this can lead to inode starvation and degrade the performance of the whole system. Since we can never pack those objects, these repositories often take up a large amount of disk space, since we can only zlib compress them, but not store them in delta chains.

Cruft packs

A cruft pack eliminates the need for storing unreachable objects in a loose state by including the per-object mtimes in a separate file alongside a single pack containing all loose objects.

A cruft pack is written by git repack –cruft when generating a new pack. git-pack-objects(1)s –cruft option. Note that git repack –cruft is a classic all-into-one repack, meaning that everything in the resulting pack is reachable, and everything else is unreachable. Once written, the –cruft option instructs git repack to generate another pack containing only objects not packed in the previous step (which equates to packing all unreachable objects together). This progresses as follows:

1.
Enumerate every object, marking any object which is (a) not contained in a kept-pack, and (b) whose mtime is within the grace period as a traversal tip.

2.
Perform a reachability traversal based on the tips gathered in the previous step, adding every object along the way to the pack.

3.
Write the pack out, along with a .mtimes file that records the per-object timestamps.

This mode is invoked internally by git-repack(1) when instructed to write a cruft pack. Crucially, the set of in-core kept packs is exactly the set of packs which will not be deleted by the repack; in other words, they contain all of the repository’s reachable objects.

When a repository already has a cruft pack, git repack –cruft typically only adds objects to it. An exception to this is when git repack is given the –cruft-expiration option, which allows the generated cruft pack to omit expired objects instead of waiting for git-gc(1) to expire those objects later on.

It is git-gc(1) that is typically responsible for removing expired unreachable objects.

Alternatives

Notable alternatives to this design include:

·
The location of the per-object mtime data.

On the location of mtime data, a new auxiliary file tied to the pack was chosen to avoid complicating the .idx format. If the .idx format were ever to gain support for optional chunks of data, it may make sense to consolidate the .mtimes format into the .idx itself.

GIT

Part of the git(1) suite

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

315 - Linux cli command idmapd.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command idmapd.conf and provides detailed information about the command idmapd.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the idmapd.conf.

NAME 🖥️ idmapd.conf 🖥️

configuration file for libnfsidmap

SYNOPSIS

Configuration file for libnfsidmap. Used by idmapd and svcgssd to map NFSv4 name to and from ids.

DESCRIPTION

The idmapd.conf configuration file consists of several sections, initiated by strings of the form [General] and [Mapping]. Each section may contain lines of the form

  variable = value

The recognized sections and their recognized variables are as follows:

[General] section variables

Verbosity
Verbosity level of debugging (Default: 0)

Domain
The local NFSv4 domain name. An NFSv4 domain is a namespace with a unique username<->UID and groupname<->GID mapping. (Default: Host’s fully-qualified DNS domain name)

No-Strip
In multi-domain environments, some NFS servers will append the identity management domain to the owner and owner_group in lieu of a true NFSv4 domain. This option can facilitate lookups in such environments. If set to a value other than “none”, the nsswitch plugin will first pass the name to the password/group lookup function without stripping the domain off. If that mapping fails then the plugin will try again using the old method (comparing the domain in the string to the Domain value, stripping it if it matches, and passing the resulting short name to the lookup function). Valid values are “user”, “group”, “both”, and “none”. (Default: “none”)

Reformat-Group
Winbind has a quirk whereby doing a group lookup in UPN format (e.g. [email protected]) will cause the group to be displayed prefixed with the full domain in uppercase (e.g. AMERICAS.EXAMPLE.COM\staff) instead of in the familiar netbios name format (e.g. AMERICAS\staff). Setting this option to true causes the name to be reformatted before passing it to the group lookup function in order to work around this. This setting is ignored unless No-Strip is set to either “both” or “group”. (Default: “false”)

Local-Realms
A comma-separated list of Kerberos realm names that may be considered equivalent to the local realm name. For example, users [email protected] and [email protected] may be considered to be the same user in the specified Domain. (Default: the host’s default realm name)
Note: If a value is specified here, the default local realm must be included as well.

[Mapping] section variables

Nobody-User
Local user name to be used when a mapping cannot be completed.

Nobody-Group
Local group name to be used when a mapping cannot be completed.

[Translation] section variables

Method
A comma-separated, ordered list of mapping methods (plug-ins) to use when mapping between NFSv4 names and local IDs. Each specified method is tried in order until a mapping is found, or there are no more methods to try. The methods included in the default distribution include “nsswitch”, “umich_ldap”, and “static”. (Default: nsswitch)

GSS-Methods
An optional comma-separated, ordered list of mapping methods (plug-ins) to use when mapping between GSS Authenticated names and local IDs. (Default: the same list as specified for Method)

[Static] section variables

The “static” translation method uses a static list of GSS-Authenticated names to local user names. Entries in the list are of the form:

 principal@REALM = localusername

[REGEX] section variables

If the “regex” translation method is specified, the following variables within the [REGEX] section are used to map between NFS4 names and local IDs.

User-Regex
Case-insensitive regular expression that extracts the local user name from an NFSv4 name. Multiple expressions may be concatenated with ‘|’. The first match will be used. There is no default. A basic regular expression for domain DOMAIN.ORG and realm MY.DOMAIN.ORG would be:

^DOMAIN\([^@]+)@MY.DOMAIN.ORG$

Group-Regex
Case-insensitive regular expression that extracts the local group name from an NFSv4 name. Multiple expressions may be concatenated with ‘|’. The first match will be used. There is no default. A basic regular expression for domain DOMAIN.ORG and realm MY.DOMAIN.ORG would be:

^([^@]+)@[email protected]$|^DOMAIN\([^@]+)@MY.DOMAIN.ORG$

Prepend-Before-User
Constant string to put before a local user name when building an NFSv4 name. Usually this is the short domain name followed by ‘’. (Default: none)

Append-After-User
Constant string to put after a local user name when building an NFSv4 name. Usually this is ‘@’ followed by the default realm. (Default: none)

Prepend-Before-Group
Constant string to put before a local group name when building an NFSv4 name. Usually not used. (Default: none)

Append-After-Group
Constant string to put before a local group name when building an NFSv4 name. Usually this is ‘@’ followed by the domain name followed by another ‘@’ and the default realm. (Default: none)

Group-Name-Prefix
Constant string that is prepended to a local group name when converting it to an NFSv4 name. If an NFSv4 group name has this prefix it is removed when converting it to a local group name. With this group names of a central directory can be shortened for an isolated organizational unit if all groups have a common prefix. (Default: none)

Group-Name-No-Prefix-Regex
Case-insensitive regular expression to exclude groups from adding and removing the prefix set by Group-Name-Prefix. The regular expression must match both the remote and local group names. Multiple expressions may be concatenated with ‘|’. (Default: none)

[UMICH_SCHEMA] section variables

If the “umich_ldap” translation method is specified, the following variables within the [UMICH_SCHEMA] section are used.

LDAP_server
LDAP server name or address (Required if using UMICH_LDAP)

LDAP_base
Absolute LDAP search base. (Required if using UMICH_LDAP)

LDAP_people_base
Absolute LDAP search base for people accounts. (Default: The LDAP_base value)

LDAP_group_base
Absolute LDAP search base for group accounts. (Default: The LDAP_base value)

LDAP_canonicalize_name
Whether or not to perform name canonicalization on the name given as LDAP_server (Default: “true”)

LDAP_follow_referrals
Whether or not to follow ldap referrals. (Default: “true”)

LDAP_use_ssl
Set to “true” to enable SSL communication with the LDAP server. (Default: “false”)

LDAP_ca_cert
Location of a trusted CA certificate used when SSL is enabled (Required if LDAP_use_ssl is true and LDAP_tls_reqcert is not set to never)

LDAP_tls_reqcert
Controls the LDAP server certificate validation behavior. It can take the same values as ldap.conf(5)’s TLS_REQCERT tunable. (Default: “hard”)

LDAP_timeout_seconds
Number of seconds before timing out an LDAP request (Default: 4)

LDAP_sasl_mech
SASL mechanism to be used for sasl authentication. Required if SASL auth is to be used (Default: None)

LDAP_realm
SASL realm to be used for sasl authentication. (Default: None)

LDAP_sasl_authcid
Authentication identity to be used for sasl authentication. (Default: None)

LDAP_sasl_authzid
Authorization identity to be used for sasl authentication. (Default: None)

LDAP_sasl_secprops
Cyrus SASL security properties. It can the same values as ldap.conf(5)’s sasl_secprops.

LDAP_sasl_canonicalize
Specifies whether the LDAP server hostname should be canonicalised. If set to yes LDAP lib with do a reverse hostname lookup. If this is not set the LDAP library’s default will be used. (Default: None)

LDAP_sasl_krb5_ccname
Path to kerberos credential cache. If it is not set then the value of environment variable KRB5CCNAME will be used. If the environment variable is not set then the default mechanism of kerberos library will be used.

NFSv4_person_objectclass
The object class name for people accounts in your local LDAP schema (Default: NFSv4RemotePerson)

NFSv4_name_attr
Your local schema’s attribute name to be used for NFSv4 user names (Default: NFSv4Name)

NFSv4_uid_attr
Your local schema’s attribute name to be used for uidNumber (Default: uidNumber)

GSS_principal_attr
Your local schema’s attribute name for GSSAPI Principal names (Default: GSSAuthName)

NFSv4_acctname_attr
Your local schema’s attribute name to be used for account names (Default: uid)

NFSv4_group_objectclass
The object class name for group accounts in your local LDAP schema (Default: NFSv4RemoteGroup)

NFSv4_gid_attr
Your local schema’s attribute name to be used for gidNumber (Default: gidNumber)

NFSv4_group_attr
Your local schema’s attribute name to be used for NFSv4 group names (Default: NFSv4Name)

LDAP_use_memberof_for_groups
Some LDAP servers do a better job with indexing where searching through all the groups searching for the user in the memberuid list. Others like SunOne directory that search can takes minutes if there are thousands of groups. So setting LDAP_use_memberof_for_groups to true in the configuration file will use the memberof lists of the account and search through only those groups to obtain gids. (Default: false)

NFSv4_member_attr
If LDAP_use_memberof_for_groups is true, this is the attribute to be searched for. (Default: memberUid)

NFSv4_grouplist_filter
An optional search filter for determining group membership. (No Default)

EXAMPLES

An example /etc/idmapd.conf file:

[General]

Verbosity = 0
Domain = domain.org
Local-Realms = DOMAIN.ORG,MY.DOMAIN.ORG,YOUR.DOMAIN.ORG

[Mapping]

Nobody-User = nfsnobody
Nobody-Group = nfsnobody

[Translation]

Method = umich_ldap,regex,nsswitch
GSS-Methods = umich_ldap,regex,static

[Static]

[email protected] = johnny

[Regex]

User-Regex = ^DOMAIN\([^@]+)@DOMAIN.ORG$
Group-Regex = ^([^@]+)@[email protected]$|^DOMAIN\([^@]+)@DOMAIN.ORG$
Prepend-Before-User = DOMAIN 
Append-After-User = @DOMAIN.ORG
Append-After-Group = @[email protected]
Group-Name-Prefix = sales-
Group-Name-No-Prefix-Regex = -personal-group$

[UMICH_SCHEMA]

LDAP_server = ldap.domain.org
LDAP_base = dc=org,dc=domain

BUGS

Report bugs to <[email protected]>

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

316 - Linux cli command proc_swaps

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_swaps and provides detailed information about the command proc_swaps, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_swaps.

NAME 🖥️ proc_swaps 🖥️

swap areas

DESCRIPTION

/proc/swaps
Swap areas in use. See also swapon(8).

317 - Linux cli command org.bluez.Adapter

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.Adapter and provides detailed information about the command org.bluez.Adapter, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.Adapter.

NAME 🖥️ org.bluez.Adapter 🖥️

BlueZ D-Bus Adapter API documentation

INTERFACE

Service
org.bluez
Interface
org.bluez.Adapter1
Object path
[variable prefix]/{hci0,hci1,…}

Methods

void StartDiscovery()

Starts device discovery session which may include starting an inquiry and/or scanning procedures and remote device name resolving.
Use StopDiscovery to release the sessions acquired.
This process will start creating Device objects as new devices are discovered.
During discovery RSSI delta-threshold is imposed.
Each client can request a single device discovery session per adapter.
Possible errors:
org.bluez.Error.NotReady
org.bluez.Error.Failed
org.bluez.Error.InProgress

void StopDiscovery()

Stops device discovery session started by StartDiscovery.
Note that a discovery procedure is shared between all discovery sessions thus calling StopDiscovery will only release a single session and discovery will stop when all sessions from all clients have finished.
Possible errors:
org.bluez.Error.NotReady
org.bluez.Error.Failed
org.bluez.Error.NotAuthorized

void RemoveDevice(object device)

Removes the remote device object at the given path including cahed information such as bonding information.
Possible errors:
org.bluez.Error.InvalidArguments
org.bluez.Error.Failed

void SetDiscoveryFilter(dict filter)

Sets the device discovery filter for the caller. When this method is called with no filter parameter, filter is removed.
Possible filter values:
array{string} UUIDs
Filter by service UUIDs, empty means match any UUID.
When a remote device is found that advertises any UUID from UUIDs, it will be reported if:
Pathloss and RSSI are both empty.
only Pathloss param is set, device advertise TX power, and computed pathloss is less than Pathloss param.
only RSSI param is set, and received RSSI is higher than RSSI param.
int16 RSSI
RSSI threshold value.
PropertiesChanged signals will be emitted for already existing Device objects, with updated RSSI value. If one or more discovery filters have been set, the RSSI delta-threshold, that is imposed by StartDiscovery by default, will not be applied.
uint16 Pathloss
Pathloss threshold value.
PropertiesChanged signals will be emitted for already existing Device objects, with updated Pathloss value.
string Transport (Default “auto”)
Transport parameter determines the type of scan.
Possible values:
“auto”
Interleaved scan, use LE, BREDR, or both, depending on what’s currently enabled.
“bredr”
BR/EDR inquiry only.
“le”
LE scan only.
bool DuplicateData (Default true)
Disables duplicate detection of advertisement data.
When enabled PropertiesChanged signals will be generated for either ManufacturerData and ServiceData everytime they are discovered.
bool Discoverable (Default false)
Make adapter discoverable while discovering, if the adapter is already discoverable setting this filter won’t do anything.
string Pattern (Default none)
Discover devices where the pattern matches either the prefix of the address or device name which is convenient way to limited the number of device objects created during a discovery.
When set disregards device discoverable flags.
Note: The pattern matching is ignored if there are other client that don’t set any pattern as it work as a logical OR, also setting empty string "" pattern will match any device found.
When discovery filter is set, Device objects will be created as new devices with matching criteria are discovered regardless of they are connectable or discoverable which enables listening to non-connectable and non-discoverable devices.
When multiple clients call SetDiscoveryFilter, their filters are internally merged, and notifications about new devices are sent to all clients. Therefore, each client must check that device updates actually match its filter.
When SetDiscoveryFilter is called multiple times by the same client, last filter passed will be active for given client.
SetDiscoveryFilter can be called before StartDiscovery. It is useful when client will create first discovery session, to ensure that proper scan will be started right after call to StartDiscovery.
Possible errors:
org.bluez.Error.NotReady
org.bluez.Error.NotSupported
org.bluez.Error.Failed

array{string} GetDiscoveryFilters()

Returns available filters that can be given to SetDiscoveryFilter.
Possible errors: None

object ConnectDevice(dict properties) [experimental]

connects to device without need of performing General Discovery. Connection mechanism is similar to Connect method on org.bluez.Device1(5) interface with exception that this method returns success when physical connection is established and you can specify bearer to connect with parameter. After this method returns, services discovery will continue and any supported profile will be connected. There is no need for calling Connect on Device1 after this call. If connection was successful this method returns object path to created device object or device that already exist.
Possible properties values:
string Address (Mandatory)
The Bluetooth device address of the remote device.
string AddressType (Default “BR/EDR”)
The Bluetooth device Address Type. This is address type that should be used for initial connection.
Possible values:
“public”
Public address
“random”
Random address
Possible errors:
org.bluez.Error.InvalidArguments
org.bluez.Error.AlreadyExists
org.bluez.Error.NotSupported
org.bluez.Error.NotReady
org.bluez.Error.Failed

Properties

string Address [readonly]

The Bluetooth device address.

string AddressType [readonly]

The Bluetooth Address Type. For dual-mode and BR/EDR only adapter this defaults to “public”. Single mode LE adapters may have either value. With privacy enabled this contains type of Identity Address and not type of address used for connection.
Possible values:
“public”
Public address.
“random
Random address.

string Name [readonly]

The Bluetooth system name (pretty hostname).
This property is either a static system default or controlled by an external daemon providing access to the pretty hostname configuration.

string Alias [readwrite]

The Bluetooth friendly name. This value can be changed.
In case no alias is set, it will return the system provided name. Setting an empty string as alias will convert it back to the system provided name.
When resetting the alias with an empty string, the property will default back to system name.
On a well configured system, this property never needs to be changed since it defaults to the system name and provides the pretty hostname. Only if the local name needs to be different from the pretty hostname, this property should be used as last resort.

uint32 Class [readonly]

The Bluetooth class of device.
This property represents the value that is either automatically configured by DMI/ACPI information or provided as static configuration.

boolean Powered [readwrite]

Switch an adapter on or off. This will also set the appropriate connectable state of the controller.
The value of this property is not persistent. After restart or unplugging of the adapter it will reset back to false.

string PowerState [readonly, experimental]

The power state of an adapter.
The power state will show whether the adapter is turning off, or turning on, as well as being on or off.
Possible values:
“on”
Powered on.
“off”
Powered off
“off-enabling”
Transitioning from “off” to “on”.
“on-disabling”
Transitioning from “on” to “off”.
“off-blocked”
Blocked by rfkill.

boolean Discoverable [readwrite] (Default: false)

Switch an adapter to discoverable or non-discoverable to either make it visible or hide it. This is a global setting and should only be used by the settings application.
If the DiscoverableTimeout is set to a non-zero value then the system will set this value back to false after the timer expired.
In case the adapter is switched off, setting this value will fail.
When changing the Powered property the new state of this property will be updated via a PropertiesChanged signal.

boolean Pairable [readwrite] (Default: true)

Switch an adapter to pairable or non-pairable. This is a global setting and should only be used by the settings application.
Note that this property only affects incoming pairing requests.

uint32 PairableTimeout [readwrite] (Default: 0)

The pairable timeout in seconds. A value of zero means that the timeout is disabled and it will stay in pairable mode forever.

uint32 DiscoverableTimeout [readwrite] (Default: 180)

The discoverable timeout in seconds. A value of zero means that the timeout is disabled and it will stay in discoverable/limited mode forever.

boolean Discovering [readonly]

Indicates that a device discovery procedure is active.

array{string} UUIDs [readonly]

List of 128-bit UUIDs that represents the available local services.

string Modalias [readonly, optional]

Local Device ID information in modalias format used by the kernel and udev.

array{string} Roles [readonly]

List of supported roles.
Possible values:
“central”
Supports the central role.
“peripheral”
Supports the peripheral role.
“central-peripheral”
Supports both roles concurrently.

array{string} ExperimentalFeatures [readonly, optional]

List of 128-bit UUIDs that represents the experimental features currently enabled.

uint16 Manufacturer [readonly]

The manufacturer of the device, as a uint16 company identifier defined by the Core Bluetooth Specification.

byte Version [readonly]

The Bluetooth version supported by the device, as a core version code defined by the Core Bluetooth Specification.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

318 - Linux cli command odbc.ini

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command odbc.ini and provides detailed information about the command odbc.ini, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the odbc.ini.

NAME 🖥️ odbc.ini 🖥️

unixODBC data source configuration files

DESCRIPTION

/etc/odbc.ini is a system-wide configuration file for ODBC Data Source Names (DSNs).

$HOME/.odbc.ini is a user-specific configuration file for ODBC Data Source Names (DSNs).

Paths to both configuration files can be overridden by unixODBC build options. Call odbcinst -j to determine the default configuration file paths on your system.

NOTES

Templates

Many ODBC drivers come with .ini file templates. Using odbcinst to install these templates is recommended.

FILE FORMAT

odbc.ini follows the pesudo-standard ini file syntax convention of one or more [section headings], each followed by zero or more key = value attributes.

[ODBC Data Sources] section
This mandatory section lists each data source name (DSN) as a key. The associated values serve as comments. Each entry must be matched by an ini file [section] describing the data source.

Data Source Name [section]
Each data source is identified by a [section header], which is the DSN name used by applications. Each DSN definition section may contain values for the keys:

· Driver (REQUIRED)
The name of the ODBC driver to use for the DSN. The name must exactly match the [section name] of the driver definition stored in odbcinst.ini (and listed by odbcinst -q -d).

· Description
Human-readable data source description.

· Database
Database name or identifier. The meaning is driver-specific and can specify a file path, Unix socket path, an identifier relative to a server name, etc.

· Servername
Server name. The meaning is driver-specific but generally specifies a DNS name, IP network address or driver-specific discovery identifier.

For a full list of supported parameters, refer to the HTML-formatted “Administrator Manual” shipped with unixODBC, the documentation for your ODBC driver and any data-source templates supplied by your driver.

EXAMPLES

An example odbc.ini configuration file is shown in the “Administrator Manual” shipped with unixODBC.

AUTHORS

The authors of unixODBC are Peter Harvey <[email protected]> and Nick Gorham <[email protected]>.

For a full list of contributors, refer to the AUTHORS file.

COPYRIGHT

unixODBC is licensed under the GNU Lesser General Public License. For details about the license, see the COPYING file.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

319 - Linux cli command login.defs

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command login.defs and provides detailed information about the command login.defs, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the login.defs.

NAME 🖥️ login.defs 🖥️

shadow password suite configuration

DESCRIPTION

The /etc/login.defs file defines the site-specific configuration for the shadow password suite. This file is required. Absence of this file will not prevent system operation, but will probably result in undesirable operation.

This file is a readable text file, each line of the file describing one configuration parameter. The lines consist of a configuration name and value, separated by whitespace. Blank lines and comment lines are ignored. Comments are introduced with a “#” pound sign and the pound sign must be the first non-white character of the line.

Parameter values may be of four types: strings, booleans, numbers, and long numbers. A string is comprised of any printable characters. A boolean should be either the value yes or no. An undefined boolean parameter or one with a value other than these will be given a no value. Numbers (both regular and long) may be either decimal values, octal values (precede the value with 0) or hexadecimal values (precede the value with 0x). The maximum value of the regular and long numeric parameters is machine-dependent.

The following configuration items are provided:

CHFN_RESTRICT (string)

This parameter specifies which values in the gecos field of the /etc/passwd file may be changed by regular users using the chfn program. It can be any combination of letters f, r, w, h, for Full name, Room number, Work phone, and Home phone, respectively. For backward compatibility, yes is equivalent to rwh and no is equivalent to frwh. If not specified, only the superuser can make any changes. The most restrictive setting is better achieved by not installing chfn SUID.

CREATE_HOME (boolean)

Indicate if a home directory should be created by default for new users.
This setting does not apply to system users, and can be overridden on the command line.

DEFAULT_HOME (boolean)

Indicate if login is allowed if we cant cd to the home directory. Default is no.
If set to yes, the user will login in the root (/) directory if it is not possible to cd to her home directory.

ENCRYPT_METHOD (string)

This defines the system default encryption algorithm for encrypting passwords (if no algorithm are specified on the command line).
It can take one of these values: DES (default), MD5, SHA256, SHA512, YESCRYPT. MD5 and DES should not be used for new hashes, see crypt(5) for recommendations.
Note: this parameter overrides the MD5_CRYPT_ENAB variable.
Note: This only affect the generation of group passwords. The generation of user passwords is done by PAM and subject to the PAM configuration. It is recommended to set this variable consistently with the PAM configuration.

ENV_PATH (string)

If set, it will be used to define the PATH environment variable when a regular user login. The value is a colon separated list of paths (for example /bin:/usr/bin) and can be preceded by PATH=. The default value is PATH=/bin:/usr/bin.

ENV_SUPATH (string)

If set, it will be used to define the PATH environment variable when the superuser login. The value is a colon separated list of paths (for example /sbin:/bin:/usr/sbin:/usr/bin) and can be preceded by PATH=. The default value is PATH=/sbin:/bin:/usr/sbin:/usr/bin.

ERASECHAR (number)

Terminal ERASE character (010 = backspace, 0177 = DEL).
The value can be prefixed “0” for an octal value, or “0x” for an hexadecimal value.

FAIL_DELAY (number)

Delay in seconds before being allowed another attempt after a login failure.

FAKE_SHELL (string)

If set, login will execute this shell instead of the users shell specified in /etc/passwd.

GID_MAX (number), GID_MIN (number)

Range of group IDs used for the creation of regular groups by useradd, groupadd, or newusers.
The default value for GID_MIN (resp. GID_MAX) is 1000 (resp. 60000).

HOME_MODE (number)

The mode for new home directories. If not specified, the UMASK is used to create the mode.
useradd and newusers use this to set the mode of the home directory they create.

HUSHLOGIN_FILE (string)

If defined, this file can inhibit all the usual chatter during the login sequence. If a full pathname is specified, then hushed mode will be enabled if the users name or shell are found in the file. If not a full pathname, then hushed mode will be enabled if the file exists in the users home directory.

KILLCHAR (number)

Terminal KILL character (025 = CTRL/U).
The value can be prefixed “0” for an octal value, or “0x” for an hexadecimal value.

LASTLOG_UID_MAX (number)

Highest user ID number for which the lastlog entries should be updated. As higher user IDs are usually tracked by remote user identity and authentication services there is no need to create a huge sparse lastlog file for them.
No LASTLOG_UID_MAX option present in the configuration means that there is no user ID limit for writing lastlog entries.

LOG_OK_LOGINS (boolean)

Enable logging of successful logins.

LOG_UNKFAIL_ENAB (boolean)

Enable display of unknown usernames when login failures are recorded.
Note: logging unknown usernames may be a security issue if an user enter her password instead of her login name.

LOGIN_RETRIES (number)

Maximum number of login retries in case of bad password.
This will most likely be overridden by PAM, since the default pam_unix module has its own built in of 3 retries. However, this is a safe fallback in case you are using an authentication module that does not enforce PAM_MAXTRIES.

LOGIN_TIMEOUT (number)

Max time in seconds for login.

MAIL_DIR (string)

The mail spool directory. This is needed to manipulate the mailbox when its corresponding user account is modified or deleted. If not specified, a compile-time default is used. The parameter CREATE_MAIL_SPOOL in /etc/default/useradd determines whether the mail spool should be created.

MAIL_FILE (string)

Defines the location of the users mail spool files relatively to their home directory.

The MAIL_DIR and MAIL_FILE variables are used by useradd, usermod, and userdel to create, move, or delete the users mail spool.

MAX_MEMBERS_PER_GROUP (number)

Maximum members per group entry. When the maximum is reached, a new group entry (line) is started in /etc/group (with the same name, same password, and same GID).
The default value is 0, meaning that there are no limits in the number of members in a group.
This feature (split group) permits to limit the length of lines in the group file. This is useful to make sure that lines for NIS groups are not larger than 1024 characters.
If you need to enforce such limit, you can use 25.
Note: split groups may not be supported by all tools (even in the Shadow toolsuite). You should not use this variable unless you really need it.

MD5_CRYPT_ENAB (boolean)

Indicate if passwords must be encrypted using the MD5-based algorithm. If set to yes, new passwords will be encrypted using the MD5-based algorithm compatible with the one used by recent releases of FreeBSD. It supports passwords of unlimited length and longer salt strings. Set to no if you need to copy encrypted passwords to other systems which dont understand the new algorithm. Default is no.
This variable is superseded by the ENCRYPT_METHOD variable or by any command line option used to configure the encryption algorithm.
This variable is deprecated. You should use ENCRYPT_METHOD.
Note: This only affect the generation of group passwords. The generation of user passwords is done by PAM and subject to the PAM configuration. It is recommended to set this variable consistently with the PAM configuration.

NONEXISTENT (string)

If a system account intentionally does not have a home directory that exists, this string can be provided in the /etc/passwd entry for the account to indicate this. The result is that pwck will not emit a spurious warning for this account.

PASS_MAX_DAYS (number)

The maximum number of days a password may be used. If the password is older than this, a password change will be forced. If not specified, -1 will be assumed (which disables the restriction).

PASS_MIN_DAYS (number)

The minimum number of days allowed between password changes. Any password changes attempted sooner than this will be rejected. If not specified, 0 will be assumed (which disables the restriction).

PASS_WARN_AGE (number)

The number of days warning given before a password expires. A zero means warning is given only upon the day of expiration, a value of -1 means no warning is given. If not specified, no warning will be provided.

PASS_MAX_DAYS, PASS_MIN_DAYS and PASS_WARN_AGE are only used at the time of account creation. Any changes to these settings wont affect existing accounts.

SHA_CRYPT_MIN_ROUNDS (number), SHA_CRYPT_MAX_ROUNDS (number)

When ENCRYPT_METHOD is set to SHA256 or SHA512, this defines the number of SHA rounds used by the encryption algorithm by default (when the number of rounds is not specified on the command line).
With a lot of rounds, it is more difficult to brute force the password. But note also that more CPU resources will be needed to authenticate users.
If not specified, the libc will choose the default number of rounds (5000), which is orders of magnitude too low for modern hardware.
The values must be inside the 1000-999,999,999 range.
If only one of the SHA_CRYPT_MIN_ROUNDS or SHA_CRYPT_MAX_ROUNDS values is set, then this value will be used.
If SHA_CRYPT_MIN_ROUNDS > SHA_CRYPT_MAX_ROUNDS, the highest value will be used.
Note: This only affect the generation of group passwords. The generation of user passwords is done by PAM and subject to the PAM configuration. It is recommended to set this variable consistently with the PAM configuration.

SULOG_FILE (string)

If defined, all su activity is logged to this file.

SU_NAME (string)

If defined, the command name to display when running “su -”. For example, if this is defined as “su” then a “ps” will display the command is “-su”. If not defined, then “ps” would display the name of the shell actually being run, e.g. something like “-sh”.

SUB_GID_MIN (number), SUB_GID_MAX (number), SUB_GID_COUNT (number)

If /etc/subuid exists, the commands useradd and newusers (unless the user already have subordinate group IDs) allocate SUB_GID_COUNT unused group IDs from the range SUB_GID_MIN to SUB_GID_MAX for each new user.
The default values for SUB_GID_MIN, SUB_GID_MAX, SUB_GID_COUNT are respectively 100000, 600100000 and 65536.

SUB_UID_MIN (number), SUB_UID_MAX (number), SUB_UID_COUNT (number)

If /etc/subuid exists, the commands useradd and newusers (unless the user already have subordinate user IDs) allocate SUB_UID_COUNT unused user IDs from the range SUB_UID_MIN to SUB_UID_MAX for each new user.
The default values for SUB_UID_MIN, SUB_UID_MAX, SUB_UID_COUNT are respectively 100000, 600100000 and 65536.

SYS_GID_MAX (number), SYS_GID_MIN (number)

Range of group IDs used for the creation of system groups by useradd, groupadd, or newusers.
The default value for SYS_GID_MIN (resp. SYS_GID_MAX) is 101 (resp. GID_MIN-1).

SYS_UID_MAX (number), SYS_UID_MIN (number)

Range of user IDs used for the creation of system users by useradd or newusers.
The default value for SYS_UID_MIN (resp. SYS_UID_MAX) is 101 (resp. UID_MIN-1).

SYSLOG_SG_ENAB (boolean)

Enable “syslog” logging of sg activity.

SYSLOG_SU_ENAB (boolean)

Enable “syslog” logging of su activity - in addition to sulog file logging.

TTYGROUP (string), TTYPERM (string)

The terminal permissions: the login tty will be owned by the TTYGROUP group, and the permissions will be set to TTYPERM.
TTYGROUP can be either the name of a group or a numeric group identifier.
If TTYGROUP is not defined, then the group ownership of the terminal is set to the users primary group. If TTYPERM is not defined, then the permissions are set to 0600.
If you have a write program which is “setgid” to a special group which owns the terminals, define TTYGROUP to the group number and TTYPERM to 0620. Otherwise leave TTYGROUP commented out and assign TTYPERM to either 622 or 600.

TTYTYPE_FILE (string)

If defined, file which maps tty line to TERM environment parameter. Each line of the file is in a format something like “vt100 tty01”.

UID_MAX (number), UID_MIN (number)

Range of user IDs used for the creation of regular users by useradd or newusers.
The default value for UID_MIN (resp. UID_MAX) is 1000 (resp. 60000).

UMASK (number)

The file mode creation mask is initialized to this value. If not specified, the mask will be initialized to 022.
useradd and newusers use this mask to set the mode of the home directory they create if HOME_MODE is not set.
It is also used by pam_umask as the default umask value.

USERDEL_CMD (string)

If defined, this command is run when removing a user. It should remove any at/cron/print jobs etc. owned by the user to be removed (passed as the first argument).
The return code of the script is not taken into account.
Here is an example script, which removes the users cron, at and print jobs:
#! /bin/sh
# Check for the required argument.
if [ $# != 1 ]; then
	echo "Usage: $0 username"
	exit 1
fi

# Remove cron jobs.
crontab -r -u $1

# Remove at jobs.
# Note that it will remove any jobs owned by the same UID,
# even if it was shared by a different username.
AT_SPOOL_DIR=/var/spool/cron/atjobs
find $AT_SPOOL_DIR -name "[^.]*" -type f -user $1 -delete \;

# Remove print jobs.
lprm $1

# All done.
exit 0

USERGROUPS_ENAB (boolean)

If set to yes, userdel will remove the users group if it contains no more members, and useradd will create by default a group with the name of the user.

YESCRYPT_COST_FACTOR (number)

When ENCRYPT_METHOD is set to YESCRYPT, this defines the cost factor used by the encryption algorithm by default (when the cost factor is not specified on the command line).
With a high cost factor, it is more difficult to brute force the password. But note also that more CPU resources will be needed to authenticate users.
The value must be inside the 1-11 range.
Note: This only affect the generation of group passwords. The generation of user passwords is done by PAM and subject to the PAM configuration. It is recommended to set this variable consistently with the PAM configuration.

CROSS REFERENCES

The following cross references show which programs in the shadow password suite use which parameters.

chfn

CHFN_RESTRICT

chgpasswd

ENCRYPT_METHOD MAX_MEMBERS_PER_GROUP MD5_CRYPT_ENAB SHA_CRYPT_MAX_ROUNDS SHA_CRYPT_MIN_ROUNDS YESCRYPT_COST_FACTOR

chpasswd

SHA_CRYPT_MAX_ROUNDS SHA_CRYPT_MIN_ROUNDS YESCRYPT_COST_FACTOR

gpasswd

ENCRYPT_METHOD MAX_MEMBERS_PER_GROUP MD5_CRYPT_ENAB SHA_CRYPT_MAX_ROUNDS SHA_CRYPT_MIN_ROUNDS YESCRYPT_COST_FACTOR

groupadd

GID_MAX GID_MIN MAX_MEMBERS_PER_GROUP SYS_GID_MAX SYS_GID_MIN

groupdel

MAX_MEMBERS_PER_GROUP

groupmems

MAX_MEMBERS_PER_GROUP

groupmod

MAX_MEMBERS_PER_GROUP

grpck

MAX_MEMBERS_PER_GROUP

grpconv

MAX_MEMBERS_PER_GROUP

grpunconv

MAX_MEMBERS_PER_GROUP

lastlog

LASTLOG_UID_MAX

CONSOLE_GROUPS DEFAULT_HOME ERASECHAR FAIL_DELAY FAKE_SHELL HUSHLOGIN_FILE KILLCHAR LOGIN_RETRIES LOGIN_TIMEOUT LOG_OK_LOGINS LOG_UNKFAIL_ENAB TTYGROUP TTYPERM TTYTYPE_FILE USERGROUPS_ENAB

newgrp / sg

SYSLOG_SG_ENAB

newusers

ENCRYPT_METHOD GID_MAX GID_MIN MAX_MEMBERS_PER_GROUP MD5_CRYPT_ENAB HOME_MODE PASS_MAX_DAYS PASS_MIN_DAYS PASS_WARN_AGE SHA_CRYPT_MAX_ROUNDS SHA_CRYPT_MIN_ROUNDS SUB_GID_COUNT SUB_GID_MAX SUB_GID_MIN SUB_UID_COUNT SUB_UID_MAX SUB_UID_MIN SYS_GID_MAX SYS_GID_MIN SYS_UID_MAX SYS_UID_MIN UID_MAX UID_MIN UMASK YESCRYPT_COST_FACTOR

pwck

PASS_MAX_DAYS PASS_MIN_DAYS PASS_WARN_AGE

pwconv

PASS_MAX_DAYS PASS_MIN_DAYS PASS_WARN_AGE

CONSOLE_GROUPS DEFAULT_HOME ENV_PATH ENV_SUPATH SULOG_FILE SU_NAME SYSLOG_SU_ENAB

useradd

CREATE_HOME GID_MAX GID_MIN HOME_MODE LASTLOG_UID_MAX MAIL_DIR MAX_MEMBERS_PER_GROUP PASS_MAX_DAYS PASS_MIN_DAYS PASS_WARN_AGE SUB_GID_COUNT SUB_GID_MAX SUB_GID_MIN SUB_UID_COUNT SUB_UID_MAX SUB_UID_MIN SYS_GID_MAX SYS_GID_MIN SYS_UID_MAX SYS_UID_MIN UID_MAX UID_MIN UMASK

userdel

MAIL_DIR MAIL_FILE MAX_MEMBERS_PER_GROUP USERDEL_CMD USERGROUPS_ENAB

usermod

LASTLOG_UID_MAX MAIL_DIR MAIL_FILE MAX_MEMBERS_PER_GROUP

BUGS

Much of the functionality that used to be provided by the shadow password suite is now handled by PAM. Thus, /etc/login.defs is no longer used by passwd(1), or less used by login(1), and su(1). Please refer to the corresponding PAM configuration files instead.

320 - Linux cli command fmtutil.cnf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command fmtutil.cnf and provides detailed information about the command fmtutil.cnf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the fmtutil.cnf.

NAME 🖥️ fmtutil.cnf 🖥️

configuration file for fmtutil

DESCRIPTION

The fmtutil.cnf file contains the configuration information for fmtutil(8). Each line contains the name of the format (e.g., ``tex’’, ``latex’’, ``omega’’), the name of the engine that is used by that format (e.g., ``tex’’, ``etex’’, ``omega’’), the pattern file (e.g., language.dat, language.def), and any arguments (name of an .ini file).

Fields are separated by whitespace and complete lines can be commented out with ``#’’. The ``pattern file’’ field cannot be used to define a file that is used while building the format. It tells fmtutil which files (separated by commas) the format creation procedure reads and it has an effect to the options –showhyphen and –byhyphen. If the format has no way to customize hyphenation, a ``-’’ can be used to indicate this.

NOTES

The tex(1) and amstex(1) formats always load hyphen.tex. No customization by a pattern file is available for these formats. Therefore, the pattern-file field for the tex and amstex is usually indicated to be empty (``-’’).

You can, however, build customized formats on top of plain tex(1) or amstex(1) by using bplain.tex instead of plain.tex (b for the Babel system). See, for example, the bplain.ini file for the bplain format).

etex(1) loads language.def, not language.dat.

Symbolic links to the correct engines (e.g., bplain -> tex) are generated by the texlinks(8) script. Remember to run texlinks(8) if you run fmtutil(8) yourself, rather than using the FORMATS option in texconfig(8).

FILES

fmtutil.cnf
default configuration file

language.dat
hyphenation pattern file

language.def
hyphenation pattern file

language.dat.lua
hyphenation pattern file

BUGS

Email bug reports to <https://lists.tug.org/tex-k> (public mailing list).

AUTHOR

fmtutil and fmtutil.cnf was originally written by Thomas Esser.

This manual page was written by C.M. Connelly for the Debian GNU/Linux system. It is now maintained as part of TeX Live.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

321 - Linux cli command systemd.dnssd

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.dnssd and provides detailed information about the command systemd.dnssd, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.dnssd.

NAME 🖥️ systemd.dnssd 🖥️

DNS-SD configuration

SYNOPSIS

network_service.dnssd

DESCRIPTION

DNS-SD setup is performed by systemd-resolved(8).

The main network service file must have the extension .dnssd; other extensions are ignored.

The .dnssd files are read from the files located in the system network directories /usr/lib/systemd/dnssd and /usr/local/lib/systemd/dnssd, the volatile runtime network directory /run/systemd/dnssd and the local administration network directory /etc/systemd/dnssd. All configuration files are collectively sorted and processed in lexical order, regardless of the directories in which they live. However, files with identical filenames replace each other. Files in /etc/ have the highest priority, files in /run/ take precedence over files with the same name in /usr/lib/. This can be used to override a system-supplied configuration file with a local file if needed.

Along with the network service file foo.dnssd, a “drop-in” directory foo.dnssd.d/ may exist. All files with the suffix “.conf” from this directory will be parsed after the file itself is parsed. This is useful to alter or add configuration settings, without having to modify the main configuration file. Each drop-in file must have appropriate section headers.

In addition to /etc/systemd/dnssd, drop-in “.d” directories can be placed in /usr/lib/systemd/dnssd or /run/systemd/dnssd directories. Drop-in files in /etc/ take precedence over those in /run/ which in turn take precedence over those in /usr/lib/ or /usr/local/lib. Drop-in files under any of these directories take precedence over the main network service file wherever located.

[SERVICE] SECTION OPTIONS

The network service file contains a [Service] section, which specifies a discoverable network service announced in a local network with Multicast DNS broadcasts.

Name=

An instance name of the network service as defined in the section 4.1.1 of RFC 6763[1], e.g. “webserver”.
The option supports simple specifier expansion. The following expansions are understood:
Table 1. Specifiers available
Specifier Meaning Details
"%a" Architecture A short string identifying the architecture of the local system. A string such as x86, x86-64 or arm64. See the architectures defined for ConditionArchitecture= in systemd.unit(5) for a full list.
"%A" Operating system image version The operating system image version identifier of the running system, as read from the IMAGE_VERSION= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.
"%b" Boot ID The boot ID of the running system, formatted as string. See random(4) for more information.
"%B" Operating system build ID The operating system build identifier of the running system, as read from the BUILD_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.
"%H" Host name The hostname of the running system.
"%m" Machine ID The machine ID of the running system, formatted as string. See machine-id(5) for more information.
"%M" Operating system image identifier The operating system image identifier of the running system, as read from the IMAGE_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.
"%o" Operating system ID The operating system identifier of the running system, as read from the ID= field of /etc/os-release. See os-release(5) for more information.
"%v" Kernel release Identical to uname -r output.
"%w" Operating system version ID The operating system version identifier of the running system, as read from the VERSION_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.
"%W" Operating system variant ID The operating system variant identifier of the running system, as read from the VARIANT_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.
"%%" Single percent sign Use "%%" in place of "%" to specify a single percent sign.
Added in version 236.

Type=

A type of the network service as defined in the section 4.1.2 of RFC 6763[1], e.g. “_http._tcp”.
Added in version 236.

SubType=

A subtype of the network service as defined in the section 7.1 of RFC 6763[1], e.g. “_printer”.
Added in version 256.

Port=

An IP port number of the network service.
Added in version 236.

Priority=

A priority number set in SRV resource records corresponding to the network service.
Added in version 236.

Weight=

A weight number set in SRV resource records corresponding to the network service.
Added in version 236.

TxtText=

A whitespace-separated list of arbitrary key/value pairs conveying additional information about the named service in the corresponding TXT resource record, e.g. “path=/portal/index.html”. Keys and values can contain C-style escape sequences which get translated upon reading configuration files.
This option together with TxtData= may be specified more than once, in which case multiple TXT resource records will be created for the service. If the empty string is assigned to this option, the list is reset and all prior assignments will have no effect.
Added in version 236.

TxtData=

A whitespace-separated list of arbitrary key/value pairs conveying additional information about the named service in the corresponding TXT resource record where values are base64-encoded string representing any binary data, e.g. “data=YW55IGJpbmFyeSBkYXRhCg==”. Keys can contain C-style escape sequences which get translated upon reading configuration files.
This option together with TxtText= may be specified more than once, in which case multiple TXT resource records will be created for the service. If the empty string is assigned to this option, the list is reset and all prior assignments will have no effect.
Added in version 236.

EXAMPLES

Example 1. HTTP service

/etc/systemd/dnssd/http.dnssd

[Service]
Name=%H
Type=_http._tcp
Port=80
TxtText=path=/stats/index.html t=temperature_sensor

This makes the http server running on the host discoverable in the local network given MulticastDNS is enabled on the network interface.

Now the utility “resolvectl” should be able to resolve the service to the hosts name:

$ resolvectl service meteo._http._tcp.local meteo._http._tcp.local: meteo.local:80 [priority=0, weight=0] 169.254.208.106%senp0s21f0u2u4 fe80::213:3bff:fe49:8aa%senp0s21f0u2u4 path=/stats/index.html t=temperature_sensor (meteo/_http._tcp/local)
-- Information acquired via protocol mDNS/IPv6 in 4.0ms.
-- Data is authenticated: yes

“Avahi” running on a different host in the same local network should see the service as well:

$ avahi-browse -a -r + enp3s0 IPv6 meteo Web Site local + enp3s0 IPv4 meteo Web Site local = enp3s0 IPv6 meteo Web Site local hostname = [meteo.local] address = [fe80::213:3bff:fe49:8aa] port = [80] txt = [“path=/stats/index.html” “t=temperature_sensor”] = enp3s0 IPv4 meteo Web Site local hostname = [meteo.local] address = [169.254.208.106] port = [80] txt = [“path=/stats/index.html” “t=temperature_sensor”]

NOTES

RFC 6763

https://tools.ietf.org/html/rfc6763

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

322 - Linux cli command dsc

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command dsc and provides detailed information about the command dsc, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the dsc.

NAME 🖥️ dsc 🖥️

Debian source package control file format

SYNOPSIS

filename**.dsc**

DESCRIPTION

Each Debian source package is composed of a .dsc control file, which contains a number of fields, in deb822 (5) format.

Each field begins with a tag, such as Source or Binary (case insensitive), followed by a colon, and the body of the field (case sensitive unless stated otherwise). Fields are delimited only by field tags. In other words, field text may be multiple lines in length, but the installation tools will generally join lines when processing the body of the field (except in case of the multiline fields Package-List, Files, Checksums-Sha1 and Checksums-Sha256, see below).

The control data might be enclosed in an OpenPGP ASCII Armored signature, as specified in RFC4880.

FIELDS

Format: format-version (required)
The value of this field declares the format version of the source package. The field value is used by programs acting on a source package to interpret the list of files in the source package and determine how to unpack it. The syntax of the field value is a numeric major revision (“0-9”), a period (“.”), a numeric minor revision (“0-9”), and then an optional subtype after whitespace (“ ”), which if specified is a lowercase alphanumeric (“a-z0-9”) word in parentheses (“()”). The subtype is optional in the syntax but may be mandatory for particular source format revisions. The source formats currently supported by dpkg are 1.0, 2.0, 3.0 (native), 3.0 (quilt), 3.0 (git), 3.0 (bzr) and 3.0 (custom). See dpkg-source (1) for their description.

Source: source-name (required)
The value of this field determines the package name, and is used to generate file names by most installation tools.

Binary: binary-package-list
This folded field lists binary packages which this source package can produce, separated by commas. This field has now been superseded by the Package-List field, which gives enough information about what binary packages are produced on which architecture, build-profile and other involved restrictions.

Architecture: arch-list (recommended)
A list of architectures and architecture wildcards separated by spaces which specify the type of hardware this package can be compiled for. Common architecture names and architecture wildcards are amd64, armel, i386, linux-any, any-amd64, etc. Note that the all value is meant for packages that are architecture independent, and any for packages that are architecture dependent. The list may include (or consist solely of) the special value all. When the list contains the architecture wildcard any, the only other value allowed in the list is all. The field value is generally generated from Architecture fields from in the debian/control in the source package.

Origin: name
The name of the distribution this package is originating from.

Uploaders: fullname-email-list
Lists all the names and email addresses of co-maintainers of the package, in the same format as the Maintainer field. Multiple co-maintainers should be separated by a comma.

Description short-description

long-description

The format for the source package description is a short brief summary on the first line (after the Description field). The following lines should be used as a longer, more detailed description. Each line of the long description must be preceded by a space, and blank lines in the long description must contain a single ‘.’ following the preceding space.

Homepage: url
The upstream project home page url.

Standards-Version: version-string (recommended)
This documents the most recent version of the distribution policy standards this package complies with.

Vcs-Browser: url
The url of a web interface to browse the Version Control System repository.

Vcs-Arch: url

Vcs-Bzr: url

Vcs-Cvs: url

Vcs-Darcs: url

Vcs-Git: url

Vcs-Hg: url

Vcs-Mtn: url

Vcs-Svn: url

These fields declare the url of the Version Control System repository used to maintain this package. See deb-src-control (5) for more details.

Testsuite: name-list
This field declares that the source package contains the specified test suites. The value is a comma-separated list of test suites. If the autopkgtest value is present, a debian/tests/control is expected to be present, if the file is present but not the value, then dpkg-source will automatically add it, preserving previous values.

Testsuite-Triggers: package-list
This field declares the comma-separated union of all test dependencies (Depends fields in debian/tests/control file), with all restrictions removed, and OR dependencies flattened (that is, converted to separate AND relationships), except for binaries generated by this source package and its meta-dependency equivalent @. Rationale: this field is needed because otherwise to be able to get the test dependencies, each source package would need to be unpacked.

Build-Depends: package-list

Build-Depends-Arch: package-list

Build-Depends-Indep: package-list

Build-Conflicts: package-list

Build-Conflicts-Arch: package-list

Build-Conflicts-Indep: package-list

These fields declare relationships between the source package and packages used to build it. They are discussed in the deb-src-control (5) manual page.

Package-List:

package package-type section priority key-value-list

This multiline field contains a list of binary packages generated by this source package. The package is the binary package name. The package-type is the binary package type, usually deb, another common value is udeb. The section and priority match the binary package fields of the same name. The key-value-list is a space separated key**=**value list, and the currently known optional keys are:

arch
The architecture restriction from the binary package Architecture field, with spaces converted to ‘,’.
profile
The normalized build-profile restriction formula from the binary package Build-Profile field, with ORs converted to ‘+’ and ANDs to ‘,’.
protected
If the binary package is protected, this key will contain the value of the Protected field, that is a yes value. Supported since dpkg 1.20.1.
essential
If the binary package is essential, this key will contain the value of the Essential field, that is a yes value.

Files: (required)

Checksums-Sha1: (required)

Checksums-Sha256: (required)

checksum size filename

These multiline fields contain a list of files with a checksum and size for each one. These fields have the same syntax and differ only in the checksum algorithm used: MD5 for Files, SHA-1 for Checksums-Sha1 and SHA-256 for Checksums-Sha256. The first line of the field value (the part on the same line as the field name followed by a colon) is always empty. The content of the field is expressed as continuation lines, one line per file. Each line consists of the checksum, a space, the file size, a space, and the file name. These fields list all files that make up the source package. The list of files in these fields must match the list of files in the other related fields.

BUGS

The Format field conflates the format for the .dsc file itself and the format of the extracted source package.

323 - Linux cli command proc_zoneinfo

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_zoneinfo and provides detailed information about the command proc_zoneinfo, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_zoneinfo.

NAME 🖥️ proc_zoneinfo 🖥️

memory zones

DESCRIPTION

/proc/zoneinfo (since Linux 2.6.13)
This file displays information about memory zones. This is useful for analyzing virtual memory behavior.

324 - Linux cli command ucf.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ucf.conf and provides detailed information about the command ucf.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ucf.conf.

NAME 🖥️ ucf.conf 🖥️

site-wide configuration file for ucf

SYNOPSIS

/etc/ucf.conf

DESCRIPTION

The file /etc/ucf.conf is actually a Bourne Shell snippet included during the package build process, and hence you may put any shell directive in that file (just make very sure you know what you are doing).

All the variables have reasonable default values, and some may be overridden on a per run or a per individual basis by using environment variables, and all configurable variables can be overridden by options to the scripts themselves.

The value of a variable can be set so:

a)
Defaults exist in the rules file. These are the values used if no customization is done.

Some variables can be set in the config file /etc/ucf.conf. These values override the defaults.
Some variables can also be set by setting a corresponding environment variable. These values override the config file and the defaults.
Using script command line options. All configurable variables may be set by this method, and will override the other methods above.

Configuration File options

At the moment, the user modifiable variables supported are:

DEBUG
Debugging information: The default value is 0 (no debugging information is printed). To enable debugging output, set the value to 1.

VERBOSE
Verbosity: The default value is 0 (quiet). To change the default behavior, set the value to 1.

conf_force_conffold
Force the installed file to be retained. The default is to have this variable unset, which makes the script ask in case of doubt. This can be overridden by the environment variable UCF_FORCE_CONFFOLD

conf_force_conffnew
Force the installed file to be overridden. The default is to have this variable unset, which makes the script ask in case of doubt. This can be overridden by the environment variable UCF_FORCE_CONFFNEW

conf_source_dir
This is the directory where the historical md5sums for a file are looked for. Specifically, the historical md5sums are looked for in either the file ${filename}.md5sum, or the subdirectory ${filename}.md5sum.d/

conf_old_mdsum_file
Force the historical md5sums to be read from this file, rather than defaulting to living in the source directory. Setting this option overrides settings in the environment variable UCF_OLD_MDSUM_FILE

Files

System-wide defaults are placed in /etc/ucf.conf,

BUGS

There are no bugs. Any resemblance thereof is delirium. Really.

AUTHOR

This manual page was written by Manoj Srivastava <[email protected]>, for the Debian GNU/Linux system.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

325 - Linux cli command binfmt.d

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command binfmt.d and provides detailed information about the command binfmt.d, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the binfmt.d.

NAME 🖥️ binfmt.d 🖥️

Configure additional binary formats for executables at boot

SYNOPSIS

/etc/binfmt.d/*.conf

/run/binfmt.d/*.conf

/usr/local/lib/binfmt.d/*.conf

/usr/lib/binfmt.d/*.conf

DESCRIPTION

At boot, systemd-binfmt.service(8) reads configuration files from the above directories to register in the kernel additional binary formats for executables.

CONFIGURATION FORMAT

Each file contains a list of binfmt_misc kernel binary format rules. Consult the kernels Kernel Support for miscellaneous Binary Formats (binfmt_misc)[1] documentation file for more information on registration of additional binary formats and how to write rules.

Empty lines and lines beginning with “;” and “#” are ignored. Note that this means you may not use those symbols as the delimiter in binary format rules.

CONFIGURATION DIRECTORIES AND PRECEDENCE

Packages should install their configuration files in /usr/lib/ (distribution packages) or /usr/local/lib/ (local installs) [2]. Files in /etc/ are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages.

EXAMPLE

Example 1. /etc/binfmt.d/wine.conf example:

Start WINE on Windows executables
:DOSWin:M::MZ::/usr/bin/wine:

NOTES

Kernel Support for miscellaneous Binary Formats (binfmt_misc)

https://docs.kernel.org/admin-guide/binfmt-misc.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

326 - Linux cli command logind.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command logind.conf and provides detailed information about the command logind.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the logind.conf.

NAME 🖥️ logind.conf 🖥️

SYNOPSIS

/etc/systemd/logind.conf

/run/systemd/logind.conf

/usr/local/lib/systemd/logind.conf

/usr/lib/systemd/logind.conf

/etc/systemd/logind.conf.d/*.conf

/run/systemd/logind.conf.d/*.conf

/usr/local/lib/systemd/logind.conf.d/*.conf

/usr/lib/systemd/logind.conf.d/*.conf

DESCRIPTION

These files configure various parameters of the systemd login manager, systemd-logind.service(8). See systemd.syntax(7) for a general description of the syntax.

CONFIGURATION DIRECTORIES AND PRECEDENCE

OPTIONS

All options are configured in the [Login] section:

NAutoVTs=

Takes a positive integer. Configures how many virtual terminals (VTs) to allocate by default that, when switched to and are previously unused, “autovt” services are automatically spawned on. These services are instantiated from the template unit [email protected] for the respective VT TTY name, for example, [email protected]. By default, [email protected] is linked to [email protected]. In other words, login prompts are started dynamically as the user switches to unused virtual terminals. Hence, this parameter controls how many login “gettys” are available on the VTs. If a VT is already used by some other subsystem (for example, a graphical login), this kind of activation will not be attempted. Note that the VT configured in ReserveVT= is always subject to this kind of activation, even if it is not one of the VTs configured with the NAutoVTs= directive. Defaults to 6. When set to 0, automatic spawning of “autovt” services is disabled.

ReserveVT=

Takes a positive integer. Identifies one virtual terminal that shall unconditionally be reserved for [email protected] activation (see above). The VT selected with this option will be marked busy unconditionally, so that no other subsystem will allocate it. This functionality is useful to ensure that, regardless of how many VTs are allocated by other subsystems, one login “getty” is always available. Defaults to 6 (in other words, there will always be a “getty” available on Alt-F6.). When set to 0, VT reservation is disabled.
Added in version 190.

KillUserProcesses=

Takes a boolean argument. Configures whether the processes of a user should be killed when the user logs out. If true, the scope unit corresponding to the session and all processes inside that scope will be terminated. If false, the scope is “abandoned”, see systemd.scope(5), and processes are not killed. Defaults to “no”, but see the options KillOnlyUsers= and KillExcludeUsers= below.
In addition to session processes, user process may run under the user manager unit [email protected]. Depending on the linger settings, this may allow users to run processes independent of their login sessions. See the description of enable-linger in loginctl(1).
Note that setting KillUserProcesses=yes will break tools like screen(1) and tmux(1), unless they are moved out of the session scope. See example in systemd-run(1).

KillOnlyUsers=, KillExcludeUsers=

These settings take space-separated lists of usernames that override the KillUserProcesses= setting. A user name may be added to KillExcludeUsers= to exclude the processes in the session scopes of that user from being killed even if KillUserProcesses=yes is set. If KillExcludeUsers= is not set, the “root” user is excluded by default. KillExcludeUsers= may be set to an empty value to override this default. If a user is not excluded, KillOnlyUsers= is checked next. If this setting is specified, only the processes in the session scopes of those users will be killed. Otherwise, users are subject to the KillUserProcesses=yes setting.

IdleAction=

Configures the action to take when the system is idle. Takes one of “ignore”, “poweroff”, “reboot”, “halt”, “kexec”, “suspend”, “hibernate”, “hybrid-sleep”, “suspend-then-hibernate”, “sleep”, and “lock”. Defaults to “ignore”.
Note that this requires that user sessions correctly report the idle status to the system. The system will execute the action after all sessions report that they are idle, no idle inhibitor lock is active, and subsequently, the time configured with IdleActionSec= (see below) has expired.
Added in version 198.

IdleActionSec=

Configures the delay after which the action configured in IdleAction= (see above) is taken after the system is idle.
Added in version 198.

InhibitDelayMaxSec=

Specifies the maximum time a system shutdown or sleep request is delayed due to an inhibitor lock of type “delay” being active before the inhibitor is ignored and the operation executes anyway. Defaults to 5.

UserStopDelaySec=

Specifies how long to keep the user record and per-user service [email protected] around for a user after they logged out fully. If set to zero, the per-user service is terminated immediately when the last session of the user has ended. If this option is configured to non-zero rapid logout/login cycles are sped up, as the users service manager is not constantly restarted. If set to “infinity” the per-user service for a user is never terminated again after first login, and continues to run until system shutdown. Defaults to 10s.
Added in version 240.

SleepOperation=

Takes a list of sleep operations. Possible values are “suspend”, “hibernate”, “hybrid-sleep”, and “suspend-then-hibernate”. Controls the candidate sleep operations for the “sleep” action. When “sleep” action is performed, the specified sleep operations are checked in a fixed order (“suspend-then-hibernate” → “hybrid-sleep” → “suspend” → “hibernate”), and the first one supported by the machine is used to put the system into sleep. Defaults to “suspend-then-hibernate suspend hibernate”.
Added in version 256.

Controls how logind shall handle the system power, reboot and sleep keys and the lid switch to trigger actions such as system power-off, reboot or suspend. Can be one of “ignore”, “poweroff”, “reboot”, “halt”, “kexec”, “suspend”, “hibernate”, “hybrid-sleep”, “suspend-then-hibernate”, “sleep”, “lock”, and “factory-reset”. If “ignore”, systemd-logind will never handle these keys. If “lock”, all running sessions will be screen-locked; otherwise, the specified action will be taken in the respective event. Only input devices with the “power-switch” udev tag will be watched for key/lid switch events.
HandlePowerKey= defaults to “poweroff”, HandleRebootKey= defaults to “reboot”, HandleSuspendKey= defaults to “suspend”, HandleHibernateKey= defaults to “hibernate”, HandlePowerKeyLongPress= defaults to “ignore”, HandleRebootKeyLongPress= defaults to “poweroff”, HandleSuspendKeyLongPress= defaults to “hibernate”, HandleHibernateKeyLongPress= defaults to “ignore”. HandleLidSwitch= defaults to “suspend”. HandleLidSwitchExternalPower= is completely ignored by default (for backwards compatibility) — an explicit value must be set before it will be used to determine behaviour. HandleLidSwitchDocked= defaults to “ignore”. If the system is inserted in a docking station, or if more than one display is connected, the action specified by HandleLidSwitchDocked= occurs; if the system is on external power the action (if any) specified by HandleLidSwitchExternalPower= occurs; otherwise the HandleLidSwitch= action occurs.
A different application may disable loginds handling of system power and sleep keys and the lid switch by taking a low-level inhibitor lock (“handle-power-key”, “handle-suspend-key”, “handle-hibernate-key”, “handle-lid-switch”, “handle-reboot-key”). This is most commonly used by graphical desktop environments to take over suspend and hibernation handling, and to use their own configuration mechanisms. If a low-level inhibitor lock is taken, logind will not take any action when that key or switch is triggered and the Handle*= settings are irrelevant.
Added in version 184.

PowerKeyIgnoreInhibited=, SuspendKeyIgnoreInhibited=, HibernateKeyIgnoreInhibited=, LidSwitchIgnoreInhibited=, RebootKeyIgnoreInhibited=

Controls whether actions that systemd-logind takes when the power, reboot and sleep keys and the lid switch are triggered are subject to high-level inhibitor locks (“shutdown”, “reboot”, “sleep”, “idle”). Low level inhibitor locks (“handle-power-key”, “handle-suspend-key”, “handle-hibernate-key”, “handle-lid-switch”, “handle-reboot-key”), are always honored, irrespective of this setting.
These settings take boolean arguments. If “no”, the inhibitor locks taken by applications are respected. If “yes”, “shutdown”, “reboot” “sleep”, and “idle” inhibitor locks are ignored. PowerKeyIgnoreInhibited=, SuspendKeyIgnoreInhibited=, HibernateKeyIgnoreInhibited= and RebootKeyIgnoreInhibited= default to “no”. LidSwitchIgnoreInhibited= defaults to “yes”. This means that when systemd-logind is handling events by itself (no low level inhibitor locks are taken by another application), the lid switch does not respect suspend blockers by default, but the power and sleep keys do.
Added in version 190.

HoldoffTimeoutSec=

Specifies a period of time after system startup or system resume in which systemd will hold off on reacting to lid events. This is required for the system to properly detect any hotplugged devices so systemd can ignore lid events if external monitors, or docks, are connected. If set to 0, systemd will always react immediately, possibly before the kernel fully probed all hotplugged devices. This is safe, as long as you do not care for systemd to account for devices that have been plugged or unplugged while the system was off. Defaults to 30s.
Added in version 220.

RuntimeDirectorySize=

Sets the size limit on the $XDG_RUNTIME_DIR runtime directory for each user who logs in. Takes a size in bytes, optionally suffixed with the usual K, G, M, and T suffixes, to the base 1024 (IEC). Alternatively, a numerical percentage suffixed by “%” may be specified, which sets the size limit relative to the amount of physical RAM. Defaults to 10%. Note that this size is a safety limit only. As each runtime directory is a tmpfs file system, it will only consume as much memory as is needed.
Added in version 211.

RuntimeDirectoryInodesMax=

Sets the limit on number of inodes for the $XDG_RUNTIME_DIR runtime directory for each user who logs in. Takes a number, optionally suffixed with the usual K, G, M, and T suffixes, to the base 1024 (IEC). Defaults to RuntimeDirectorySize= divided by 4096. Note that this size is a safety limit only. As each runtime directory is a tmpfs file system, it will only consume as much memory as is needed.
Added in version 246.

InhibitorsMax=

Controls the maximum number of concurrent inhibitors to permit. Defaults to 8192 (8K).
Added in version 230.

SessionsMax=

Controls the maximum number of concurrent user sessions to manage. Defaults to 8192 (8K). Depending on how the pam_systemd.so module is included in the PAM stack configuration, further login sessions will either be refused, or permitted but not tracked by systemd-logind.
Added in version 230.

RemoveIPC=

Controls whether System V and POSIX IPC objects belonging to the user shall be removed when the user fully logs out. Takes a boolean argument. If enabled, the user may not consume IPC resources after the last of the users sessions terminated. This covers System V semaphores, shared memory and message queues, as well as POSIX shared memory and message queues. Note that IPC objects of the root user and other system users are excluded from the effect of this setting. Defaults to “yes”.
Added in version 212.

StopIdleSessionSec=

Specifies a timeout in seconds, or a time span value after which systemd-logind checks the idle state of all sessions. Every session that is idle for longer than the timeout will be stopped. Note that this option doesnt apply to “greeter” or “lock-screen” sessions. Defaults to “infinity” (systemd-logind is not checking the idle state of sessions). For details about the syntax of time spans, see systemd.time(7).
Added in version 252.

NOTES

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

327 - Linux cli command proc_pid_net

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_net and provides detailed information about the command proc_pid_net, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_net.

NAME 🖥️ proc_pid_net 🖥️

network layer information

DESCRIPTION

/proc/pid/net/ (since Linux 2.6.25)
See the description of /proc/net.

/proc/net/arp
This holds an ASCII readable dump of the kernel ARP table used for address resolutions. It will show both dynamically learned and preprogrammed ARP entries. The format is:

IP address     HW type   Flags     HW address          Mask   Device
192.168.0.50   0x1       0x2       00:50:BF:25:68:F3   *      eth0
192.168.0.250  0x1       0xc       00:00:00:00:00:00   *      eth0

Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
    lo: 2776770   11307    0    0    0     0          0         0  2776770   11307    0    0    0     0       0          0
  eth0: 1215645    2751    0    0    0     0          0         0  1782404    4324    0    0    0   427       0          0
  ppp0: 1622270    5552    1    0    0     0          0         0   354130    5669    0    0    0     0       0          0
  tap0:    7714      81    0    0    0     0          0         0     7714      81    0    0    0     0       0          0

/proc/net/dev_mcast
Defined in /usr/src/linux/net/core/dev_mcast.c:

indx interface_name  dmi_u dmi_g dmi_address
2    eth0            1     0     01005e000001
3    eth1            1     0     01005e000001
4    eth2            1     0     01005e000001

/proc/net/igmp
Internet Group Management Protocol. Defined in /usr/src/linux/net/core/igmp.c.

/proc/net/snmp
This file holds the ASCII data needed for the IP, ICMP, TCP, and UDP management information bases for an SNMP agent.

sl  local_address rem_address   st tx_queue rx_queue tr rexmits  tm->when uid
 1: 01642C89:0201 0C642C89:03FF 01 00000000:00000001 01:000071BA 00000000 0
 1: 00000000:0801 00000000:0000 0A 00000000:00000000 00:00000000 6F000100 0
 1: 00000000:0201 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0

/proc/net/unix
Lists the UNIX domain sockets present within the system and their status. The format is:

Num RefCount Protocol Flags    Type St Inode Path
 0: 00000002 00000000 00000000 0001 03    42
 1: 00000001 00000000 00010000 0001 01  1948 /dev/printer

The fields are as follows:

Num:
the kernel table slot number.

RefCount:
the number of users of the socket.

Protocol:
currently always 0.

Flags:
the internal kernel flags holding the status of the socket.

Type:
the socket type. For SOCK_STREAM sockets, this is 0001; for SOCK_DGRAM sockets, it is 0002; and for SOCK_SEQPACKET sockets, it is 0005.

St:
the internal state of the socket.

Inode:
the inode number of the socket.

Path:
the bound pathname (if any) of the socket. Sockets in the abstract namespace are included in the list, and are shown with a Path that commences with the character ‘@’.

   1   4207     0  2 65535     0     0        0  1
  (1)   (2)    (3)(4)  (5)    (6)   (7)      (8)

The fields in each line are:

(2)
The netlink port ID subscribed to the queue.

(3)
The number of packets currently queued and waiting to be processed by the application.

(4)
The copy mode of the queue. It is either 1 (metadata only) or 2 (also copy payload data to user space).

(5)
Copy range; that is, how many bytes of packet payload should be copied to user space at most.

(6)
queue dropped. Number of packets that had to be dropped by the kernel because too many packets are already waiting for user space to send back the mandatory accept/drop verdicts.

(8)
sequence number. Every queued packet is associated with a (32-bit) monotonically increasing sequence number. This shows the ID of the most recent packet queued.

The last number exists only for compatibility reasons and is always 1.

328 - Linux cli command org.freedesktop.machine1

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.freedesktop.machine1 and provides detailed information about the command org.freedesktop.machine1, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.freedesktop.machine1.

NAME 🖥️ org.freedesktop.machine1 🖥️

The D-Bus interface of systemd-machined

INTRODUCTION

systemd-machined.service(8) is a system service that keeps track of locally running virtual machines and containers. This page describes the D-Bus interface.

THE MANAGER OBJECT

The service exposes the following interfaces on the Manager object on the bus:

node /org/freedesktop/machine1 { interface org.freedesktop.machine1.Manager { methods: GetMachine(in s name, out o machine); GetImage(in s name, out o image); GetMachineByPID(in u pid, out o machine); ListMachines(out a(ssso) machines); ListImages(out a(ssbttto) images); @org.freedesktop.systemd1.Privileged(“true”) CreateMachine(in s name, in ay id, in s service, in s class, in u leader, in s root_directory, in a(sv) scope_properties, out o path); @org.freedesktop.systemd1.Privileged(“true”) CreateMachineWithNetwork(in s name, in ay id, in s service, in s class, in u leader, in s root_directory, in ai ifindices, in a(sv) scope_properties, out o path); @org.freedesktop.systemd1.Privileged(“true”) RegisterMachine(in s name, in ay id, in s service, in s class, in u leader, in s root_directory, out o path); @org.freedesktop.systemd1.Privileged(“true”) RegisterMachineWithNetwork(in s name, in ay id, in s service, in s class, in u leader, in s root_directory, in ai ifindices, out o path); UnregisterMachine(in s name); TerminateMachine(in s id); KillMachine(in s name, in s who, in i signal); GetMachineAddresses(in s name, out a(iay) addresses); GetMachineSSHInfo(in s name, out s ssh_address, out s ssh_private_key_path); GetMachineOSRelease(in s name, out a{ss} fields); @org.freedesktop.systemd1.Privileged(“true”) OpenMachinePTY(in s name, out h pty, out s pty_path); OpenMachineLogin(in s name, out h pty, out s pty_path); OpenMachineShell(in s name, in s user, in s path, in as args, in as environment, out h pty, out s pty_path); BindMountMachine(in s name, in s source, in s destination, in b read_only, in b mkdir); CopyFromMachine(in s name, in s source, in s destination); CopyToMachine(in s name, in s source, in s destination); CopyFromMachineWithFlags(in s name, in s source, in s destination, in t flags); CopyToMachineWithFlags(in s name, in s source, in s destination, in t flags); OpenMachineRootDirectory(in s name, out h fd); GetMachineUIDShift(in s name, out u shift); RemoveImage(in s name); RenameImage(in s name, in s new_name); CloneImage(in s name, in s new_name, in b read_only); MarkImageReadOnly(in s name, in b read_only); GetImageHostname(in s name, out s hostname); GetImageMachineID(in s name, out ay id); GetImageMachineInfo(in s name, out a{ss} machine_info); GetImageOSRelease(in s name, out a{ss} os_release); SetPoolLimit(in t size); SetImageLimit(in s name, in t size); CleanPool(in s mode, out a(st) images); MapFromMachineUser(in s name, in u uid_inner, out u uid_outer); MapToMachineUser(in u uid_outer, out s machine_name, out o machine_path, out u uid_inner); MapFromMachineGroup(in s name, in u gid_inner, out u gid_outer); MapToMachineGroup(in u gid_outer, out s machine_name, out o machine_path, out u gid_inner); signals: MachineNew(s machine, o path); MachineRemoved(s machine, o path); properties: @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s PoolPath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t PoolUsage = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly t PoolLimit = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; };

Methods

GetMachine() may be used to get the machine object path for the machine with the specified name. Similarly, GetMachineByPID() gets the machine object the specified PID belongs to if there is any.

GetImage() may be used to get the image object path of the image with the specified name.

ListMachines() returns an array of all currently registered machines. The structures in the array consist of the following fields: machine name, machine class, an identifier for the service that registered the machine and the machine object path.

CreateMachine() may be used to register a new virtual machine or container with systemd-machined, creating a scope unit for it. It accepts the following arguments: a machine name chosen by the registrar, an optional UUID as a 32 byte array, a string that identifies the service that registers the machine, a class string, the PID of the leader process of the machine, an optional root directory of the container, and an array of additional properties to use for the scope registration. The virtual machine name must be suitable as a hostname, and hence should follow the usual DNS hostname rules, as well as the Linux hostname restrictions. Specifically, only 7 bit ASCII is permitted, a maximum length of 64 characters is enforced, only characters from the set “a-zA-Z0-9-_.” are allowed, the name may not begin with a dot, and it may not contain two dots immediately following each other. Container and VM managers should ideally use the hostname used internally in the machine for this parameter. This recommendation is made in order to make the machine name naturally resolvable using nss-mymachines(8). If a container manager needs to embed characters outside of the indicated range, escaping is required, possibly using “_” as the escape character. Another (somewhat natural) option would be to utilize Internet IDNA encoding. The UUID is passed as a 32 byte array or, if no suitable UUID is available, an empty array (zero length) or zeroed out array shall be passed. The UUID should identify the virtual machine/container uniquely and should ideally be the same UUID that /etc/machine-id in the VM/container is initialized from. The service string can be free-form, but it is recommended to pass a short lowercase identifier like “systemd-nspawn”, “libvirt-lxc” or similar. The class string should be either “container” or “vm” indicating whether the machine to register is of the respective class. The leader PID should be the host PID of the init process of the container or the encapsulating process of the VM. If the root directory of the container is known and available in the hosts hierarchy, it should be passed. Otherwise, pass the empty string instead. Finally, the scope properties are passed as array in the same way as to PID1s StartTransientUnit() method. Calling this method will internally register a transient scope unit for the calling client (utilizing the passed scope_properties) and move the leader PID into it. The method returns an object path for the registered machine object that implements the org.freedesktop.machine1.Machine interface (see below). Also see the New Control Group Interfaces[1] for details about scope units and how to alter resource control settings on the created machine at runtime.

RegisterMachine() is similar to CreateMachine(). However, it only registers a machine and does not create a scope unit for it. Instead, the callers unit is registered. We recommend to only use this method for container or VM managers that are run multiple times, one instance for each container/VM they manage, and are invoked as system services.

CreateMachineWithNetwork() and RegisterMachineWithNetwork() are similar to CreateMachine() and RegisterMachine() but take an extra argument: an array of network interface indices that point towards the virtual machine or container. The interface indices should reference one or more network interfaces on the host that can be used to communicate with the guest. Commonly, the passed interface index refers to the host side of a “veth” link (in case of containers), a “tun”/“tap” link (in case of VMs), or the host side of a bridge interface that bridges access to the VM/container interfaces. Specifying this information is useful to enable support for link-local IPv6 communication to the machines since the scope field of sockaddr_in6 can be initialized by the specified ifindex. nss-mymachines(8) makes use of this information.

KillMachine() sends a UNIX signal to the machines processes. As its arguments, it takes a machine name (as originally passed to CreateMachine() or returned by ListMachines()), an identifier that specifies what precisely to send the signal to (either “leader” or “all”), and a numeric UNIX signal integer.

TerminateMachine() terminates a virtual machine, killing its processes. It takes a machine name as its only argument.

GetMachineAddresses() retrieves the IP addresses of a container. This method returns an array of pairs consisting of an address family specifier (AF_INET or AF_INET6) and a byte array containing the addresses. This is only supported for containers that make use of network namespacing.

GetMachineSSHInfo() retrieves the SSH information of a machine. This method returns two strings, the SSH address which can be used to tell SSH where to connect, and the path to the SSH private key required for the connection to succeed.

GetMachineOSRelease() retrieves the OS release information of a container. This method returns an array of key value pairs read from the os-release(5) file in the container and is useful to identify the operating system used in a container.

OpenMachinePTY() allocates a pseudo TTY in the container and returns a file descriptor and its path. This is equivalent to transitioning into the container and invoking posix_openpt(3).

OpenMachineLogin() allocates a pseudo TTY in the container and ensures that a getty login prompt of the container is running on the other end. It returns the file descriptor of the PTY and the PTY path. This is useful for acquiring a pty with a login prompt from the container.

OpenMachineShell() allocates a pseudo TTY in the container, as the specified user, and invokes the executable at the specified path with a list of arguments (starting from argv[0]) and an environment block. It then returns the file descriptor of the PTY and the PTY path.

BindMountMachine() bind mounts a file or directory from the host into the container. Its arguments consist of a machine name, the source directory on the host, the destination directory in the container, and two booleans, one indicating whether the bind mount shall be read-only, the other indicating whether the destination mount point shall be created first, if it is missing.

CopyFromMachine() copies files or directories from a container into the host. It takes a container name, a source directory in the container and a destination directory on the host as arguments. CopyToMachine() does the opposite and copies files from a source directory on the host into a destination directory in the container. CopyFromMachineWithFlags() and CopyToMachineWithFlags() do the same but take an additional flags argument.

RemoveImage() removes the image with the specified name.

RenameImage() renames the specified image.

CloneImage() clones the specified image under a new name. It also takes a boolean argument indicating whether the resulting image shall be read-only or not.

MarkImageReadOnly() toggles the read-only flag of an image.

SetPoolLimit() sets an overall quota limit on the pool of images.

SetImageLimit() sets a per-image quota limit.

MapFromMachineUser(), MapToMachineUser(), MapFromMachineGroup(), and MapToMachineGroup() may be used to map UIDs/GIDs from the host user namespace to a container user namespace or vice versa.

Signals

MachineNew() and MachineRemoved() are sent whenever a new machine is registered or removed. These signals carry the machine name and the object path to the corresponding org.freedesktop.machine1.Machine interface (see below).

Properties

PoolPath specifies the file system path where images are written to.

PoolUsage specifies the current usage size of the image pool in bytes.

PoolLimit specifies the size limit of the image pool in bytes.

MACHINE OBJECTS

node /org/freedesktop/machine1/machine/rawhide { interface org.freedesktop.machine1.Machine { methods: Terminate(); Kill(in s who, in i signal); GetAddresses(out a(iay) addresses); GetSSHInfo(out s ssh_address, out s ssh_private_key_path); GetOSRelease(out a{ss} fields); GetUIDShift(out u shift); OpenPTY(out h pty, out s pty_path); OpenLogin(out h pty, out s pty_path); OpenShell(in s user, in s path, in as args, in as environment, out h pty, out s pty_path); BindMount(in s source, in s destination, in b read_only, in b mkdir); CopyFrom(in s source, in s destination); CopyTo(in s source, in s destination); CopyFromWithFlags(in s source, in s destination, in t flags); CopyToWithFlags(in s source, in s destination, in t flags); OpenRootDirectory(out h fd); properties: @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Name = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ay Id = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t Timestamp = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly t TimestampMonotonic = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Service = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Unit = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u Leader = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s Class = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s RootDirectory = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly ai NetworkInterfaces = […]; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly u VSockCID = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s SSHAddress = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“const”) readonly s SSHPrivateKeyPath = …; @org.freedesktop.DBus.Property.EmitsChangedSignal(“false”) readonly s State = …; }; interface org.freedesktop.DBus.Peer { … }; interface org.freedesktop.DBus.Introspectable { … }; interface org.freedesktop.DBus.Properties { … }; };

Methods

Terminate() and Kill() terminate/kill the machine. These methods take the same arguments as TerminateMachine() and KillMachine() on the Manager interface, respectively.

GetAddresses(), GetSSHInfo() and GetOSRelease() get the IP address, SSH connection and OS release information from the machine. These methods take the same arguments as GetMachineAddresses(), GetMachineSSHInfo() and GetMachineOSRelease() of the Manager interface, respectively.

Properties

Name is the machine name as it was passed in during registration with CreateMachine() on the manager object.

Id is the machine UUID.

Timestamp and TimestampMonotonic are the realtime and monotonic timestamps when the virtual machines where created in microseconds since the epoch.

Service contains a short string identifying the registering service as passed in during registration of the machine.

Unit is the systemd scope or service unit name for the machine.

Leader is the PID of the leader process of the machine.

Class is the class of the machine and is either the string “vm” (for real VMs based on virtualized hardware) or “container” (for light-weight userspace virtualization sharing the same kernel as the host).

RootDirectory is the root directory of the container if it is known and applicable or the empty string.

NetworkInterfaces contains an array of network interface indices that point towards the container, the VM or the host. For details about this information see the description of CreateMachineWithNetwork() above.

VSockCID is the VSOCK CID of the VM if it is known, or VMADDR_CID_ANY otherwise.

SSHAddress is the address of the VM in a format ssh can understand if it is known or the empty string.

SSHPrivateKeyPath is the path to the SSH private key of the VM if it is known or the empty string.

State is the state of the machine and is one of “opening”, “running”, or “closing”. Note that the state machine is not considered part of the API and states might be removed or added without this being considered API breakage.

EXAMPLES

Example 1. Introspect org.freedesktop.machine1.Manager on the bus

$ gdbus introspect –system
–dest org.freedesktop.machine1
–object-path /org/freedesktop/machine1

Example 2. Introspect org.freedesktop.machine1.Machine on the bus

$ gdbus introspect –system
–dest org.freedesktop.machine1
–object-path /org/freedesktop/machine1/machine/rawhide

VERSIONING

These D-Bus interfaces follow the usual interface versioning guidelines[2].

HISTORY

The Manager Object

CopyFromMachineWithFlags() and CopyToMachineWithFlags() were added in version 252.

GetMachineSSHInfo() was added in version 256.

Machine Objects

CopyFromWithFlags() and CopyToWithFlags() were added in version 252.

GetSSHInfo(), VSockCID, SSHAddress and SSHPrivateKeyPath were added in version 256.

NOTES

New Control Group Interfaces

https://systemd.io/CONTROL_GROUP_INTERFACE

the usual interface versioning guidelines

https://0pointer.de/blog/projects/versioning-dbus.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

329 - Linux cli command motd

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command motd and provides detailed information about the command motd, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the motd.

NAME 🖥️ motd 🖥️

message of the day

DESCRIPTION

The contents of /etc/motd are displayed by pam_motd(8) after a successful login but just before it executes the login shell.

The abbreviation “motd” stands for “message of the day”, and this file has been traditionally used for exactly that (it requires much less disk space than mail to all users).

On Debian GNU/Linux, dynamic content configured at /etc/pam.d/login is also displayed by pam_exec

FILES

/etc/motd

330 - Linux cli command proc_mtrr

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_mtrr and provides detailed information about the command proc_mtrr, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_mtrr.

NAME 🖥️ proc_mtrr 🖥️

memory type range registers

DESCRIPTION

/proc/mtrr
Memory Type Range Registers. See the Linux kernel source file Documentation/x86/mtrr.rst (or Documentation/x86/mtrr.txt before Linux 5.2, or Documentation/mtrr.txt before Linux 2.6.28) for details.

331 - Linux cli command org.bluez.AdvertisementMonitorManager

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.AdvertisementMonitorManager and provides detailed information about the command org.bluez.AdvertisementMonitorManager, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.AdvertisementMonitorManager.

NAME 🖥️ org.bluez.AdvertisementMonitorManager 🖥️

BlueZ D-Bus AdvertisementMonitorManager API documentation

INTERFACE

Service org.bluez Interface org.bluez.AdvertisementMonitorManager1 [experimental] Object path /org/bluez/{hci0,hci1,…}

Methods

void RegisterMonitor(object application)

Registers the root path of a hierarchy of advertisement monitors implementing org.bluez.AdvertisementMonitor(5).
The application object path together with the D-Bus ystem bus connection ID define the identification of the application registering advertisement monitors.
Once a root path is registered by a client via this method, the client can freely expose/unexpose advertisement monitors without re-registering the root path again. After use, the client should call UnregisterMonitor() method to invalidate the advertisement monitors.
Possible errors:
org.bluez.Error.InvalidArguments
org.bluez.Error.AlreadyExists
org.bluez.Error.Failed

void UnregisterMonitor(object application)

Unregisters a hierarchy of advertisement monitors that has been previously registered with RegisterMonitor(). The object path parameter must match the same value that has been used on registration.
Upon unregistration, the advertisement monitor(s) should expect to receive Release() method as the signal that the advertisement monitor(s) has been deactivated.
Possible errors:
org.bluez.Error.InvalidArguments
org.bluez.Error.DoesNotExist

Properties

array{string} SupportedMonitorTypes [read-only]

This lists the supported types of advertisement monitors. An application should check this before instantiate and expose an object of org.bluez.AdvertisementMonitor(5).
Possible values:
“or_patterns”
Patterns with logic OR applied. With this type, property Patterns must exist and has at least one pattern.

array{string} SupportedFeatures [read-only]

This lists the features of advertisement monitoring supported by bluetoothd(8).
Possible values:
“controller-patterns”
If the controller is capable of performing advertisement monitoring by patterns, bluetoothd(8) would offload the patterns to the controller to reduce power consumption.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

332 - Linux cli command postgresqlrc

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command postgresqlrc and provides detailed information about the command postgresqlrc, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the postgresqlrc.

NAME 🖥️ postgresqlrc 🖥️

Per-user PostgreSQL cluster configuration

DESCRIPTION

The file ~/.postgresqlrc configures the default PostgreSQL version/cluster and the default database for an user. If it is not present, the system-wide file /etc/postgresql-common/user_clusters is used instead.

FORMAT

Comments are introduced by the character #. Comments may follow data on a line; the first comment character terminates the data. Leading whitespace and blank lines are ignored.

The first uncommented, non-blank line is used, all following lines are ignored.

Fields must be given in the following order, separated by white space:

VERSION
The major PostgreSQL version of the cluster to connect to.

CLUSTER
The name of a cluster to connect to. A remote cluster is specified with host:port. If port is empty, it defaults to 5432.

333 - Linux cli command vlan-interfaces

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command vlan-interfaces and provides detailed information about the command vlan-interfaces, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the vlan-interfaces.

NAME 🖥️ vlan-interfaces 🖥️

legacy VLAN extensions for the interfaces(5) file format

DESCRIPTION

/etc/network/interfaces contains network interface configuration information for the ifup(8) and ifdown(8) commands. This manpage describes the VLAN extensions to the standard interfaces(5) file format.

Primary extensions exist to make and destroy VLAN interfaces, secondary extensions exist for IPv4 interface manipulation which are generally needed when using (a lot of) VLANs.

VLAN CREATION

VLAN interface definitions exist of the VLAN interface name, and an optional ‘raw-device’ parameter. Vlan interfaces are numbered 1 to 4095. You have the option to have interface names zero-padded to 4 numbers, or just the plain digits without leading zero. The following example shows four ways to create a VLAN with id 1 on interface eth0. They all result in different names.

iface eth0.1 inet static address 192.168.1.1 netmask 255.255.255.0

iface vlan1 inet static vlan-raw-device eth0 address 192.168.1.1 netmask 255.255.255.0

iface eth0.0001 inet static address 192.168.1.1 netmask 255.255.255.0

iface vlan0001 inet static vlan-raw-device eth0 address 192.168.1.1 netmask 255.255.255.0

# We don’t have br support out of the box iface br0.2 inet static vlan-raw-device br0 address 192.168.1.1 netmask 255.255.255.0

# Aliases are ignored iface br0.2:1 inet static address 192.168.1.1 netmask 255.255.255.255

EXTRA IFACE OPTIONS

Usually someone who uses vlans also wants to do some other manipulations with the ip stack or interface.

vlan-raw-device* devicename*
Indicates the device to create the vlan on. This is ignored when the devicename is part of the vlan interface name.

ip-proxy-arp* 0|1*
Turn proxy-arp off or on for this specific interface. This also works on plain ethernet like devices.

ip-rp-filter* 0|1|2*
Set the return path filter for this specific interface. This also works on plain ethernet like devices.

hw-mac-address* mac-address*
This sets the mac address of the interface before bringing it up. This works on any device that allows setting the hardware address with the ip command.

AUTHOR

This manpage was adapted from interfaces(5) by Ard van Breemen <[email protected]>

334 - Linux cli command proc_pid_ns

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_ns and provides detailed information about the command proc_pid_ns, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_ns.

NAME 🖥️ proc_pid_ns 🖥️

namespaces

DESCRIPTION

/proc/pid/ns/ (since Linux 3.0)
This is a subdirectory containing one entry for each namespace that supports being manipulated by setns(2). For more information, see namespaces(7).

335 - Linux cli command smb.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command smb.conf and provides detailed information about the command smb.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the smb.conf.

NAME 🖥️ smb.conf 🖥️

The configuration file for the Samba suite

SYNOPSIS

The smb.conf file is a configuration file for the Samba suite. smb.conf contains runtime configuration information for the Samba programs. The complete description of the file format and possible parameters held within are here for reference purposes.

HOW CONFIGURATION CHANGES ARE APPLIED

The Samba suite includes a number of different programs. Some of them operate in a client mode, others are server daemons that provide various services to its clients. The smb.conf file is processed in the following way:

·
The Samba suites client applications read their configuration only once. Any changes made after start arent reflected in the context of already running client code.
·
The Samba suites server daemons reload their configuration when requested. However, already active connections do not change their configuration. More detailed information can be found in smbd(8) and winbindd(8) manual pages.

To request Samba server daemons to refresh their configuration, please use smbcontrol(1) utility.

FILE FORMAT

The file consists of sections and parameters. A section begins with the name of the section in square brackets and continues until the next section begins. Sections contain parameters of the form:

name = value

The file is line-based - that is, each newline-terminated line represents either a comment, a section name or a parameter.

Section and parameter names are not case sensitive.

Only the first equals sign in a parameter is significant. Whitespace before or after the first equals sign is discarded. Leading, trailing and internal whitespace in section and parameter names is irrelevant. Leading and trailing whitespace in a parameter value is discarded. Internal whitespace within a parameter value is retained verbatim.

Any line beginning with a semicolon (“;”) or a hash (“#”) character is ignored, as are lines containing only whitespace.

Any line ending in a “\ is continued on the next line in the customary UNIX fashion.

The values following the equals sign in parameters are all either a string (no quotes needed) or a boolean, which may be given as yes/no, 1/0 or true/false. Case is not significant in boolean values, but is preserved in string values. Some items such as create masks are numeric.

SECTION DESCRIPTIONS

Each section in the configuration file (except for the [global] section) describes a shared resource (known as a “share”). The section name is the name of the shared resource and the parameters within the section define the shares attributes.

There are three special sections, [global], [homes] and [printers], which are described under special sections. The following notes apply to ordinary section descriptions.

A share consists of a directory to which access is being given plus a description of the access rights which are granted to the user of the service. Some housekeeping options are also specifiable.

Sections are either file share services (used by the client as an extension of their native file systems) or printable services (used by the client to access print services on the host running the server).

Sections may be designated guest services, in which case no password is required to access them. A specified UNIX guest account is used to define access privileges in this case.

Sections other than guest services will require a password to access them. The client provides the username. As older clients only provide passwords and not usernames, you may specify a list of usernames to check against the password using the user = option in the share definition. For modern clients such as Windows 95/98/ME/NT/2000, this should not be necessary.

The access rights granted by the server are masked by the access rights granted to the specified or guest UNIX user by the host system. The server does not grant more access than the host system grants.

The following sample section defines a file space share. The user has write access to the path /home/bar. The share is accessed via the share name foo:

[foo] path = /home/bar read only = no

The following sample section defines a printable share. The share is read-only, but printable. That is, the only write access permitted is via calls to open, write to and close a spool file. The guest ok parameter means access will be permitted as the default guest user (specified elsewhere):

[aprinter] path = /var/tmp read only = yes printable = yes guest ok = yes

SPECIAL SECTIONS

The [global] section

Parameters in this section apply to the server as a whole, or are defaults for sections that do not specifically define certain items. See the notes under PARAMETERS for more information.

The [homes] section

If a section called [homes] is included in the configuration file, services connecting clients to their home directories can be created on the fly by the server.

When the connection request is made, the existing sections are scanned. If a match is found, it is used. If no match is found, the requested section name is treated as a username and looked up in the local password file. If the name exists and the correct password has been given, a share is created by cloning the [homes] section.

Some modifications are then made to the newly created share:

·
The share name is changed from homes to the located username.
·
If no path was given, the path is set to the users home directory.

If you decide to use a path = line in your [homes] section, it may be useful to use the %S macro. For example:

path = /data/pchome/%S

is useful if you have different home directories for your PCs than for UNIX access.

This is a fast and simple way to give a large number of clients access to their home directories with a minimum of fuss.

A similar process occurs if the requested section name is “homes”, except that the share name is not changed to that of the requesting user. This method of using the [homes] section works well if different users share a client PC.

The [homes] section can specify all the parameters a normal service section can specify, though some make more sense than others. The following is a typical and suitable [homes] section:

[homes] read only = no

An important point is that if guest access is specified in the [homes] section, all home directories will be visible to all clients without a password. In the very unlikely event that this is actually desirable, it is wise to also specify read only access.

The browseable flag for auto home directories will be inherited from the global browseable flag, not the [homes] browseable flag. This is useful as it means setting browseable = no in the [homes] section will hide the [homes] share but make any auto home directories visible.

The [printers] section

This section works like [homes], but for printers.

If a [printers] section occurs in the configuration file, users are able to connect to any printer specified in the local hosts printcap file.

When a connection request is made, the existing sections are scanned. If a match is found, it is used. If no match is found, but a [homes] section exists, it is used as described above. Otherwise, the requested section name is treated as a printer name and the appropriate printcap file is scanned to see if the requested section name is a valid printer share name. If a match is found, a new printer share is created by cloning the [printers] section.

A few modifications are then made to the newly created share:

·
The share name is set to the located printer name
·
If no printer name was given, the printer name is set to the located printer name
·
If the share does not permit guest access and no username was given, the username is set to the located printer name.

The [printers] service MUST be printable - if you specify otherwise, the server will refuse to load the configuration file.

Typically the path specified is that of a world-writeable spool directory with the sticky bit set on it. A typical [printers] entry looks like this:

[printers] path = /var/tmp guest ok = yes printable = yes

All aliases given for a printer in the printcap file are legitimate printer names as far as the server is concerned. If your printing subsystem doesnt work like that, you will have to set up a pseudo-printcap. This is a file consisting of one or more lines like this:

alias|alias|alias|alias…

Each alias should be an acceptable printer name for your printing subsystem. In the [global] section, specify the new file as your printcap. The server will only recognize names found in your pseudo-printcap, which of course can contain whatever aliases you like. The same technique could be used simply to limit access to a subset of your local printers.

An alias, by the way, is defined as any component of the first entry of a printcap record. Records are separated by newlines, components (if there are more than one) are separated by vertical bar symbols (|).

Note
On SYSV systems which use lpstat to determine what printers are defined on the system you may be able to use printcap name = lpstat to automatically obtain a list of printers. See the printcap name option for more details.

USERSHARES

Starting with Samba version 3.0.23 the capability for non-root users to add, modify, and delete their own share definitions has been added. This capability is called usershares and is controlled by a set of parameters in the [global] section of the smb.conf. The relevant parameters are :

usershare allow guests

Controls if usershares can permit guest access.

usershare max shares

Maximum number of user defined shares allowed.

usershare owner only

If set only directories owned by the sharing user can be shared.

usershare path

Points to the directory containing the user defined share definitions. The filesystem permissions on this directory control who can create user defined shares.

usershare prefix allow list

Comma-separated list of absolute pathnames restricting what directories can be shared. Only directories below the pathnames in this list are permitted.

usershare prefix deny list

Comma-separated list of absolute pathnames restricting what directories can be shared. Directories below the pathnames in this list are prohibited.

usershare template share

Names a pre-existing share used as a template for creating new usershares. All other share parameters not specified in the user defined share definition are copied from this named share.

To allow members of the UNIX group foo to create user defined shares, create the directory to contain the share definitions as follows:

Become root:

mkdir /usr/local/samba/lib/usershares chgrp foo /usr/local/samba/lib/usershares chmod 1770 /usr/local/samba/lib/usershares

Then add the parameters

usershare path = /usr/local/samba/lib/usershares usershare max shares = 10 # (or the desired number of shares)

to the global section of your smb.conf. Members of the group foo may then manipulate the user defined shares using the following commands.

net usershare add sharename path [comment] [acl] [guest_ok=[y|n]]

To create or modify (overwrite) a user defined share.

net usershare delete sharename

To delete a user defined share.

net usershare list wildcard-sharename

To list user defined shares.

net usershare info wildcard-sharename

To print information about user defined shares.

PARAMETERS

Parameters define the specific attributes of sections.

Some parameters are specific to the [global] section (e.g., security). Some parameters are usable in all sections (e.g., create mask). All others are permissible only in normal sections. For the purposes of the following descriptions the [homes] and [printers] sections will be considered normal. The letter G in parentheses indicates that a parameter is specific to the [global] section. The letter S indicates that a parameter can be specified in a service specific section. All S parameters can also be specified in the [global] section - in which case they will define the default behavior for all services.

Parameters are arranged here in alphabetical order - this may not create best bedfellows, but at least you can find them! Where there are synonyms, the preferred synonym is described, others refer to the preferred synonym.

VARIABLE SUBSTITUTIONS

Many of the strings that are settable in the config file can take substitutions. For example the option “path = /tmp/%u” is interpreted as “path = /tmp/john” if the user connected with the username john.

These substitutions are mostly noted in the descriptions below, but there are some general substitutions which apply whenever they might be relevant. These are:

session username (the username that the client wanted, not necessarily the same as the one they got).

primary group name of %U.

the Internet hostname that Samba is running on.

the NetBIOS name of the client machine (very useful).
This parameter is not available when Samba listens on port 445, as clients no longer send this information. If you use this macro in an include statement on a domain that has a Samba domain controller be sure to set in the [global] section smb ports = 139. This will cause Samba to not listen on port 445 and will permit include functionality to function as it did with Samba 2.x.

the NetBIOS name of the server. This allows you to change your config based on what the client calls you. Your server can have a “dual personality”.

the Internet name of the client machine.

the selected protocol level after protocol negotiation. It can be one of CORE, COREPLUS, LANMAN1, LANMAN2, NT1, SMB2_02, SMB2_10, SMB3_00, SMB3_02, SMB3_11 or SMB2_FF.

the process id of the current server process.

The architecture of the remote machine. It currently recognizes Samba (Samba), the Linux CIFS file system (CIFSFS), OS/2, (OS2), Mac OS X (OSX), Windows for Workgroups (WfWg), Windows 9x/ME (Win95), Windows NT (WinNT), Windows 2000 (Win2K), Windows XP (WinXP), Windows XP 64-bit(WinXP64), Windows 2003 including 2003R2 (Win2K3), and Windows Vista (Vista). Anything else will be known as UNKNOWN.

the IP address of the client machine.
Before 4.0.0 it could contain IPv4 mapped IPv6 addresses, now it only contains IPv4 or IPv6 addresses.

the IP address of the client machine, colons/dots replaced by underscores.

the local IP address to which a client connected.
Before 4.0.0 it could contain IPv4 mapped IPv6 addresses, now it only contains IPv4 or IPv6 addresses.

the local IP address to which a client connected, colons/dots replaced by underscores.

the current date and time.

the current date and time in a minimal format without colons (YYYYYmmdd_HHMMSS).

name of the domain or workgroup of the current user.

the winbind separator.

%$(envvar)

the value of the environment variable envar.

The following substitutes apply only to some configuration options (only those that are used when a connection has been established):

the name of the current service, if any.

the root directory of the current service, if any.

username of the current service, if any.

primary group name of %u.

the home directory of the user given by %u.

This value is the same as %L.

There are some quite creative things that can be done with these substitutions and other smb.conf options.

NAME MANGLING

Samba supports name mangling so that DOS and Windows clients can use files that dont conform to the 8.3 format. It can also be set to adjust the case of 8.3 format filenames.

There are several options that control the way mangling is performed, and they are grouped here rather than listed separately. For the defaults look at the output of the testparm program.

These options can be set separately for each service.

The options are:

case sensitive = yes/no/auto

controls whether filenames are case sensitive. If they arent, Samba must do a filename search and match on passed names. The default setting of auto allows clients that support case sensitive filenames (Linux CIFSVFS and smbclient 3.0.5 and above currently) to tell the Samba server on a per-packet basis that they wish to access the file system in a case-sensitive manner (to support UNIX case sensitive semantics). No Windows or DOS system supports case-sensitive filename so setting this option to auto is the same as setting it to no for them. Default auto.

default case = upper/lower

controls what the default case is for new filenames (ie. files that dont currently exist in the filesystem). Default lower. IMPORTANT NOTE: As part of the optimizations for directories containing large numbers of files, the following special case applies. If the options case sensitive = yes, preserve case = No, and short preserve case = No are set, then the case of all incoming client filenames, not just new filenames, will be modified. See additional notes below.

preserve case = yes/no

controls whether new files (ie. files that dont currently exist in the filesystem) are created with the case that the client passes, or if they are forced to be the default case. Default yes.

short preserve case = yes/no

controls if new files (ie. files that dont currently exist in the filesystem) which conform to 8.3 syntax, that is all in upper case and of suitable length, are created upper case, or if they are forced to be the default case. This option can be used with preserve case = yes to permit long filenames to retain their case, while short names are lowercased. Default yes.

By default, Samba 3.0 has the same semantics as a Windows NT server, in that it is case insensitive but case preserving. As a special case for directories with large numbers of files, if the case options are set as follows, “case sensitive = yes”, “case preserve = no”, “short preserve case = no” then the “default case” option will be applied and will modify all filenames sent from the client when accessing this share.

REGISTRY-BASED CONFIGURATION

Starting with Samba version 3.2.0, the capability to store Samba configuration in the registry is available. The configuration is stored in the registry key HKLM\Software\Samba\smbconf. There are two levels of registry configuration:

1.
Share definitions stored in registry are used. This is triggered by setting the global parameter registry shares to “yes” in smb.conf.
The registry shares are loaded not at startup but on demand at runtime by smbd. Shares defined in smb.conf take priority over shares of the same name defined in registry.
2.
Global smb.conf options stored in registry are used. This can be activated in two different ways:
Firstly, a registry only configuration is triggered by setting config backend = registry in the [global] section of smb.conf. This resets everything that has been read from config files to this point and reads the content of the global configuration section from the registry. This is the recommended method of using registry based configuration.
Secondly, a mixed configuration can be activated by a special new meaning of the parameter include = registry in the [global] section of smb.conf. This reads the global options from registry with the same priorities as for an include of a text file. This may be especially useful in cases where an initial configuration is needed to access the registry.
Activation of global registry options automatically activates registry shares. So in the registry only case, shares are loaded on demand only.

Note: To make registry-based configurations foolproof at least to a certain extent, the use of lock directory and config backend inside the registry configuration has been disabled: Especially by changing the lock directory inside the registry configuration, one would create a broken setup where the daemons do not see the configuration they loaded once it is active.

The registry configuration can be accessed with tools like regedit or net (rpc) registry in the key HKLM\Software\Samba\smbconf. More conveniently, the conf subcommand of the net(8) utility offers a dedicated interface to read and write the registry based configuration locally, i.e. directly accessing the database file, circumventing the server.

IDENTITY MAPPING CONSIDERATIONS

In the SMB protocol, users, groups, and machines are represented by their security identifiers (SIDs). On POSIX system Samba processes need to run under corresponding POSIX user identities and with supplemental POSIX groups to allow access to the files owned by those users and groups. The process of mapping SIDs to POSIX users and groups is called IDENTITY MAPPING or, in short, ID MAPPING.

Samba supports multiple ways to map SIDs to POSIX users and groups. The configuration is driven by the idmap config DOMAIN : OPTION option which allows one to specify identity mapping (idmap) options for each domain separately.

Identity mapping modules implement different strategies for mapping of SIDs to POSIX user and group identities. They are applicable to different use cases and scenarios. It is advised to read the documentation of the individual identity mapping modules before choosing a specific scenario to use. Each identity management module is documented in a separate manual page. The standard idmap backends are tdb (idmap_tdb(8)), tdb2 (idmap_tdb2(8)), ldap (idmap_ldap(8)), rid (idmap_rid(8)), hash (idmap_hash(8)), autorid (idmap_autorid(8)), ad (idmap_ad(8)), nss (idmap_nss(8)), and rfc2307 (idmap_rfc2307(8)).

Overall, ID mapping configuration should be decided carefully. Changes to the already deployed ID mapping configuration may create the risk of losing access to the data or disclosing the data to the wrong parties.

This example shows how to configure two domains with idmap_rid(8), the principal domain and a trusted domain, leaving the default id mapping scheme at tdb.

[global] security = domain workgroup = MAIN

	idmap config * : backend        = tdb
	idmap config * : range          = 1000000-1999999

	idmap config MAIN : backend     = rid
	idmap config MAIN : range       = 5000000-5999999

	idmap config TRUSTED : backend  = rid
	idmap config TRUSTED : range    = 6000000-6999999

EXPLANATION OF EACH PARAMETER

abort shutdown script (G)

This a full path name to a script called by smbd(8) that should stop a shutdown procedure issued by the shutdown script.
If the connected user possesses the SeRemoteShutdownPrivilege, right, this command will be run as root.
Default: abort shutdown script = ""
Example: abort shutdown script = /sbin/shutdown -c

access based share enum (S)

If this parameter is yes for a service, then the share hosted by the service will only be visible to users who have read or write access to the share during share enumeration (for example net view \sambaserver). The share ACLs which allow or deny the access to the share can be modified using for example the sharesec command or using the appropriate Windows tools. This has parallels to access based enumeration, the main difference being that only share permissions are evaluated, and security descriptors on files contained on the share are not used in computing enumeration access rights.
Default: access based share enum = no

acl allow execute always (S)

This boolean parameter controls the behaviour of smbd(8) when receiving a protocol request of “open for execution” from a Windows client. With Samba 3.6 and older, the execution right in the ACL was not checked, so a client could execute a file even if it did not have execute rights on the file. In Samba 4.0, this has been fixed, so that by default, i.e. when this parameter is set to “False”, “open for execution” is now denied when execution permissions are not present.
If this parameter is set to “True”, Samba does not check execute permissions on “open for execution”, thus re-establishing the behaviour of Samba 3.6. This can be useful to smoothen upgrades from older Samba versions to 4.0 and newer. This setting is not meant to be used as a permanent setting, but as a temporary relief: It is recommended to fix the permissions in the ACLs and reset this parameter to the default after a certain transition period.
Default: acl allow execute always = no

acl check permissions (S)

Please note this parameter is now deprecated in Samba 3.6.2 and will be removed in a future version of Samba.
This boolean parameter controls what smbd(8) does on receiving a protocol request of “open for delete” from a Windows client. If a Windows client doesnt have permissions to delete a file then they expect this to be denied at open time. POSIX systems normally only detect restrictions on delete by actually attempting to delete the file or directory. As Windows clients can (and do) “back out” a delete request by unsetting the “delete on close” bit Samba cannot delete the file immediately on “open for delete” request as we cannot restore such a deleted file. With this parameter set to true (the default) then smbd checks the file system permissions directly on “open for delete” and denies the request without actually deleting the file if the file system permissions would seem to deny it. This is not perfect, as its possible a user could have deleted a file without Samba being able to check the permissions correctly, but it is close enough to Windows semantics for mostly correct behaviour. Samba will correctly check POSIX ACL semantics in this case.
If this parameter is set to “false” Samba doesnt check permissions on “open for delete” and allows the open. If the user doesnt have permission to delete the file this will only be discovered at close time, which is too late for the Windows user tools to display an error message to the user. The symptom of this is files that appear to have been deleted “magically” re-appearing on a Windows explorer refresh. This is an extremely advanced protocol option which should not need to be changed. This parameter was introduced in its final form in 3.0.21, an earlier version with slightly different semantics was introduced in 3.0.20. That older version is not documented here.
Default: acl check permissions = yes

acl claims evaluation (G)

This option controls the way Samba handles evaluation of security descriptors in Samba, with regards to Active Directory Claims. AD Claims, introduced with Windows 2012, are essentially administrator-defined key-value pairs that can be set both in Active Directory (communicated via the Kerberos PAC) and in the security descriptor themselves.
Active Directory claims are new with Samba 4.20. Because the claims are evaluated against a very flexible expression language within the security descriptor, this option provides a mechanism to disable this logic if required by the administrator.
This default behaviour is that claims evaluation is enabled in the AD DC only. Additionally, claims evaluation on the AD DC is only enabled if the DC functional level is 2012 or later. See ad dc functional level.
Possible values are :
·
AD DC only: Enabled for the Samba AD DC (for DC functional level 2012 or higher).
·
never: Disabled in all cases. This option disables some but not all of the Authentication Policies and Authentication Policy Silos features of the Windows 2012R2 functional level in the AD DC.
Default: acl claims evaluation = AD DC only

acl flag inherited canonicalization (S)

This option controls the way Samba handles client requests setting the Security Descriptor of files and directories and the effect the operation has on the Security Descriptor flag “DACL auto-inherited” (DI). Generally, this flag is set on a file (or directory) upon creation if the parent directory has DI set and also has inheritable ACEs.
On the other hand when a Security Descriptor is explicitly set on a file, the DI flag is cleared, unless the flag “DACL Inheritance Required” (DR) is also set in the new Security Descriptor (fwiw, DR is never stored on disk).
This is the default behaviour when this option is enabled (the default). When setting this option to no, the resulting value of the DI flag on-disk is directly taken from the DI value of the to-be-set Security Descriptor. This can be used so dump tools like rsync that copy data blobs from xattrs that represent ACLs created by the acl_xattr VFS module will result in copies of the ACL that are identical to the source. Without this option, the copied ACLs would all lose the DI flag if set on the source.
Default: acl flag inherited canonicalization = yes

acl group control (S)

In a POSIX filesystem, only the owner of a file or directory and the superuser can modify the permissions and ACLs on a file. If this parameter is set, then Samba overrides this restriction, and also allows the primary group owner of a file or directory to modify the permissions and ACLs on that file.
On a Windows server, groups may be the owner of a file or directory - thus allowing anyone in that group to modify the permissions on it. This allows the delegation of security controls on a point in the filesystem to the group owner of a directory and anything below it also owned by that group. This means there are multiple people with permissions to modify ACLs on a file or directory, easing manageability.
This parameter allows Samba to also permit delegation of the control over a point in the exported directory hierarchy in much the same way as Windows. This allows all members of a UNIX group to control the permissions on a file or directory they have group ownership on.
This parameter is best used with the inherit owner option and also on a share containing directories with the UNIX setgid bit set on them, which causes new files and directories created within it to inherit the group ownership from the containing directory.
This parameter was deprecated in Samba 3.0.23, but re-activated in Samba 3.0.31 and above, as it now only controls permission changes if the user is in the owning primary group. It is now no longer equivalent to the dos filemode option.
Default: acl group control = no

acl map full control (S)

This boolean parameter controls whether smbd(8) maps a POSIX ACE entry of “rwx” (read/write/execute), the maximum allowed POSIX permission set, into a Windows ACL of “FULL CONTROL”. If this parameter is set to true any POSIX ACE entry of “rwx” will be returned in a Windows ACL as “FULL CONTROL”, is this parameter is set to false any POSIX ACE entry of “rwx” will be returned as the specific Windows ACL bits representing read, write and execute.
Default: acl map full control = yes

ad dc functional level (G)

The value of the parameter (a string) is the Active Directory functional level that this Domain Controller will claim to support.
Possible values are :
·
2008_R2: Similar to Windows 2008 R2 Functional Level
·
2012: Similar to Windows 2012 Functional Level
·
2012_R2: Similar to Windows 2012 R2 Functional Level
·
2016: Similar to Windows 2016 Functional Level
Normally this option should not be set as Samba will operate per the released functionality of the Samba Active Directory Domain Controller.
However to access incomplete features in domain functional level 2016 it may be useful to set this value, prior to upgrading the domain functional level.
If this is set manually, the protection against mismatching features between domain controllers is reduced, so all domain controllers should be running the same version of Samba, to ensure that behaviour as seen by the client is the same no matter which DC is contacted.
Setting this to 2016 will allow raising the domain functional level with samba-tool domain level raise –domain-level=2016 and provide access to Sambas Kerberos Claims and Dynamic Access Control feature.
Warning
The Sambas Kerberos Claims and Dynamic Access Control features enabled with 2016 are incomplete in Samba 4.19.
Default: ad dc functional level = 2008_R2
Example: ad dc functional level = 2016

add group script (G)

This is the full pathname to a script that will be run AS ROOT by smbd(8) when a new group is requested. It will expand any %g to the group name passed. This script is only useful for installations using the Windows NT domain administration tools. The script is free to create a group with an arbitrary name to circumvent unix group name restrictions. In that case the script must print the numeric gid of the created group on stdout.
Default: add group script =
Example: add group script = /usr/sbin/groupadd %g

additional dns hostnames (G)

A list of additional DNS names by which this host can be identified
Default: additional dns hostnames = # empty string (no additional dns names)
Example: additional dns hostnames = host2.example.com host3.other.com

add machine script (G)

This is the full pathname to a script that will be run by smbd(8) when a machine is added to Sambas domain and a Unix account matching the machines name appended with a “$” does not already exist.
This option is very similar to the add user script, and likewise uses the %u substitution for the account name. Do not use the %m substitution.
Default: add machine script =
Example: add machine script = /usr/sbin/adduser -n -g machines -c Machine -d /var/lib/nobody -s /bin/false %u

addport command (G)

Samba 3.0.23 introduced support for adding printer ports remotely using the Windows “Add Standard TCP/IP Port Wizard”. This option defines an external program to be executed when smbd receives a request to add a new Port to the system. The script is passed two parameters:
·
port name
·
device URI
The deviceURI is in the format of socket://<hostname>[:<portnumber>] or lpd://<hostname>/<queuename>.
Default: addport command =
Example: addport command = /etc/samba/scripts/addport.sh

addprinter command (G)

With the introduction of MS-RPC based printing support for Windows NT/2000 clients in Samba 2.2, The MS Add Printer Wizard (APW) icon is now also available in the “Printers…” folder displayed a share listing. The APW allows for printers to be add remotely to a Samba or Windows NT/2000 print server.
For a Samba host this means that the printer must be physically added to the underlying printing system. The addprinter command defines a script to be run which will perform the necessary operations for adding the printer to the print system and to add the appropriate service definition to the smb.conf file in order that it can be shared by smbd(8).
The addprinter command is automatically invoked with the following parameter (in order):
·
printer name
·
share name
·
port name
·
driver name
·
location
·
Windows 9x driver location
All parameters are filled in from the PRINTER_INFO_2 structure sent by the Windows NT/2000 client with one exception. The “Windows 9x driver location” parameter is included for backwards compatibility only. The remaining fields in the structure are generated from answers to the APW questions.
Once the addprinter command has been executed, smbd will reparse the smb.conf to determine if the share defined by the APW exists. If the sharename is still invalid, then smbd will return an ACCESS_DENIED error to the client.
The addprinter command program can output a single line of text, which Samba will set as the port the new printer is connected to. If this line isnt output, Samba wont reload its printer shares.
Default: addprinter command =
Example: addprinter command = /usr/bin/addprinter

add share command (G)

Samba 2.2.0 introduced the ability to dynamically add and delete shares via the Windows NT 4.0 Server Manager. The add share command is used to define an external program or script which will add a new service definition to smb.conf.
In order to successfully execute the add share command, smbd requires that the administrator connects using a root account (i.e. uid == 0) or has the SeDiskOperatorPrivilege. Scripts defined in the add share command parameter are executed as root.
When executed, smbd will automatically invoke the add share command with five parameters.
·
configFile - the location of the global smb.conf file.
·
shareName - the name of the new share.
·
pathName - path to an **existing** directory on disk.
·
comment - comment string to associate with the new share.
·
max connections Number of maximum simultaneous connections to this share.
This parameter is only used to add file shares. To add printer shares, see the addprinter command.
Default: add share command =
Example: add share command = /usr/local/bin/addshare

add user script (G)

This is the full pathname to a script that will be run AS ROOT by smbd(8) under special circumstances described below.
Normally, a Samba server requires that UNIX users are created for all users accessing files on this server. For sites that use Windows NT account databases as their primary user database creating these users and keeping the user list in sync with the Windows NT PDC is an onerous task. This option allows smbd to create the required UNIX users ON DEMAND when a user accesses the Samba server.
When the Windows user attempts to access the Samba server, at login (session setup in the SMB protocol) time, smbd(8) contacts the password server and attempts to authenticate the given user with the given password. If the authentication succeeds then smbd attempts to find a UNIX user in the UNIX password database to map the Windows user into. If this lookup fails, and add user script is set then smbd will call the specified script AS ROOT, expanding any %u argument to be the user name to create.
If this script successfully creates the user then smbd will continue on as though the UNIX user already existed. In this way, UNIX users are dynamically created to match existing Windows NT accounts.
See also security, password server, delete user script.
Default: add user script =
Example: add user script = /usr/local/samba/bin/add_user %u

add user to group script (G)

Full path to the script that will be called when a user is added to a group using the Windows NT domain administration tools. It will be run by smbd(8) AS ROOT. Any %g will be replaced with the group name and any %u will be replaced with the user name.
Note that the adduser command used in the example below does not support the used syntax on all systems.
Default: add user to group script =
Example: add user to group script = /usr/sbin/adduser %u %g

administrative share (S)

If this parameter is set to yes for a share, then the share will be an administrative share. The Administrative Shares are the default network shares created by all Windows NT-based operating systems. These are shares like C$, D$ or ADMIN$. The type of these shares is STYPE_DISKTREE_HIDDEN.
See the section below on security for more information about this option.
Default: administrative share = no

admin users (S)

This is a list of users who will be granted administrative privileges on the share. This means that they will do all file operations as the super-user (root).
You should use this option very carefully, as any user in this list will be able to do anything they like on the share, irrespective of file permissions.
Default: admin users =
Example: admin users = jason

afs share (S)

This parameter controls whether special AFS features are enabled for this share. If enabled, it assumes that the directory exported via the path parameter is a local AFS import. The special AFS features include the attempt to hand-craft an AFS token if you enabled –with-fake-kaserver in configure.
Default: afs share = no

afs token lifetime (G)

This parameter controls the lifetime of tokens that the AFS fake-kaserver claims. In reality these never expire but this lifetime controls when the afs client will forget the token.
Set this parameter to 0 to get NEVERDATE.
Default: afs token lifetime = 604800

afs username map (G)

If you are using the fake kaserver AFS feature, you might want to hand-craft the usernames you are creating tokens for. For example this is necessary if you have users from several domain in your AFS Protection Database. One possible scheme to code users as DOMAIN+User as it is done by winbind with the + as a separator.
The mapped user name must contain the cell name to log into, so without setting this parameter there will be no token.
Default: afs username map =
Example: afs username map = %[email protected]

aio max threads (G)

The integer parameter specifies the maximum number of threads each smbd process will create when doing parallel asynchronous IO calls. If the number of outstanding calls is greater than this number the requests will not be refused but go onto a queue and will be scheduled in turn as outstanding requests complete.
Related command: aio read size
Related command: aio write size
Default: aio max threads = 100

aio read size (S)

If this integer parameter is set to a non-zero value, Samba will read from files asynchronously when the request size is bigger than this value. Note that it happens only for non-chained and non-chaining reads.
The only reasonable values for this parameter are 0 (no async I/O) and 1 (always do async I/O).
Related command: aio write size
Default: aio read size = 1
Example: aio read size = 0 # Always do reads synchronously

aio write behind (S)

If Samba has been built with asynchronous I/O support, Samba will not wait until write requests are finished before returning the result to the client for files listed in this parameter. Instead, Samba will immediately return that the write request has been finished successfully, no matter if the operation will succeed or not. This might speed up clients without aio support, but is really dangerous, because data could be lost and files could be damaged.
The syntax is identical to the veto files parameter.
Default: aio write behind =
Example: aio write behind = /*.tmp/

aio write size (S)

If this integer parameter is set to a non-zero value, Samba will write to files asynchronously when the request size is bigger than this value. Note that it happens only for non-chained and non-chaining writes.
The only reasonable values for this parameter are 0 (no async I/O) and 1 (always do async I/O).
Compared to aio read size this parameter has a smaller effect, most writes should end up in the file system cache. Writes that require space allocation might benefit most from going asynchronous.
Related command: aio read size
Default: aio write size = 1
Example: aio write size = 0 # Always do writes synchronously

algorithmic rid base (G)

This determines how Samba will use its algorithmic mapping from uids/gid to the RIDs needed to construct NT Security Identifiers.
Setting this option to a larger value could be useful to sites transitioning from WinNT and Win2k, as existing user and group rids would otherwise clash with system users etc.
All UIDs and GIDs must be able to be resolved into SIDs for the correct operation of ACLs on the server. As such the algorithmic mapping cant be turned off, but pushing it out of the way should resolve the issues. Users and groups can then be assigned low RIDs in arbitrary-rid supporting backends.
Default: algorithmic rid base = 1000
Example: algorithmic rid base = 100000

allocation roundup size (S)

This parameter allows an administrator to tune the allocation size reported to Windows clients. This is only useful for old SMB1 clients because modern SMB dialects eliminated that bottleneck and have better performance by default. Using this parameter may cause difficulties for some applications, e.g. MS Visual Studio. If the MS Visual Studio compiler starts to crash with an internal error, set this parameter to zero for this share. Settings this parameter to a large value can also cause small files to allocate more space on the disk than needed.
This parameter is deprecated and will be removed in one of the next Samba releases.
The integer parameter specifies the roundup size in bytes.
Default: allocation roundup size = 0
Example: allocation roundup size = 1048576 # (to set it to the former default of 1 MiB)

allow dcerpc auth level connect (G)

This option controls whether DCERPC services are allowed to be used with DCERPC_AUTH_LEVEL_CONNECT, which provides authentication, but no per message integrity nor privacy protection.
Some interfaces like samr, lsarpc and netlogon have a hard-coded default of no and epmapper, mgmt and rpcecho have a hard-coded default of yes.
The behavior can be overwritten per interface name (e.g. lsarpc, netlogon, samr, srvsvc, winreg, wkssvc …) by using allow dcerpc auth level connect:interface = yes as option.
This option is over-ridden by the implementation specific restrictions. E.g. the drsuapi and backupkey protocols require DCERPC_AUTH_LEVEL_PRIVACY. The dnsserver protocol requires DCERPC_AUTH_LEVEL_INTEGRITY.
Default: allow dcerpc auth level connect = no
Example: allow dcerpc auth level connect = yes

allow dns updates (G)

This option determines what kind of updates to the DNS are allowed.
DNS updates can either be disallowed completely by setting it to disabled, enabled over secure connections only by setting it to secure only or allowed in all cases by setting it to nonsecure.
Default: allow dns updates = secure only
Example: allow dns updates = disabled

allow insecure wide links (G)

In normal operation the option wide links which allows the server to follow symlinks outside of a share path is automatically disabled when unix extensions are enabled on a Samba server. This is done for security purposes to prevent UNIX clients creating symlinks to areas of the server file system that the administrator does not wish to export.
Setting allow insecure wide links to true disables the link between these two parameters, removing this protection and allowing a site to configure the server to follow symlinks (by setting wide links to “true”) even when unix extensions is turned on.
It is not recommended to enable this option unless you fully understand the implications of allowing the server to follow symbolic links created by UNIX clients. For most normal Samba configurations this would be considered a security hole and setting this parameter is not recommended.
This option was added at the request of sites who had deliberately set Samba up in this way and needed to continue supporting this functionality without having to patch the Samba code.
Default: allow insecure wide links = no

allow nt4 crypto (G)

This option is deprecated and will be removed in future, as it is a security problem if not set to “no” (which will be the hardcoded behavior in future).
This option controls whether the netlogon server (currently only in active directory domain controller mode), will reject clients which do not support NETLOGON_NEG_STRONG_KEYS nor NETLOGON_NEG_SUPPORTS_AES.
This option was added with Samba 4.2.0. It may lock out clients which worked fine with Samba versions up to 4.1.x. as the effective default was “yes” there, while it is “no” now.
If you have clients without RequireStrongKey = 1 in the registry, you may need to set “allow nt4 crypto = yes”, until you have fixed all clients.
“allow nt4 crypto = yes” allows weak crypto to be negotiated, maybe via downgrade attacks.
Avoid using this option! Use explicit allow nt4 crypto:COMPUTERACCOUNT = yes instead! Which is available with the patches for CVE-2022-38023 see https://bugzilla.samba.org/show_bug.cgi?id=15240
Samba will log an error in the log files at log level 0 if legacy a client is rejected or allowed without an explicit, allow nt4 crypto:COMPUTERACCOUNT = yes option for the client. The message will indicate the explicit allow nt4 crypto:COMPUTERACCOUNT = yes line to be added, if the legacy client software requires it. (The log level can be adjusted with CVE_2022_38023:error_debug_level = 1 in order to complain only at a higher log level).
This allows admins to use “yes” only for a short grace period, in order to collect the explicit allow nt4 crypto:COMPUTERACCOUNT = yes options.
This option is over-ridden by the effective value of yes from the server reject md5 schannel:COMPUTERACCOUNT and/or reject md5 clients options.
Default: allow nt4 crypto = no

allow nt4 crypto:COMPUTERACCOUNT (G)

If you still have legacy domain members which required allow nt4 crypto = yes, it is possible to specify an explicit exception per computer account by using allow nt4 crypto:COMPUTERACCOUNT = yes as option. Note that COMPUTERACCOUNT has to be the sAMAccountName value of the computer account (including the trailing $ sign).
Samba will log a complaint in the log files at log level 0 about the security problem if the option is set to “yes”, but the related computer does not require it. (The log level can be adjusted with CVE_2022_38023:warn_about_unused_debug_level = 1 in order to complain only at a higher log level).
Samba will log a warning in the log files at log level 5, if a setting is still needed for the specified computer account.
See CVE-2022-38023, https://bugzilla.samba.org/show_bug.cgi?id=15240.
This option overrides the allow nt4 crypto option.
This option is over-ridden by the effective value of yes from the server reject md5 schannel:COMPUTERACCOUNT and/or reject md5 clients options.
Which means allow nt4 crypto:COMPUTERACCOUNT = yes is only useful in combination with server reject md5 schannel:COMPUTERACCOUNT = no
allow nt4 crypto:LEGACYCOMPUTER1$ = yes
	server reject md5 schannel:LEGACYCOMPUTER1$ = no
	allow nt4 crypto:NASBOX$ = yes
	server reject md5 schannel:NASBOX$ = no
	allow nt4 crypto:LEGACYCOMPUTER2$ = yes
	server reject md5 schannel:LEGACYCOMPUTER2$ = no
No default

allow trusted domains (G)

This option only takes effect when the security option is set to server, domain or ads. If it is set to no, then attempts to connect to a resource from a domain or workgroup other than the one which smbd is running in will fail, even if that domain is trusted by the remote server doing the authentication.
This is useful if you only want your Samba server to serve resources to users in the domain it is a member of. As an example, suppose that there are two domains DOMA and DOMB. DOMB is trusted by DOMA, which contains the Samba server. Under normal circumstances, a user with an account in DOMB can then access the resources of a UNIX account with the same account name on the Samba server even if they do not have an account in DOMA. This can make implementing a security boundary difficult.
Default: allow trusted domains = yes

allow unsafe cluster upgrade (G)

If set to no (the default), smbd checks at startup if other smbd versions are running in the cluster and refuses to start if so. This is done to protect data corruption in internal data structures due to incompatible Samba versions running concurrently in the same cluster. Setting this parameter to yes disables this safety check.
Default: allow unsafe cluster upgrade = no

apply group policies (G)

This option controls whether winbind will execute the gpupdate command defined in gpo update command on the Group Policy update interval. The Group Policy update interval is defined as every 90 minutes, plus a random offset between 0 and 30 minutes. This applies Group Policy Machine polices to the client or KDC and machine policies to a server.
Default: apply group policies = no
Example: apply group policies = yes

async dns timeout (G)

The number of seconds the asynchronous DNS resolver code in Samba will wait for responses. Some of the Samba client library code uses internal asynchronous DNS resolution for A and AAAA records when trying to find Active Directory Domain controllers. This value prevents this name resolution code from waiting for DNS server timeouts.
The minimum value of this parameter is clamped at 1 second.
Default: async dns timeout = 10
Example: async dns timeout = 20

async smb echo handler (G)

This parameter specifies whether Samba should fork the async smb echo handler. It can be beneficial if your file system can block syscalls for a very long time. In some circumstances, it prolongs the timeout that Windows uses to determine whether a connection is dead. This parameter is only for SMB1. For SMB2 and above TCP keepalives can be used instead.
Default: async smb echo handler = no

auth event notification (G)

When enabled, this option causes Samba (acting as an Active Directory Domain Controller) to stream authentication events across the internal message bus. Scripts built using Sambas python bindings can listen to these events by registering as the service auth_event.
This is not needed for the audit logging described in log level.
Instead, this should instead be considered a developer option (it assists in the Samba testsuite) rather than a facility for external auditing, as message delivery is not guaranteed (a feature that the testsuite works around).
The authentication events are also logged via the normal logging methods when the log level is set appropriately, say to auth_json_audit:3.
Default: auth event notification = no

preload

This parameter is a synonym for auto services.

auto services (G)

This is a list of services that you want to be automatically added to the browse lists. This is most useful for homes and printers services that would otherwise not be visible.
Note that if you just want all printers in your printcap file loaded then the load printers option is easier.
Default: auto services =
Example: auto services = fred lp colorlp

available (S)

This parameter lets you “turn off” a service. If available = no, then ALL attempts to connect to the service will fail. Such failures are logged.
Default: available = yes

bind dns directory

This parameter is a synonym for binddns dir.

binddns dir (G)

This parameters defines the directory samba will use to store the configuration files for bind, such as named.conf. NOTE: The bind dns directory needs to be on the same mount point as the private directory!
Default: binddns dir = /var/lib/samba/bind-dns

bind interfaces only (G)

This global parameter allows the Samba admin to limit what interfaces on a machine will serve SMB requests. It affects file service smbd(8) and name service nmbd(8) in a slightly different ways.
For name service it causes nmbd to bind to ports 137 and 138 on the interfaces listed in the interfaces parameter. nmbd also binds to the “all addresses” interface (0.0.0.0) on ports 137 and 138 for the purposes of reading broadcast messages. If this option is not set then nmbd will service name requests on all of these sockets. If bind interfaces only is set then nmbd will check the source address of any packets coming in on the broadcast sockets and discard any that dont match the broadcast addresses of the interfaces in the interfaces parameter list. As unicast packets are received on the other sockets it allows nmbd to refuse to serve names to machines that send packets that arrive through any interfaces not listed in the interfaces list. IP Source address spoofing does defeat this simple check, however, so it must not be used seriously as a security feature for nmbd.
For file service it causes smbd(8) to bind only to the interface list given in the interfaces parameter. This restricts the networks that smbd will serve, to packets coming in on those interfaces. Note that you should not use this parameter for machines that are serving PPP or other intermittent or non-broadcast network interfaces as it will not cope with non-permanent interfaces.
If bind interfaces only is set and the network address 127.0.0.1 is not added to the interfaces parameter list smbpasswd(8) may not work as expected due to the reasons covered below.
To change a users SMB password, the smbpasswd by default connects to the localhost - 127.0.0.1 address as an SMB client to issue the password change request. If bind interfaces only is set then unless the network address 127.0.0.1 is added to the interfaces parameter list then smbpasswd will fail to connect in its default mode. smbpasswd can be forced to use the primary IP interface of the local host by using its smbpasswd(8) -r remote machine parameter, with remote machine set to the IP name of the primary interface of the local host.
Default: bind interfaces only = no

blocking locks (S)

This parameter controls the behavior of smbd(8) when given a request by a client to obtain a byte range lock on a region of an open file, and the request has a time limit associated with it.
If this parameter is set and the lock range requested cannot be immediately satisfied, samba will internally queue the lock request, and periodically attempt to obtain the lock until the timeout period expires.
If this parameter is set to no, then samba will behave as previous versions of Samba would and will fail the lock request immediately if the lock range cannot be obtained.
Default: blocking locks = yes

block size (S)

This parameter controls the behavior of smbd(8) when reporting disk free sizes. By default, this reports a disk block size of 1024 bytes.
Changing this parameter may have some effect on the efficiency of client writes, this is not yet confirmed. This parameter was added to allow advanced administrators to change it (usually to a higher value) and test the effect it has on client write performance without re-compiling the code. As this is an experimental option it may be removed in a future release.
Changing this option does not change the disk free reporting size, just the block size unit reported to the client.
Default: block size = 1024
Example: block size = 4096

browsable

This parameter is a synonym for browseable.

browseable (S)

This controls whether this share is seen in the list of available shares in a net view and in the browse list.
Default: browseable = yes

browse list (G)

This controls whether smbd(8) will serve a browse list to a client doing a NetServerEnum call. Normally set to yes. You should never need to change this.
Default: browse list = yes

cache directory (G)

Usually, most of the TDB files are stored in the lock directory. Since Samba 3.4.0, it is possible to differentiate between TDB files with persistent data and TDB files with non-persistent data using the state directory and the cache directory options.
This option specifies the directory for storing TDB files containing non-persistent data that will be kept across service restarts. The directory should be placed on persistent storage, but the data can be safely deleted by an administrator.
Default: cache directory = /var/cache/samba
Example: cache directory = /var/run/samba/locks/cache

casesignames

This parameter is a synonym for case sensitive.

case sensitive (S)

See the discussion in the section name mangling.
Default: case sensitive = auto

change notify (G)

This parameter specifies whether Samba should reply to a clients file change notify requests.
You should never need to change this parameter
Default: change notify = yes

change share command (G)

Samba 2.2.0 introduced the ability to dynamically add and delete shares via the Windows NT 4.0 Server Manager. The change share command is used to define an external program or script which will modify an existing service definition in smb.conf.
In order to successfully execute the change share command, smbd requires that the administrator connects using a root account (i.e. uid == 0) or has the SeDiskOperatorPrivilege. Scripts defined in the change share command parameter are executed as root.
When executed, smbd will automatically invoke the change share command with six parameters.
·
configFile - the location of the global smb.conf file.
·
shareName - the name of the new share.
·
pathName - path to an **existing** directory on disk.
·
comment - comment string to associate with the new share.
·
max connections Number of maximum simultaneous connections to this share.
·
CSC policy - client side caching policy in string form. Valid values are: manual, documents, programs, disable.
This parameter is only used to modify existing file share definitions. To modify printer shares, use the “Printers…” folder as seen when browsing the Samba host.
Default: change share command =
Example: change share command = /usr/local/bin/changeshare

check parent directory delete on close (S)

A Windows SMB server prevents the client from creating files in a directory that has the delete-on-close flag set. By default Samba doesnt perform this check as this check is a quite expensive operation in Samba.
Default: check parent directory delete on close = no

check password script (G)

The name of a program that can be used to check password complexity. The password is sent to the programs standard input.
The program must return 0 on a good password, or any other value if the password is bad. In case the password is considered weak (the program does not return 0) the user will be notified and the password change will fail.
In Samba AD, this script will be run AS ROOT by samba(8) without any substitutions.
Note that starting with Samba 4.11 the following environment variables are exported to the script:
·
SAMBA_CPS_ACCOUNT_NAME is always present and contains the sAMAccountName of user, the is the same as the %u substitutions in the none AD DC case.
·
SAMBA_CPS_USER_PRINCIPAL_NAME is optional in the AD DC case if the userPrincipalName is present.
·
SAMBA_CPS_FULL_NAME is optional if the displayName is present.
Note: In the example directory is a sample program called crackcheck that uses cracklib to check the password quality.
Default: check password script = # Disabled
Example: check password script = /usr/local/sbin/crackcheck

cldap port (G)

This option controls the port used by the CLDAP protocol.
Default: cldap port = 389
Example: cldap port = 3389

client ipc max protocol (G)

The value of the parameter (a string) is the highest protocol level that will be supported for IPC$ connections as DCERPC transport.
Normally this option should not be set as the automatic negotiation phase in the SMB protocol takes care of choosing the appropriate protocol.
The value default refers to the latest supported protocol, currently SMB3_11.
See client max protocol for a full list of available protocols. The values CORE, COREPLUS, LANMAN1, LANMAN2 are silently upgraded to NT1.
Default: client ipc max protocol = default
Example: client ipc max protocol = SMB2_10

client ipc min protocol (G)

This setting controls the minimum protocol version that the will be attempted to use for IPC$ connections as DCERPC transport.
Normally this option should not be set as the automatic negotiation phase in the SMB protocol takes care of choosing the appropriate protocol.
The value default refers to the higher value of NT1 and the effective value of client min protocol.
See client max protocol for a full list of available protocols. The values CORE, COREPLUS, LANMAN1, LANMAN2 are silently upgraded to NT1.
Default: client ipc min protocol = default
Example: client ipc min protocol = SMB3_11

client ipc signing (G)

This controls whether the client is allowed or required to use SMB signing for IPC$ connections as DCERPC transport. Possible values are desired, required and disabled.
When set to required or default, SMB signing is mandatory.
When set to desired, SMB signing is offered, but not enforced and if set to disabled, SMB signing is not offered either.
Connections from winbindd to Active Directory Domain Controllers always enforce signing.
Default: client ipc signing = default

client lanman auth (G)

This parameter has been deprecated since Samba 4.13 and support for LanMan (as distinct from NTLM, NTLMv2 or Kerberos) authentication as a client will be removed in a future Samba release.
That is, in the future, the current default of client NTLMv2 auth = yes will be the enforced behaviour.
This parameter determines whether or not smbclient(8) and other samba client tools will attempt to authenticate itself to servers using the weaker LANMAN password hash. If disabled, only server which support NT password hashes (e.g. Windows NT/2000, Samba, etc… but not Windows 95/98) will be able to be connected from the Samba client.
The LANMAN encrypted response is easily broken, due to its case-insensitive nature, and the choice of algorithm. Clients without Windows 95/98 servers are advised to disable this option.
Disabling this option will also disable the client plaintext auth option.
Likewise, if the client ntlmv2 auth parameter is enabled, then only NTLMv2 logins will be attempted.
Default: client lanman auth = no

client ldap sasl wrapping (G)

The client ldap sasl wrapping defines whether ldap traffic will be signed or signed and encrypted (sealed). Possible values are plain, sign and seal.
The values sign and seal are only available if Samba has been compiled against a modern OpenLDAP version (2.3.x or higher).
This option is needed firstly to secure the privacy of administrative connections from samba-tool, including in particular new or reset passwords for users. For this reason the default is seal.
Additionally, winbindd and the net tool can use LDAP to communicate with Domain Controllers, so this option also controls the level of privacy for those connections. All supported AD DC versions will enforce the usage of at least signed LDAP connections by default, so a value of at least sign is required in practice.
The default value is seal. That implies synchronizing the time with the KDC in the case of using Kerberos.
Default: client ldap sasl wrapping = seal

client max protocol (G)

The value of the parameter (a string) is the highest protocol level that will be supported by the client.
Possible values are :
·
CORE: Earliest version. No concept of user names.
·
COREPLUS: Slight improvements on CORE for efficiency.
·
LANMAN1: First modern version of the protocol. Long filename support.
·
LANMAN2: Updates to Lanman1 protocol.
·
NT1: Current up to date version of the protocol. Used by Windows NT. Known as CIFS.
·
SMB2: Re-implementation of the SMB protocol. Used by Windows Vista and later versions of Windows. SMB2 has sub protocols available.
·
SMB2_02: The earliest SMB2 version.
·
SMB2_10: Windows 7 SMB2 version.
By default SMB2 selects the SMB2_10 variant.
·
SMB3: The same as SMB2. Used by Windows 8. SMB3 has sub protocols available.
·
SMB3_00: Windows 8 SMB3 version.
·
SMB3_02: Windows 8.1 SMB3 version.
·
SMB3_11: Windows 10 SMB3 version.
By default SMB3 selects the SMB3_11 variant.
Normally this option should not be set as the automatic negotiation phase in the SMB protocol takes care of choosing the appropriate protocol.
The value default refers to SMB3_11.
IPC$ connections for DCERPC e.g. in winbindd, are handled by the client ipc max protocol option.
Default: client max protocol = default
Example: client max protocol = LANMAN1

client min protocol (G)

This setting controls the minimum protocol version that the client will attempt to use.
Normally this option should not be set as the automatic negotiation phase in the SMB protocol takes care of choosing the appropriate protocol unless you connect to a legacy SMB1-only server.
See Related command: client max protocol for a full list of available protocols.
IPC$ connections for DCERPC e.g. in winbindd, are handled by the client ipc min protocol option.
Note that most command line tools support –option=client min protocol=NT1, so it may not be required to enable SMB1 protocols globally in smb.conf.
Default: client min protocol = SMB2_02
Example: client min protocol = NT1

client NTLMv2 auth (G)

This parameter has been deprecated since Samba 4.13 and support for NTLM and LanMan (as distinct from NTLMv2 or Kerberos authentication) will be removed in a future Samba release.
That is, in the future, the current default of client NTLMv2 auth = yes will be the enforced behaviour.
This parameter determines whether or not smbclient(8) will attempt to authenticate itself to servers using the NTLMv2 encrypted password response.
If enabled, only an NTLMv2 and LMv2 response (both much more secure than earlier versions) will be sent. Older servers (including NT4 < SP4, Win9x and Samba 2.2) are not compatible with NTLMv2 when not in an NTLMv2 supporting domain
Similarly, if enabled, NTLMv1, client lanman auth and client plaintext auth authentication will be disabled. This also disables share-level authentication.
If disabled, an NTLM response (and possibly a LANMAN response) will be sent by the client, depending on the value of client lanman auth.
Note that Windows Vista and later versions already use NTLMv2 by default, and some sites (particularly those following best practice security polices) only allow NTLMv2 responses, and not the weaker LM or NTLM.
When client use spnego is also set to yes extended security (SPNEGO) is required in order to use NTLMv2 only within NTLMSSP. This behavior was introduced with the patches for CVE-2016-2111.
Default: client NTLMv2 auth = yes

client plaintext auth (G)

This parameter has been deprecated since Samba 4.13 and support for plaintext (as distinct from NTLM, NTLMv2 or Kerberos authentication) will be removed in a future Samba release.
That is, in the future, the current default of client plaintext auth = no will be the enforced behaviour.
Specifies whether a client should send a plaintext password if the server does not support encrypted passwords.
Default: client plaintext auth = no

client protection (G)

This parameter defines which protection Samba client tools should use by default.
Possible client settings are:
·
default - Use the individual default values of the options:
·
client signing
·
client smb encrypt
·
plain - This will send everything just as plaintext, signing or encryption are turned off.
·
sign - This will enable integrity checking.
·
encrypt - This will enable integrity checks and force encryption for privacy.
Default: client protection = default

client schannel (G)

This option is deprecated with Samba 4.8 and will be removed in future. At the same time the default changed to yes, which will be the hardcoded behavior in future.
This controls whether the client offers or even demands the use of the netlogon schannel. client schannel = no does not offer the schannel, client schannel = auto offers the schannel but does not enforce it, and client schannel = yes denies access if the server is not able to speak netlogon schannel.
Note that for active directory domains this is hardcoded to client schannel = yes.
This option is over-ridden by the require strong key option.
Default: client schannel = yes
Example: client schannel = auto

client signing (G)

This controls whether the client is allowed or required to use SMB signing. Possible values are desired, required and disabled.
When set to desired or default, SMB signing is offered, but not enforced.
When set to required, SMB signing is mandatory and if set to disabled, SMB signing is not offered either.
IPC$ connections for DCERPC e.g. in winbindd, are handled by the client ipc signing option.
Default: client signing = default

client smb encrypt (G)

This parameter controls whether a client should try or is required to use SMB encryption. It has different effects depending on whether the connection uses SMB1 or SMB3:
·
If the connection uses SMB1, then this option controls the use of a Samba-specific extension to the SMB protocol introduced in Samba 3.2 that makes use of the Unix extensions.
·
If the connection uses SMB2 or newer, then this option controls the use of the SMB-level encryption that is supported in SMB version 3.0 and above and available in Windows 8 and newer.
This parameter can be set globally. Possible values are off, if_required, desired, and required. A special value is default which is the implicit default setting of if_required.
Effects for SMB1
The Samba-specific encryption of SMB1 connections is an extension to the SMB protocol negotiated as part of the UNIX extensions. SMB encryption uses the GSSAPI (SSPI on Windows) ability to encrypt and sign every request/response in a SMB protocol stream. When enabled it provides a secure method of SMB/CIFS communication, similar to an ssh protected session, but using SMB/CIFS authentication to negotiate encryption and signing keys. Currently this is only supported smbclient of by Samba 3.2 and newer. Windows does not support this feature.
When set to default, SMB encryption is probed, but not enforced. When set to required, SMB encryption is required and if set to disabled, SMB encryption can not be negotiated.
Effects for SMB3 and newer
Native SMB transport encryption is available in SMB version 3.0 or newer. It is only used by Samba if client max protocol is set to SMB3 or newer.
These features can be controlled with settings of client smb encrypt as follows:
·
Leaving it as default, explicitly setting default, or setting it to if_required globally will enable negotiation of encryption but will not turn on data encryption globally.
·
Setting it to desired globally will enable negotiation and will turn on data encryption on sessions and share connections for those servers that support it.
·
Setting it to required globally will enable negotiation and turn on data encryption on sessions and share connections. Clients that do not support encryption will be denied access to the server.
·
Setting it to off globally will completely disable the encryption feature for all connections.
Default: client smb encrypt = default

client smb3 encryption algorithms (G)

This parameter specifies the availability and order of encryption algorithms which are available for negotiation in the SMB3_11 dialect.
It is also possible to remove individual algorithms from the default list, by prefixing them with -. This can avoid having to specify a hardcoded list.
Note: that the removal of AES-128-CCM from the list will result in SMB3_00 and SMB3_02 being unavailable, as it is the default and only available algorithm for these dialects.
Default: client smb3 encryption algorithms = AES-128-GCM, AES-128-CCM, AES-256-GCM, AES-256-CCM
Example: client smb3 encryption algorithms = AES-256-GCM
Example: client smb3 encryption algorithms = -AES-128-GCM -AES-128-CCM

client smb3 signing algorithms (G)

This parameter specifies the availability and order of signing algorithms which are available for negotiation in the SMB3_11 dialect.
It is also possible to remove individual algorithms from the default list, by prefixing them with -. This can avoid having to specify a hardcoded list.
Note: that the removal of AES-128-CMAC from the list will result in SMB3_00 and SMB3_02 being unavailable, and the removal of HMAC-SHA256 will result in SMB2_02 and SMB2_10 being unavailable, as these are the default and only available algorithms for these dialects.
Default: client smb3 signing algorithms = AES-128-GMAC, AES-128-CMAC, HMAC-SHA256
Example: client smb3 signing algorithms = AES-128-CMAC, HMAC-SHA256
Example: client smb3 signing algorithms = -AES-128-CMAC

client use kerberos (G)

This parameter determines whether Samba client tools will try to authenticate using Kerberos. For Kerberos authentication you need to use dns names instead of IP addresses when connecting to a service.
Possible option settings are:
·
desired - Kerberos authentication will be tried first and if it fails it automatically fallback to NTLM.
·
required - Kerberos authentication will be required. There will be no fallback to NTLM or a different alternative.
·
off - Dont use Kerberos, use NTLM instead or another alternative.
In case that weak cryptography is not allowed (e.g. FIPS mode) the default will be forced to required.
Default: client use kerberos = desired

client use spnego principal (G)

This parameter determines whether or not smbclient(8) and other samba components acting as a client will attempt to use the server-supplied principal sometimes given in the SPNEGO exchange.
If enabled, Samba can attempt to use Kerberos to contact servers known only by IP address. Kerberos relies on names, so ordinarily cannot function in this situation.
This is a VERY BAD IDEA for security reasons, and so this parameter SHOULD NOT BE USED. It will be removed in a future version of Samba.
If disabled, Samba will use the name used to look up the server when asking the KDC for a ticket. This avoids situations where a server may impersonate another, soliciting authentication as one principal while being known on the network as another.
Note that Windows XP SP2 and later versions already follow this behaviour, and Windows Vista and later servers no longer supply this rfc4178 hint principal on the server side.
This parameter is deprecated in Samba 4.2.1 and will be removed (along with the functionality) in a later release of Samba.
Default: client use spnego principal = no

client use spnego (G)

This parameter has been deprecated since Samba 4.13 and support for NTLMv2, NTLM and LanMan authentication outside NTLMSSP will be removed in a future Samba release.
That is, in the future, the current default of client use spnego = yes will be the enforced behaviour.
This variable controls whether Samba clients will try to use Simple and Protected NEGOtiation (as specified by rfc2478) with supporting servers (including WindowsXP, Windows2000 and Samba 3.0) to agree upon an authentication mechanism. This enables Kerberos authentication in particular.
When client NTLMv2 auth is also set to yes extended security (SPNEGO) is required in order to use NTLMv2 only within NTLMSSP. This behavior was introduced with the patches for CVE-2016-2111.
Default: client use spnego = yes

cluster addresses (G)

With this parameter you can add additional addresses that nmbd will register with a WINS server. Similarly, these addresses will be registered by default when net ads dns register is called with clustering = yes configured.
Default: cluster addresses =
Example: cluster addresses = 10.0.0.1 10.0.0.2 10.0.0.3

clustering (G)

This parameter specifies whether Samba should contact ctdb for accessing its tdb files and use ctdb as a backend for its messaging backend.
Set this parameter to yes only if you have a cluster setup with ctdb running.
Default: clustering = no

comment (S)

This is a text field that is seen next to a share when a client does a queries the server, either via the network neighborhood or via net view to list what shares are available.
If you want to set the string that is displayed next to the machine name then see the server string parameter.
Default: comment = # No comment
Example: comment = Freds Files

config backend (G)

This controls the backend for storing the configuration. Possible values are file (the default) and registry. When config backend = registry is encountered while loading smb.conf, the configuration read so far is dropped and the global options are read from registry instead. So this triggers a registry only configuration. Share definitions are not read immediately but instead registry shares is set to yes.
Note: This option can not be set inside the registry configuration itself.
Default: config backend = file
Example: config backend = registry

config file (G)

This allows you to override the config file to use, instead of the default (usually smb.conf). There is a chicken and egg problem here as this option is set in the config file!
For this reason, if the name of the config file has changed when the parameters are loaded then it will reload them from the new config file.
This option takes the usual substitutions, which can be very useful.
If the config file doesnt exist then it wont be loaded (allowing you to special case the config files of just a few clients).
No default
Example: config file = /usr/local/samba/lib/smb.conf.%m

copy (S)

This parameter allows you to “clone” service entries. The specified service is simply duplicated under the current services name. Any parameters specified in the current section will override those in the section being copied.
This feature lets you set up a template service and create similar services easily. Note that the service being copied must occur earlier in the configuration file than the service doing the copying.
Default: copy =
Example: copy = otherservice

create krb5 conf (G)

Setting this parameter to no prevents winbind from creating custom krb5.conf files. Winbind normally does this because the krb5 libraries are not AD-site-aware and thus would pick any domain controller out of potentially very many. Winbind is site-aware and makes the krb5 libraries use a local DC by creating its own krb5.conf files.
Preventing winbind from doing this might become necessary if you have to add special options into your system-krb5.conf that winbind does not see.
Default: create krb5 conf = yes

create mode

This parameter is a synonym for create mask.

create mask (S)

When a file is created, the necessary permissions are calculated according to the mapping from DOS modes to UNIX permissions, and the resulting UNIX mode is then bit-wise ANDed with this parameter. This parameter may be thought of as a bit-wise MASK for the UNIX modes of a file. Any bit not set here will be removed from the modes set on a file when it is created.
The default value of this parameter removes the group and other write and execute bits from the UNIX modes.
Following this Samba will bit-wise OR the UNIX mode created from this parameter with the value of the force create mode parameter which is set to 000 by default.
This parameter does not affect directory masks. See the parameter directory mask for details.
Default: create mask = 0744
Example: create mask = 0775

csc policy (S)

This stands for client-side caching policy, and specifies how clients capable of offline caching will cache the files in the share. The valid values are: manual, documents, programs, disable.
These values correspond to those used on Windows servers.
For example, shares containing roaming profiles can have offline caching disabled using csc policy = disable.
Default: csc policy = manual
Example: csc policy = programs

ctdbd socket (G)

If you set clustering=yes, you need to tell Samba where ctdbd listens on its unix domain socket. The default path as of ctdb 1.0 is /tmp/ctdb.socket which you have to explicitly set for Samba in smb.conf.
Default: ctdbd socket =
Example: ctdbd socket = /tmp/ctdb.socket

ctdb locktime warn threshold (G)

In a cluster environment using Samba and ctdb it is critical that locks on central ctdb-hosted databases like locking.tdb are not held for long. With the current Samba architecture it happens that Samba takes a lock and while holding that lock makes file system calls into the shared cluster file system. This option makes Samba warn if it detects that it has held locks for the specified number of milliseconds. If this happens, smbd will emit a debug level 0 message into its logs and potentially into syslog. The most likely reason for such a log message is that an operation of the cluster file system Samba exports is taking longer than expected. The messages are meant as a debugging aid for potential cluster problems.
The default value of 0 disables this logging.
Default: ctdb locktime warn threshold = 0

ctdb timeout (G)

This parameter specifies a timeout in milliseconds for the connection between Samba and ctdb. It is only valid if you have compiled Samba with clustering and if you have set clustering=yes.
When something in the cluster blocks, it can happen that we wait indefinitely long for ctdb, just adding to the blocking condition. In a well-running cluster this should never happen, but there are too many components in a cluster that might have hickups. Choosing the right balance for this value is very tricky, because on a busy cluster long service times to transfer something across the cluster might be valid. Setting it too short will degrade the service your cluster presents, setting it too long might make the cluster itself not recover from something severely broken for too long.
Be aware that if you set this parameter, this needs to be in the file smb.conf, it is not really helpful to put this into a registry configuration (typical on a cluster), because to access the registry contact to ctdb is required.
Setting ctdb timeout to n makes any process waiting longer than n milliseconds for a reply by the cluster panic. Setting it to 0 (the default) makes Samba block forever, which is the highly recommended default.
Default: ctdb timeout = 0

cups connection timeout (G)

This parameter is only applicable if printing is set to cups.
If set, this option specifies the number of seconds that smbd will wait whilst trying to contact to the CUPS server. The connection will fail if it takes longer than this number of seconds.
Default: cups connection timeout = 30
Example: cups connection timeout = 60

cups encrypt (G)

This parameter is only applicable if printing is set to cups and if you use CUPS newer than 1.0.x.It is used to define whether or not Samba should use encryption when talking to the CUPS server. Possible values are auto, yes and no
When set to auto we will try to do a TLS handshake on each CUPS connection setup. If that fails, we will fall back to unencrypted operation.
Default: cups encrypt = no

cups options (S)

This parameter is only applicable if printing is set to cups. Its value is a free form string of options passed directly to the cups library.
You can pass any generic print option known to CUPS (as listed in the CUPS “Software Users Manual”). You can also pass any printer specific option (as listed in “lpoptions -d printername -l”) valid for the target queue. Multiple parameters should be space-delimited name/value pairs according to the PAPI text option ABNF specification. Collection values (“name={a=… b=… c=…}”) are stored with the curley brackets intact.
You should set this parameter to raw if your CUPS server error_log file contains messages such as “Unsupported format application/octet-stream” when printing from a Windows client through Samba. It is no longer necessary to enable system wide raw printing in /etc/cups/mime.{convs,types}.
Default: cups options = ""
Example: cups options = “raw media=a4”

cups server (G)

This parameter is only applicable if printing is set to cups.
If set, this option overrides the ServerName option in the CUPS client.conf. This is necessary if you have virtual samba servers that connect to different CUPS daemons.
Optionally, a port can be specified by separating the server name and port number with a colon. If no port was specified, the default port for IPP (631) will be used.
Default: cups server = ""
Example: cups server = mycupsserver
Example: cups server = mycupsserver:1631

dcerpc endpoint servers (G)

Specifies which DCE/RPC endpoint servers should be run.
Default: dcerpc endpoint servers = epmapper, wkssvc, samr, netlogon, lsarpc, drsuapi, dssetup, unixinfo, browser, eventlog6, backupkey, dnsserver
Example: dcerpc endpoint servers = rpcecho

deadtime (G)

The value of the parameter (a decimal integer) represents the number of minutes of inactivity before a connection is considered dead, and it is disconnected. The deadtime only takes effect if the number of open files is zero.
This is useful to stop a servers resources being exhausted by a large number of inactive connections.
Most clients have an auto-reconnect feature when a connection is broken so in most cases this parameter should be transparent to users.
Using this parameter with a timeout of a few minutes is recommended for most systems.
A deadtime of zero indicates that no auto-disconnection should be performed.
Default: deadtime = 10080
Example: deadtime = 15

debug class (G)

With this boolean parameter enabled, the debug class (DBGC_CLASS) will be displayed in the debug header.
For more information about currently available debug classes, see section about log level.
Default: debug class = no

debug encryption (G)

This option will make the smbd server and client code using libsmb (smbclient, smbget, smbspool, …) dump the Session Id, the decrypted Session Key, the Signing Key, the Application Key, the Encryption Key and the Decryption Key every time an SMB3+ session is established. This information will be printed in logs at level 0.
Warning: access to these values enables the decryption of any encrypted traffic on the dumped sessions. This option should only be enabled for debugging purposes.
Default: debug encryption = no

debug hires timestamp (G)

Sometimes the timestamps in the log messages are needed with a resolution of higher that seconds, this boolean parameter adds microsecond resolution to the timestamp message header when turned on.
Note that the parameter debug timestamp or debug syslog format must be on for this to have an effect.
Default: debug hires timestamp = yes

debug pid (G)

When using only one log file for more then one forked smbd(8)-process there may be hard to follow which process outputs which message. This boolean parameter is adds the process-id to the timestamp message headers in the logfile when turned on.
Note that the parameter debug timestamp must be on for this to have an effect.
Default: debug pid = no

debug prefix timestamp (G)

With this option enabled, the timestamp message header is prefixed to the debug message without the filename and function information that is included with the debug timestamp parameter. This gives timestamps to the messages without adding an additional line.
Note that this parameter overrides the debug timestamp parameter.
Default: debug prefix timestamp = no

debug syslog format (G)

With this option enabled (yes (alias in_logs) or always), debug messages are printed in a single-line format like that traditionally produced by syslog. The timestamp consists of an abbreviated month, space-padded date, and time including seconds. This is followed by the hostname and the program name, with the process-ID in square brackets.
The value always produces this log format even to STDOUT or STDERR
The value no defers to other parameters and typically produces traditional two-line Samba logs to log files.
If debug hires timestamp is also enabled then an RFC5424 timestamp is used instead.
Default: debug syslog format = no

winbind debug traceid (G)

With this boolean parameter enabled, the per request unique traceid will be displayed in the debug header for winbind processes.
Default: winbind debug traceid = no

debug uid (G)

Samba is sometimes run as root and sometime run as the connected user, this boolean parameter inserts the current euid, egid, uid and gid to the timestamp message headers in the log file if turned on.
Note that the parameter debug timestamp must be on for this to have an effect.
Default: debug uid = no

dedicated keytab file (G)

Specifies the absolute path to the kerberos keytab file when kerberos method is set to “dedicated keytab”.
Default: dedicated keytab file =
Example: dedicated keytab file = /usr/local/etc/krb5.keytab

default case (S)

See the section on name mangling. Also note the short preserve case parameter.
Default: default case = lower

default devmode (S)

This parameter is only applicable to printable services. When smbd is serving Printer Drivers to Windows NT/2k/XP clients, each printer on the Samba server has a Device Mode which defines things such as paper size and orientation and duplex settings. The device mode can only correctly be generated by the printer driver itself (which can only be executed on a Win32 platform). Because smbd is unable to execute the driver code to generate the device mode, the default behavior is to set this field to NULL.
Most problems with serving printer drivers to Windows NT/2k/XP clients can be traced to a problem with the generated device mode. Certain drivers will do things such as crashing the clients Explorer.exe with a NULL devmode. However, other printer drivers can cause the clients spooler service (spoolsv.exe) to die if the devmode was not created by the driver itself (i.e. smbd generates a default devmode).
This parameter should be used with care and tested with the printer driver in question. It is better to leave the device mode to NULL and let the Windows client set the correct values. Because drivers do not do this all the time, setting default devmode = yes will instruct smbd to generate a default one.
For more information on Windows NT/2k printing and Device Modes, see the MSDN documentation.
Default: default devmode = yes

default

This parameter is a synonym for default service.

default service (G)

This parameter specifies the name of a service which will be connected to if the service actually requested cannot be found. Note that the square brackets are NOT given in the parameter value (see example below).
There is no default value for this parameter. If this parameter is not given, attempting to connect to a nonexistent service results in an error.
Typically the default service would be a guest ok, read only service.
Also note that the apparent service name will be changed to equal that of the requested service, this is very useful as it allows you to use macros like %S to make a wildcard service.
Note also that any “_” characters in the name of the service used in the default service will get mapped to a “/”. This allows for interesting things.
Default: default service =
Example: default service = pub

defer sharing violations (G)

Windows allows specifying how a file will be shared with other processes when it is opened. Sharing violations occur when a file is opened by a different process using options that violate the share settings specified by other processes. This parameter causes smbd to act as a Windows server does, and defer returning a “sharing violation” error message for up to one second, allowing the client to close the file causing the violation in the meantime.
UNIX by default does not have this behaviour.
There should be no reason to turn off this parameter, as it is designed to enable Samba to more correctly emulate Windows.
Default: defer sharing violations = yes

delete group script (G)

This is the full pathname to a script that will be run AS ROOT by smbd(8) when a group is requested to be deleted. It will expand any %g to the group name passed. This script is only useful for installations using the Windows NT domain administration tools.
Default: delete group script =

deleteprinter command (G)

With the introduction of MS-RPC based printer support for Windows NT/2000 clients in Samba 2.2, it is now possible to delete a printer at run time by issuing the DeletePrinter() RPC call.
For a Samba host this means that the printer must be physically deleted from the underlying printing system. The deleteprinter command defines a script to be run which will perform the necessary operations for removing the printer from the print system and from smb.conf.
The deleteprinter command is automatically called with only one parameter: printer name.
Once the deleteprinter command has been executed, smbd will reparse the smb.conf to check that the associated printer no longer exists. If the sharename is still valid, then smbd will return an ACCESS_DENIED error to the client.
Default: deleteprinter command =
Example: deleteprinter command = /usr/bin/removeprinter

delete readonly (S)

This parameter allows readonly files to be deleted. This is not normal DOS semantics, but is allowed by UNIX.
This option may be useful for running applications such as rcs, where UNIX file ownership prevents changing file permissions, and DOS semantics prevent deletion of a read only file.
Default: delete readonly = no

delete share command (G)

Samba 2.2.0 introduced the ability to dynamically add and delete shares via the Windows NT 4.0 Server Manager. The delete share command is used to define an external program or script which will remove an existing service definition from smb.conf.
In order to successfully execute the delete share command, smbd requires that the administrator connects using a root account (i.e. uid == 0) or has the SeDiskOperatorPrivilege. Scripts defined in the delete share command parameter are executed as root.
When executed, smbd will automatically invoke the delete share command with two parameters.
·
configFile - the location of the global smb.conf file.
·
shareName - the name of the existing service.
This parameter is only used to remove file shares. To delete printer shares, see the deleteprinter command.
Default: delete share command =
Example: delete share command = /usr/local/bin/delshare

delete user from group script (G)

Full path to the script that will be called when a user is removed from a group using the Windows NT domain administration tools. It will be run by smbd(8) AS ROOT. Any %g will be replaced with the group name and any %u will be replaced with the user name.
Default: delete user from group script =
Example: delete user from group script = /usr/sbin/deluser %u %g

delete user script (G)

This is the full pathname to a script that will be run by smbd(8) when managing users with remote RPC (NT) tools.
This script is called when a remote client removes a user from the server, normally using User Manager for Domains or rpcclient.
This script should delete the given UNIX username.
Default: delete user script =
Example: delete user script = /usr/local/samba/bin/del_user %u

delete veto files (S)

This option is used when Samba is attempting to delete a directory that contains one or more vetoed files or directories or non-visible files or directories (such as dangling symlinks that point nowhere). (see the veto files, hide special files, hide unreadable, hide unwriteable files options). If this option is set to no (the default) then if a vetoed directory contains any non-vetoed files or directories then the directory delete will fail. This is usually what you want.
If this option is set to yes, then Samba will attempt to recursively delete any files and directories within the vetoed directory. This can be useful for integration with file serving systems such as NetAtalk which create meta-files within directories you might normally veto DOS/Windows users from seeing (e.g. .AppleDouble)
Setting delete veto files = yes allows these directories to be transparently deleted when the parent directory is deleted (so long as the user has permissions to do so).
Default: delete veto files = no

dfree cache time (S)

The dfree cache time should only be used on systems where a problem occurs with the internal disk space calculations. This has been known to happen with Ultrix, but may occur with other operating systems. The symptom that was seen was an error of “Abort Retry Ignore” at the end of each directory listing.
This is a new parameter introduced in Samba version 3.0.21. It specifies in seconds the time that smbd will cache the output of a disk free query. If set to zero (the default) no caching is done. This allows a heavily loaded server to prevent rapid spawning of dfree command scripts increasing the load.
By default this parameter is zero, meaning no caching will be done.
No default
Example: dfree cache time = 60

dfree command (S)

The dfree command setting should only be used on systems where a problem occurs with the internal disk space calculations. This has been known to happen with Ultrix, but may occur with other operating systems. The symptom that was seen was an error of “Abort Retry Ignore” at the end of each directory listing.
This setting allows the replacement of the internal routines to calculate the total disk space and amount available with an external routine. The example below gives a possible script that might fulfill this function.
In Samba version 3.0.21 this parameter has been changed to be a per-share parameter, and in addition the parameter dfree cache time was added to allow the output of this script to be cached for systems under heavy load.
The external program will be passed a single parameter indicating a directory in the filesystem being queried. This will typically consist of the string ./. The script should return two integers in ASCII. The first should be the total disk space in blocks, and the second should be the number of available blocks. An optional third return value can give the block size in bytes. The default blocksize is 1024 bytes.
Note: Your script should NOT be setuid or setgid and should be owned by (and writeable only by) root!
Where the script dfree (which must be made executable) could be:
#!/bin/sh
df "$1" | tail -1 | awk {print $(NF-4),$(NF-2)}
or perhaps (on Sys V based systems):
#!/bin/sh
/usr/bin/df -k "$1" | tail -1 | awk {print $3" "$5}
Note that you may have to replace the command names with full path names on some systems. Also note the arguments passed into the script should be quoted inside the script in case they contain special characters such as spaces or newlines.
By default internal routines for determining the disk capacity and remaining space will be used.
No default
Example: dfree command = /usr/local/samba/bin/dfree

dgram port (G)

Specifies which ports the server should listen on for NetBIOS datagram traffic.
Default: dgram port = 138

directory mode

This parameter is a synonym for directory mask.

directory mask (S)

This parameter is the octal modes which are used when converting DOS modes to UNIX modes when creating UNIX directories.
When a directory is created, the necessary permissions are calculated according to the mapping from DOS modes to UNIX permissions, and the resulting UNIX mode is then bit-wise ANDed with this parameter. This parameter may be thought of as a bit-wise MASK for the UNIX modes of a directory. Any bit not set here will be removed from the modes set on a directory when it is created.
The default value of this parameter removes the group and other write bits from the UNIX mode, allowing only the user who owns the directory to modify it.
Following this Samba will bit-wise OR the UNIX mode created from this parameter with the value of the force directory mode parameter. This parameter is set to 000 by default (i.e. no extra mode bits are added).
Default: directory mask = 0755
Example: directory mask = 0775

directory security mask (S)

This parameter has been removed for Samba 4.0.0.
No default

disable netbios (G)

Enabling this parameter will disable netbios support in Samba. Netbios is the only available form of browsing in Windows versions prior to Windows 2000.
Note
Clients that only support netbios wont be able to see your samba server when netbios support is disabled.
Default: disable netbios = no

disable spoolss (G)

Enabling this parameter will disable Sambas support for the SPOOLSS set of MS-RPCs and will yield identical behavior as Samba 2.0.x. Windows NT/2000 clients will downgrade to using Lanman style printing commands. Windows 9x/ME will be unaffected by the parameter. However, this will also disable the ability to upload printer drivers to a Samba server via the Windows NT Add Printer Wizard or by using the NT printer properties dialog window. It will also disable the capability of Windows NT/2000 clients to download print drivers from the Samba host upon demand. Be very careful about enabling this parameter.
Default: disable spoolss = no

dmapi support (S)

This parameter specifies whether Samba should use DMAPI to determine whether a file is offline or not. This would typically be used in conjunction with a hierarchical storage system that automatically migrates files to tape.
Note that Samba infers the status of a file by examining the events that a DMAPI application has registered interest in. This heuristic is satisfactory for a number of hierarchical storage systems, but there may be system for which it will fail. In this case, Samba may erroneously report files to be offline.
This parameter is only available if a supported DMAPI implementation was found at compilation time. It will only be used if DMAPI is found to enabled on the system at run time.
Default: dmapi support = no

dns forwarder (G)

This option specifies the list of DNS servers that DNS requests will be forwarded to if they can not be handled by Samba itself.
The DNS forwarder is only used if the internal DNS server in Samba is used. Port numbers can be appended by separating them from the address by using a colon (:). When specifying a port, IPv6 addresses must be enclosed in square brackets ([ and ]). IPv6 forwarder addresses with no port specified, dont need the square brackets, and default to port 53.
Default: dns forwarder =
Example: dns forwarder = 192.168.0.1 192.168.0.2 ::1 [2001:db8::1] [2001:db8:1:2::1]:54

dns port (G)

Specifies which ports the server should listen on for DNS traffic.
It makes possible to use another DNS server as a front and forward to Samba.
Warning
Dynamic DNS updates may not be proxied by the front DNS server when forwarding to Samba. Dynamic DNS update proxying depends on the features of the other DNS server used as a front.
Default: dns port = 53

dns proxy (G)

Specifies that nmbd(8) when acting as a WINS server and finding that a NetBIOS name has not been registered, should treat the NetBIOS name word-for-word as a DNS name and do a lookup with the DNS server for that name on behalf of the name-querying client.
Note that the maximum length for a NetBIOS name is 15 characters, so the DNS name (or DNS alias) can likewise only be 15 characters, maximum.
nmbd spawns a second copy of itself to do the DNS name lookup requests, as doing a name lookup is a blocking action.
Default: dns proxy = yes

dns update command (G)

This option sets the command that is called when there are DNS updates. It should update the local machines DNS names using TSIG-GSS.
Default: dns update command = /usr/sbin/samba_dnsupdate
Example: dns update command = /usr/local/sbin/dnsupdate

dns zone scavenging (G)

When enabled (the default is disabled) unused dynamic dns records are periodically removed.
Warning
This option should not be enabled for installations created with versions of samba before 4.9. Doing this will result in the loss of static DNS entries. This is due to a bug in previous versions of samba (BUG 12451) which marked dynamic DNS records as static and static records as dynamic.
Note
If one record for a DNS name is static (non-aging) then no other record for that DNS name will be scavenged.
Default: dns zone scavenging = no

dns zone transfer clients allow (G)

This option specifies the list of IPs authorized to ask for dns zone transfer from bind DLZ module.
The IP list is comma and space separated and specified in the same syntax as used in hosts allow, specifically including IP address, IP prefixes and IP address masks.
As this is a DNS server option, hostnames are naturally not permitted.
The default behaviour is to deny any request. A request will be authorized only if the emitting client is identified in this list, and not in dns zone transfer clients deny
Default: dns zone transfer clients allow =
Example: dns zone transfer clients allow = 192.168.0.1

dns zone transfer clients deny (G)

This option specifies the list of IPs denied to ask for dns zone transfer from bind DLZ module.
The IP list is comma and space separated and specified in the same syntax as used in hosts allow, specifically including IP address, IP prefixes and IP address masks.
As this is a DNS server option, hostnames are naturally not permitted.
If a client identified in this list sends a zone transfer request, it will always be denied, even if they are in dns zone transfer clients allow. This allows the definition of specific denied clients within an authorized subnet.
Default: dns zone transfer clients deny =
Example: dns zone transfer clients deny = 192.168.0.1

domain logons (G)

This parameter has been deprecated since Samba 4.13 and support for NT4-style domain logons(as distinct from the Samba AD DC) will be removed in a future Samba release.
That is, in the future, the current default of domain logons = no will be the enforced behaviour.
If set to yes, the Samba server will provide the netlogon service for Windows 9X network logons for the workgroup it is in. This will also cause the Samba server to act as a domain controller for NT4 style domain services. For more details on setting up this feature see the Domain Control chapter of the Samba HOWTO Collection.
Default: domain logons = no

domain master (G)

Tell smbd(8) to enable WAN-wide browse list collation. Setting this option causes nmbd to claim a special domain specific NetBIOS name that identifies it as a domain master browser for its given workgroup. Local master browsers in the same workgroup on broadcast-isolated subnets will give this nmbd their local browse lists, and then ask smbd(8) for a complete copy of the browse list for the whole wide area network. Browser clients will then contact their local master browser, and will receive the domain-wide browse list, instead of just the list for their broadcast-isolated subnet.
Note that Windows NT Primary Domain Controllers expect to be able to claim this workgroup specific special NetBIOS name that identifies them as domain master browsers for that workgroup by default (i.e. there is no way to prevent a Windows NT PDC from attempting to do this). This means that if this parameter is set and nmbd claims the special name for a workgroup before a Windows NT PDC is able to do so then cross subnet browsing will behave strangely and may fail.
If domain logons = yes, then the default behavior is to enable the domain master parameter. If domain logons is not enabled (the default setting), then neither will domain master be enabled by default.
When domain logons = Yes the default setting for this parameter is Yes, with the result that Samba will be a PDC. If domain master = No, Samba will function as a BDC. In general, this parameter should be set to No only on a BDC.
Default: domain master = auto

dont descend (S)

There are certain directories on some systems (e.g., the /proc tree under Linux) that are either not of interest to clients or are infinitely deep (recursive). This parameter allows you to specify a comma-delimited list of directories that the server should always show as empty.
Note that Samba can be very fussy about the exact format of the “dont descend” entries. For example you may need ./proc instead of just /proc. Experimentation is the best policy :-)
Default: dont descend =
Example: dont descend = /proc,/dev

dos charset (G)

DOS SMB clients assume the server has the same charset as they do. This option specifies which charset Samba should use to talk to DOS clients.
The default depends on which charsets you have installed. Samba tries to use charset 850 but falls back to ASCII in case it is not available. Run testparm(1) to check the default on your system.
No default

dos filemode (S)

The default behavior in Samba is to provide UNIX-like behavior where only the owner of a file/directory is able to change the permissions on it. However, this behavior is often confusing to DOS/Windows users. Enabling this parameter allows a user who has write access to the file (by whatever means, including an ACL permission) to modify the permissions (including ACL) on it. Note that a user belonging to the group owning the file will not be allowed to change permissions if the group is only granted read access. Ownership of the file/directory may also be changed. Note that using the VFS modules acl_xattr or acl_tdb which store native Windows as meta-data will automatically turn this option on for any share for which they are loaded, as they require this option to emulate Windows ACLs correctly.
Default: dos filemode = no

dos filetime resolution (S)

Under the DOS and Windows FAT filesystem, the finest granularity on time resolution is two seconds. Setting this parameter for a share causes Samba to round the reported time down to the nearest two second boundary when a query call that requires one second resolution is made to smbd(8).
This option is mainly used as a compatibility option for Visual C++ when used against Samba shares. If oplocks are enabled on a share, Visual C++ uses two different time reading calls to check if a file has changed since it was last read. One of these calls uses a one-second granularity, the other uses a two second granularity. As the two second call rounds any odd second down, then if the file has a timestamp of an odd number of seconds then the two timestamps will not match and Visual C++ will keep reporting the file has changed. Setting this option causes the two timestamps to match, and Visual C++ is happy.
Default: dos filetime resolution = no

dos filetimes (S)

Under DOS and Windows, if a user can write to a file they can change the timestamp on it. Under POSIX semantics, only the owner of the file or root may change the timestamp. By default, Samba emulates the DOS semantics and allows one to change the timestamp on a file if the user smbd is acting on behalf has write permissions. Due to changes in Microsoft Office 2000 and beyond, the default for this parameter has been changed from “no” to “yes” in Samba 3.0.14 and above. Microsoft Excel will display dialog box warnings about the file being changed by another user if this parameter is not set to “yes” and files are being shared between users.
Default: dos filetimes = yes

dsdb event notification (G)

When enabled, this option causes Samba (acting as an Active Directory Domain Controller) to stream Samba database events across the internal message bus. Scripts built using Sambas python bindings can listen to these events by registering as the service dsdb_event.
This is not needed for the audit logging described in log level.
Instead, this should instead be considered a developer option (it assists in the Samba testsuite) rather than a facility for external auditing, as message delivery is not guaranteed (a feature that the testsuite works around).
The Samba database events are also logged via the normal logging methods when the log level is set appropriately, say to dsdb_json_audit:5.
Default: dsdb event notification = no

dsdb group change notification (G)

When enabled, this option causes Samba (acting as an Active Directory Domain Controller) to stream group membership change events across the internal message bus. Scripts built using Sambas python bindings can listen to these events by registering as the service dsdb_group_event.
This is not needed for the audit logging described in log level.
Instead, this should instead be considered a developer option (it assists in the Samba testsuite) rather than a facility for external auditing, as message delivery is not guaranteed (a feature that the testsuite works around).
The Samba database events are also logged via the normal logging methods when the log level is set appropriately, say to dsdb_group_json_audit:5.
Default: dsdb group change notification = no

dsdb password event notification (G)

When enabled, this option causes Samba (acting as an Active Directory Domain Controller) to stream password change and reset events across the internal message bus. Scripts built using Sambas python bindings can listen to these events by registering as the service password_event.
This is not needed for the audit logging described in log level.
Instead, this should instead be considered a developer option (it assists in the Samba testsuite) rather than a facility for external auditing, as message delivery is not guaranteed (a feature that the testsuite works around).
The Samba database events are also logged via the normal logging methods when the log level is set appropriately, say to dsdb_password_json_audit:5.
Default: dsdb password event notification = no

durable handles (S)

This boolean parameter controls whether Samba can grant SMB2 durable file handles on a share.
Note that durable handles are only enabled if kernel oplocks = no, kernel share modes = no, and posix locking = no, i.e. if the share is configured for CIFS/SMB2 only access, not supporting interoperability features with local UNIX processes or NFS operations.
Also note that, for the time being, durability is not granted for a handle that has the delete on close flag set.
Default: durable handles = yes

ea support (S)

This boolean parameter controls whether smbd(8) will allow clients to attempt to access extended attributes on a share. In order to enable this parameter on a setup with default VFS modules:
·
Samba must have been built with extended attributes support.
·
The underlying filesystem exposed by the share must support extended attributes (e.g. the getfattr(1) / setfattr(1) utilities must work).
·
Access to extended user attributes must be allowed by the underlying filesystem (e.g. when mounted with a system-dependent option like user_xattr on Linux).
This option exposes the “user” attribute namespace from the underlying filesystem to clients. In order to match Windows conventions, the namespace prefix (“user.”) is stripped from the attribute name on the client side. The handling of further attribute namespaces (like “security”, “system”, or “trusted”) is not affected by this option.
Note that the SMB protocol allows setting attributes whose value is 64K bytes long, and that on NTFS, the maximum storage space for extended attributes per file is 64K. On some filesystem the limits may be lower. Filesystems with too limited EA space may experience unexpected weird effects. The default has changed to yes in Samba release 4.9.0 and above to allow better Windows fileserver compatibility in a default install.
Default: ea support = yes

elasticsearch:address (S)

Specifies the name of the Elasticsearch server to use for Spotlight queries when using the Elasticsearch backend.
Default: elasticsearch:address = localhost
Example: elasticsearch:address = needle.haystack.samba.org

elasticsearch:ignore unknown attribute (G)

Ignore unknown Spotlight attributes in search queries. An example query using the unsupported attribute “kMDItemTopic” would be kMDItemTopic==“hotstuff”. By default any query using such a type would completely fail. By enabling this option, if the type match is a subexpression of a larger expression, then this subexpression is just ignored.
Default: elasticsearch:ignore unknown attribute = no
Example: elasticsearch:ignore unknown attribute = yes

elasticsearch:ignore unknown type (G)

Ignore unknown Spotlight types in search queries. An example query using the unsupported type “public.calendar-event” would be kMDItemContentType==“public.calendar-event”. By default any query using such a type would completely fail. By enabling this option, if the type match is a subexpression of a larger expression, then this subexpression is just ignored.
Default: elasticsearch:ignore unknown type = no
Example: elasticsearch:ignore unknown type = yes

elasticsearch:index (S)

Specifies the name of the Elasticsearch index to use for Spotlight queries when using the Elasticsearch backend. The default value of “_all” is a special Elasticsearch value that performs the search operation on all indices.
Default: elasticsearch:index = _all
Example: elasticsearch:index = spotlight

elasticsearch:mappings (G)

Path to a file specifying metadata attribute mappings in JSON format. Use by the Elasticsearch backend of the Spotlight RPC service.
Default: elasticsearch:mappings = /usr/share/samba/elasticsearch_mappings.json
Example: elasticsearch:mappings = /usr/share/foo/mymappings.json

elasticsearch:max results (S)

Path to a file specifying metadata attribute mappings in JSON format. Used by the Elasticsearch backend of the Spotlight RPC service. A value of 0 means no limit.
Default: elasticsearch:max results = 100
Example: elasticsearch:max results = 10

elasticsearch:port (S)

Specifies the TCP port of the Elasticsearch server to use for Spotlight queries when using the Elasticsearch backend.
Default: elasticsearch:port = 9200
Example: elasticsearch:port = 9201

elasticsearch:use tls (S)

Specifies whether to use HTTPS when talking to the Elasticsearch server used for Spotlight queries when using the Elasticsearch backend.
Default: elasticsearch:use tls = no
Example: elasticsearch:use tls = yes

enable asu support (G)

Hosts running the “Advanced Server for Unix (ASU)” product require some special accommodations such as creating a builtin [ADMIN$] share that only supports IPC connections. The has been the default behavior in smbd for many years. However, certain Microsoft applications such as the Print Migrator tool require that the remote server support an [ADMIN$] file share. Disabling this parameter allows for creating an [ADMIN$] file share in smb.conf.
Default: enable asu support = no

enable core files (G)

This parameter specifies whether core dumps should be written on internal exits. Normally set to yes. You should never need to change this.
Default: enable core files = yes
Example: enable core files = no

enable privileges (G)

This deprecated parameter controls whether or not smbd will honor privileges assigned to specific SIDs via either net rpc rights or one of the Windows user and group manager tools. This parameter is enabled by default. It can be disabled to prevent members of the Domain Admins group from being able to assign privileges to users or groups which can then result in certain smbd operations running as root that would normally run under the context of the connected user.
An example of how privileges can be used is to assign the right to join clients to a Samba controlled domain without providing root access to the server via smbd.
Please read the extended description provided in the Samba HOWTO documentation.
Default: enable privileges = yes

enable spoolss (G)

Inverted synonym for disable spoolss.
Default: enable spoolss = yes

encrypt passwords (G)

This parameter has been deprecated since Samba 4.11 and support for plaintext (as distinct from NTLM, NTLMv2 or Kerberos authentication) will be removed in a future Samba release.
That is, in the future, the current default of encrypt passwords = yes will be the enforced behaviour.
This boolean controls whether encrypted passwords will be negotiated with the client. Note that Windows NT 4.0 SP3 and above and also Windows 98 will by default expect encrypted passwords unless a registry entry is changed. To use encrypted passwords in Samba see the chapter “User Database” in the Samba HOWTO Collection.
MS Windows clients that expect Microsoft encrypted passwords and that do not have plain text password support enabled will be able to connect only to a Samba server that has encrypted password support enabled and for which the user accounts have a valid encrypted password. Refer to the smbpasswd command man page for information regarding the creation of encrypted passwords for user accounts.
The use of plain text passwords is NOT advised as support for this feature is no longer maintained in Microsoft Windows products. If you want to use plain text passwords you must set this parameter to no.
In order for encrypted passwords to work correctly smbd(8) must either have access to a local smbpasswd(5) file (see the smbpasswd(8) program for information on how to set up and maintain this file), or set the security = [domain|ads] parameter which causes smbd to authenticate against another server.
Default: encrypt passwords = yes

enhanced browsing (G)

This option enables a couple of enhancements to cross-subnet browse propagation that have been added in Samba but which are not standard in Microsoft implementations.
The first enhancement to browse propagation consists of a regular wildcard query to a Samba WINS server for all Domain Master Browsers, followed by a browse synchronization with each of the returned DMBs. The second enhancement consists of a regular randomised browse synchronization with all currently known DMBs.
You may wish to disable this option if you have a problem with empty workgroups not disappearing from browse lists. Due to the restrictions of the browse protocols, these enhancements can cause a empty workgroup to stay around forever which can be annoying.
In general you should leave this option enabled as it makes cross-subnet browse propagation much more reliable.
Default: enhanced browsing = yes

enumports command (G)

The concept of a “port” is fairly foreign to UNIX hosts. Under Windows NT/2000 print servers, a port is associated with a port monitor and generally takes the form of a local port (i.e. LPT1:, COM1:, FILE:) or a remote port (i.e. LPD Port Monitor, etc…). By default, Samba has only one port defined–“Samba Printer Port”. Under Windows NT/2000, all printers must have a valid port name. If you wish to have a list of ports displayed (smbd does not use a port name for anything) other than the default “Samba Printer Port”, you can define enumports command to point to a program which should generate a list of ports, one per line, to standard output. This listing will then be used in response to the level 1 and 2 EnumPorts() RPC.
Default: enumports command =
Example: enumports command = /usr/bin/listports

eventlog list (G)

This option defines a list of log names that Samba will report to the Microsoft EventViewer utility. The listed eventlogs will be associated with tdb file on disk in the $(statedir)/eventlog.
The administrator must use an external process to parse the normal Unix logs such as /var/log/messages and write then entries to the eventlog tdb files. Refer to the eventlogadm(8) utility for how to write eventlog entries.
Default: eventlog list =
Example: eventlog list = Security Application Syslog Apache

fake directory create times (S)

NTFS and Windows VFAT file systems keep a create time for all files and directories. This is not the same as the ctime - status change time - that Unix keeps, so Samba by default reports the earliest of the various times Unix does keep. Setting this parameter for a share causes Samba to always report midnight 1-1-1980 as the create time for directories.
This option is mainly used as a compatibility option for Visual C++ when used against Samba shares. Visual C++ generated makefiles have the object directory as a dependency for each object file, and a make rule to create the directory. Also, when NMAKE compares timestamps it uses the creation time when examining a directory. Thus the object directory will be created if it does not exist, but once it does exist it will always have an earlier timestamp than the object files it contains.
However, Unix time semantics mean that the create time reported by Samba will be updated whenever a file is created or deleted in the directory. NMAKE finds all object files in the object directory. The timestamp of the last one built is then compared to the timestamp of the object directory. If the directorys timestamp if newer, then all object files will be rebuilt. Enabling this option ensures directories always predate their contents and an NMAKE build will proceed as expected.
Default: fake directory create times = no

fake oplocks (S)

Oplocks are the way that SMB clients get permission from a server to locally cache file operations. If a server grants an oplock (opportunistic lock) then the client is free to assume that it is the only one accessing the file and it will aggressively cache file data. With some oplock types the client may even cache file open/close operations. This can give enormous performance benefits.
When you set fake oplocks = yes, smbd(8) will always grant oplock requests no matter how many clients are using the file.
It is generally much better to use the real oplocks support rather than this parameter.
If you enable this option on all read-only shares or shares that you know will only be accessed from one client at a time such as physically read-only media like CDROMs, you will see a big performance improvement on many operations. If you enable this option on shares where multiple clients may be accessing the files read-write at the same time you can get data corruption. Use this option carefully!
Default: fake oplocks = no

follow symlinks (S)

This parameter allows the Samba administrator to stop smbd(8) from following symbolic links in a particular share. Setting this parameter to no prevents any file or directory that is a symbolic link from being followed (the user will get an error). This option is very useful to stop users from adding a symbolic link to /etc/passwd in their home directory for instance. However it will slow filename lookups down slightly.
This option is enabled (i.e. smbd will follow symbolic links) by default.
Default: follow symlinks = yes

smbd force process locks (S)

This boolean option tells smbd whether to forcefully disable the use of Open File Description locks on Linux.
This option should not be changed from the default unless you know what youre doing.
Default: smbd force process locks = no

force create mode (S)

This parameter specifies a set of UNIX mode bit permissions that will always be set on a file created by Samba. This is done by bitwise ORing these bits onto the mode bits of a file that is being created. The default for this parameter is (in octal) 000. The modes in this parameter are bitwise ORed onto the file mode after the mask set in the create mask parameter is applied.
The example below would force all newly created files to have read and execute permissions set for group and other as well as the read/write/execute bits set for the user.
Default: force create mode = 0000
Example: force create mode = 0755

force directory mode (S)

This parameter specifies a set of UNIX mode bit permissions that will always be set on a directory created by Samba. This is done by bitwise ORing these bits onto the mode bits of a directory that is being created. The default for this parameter is (in octal) 0000 which will not add any extra permission bits to a created directory. This operation is done after the mode mask in the parameter directory mask is applied.
The example below would force all created directories to have read and execute permissions set for group and other as well as the read/write/execute bits set for the user.
Default: force directory mode = 0000
Example: force directory mode = 0755

force directory security mode (S)

This parameter has been removed for Samba 4.0.0.
No default

group

This parameter is a synonym for force group.

force group (S)

This specifies a UNIX group name that will be assigned as the default primary group for all users connecting to this service. This is useful for sharing files by ensuring that all access to files on service will use the named group for their permissions checking. Thus, by assigning permissions for this group to the files and directories within this service the Samba administrator can restrict or allow sharing of these files.
In Samba 2.0.5 and above this parameter has extended functionality in the following way. If the group name listed here has a + character prepended to it then the current user accessing the share only has the primary group default assigned to this group if they are already assigned as a member of that group. This allows an administrator to decide that only users who are already in a particular group will create files with group ownership set to that group. This gives a finer granularity of ownership assignment. For example, the setting force group = +sys means that only users who are already in group sys will have their default primary group assigned to sys when accessing this Samba share. All other users will retain their ordinary primary group.
If the force user parameter is also set the group specified in force group will override the primary group set in force user.
Default: force group =
Example: force group = agroup

force printername (S)

When printing from Windows NT (or later), each printer in smb.conf has two associated names which can be used by the client. The first is the sharename (or shortname) defined in smb.conf. This is the only printername available for use by Windows 9x clients. The second name associated with a printer can be seen when browsing to the “Printers” (or “Printers and Faxes”) folder on the Samba server. This is referred to simply as the printername (not to be confused with the printer name option).
When assigning a new driver to a printer on a remote Windows compatible print server such as Samba, the Windows client will rename the printer to match the driver name just uploaded. This can result in confusion for users when multiple printers are bound to the same driver. To prevent Samba from allowing the printers printername to differ from the sharename defined in smb.conf, set force printername = yes.
Be aware that enabling this parameter may affect migrating printers from a Windows server to Samba since Windows has no way to force the sharename and printername to match.
It is recommended that this parameters value not be changed once the printer is in use by clients as this could cause a user not be able to delete printer connections from their local Printers folder.
Default: force printername = no

force security mode (S)

This parameter has been removed for Samba 4.0.0.
No default

force unknown acl user (S)

If this parameter is set, a Windows NT ACL that contains an unknown SID (security descriptor, or representation of a user or group id) as the owner or group owner of the file will be silently mapped into the current UNIX uid or gid of the currently connected user.
This is designed to allow Windows NT clients to copy files and folders containing ACLs that were created locally on the client machine and contain users local to that machine only (no domain users) to be copied to a Samba server (usually with XCOPY /O) and have the unknown userid and groupid of the file owner map to the current connected user. This can only be fixed correctly when winbindd allows arbitrary mapping from any Windows NT SID to a UNIX uid or gid.
Try using this parameter when XCOPY /O gives an ACCESS_DENIED error.
Default: force unknown acl user = no

force user (S)

This specifies a UNIX user name that will be assigned as the default user for all users connecting to this service. This is useful for sharing files. You should also use it carefully as using it incorrectly can cause security problems.
This user name only gets used once a connection is established. Thus clients still need to connect as a valid user and supply a valid password. Once connected, all file operations will be performed as the “forced user”, no matter what username the client connected as. This can be very useful.
In Samba 2.0.5 and above this parameter also causes the primary group of the forced user to be used as the primary group for all file activity. Prior to 2.0.5 the primary group was left as the primary group of the connecting user (this was a bug).
Default: force user =
Example: force user = auser

fss: prune stale (G)

When enabled, Sambas File Server Remote VSS Protocol (FSRVP) server checks all FSRVP initiated snapshots on startup, and removes any corresponding state (including share definitions) for nonexistent snapshot paths.
Default: fss: prune stale = no
Example: fss: prune stale = yes

fss: sequence timeout (G)

The File Server Remote VSS Protocol (FSRVP) server includes a message sequence timer to ensure cleanup on unexpected client disconnect. This parameter overrides the default timeout between FSRVP operations. FSRVP timeouts can be completely disabled via a value of 0.
Default: fss: sequence timeout = 180 or 1800, depending on operation
Example: fss: sequence timeout = 0

fstype (S)

This parameter allows the administrator to configure the string that specifies the type of filesystem a share is using that is reported by smbd(8) when a client queries the filesystem type for a share. The default type is NTFS for compatibility with Windows NT but this can be changed to other strings such as Samba or FAT if required.
Default: fstype = NTFS
Example: fstype = Samba

get quota command (G)

The get quota command should only be used whenever there is no operating system API available from the OS that samba can use.
This option is only available Samba was compiled with quotas support.
This parameter should specify the path to a script that queries the quota information for the specified user/group for the partition that the specified directory is on.
Such a script is being given 3 arguments:
·
directory
·
type of query
·
uid of user or gid of group
The directory is actually mostly just “.” - It needs to be treated relatively to the current working directory that the script can also query.
The type of query can be one of:
·
1 - user quotas
·
2 - user default quotas (uid = -1)
·
3 - group quotas
·
4 - group default quotas (gid = -1)
This script should print one line as output with spaces between the columns. The printed columns should be:
·
1 - quota flags (0 = no quotas, 1 = quotas enabled, 2 = quotas enabled and enforced)
·
2 - number of currently used blocks
·
3 - the softlimit number of blocks
·
4 - the hardlimit number of blocks
·
5 - currently used number of inodes
·
6 - the softlimit number of inodes
·
7 - the hardlimit number of inodes
·
8 (optional) - the number of bytes in a block(default is 1024)
Default: get quota command =
Example: get quota command = /usr/local/sbin/query_quota

getwd cache (G)

This is a tuning option. When this is enabled a caching algorithm will be used to reduce the time taken for getwd() calls. This can have a significant impact on performance, especially when the wide links parameter is set to no.
Default: getwd cache = yes

gpo update command (G)

This option sets the command that is called to apply GPO policies. The samba-gpupdate script applies System Access and Kerberos Policies to the KDC. System Access policies set minPwdAge, maxPwdAge, minPwdLength, and pwdProperties in the samdb. Kerberos Policies set kdc:service ticket lifetime, kdc:user ticket lifetime, and kdc:renewal lifetime in smb.conf.
Default: gpo update command = /usr/sbin/samba-gpupdate
Example: gpo update command = /usr/local/sbin/gpoupdate

guest account (G)

This is a username which will be used for access to services which are specified as guest ok (see below). Whatever privileges this user has will be available to any client connecting to the guest service. This user must exist in the password file, but does not require a valid login. The user account “ftp” is often a good choice for this parameter.
On some systems the default guest account “nobody” may not be able to print. Use another account in this case. You should test this by trying to log in as your guest user (perhaps by using the su - command) and trying to print using the system print command such as lpr(1) or lp(1).
This parameter does not accept % macros, because many parts of the system require this value to be constant for correct operation.
Default: guest account = nobody # default can be changed at compile-time
Example: guest account = ftp

public

This parameter is a synonym for guest ok.

guest ok (S)

If this parameter is yes for a service, then no password is required to connect to the service. Privileges will be those of the guest account.
This parameter nullifies the benefits of setting restrict anonymous = 2
See the section below on security for more information about this option.
Default: guest ok = no

only guest

This parameter is a synonym for guest only.

guest only (S)

If this parameter is yes for a service, then only guest connections to the service are permitted. This parameter will have no effect if guest ok is not set for the service.
See the section below on security for more information about this option.
Default: guest only = no

hide dot files (S)

This is a boolean parameter that controls whether files starting with a dot appear as hidden files.
Default: hide dot files = yes

hide files (S)

This is a list of files or directories that are not visible but are accessible. The DOS hidden attribute is applied to any files or directories that match.
Each entry in the list must be separated by a /, which allows spaces to be included in the entry. * and ? can be used to specify multiple files or directories as in DOS wildcards.
Each entry must be a Unix path, not a DOS path and must not include the Unix directory separator /.
Note that the case sensitivity option is applicable in hiding files.
Setting this parameter will affect the performance of Samba, as it will be forced to check all files and directories for a match as they are scanned.
The example shown above is based on files that the Macintosh SMB client (DAVE) available from Thursby creates for internal use, and also still hides all files beginning with a dot.
An example of us of this parameter is:
hide files = /.*/DesktopFolderDB/TrashFor%m/resource.frk/
Default: hide files = # no file are hidden

hide new files timeout (S)

Setting this parameter to something but 0 hides files that have been modified less than N seconds ago.
It can be used for ingest/process queue style workloads. A processing application should only see files that are definitely finished. As many applications do not have proper external workflow control, this can be a way to make sure processing does not interfere with file ingest.
Default: hide new files timeout = 0

hide special files (S)

This parameter prevents clients from seeing special files such as sockets, devices and fifos in directory listings.
Default: hide special files = no

hide unreadable (S)

This parameter prevents clients from seeing the existence of files that cannot be read. Defaults to off.
Please note that enabling this can slow down listing large directories significantly. Samba has to evaluate the ACLs of all directory members, which can be a lot of effort.
Default: hide unreadable = no

hide unwriteable files (S)

This parameter prevents clients from seeing the existence of files that cannot be written to. Defaults to off. Note that unwriteable directories are shown as usual.
Please note that enabling this can slow down listing large directories significantly. Samba has to evaluate the ACLs of all directory members, which can be a lot of effort.
Default: hide unwriteable files = no

honor change notify privilege (S)

This option can be used to make use of the change notify privilege. By default notify results are not checked against the file system permissions.
If “honor change notify privilege” is enabled, a user will only receive notify results, if he has change notify privilege or sufficient file system permissions. If a user has the change notify privilege, he will receive all requested notify results, even if the user does not have the permissions on the file system.
Default: honor change notify privilege = no

host msdfs (G)

If set to yes, Samba will act as a Dfs server, and allow Dfs-aware clients to browse Dfs trees hosted on the server.
See also the msdfs root share level parameter. For more information on setting up a Dfs tree on Samba, refer to the MSFDS chapter in the book Samba3-HOWTO.
Default: host msdfs = yes

hostname lookups (G)

Specifies whether samba should use (expensive) hostname lookups or use the ip addresses instead. An example place where hostname lookups are currently used is when checking the hosts deny and hosts allow.
Default: hostname lookups = no
Example: hostname lookups = yes

allow hosts

This parameter is a synonym for hosts allow.

hosts allow (S)

A synonym for this parameter is allow hosts.
This parameter is a comma, space, or tab delimited set of hosts which are permitted to access a service.
If specified in the [global] section then it will apply to all services, regardless of whether the individual service has a different setting.
You can specify the hosts by name or IP number. For example, you could restrict access to only the hosts on a Class C subnet with something like allow hosts = 150.203.5.. The full syntax of the list is described in the man page hosts_access(5). Note that this man page may not be present on your system, so a brief description will be given here also.
Note that the localhost address 127.0.0.1 will always be allowed access unless specifically denied by a hosts deny option.
You can also specify hosts by network/netmask pairs and by netgroup names if your system supports netgroups. The EXCEPT keyword can also be used to limit a wildcard list. The following examples may provide some help:
Example 1: allow all IPs in 150.203.*.*; except one
hosts allow = 150.203. EXCEPT 150.203.6.66
Example 2: allow hosts that match the given network/netmask
hosts allow = 150.203.15.0/255.255.255.0
Example 3: allow a couple of hosts
hosts allow = lapland, arvidsjaur
Example 4: allow only hosts in NIS netgroup “foonet”, but deny access from one particular host
hosts allow = @foonet
hosts deny = pirate
Note
Note that access still requires suitable user-level passwords.
See testparm(1) for a way of testing your host access to see if it does what you expect.
Default: hosts allow = # none (i.e., all hosts permitted access)
Example: hosts allow = 150.203.5. myhost.mynet.edu.au

deny hosts

This parameter is a synonym for hosts deny.

hosts deny (S)

The opposite of hosts allow - hosts listed here are NOT permitted access to services unless the specific services have their own lists to override this one. Where the lists conflict, the allow list takes precedence.
In the event that it is necessary to deny all by default, use the keyword ALL (or the netmask 0.0.0.0/0) and then explicitly specify to the hosts allow = hosts allow parameter those hosts that should be permitted access.
Default: hosts deny = # none (i.e., no hosts specifically excluded)
Example: hosts deny = 150.203.4. badhost.mynet.edu.au

idmap backend (G)

The idmap backend provides a plugin interface for Winbind to use varying backends to store SID/uid/gid mapping tables.
This option specifies the default backend that is used when no special configuration set, but it is now deprecated in favour of the new spelling idmap config * : backend.
Default: idmap backend = tdb

idmap cache time (G)

This parameter specifies the number of seconds that Winbinds idmap interface will cache positive SID/uid/gid query results. By default, Samba will cache these results for one week.
Default: idmap cache time = 604800

idmap config DOMAIN : OPTION (G)

ID mapping in Samba is the mapping between Windows SIDs and Unix user and group IDs. This is performed by Winbindd with a configurable plugin interface. Sambas ID mapping is configured by options starting with the idmap config prefix. An idmap option consists of the idmap config prefix, followed by a domain name or the asterisk character (*), a colon, and the name of an idmap setting for the chosen domain.
The idmap configuration is hence divided into groups, one group for each domain to be configured, and one group with the asterisk instead of a proper domain name, which specifies the default configuration that is used to catch all domains that do not have an explicit idmap configuration of their own.
There are three general options available:
backend = backend_name
This specifies the name of the idmap plugin to use as the SID/uid/gid backend for this domain. The standard backends are tdb (idmap_tdb(8)), tdb2 (idmap_tdb2(8)), ldap (idmap_ldap(8)), rid (idmap_rid(8)), hash (idmap_hash(8)), autorid (idmap_autorid(8)), ad (idmap_ad(8)) and nss (idmap_nss(8)). The corresponding manual pages contain the details, but here is a summary.
The first three of these create mappings of their own using internal unixid counters and store the mappings in a database. These are suitable for use in the default idmap configuration. The rid and hash backends use a pure algorithmic calculation to determine the unixid for a SID. The autorid module is a mixture of the tdb and rid backend. It creates ranges for each domain encountered and then uses the rid algorithm for each of these automatically configured domains individually. The ad backend uses unix ids stored in Active Directory via the standard schema extensions. The nss backend reverses the standard winbindd setup and gets the unix ids via names from nsswitch which can be useful in an ldap setup.
range = low - high
Defines the available matching uid and gid range for which the backend is authoritative. For allocating backends, this also defines the start and the end of the range for allocating new unique IDs.
winbind uses this parameter to find the backend that is authoritative for a unix ID to SID mapping, so it must be set for each individually configured domain and for the default configuration. The configured ranges must be mutually disjoint.
Note that the low value interacts with the min domain uid option!
read only = yes|no
This option can be used to turn the writing backends tdb, tdb2, and ldap into read only mode. This can be useful e.g. in cases where a pre-filled database exists that should not be extended automatically.
The following example illustrates how to configure the idmap_ad(8) backend for the CORP domain and the idmap_tdb(8) backend for all other domains. This configuration assumes that the admin of CORP assigns unix ids below 1000000 via the SFU extensions, and winbind is supposed to use the next million entries for its own mappings from trusted domains and for local groups for example.
idmap config * : backend = tdb
	idmap config * : range = 1000000-1999999

	idmap config CORP : backend  = ad
	idmap config CORP : range = 1000-999999
No default

winbind gid

This parameter is a synonym for idmap gid.

idmap gid (G)

The idmap gid parameter specifies the range of group ids for the default idmap configuration. It is now deprecated in favour of idmap config * : range.
See the idmap config option.
Default: idmap gid =
Example: idmap gid = 10000-20000

idmap negative cache time (G)

This parameter specifies the number of seconds that Winbinds idmap interface will cache negative SID/uid/gid query results.
Default: idmap negative cache time = 120

winbind uid

This parameter is a synonym for idmap uid.

idmap uid (G)

The idmap uid parameter specifies the range of user ids for the default idmap configuration. It is now deprecated in favour of idmap config * : range.
See the idmap config option.
Default: idmap uid =
Example: idmap uid = 10000-20000

include (S)

This allows you to include one config file inside another. The file is included literally, as though typed in place.
It takes the standard substitutions, except %u, %P and %S.
The parameter include = registry has a special meaning: It does not include a file named registry from the current working directory, but instead reads the global configuration options from the registry. See the section on registry-based configuration for details. Note that this option automatically activates registry shares.
Default: include =
Example: include = /usr/local/samba/lib/admin_smb.conf

include system krb5 conf (G)

Setting this parameter to no will prevent winbind to include the system /etc/krb5.conf file into the krb5.conf file it creates. See also create krb5 conf. This option only applies to Samba built with MIT Kerberos.
Default: include system krb5 conf = yes

inherit acls (S)

This parameter is only relevant for filesystems that do not support standardized NFS4 ACLs but only a POSIX draft ACL implementation and which implements default ACLs like most filesystems on Linux. It can be used to ensure that if default ACLs exist on parent directories, they are always honored when creating a new file or subdirectory in these parent directories. The default behavior is to use the unix mode specified when creating the directory. Enabling this option sets the unix mode to 0777, thus guaranteeing that the default directory ACLs are propagated. Note that using the VFS modules acl_xattr or acl_tdb which store native Windows as meta-data will automatically turn this option on for any share for which they are loaded, as they require this option to emulate Windows ACLs correctly.
Default: inherit acls = no

inherit owner (S)

The ownership of new files and directories is normally governed by effective uid of the connected user. This option allows the Samba administrator to specify that the ownership for new files and directories should be controlled by the ownership of the parent directory.
Valid options are:
·
no - Both the Windows (SID) owner and the UNIX (uid) owner of the file are governed by the identity of the user that created the file.
·
windows and unix - The Windows (SID) owner and the UNIX (uid) owner of new files and directories are set to the respective owner of the parent directory.
·
yes - a synonym for windows and unix.
·
unix only - Only the UNIX owner is set to the UNIX owner of the parent directory.
Common scenarios where this behavior is useful is in implementing drop-boxes, where users can create and edit files but not delete them and ensuring that newly created files in a users roaming profile directory are actually owned by the user.
The unix only option effectively breaks the tie between the Windows owner of a file and the UNIX owner. As a logical consequence, in this mode, setting the Windows owner of a file does not modify the UNIX owner. Using this mode should typically be combined with a backing store that can emulate the full NT ACL model without affecting the POSIX permissions, such as the acl_xattr VFS module, coupled with acl_xattr:ignore system acls = yes. This can be used to emulate folder quotas, when files are exposed only via SMB (without UNIX extensions). The UNIX owner of a directory is locally set and inherited by all subdirectories and files, and they all consume the same quota.
Default: inherit owner = no

inherit permissions (S)

The permissions on new files and directories are normally governed by create mask, directory mask, force create mode and force directory mode but the boolean inherit permissions parameter overrides this.
New directories inherit the mode of the parent directory, including bits such as setgid.
New files inherit their read/write bits from the parent directory. Their execute bits continue to be determined by map archive, map hidden and map system as usual.
Note that the setuid bit is never set via inheritance (the code explicitly prohibits this).
This can be particularly useful on large systems with many users, perhaps several thousand, to allow a single [homes] share to be used flexibly by each user.
Default: inherit permissions = no

init logon delay (G)

This parameter specifies a delay in milliseconds for the hosts configured for delayed initial samlogon with init logon delayed hosts.
Default: init logon delay = 100

init logon delayed hosts (G)

This parameter takes a list of host names, addresses or networks for which the initial samlogon reply should be delayed (so other DCs get preferred by XP workstations if there are any).
The length of the delay can be specified with the init logon delay parameter.
Default: init logon delayed hosts =
Example: init logon delayed hosts = 150.203.5. myhost.mynet.de

interfaces (G)

This option allows you to override the default network interfaces list that Samba will use for browsing, name registration and other NetBIOS over TCP/IP (NBT) traffic. By default Samba will query the kernel for the list of all active interfaces and use any interfaces except 127.0.0.1 that are broadcast capable.
The option takes a list of interface strings. Each string can be in any of the following forms:
·
a network interface name (such as eth0). This may include shell-like wildcards so eth* will match any interface starting with the substring “eth”
·
an IP address. In this case the netmask is determined from the list of interfaces obtained from the kernel
·
an IP/mask pair.
·
a broadcast/mask pair.
The “mask” parameters can either be a bit length (such as 24 for a C class network) or a full netmask in dotted decimal form.
The “IP” parameters above can either be a full dotted decimal IP address or a hostname which will be looked up via the OSs normal hostname resolution mechanisms.
By default Samba enables all active interfaces that are broadcast capable except the loopback adaptor (IP address 127.0.0.1).
In order to support SMB3 multi-channel configurations, smbd understands some extra parameters which can be appended after the actual interface with this extended syntax (note that the quoting is important in order to handle the ; and , characters):
“interface[;key1=value1[,key2=value2[…]]]”
Known keys are speed, capability, and if_index. Speed is specified in bits per second. Known capabilities are RSS and RDMA. The if_index should be used with care: the values must not coincide with indexes used by the kernel. Note that these options are mainly intended for testing and development rather than for production use. At least on Linux systems, these values should be auto-detected, but the settings can serve as last a resort when autodetection is not working or is not available. The specified values overwrite the auto-detected values.
The first two example below configures three network interfaces corresponding to the eth0 device and IP addresses 192.168.2.10 and 192.168.3.10. The netmasks of the latter two interfaces would be set to 255.255.255.0.
The other examples show how per interface extra parameters can be specified. Notice the possible usage of “,” and “;”, which makes the double quoting necessary.
Default: interfaces =
Example: interfaces = eth0 192.168.2.10/24 192.168.3.10/255.255.255.0
Example: interfaces = eth0, 192.168.2.10/24; 192.168.3.10/255.255.255.0
Example: interfaces = “eth0;if_index=65,speed=1000000000,capability=RSS”
Example: interfaces = “lo;speed=1000000000” “eth0;capability=RSS”
Example: interfaces = “lo;speed=1000000000” , “eth0;capability=RSS”
Example: interfaces = “eth0;capability=RSS” , “rdma1;capability=RDMA” ; “rdma2;capability=RSS,capability=RDMA”

invalid users (S)

This is a list of users that should not be allowed to login to this service. This is really a paranoid check to absolutely ensure an improper setting does not breach your security.
A name starting with a @ is interpreted as an NIS netgroup first (if your system supports NIS), and then as a UNIX group if the name was not found in the NIS netgroup database.
A name starting with + is interpreted only by looking in the UNIX group database via the NSS getgrnam() interface. A name starting with & is interpreted only by looking in the NIS netgroup database (this requires NIS to be working on your system). The characters + and & may be used at the start of the name in either order so the value +&group means check the UNIX group database, followed by the NIS netgroup database, and the value &+group means check the NIS netgroup database, followed by the UNIX group database (the same as the @ prefix).
The current servicename is substituted for %S. This is useful in the [homes] section.
Default: invalid users = # no invalid users
Example: invalid users = root fred admin @wheel

iprint server (G)

This parameter is only applicable if printing is set to iprint.
If set, this option overrides the ServerName option in the CUPS client.conf. This is necessary if you have virtual samba servers that connect to different CUPS daemons.
Default: iprint server = ""
Example: iprint server = MYCUPSSERVER

kdc default domain supported enctypes (G)

Set the default value of msDS-SupportedEncryptionTypes for service accounts in Active Directory that are missing this value or where msDS-SupportedEncryptionTypes is set to 0.
This allows Samba administrators to match the configuration flexibility provided by the HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC\DefaultDomainSupportedEncTypes Registry Value on Windows.
Unlike the Windows registry key (which only takes an base-10 number), in Samba this may also be expressed in hexadecimal or as a list of Kerberos encryption type names.
Specified values are ORed together bitwise, and those currently supported consist of:
·
arcfour-hmac-md5, rc4-hmac, 0x4, or 4
Known on Windows as Kerberos RC4 encryption
·
aes128-cts-hmac-sha1-96, aes128-cts, 0x8, or 8
Known on Windows as Kerberos AES 128 bit encryption
·
aes256-cts-hmac-sha1-96, aes256-cts, 0x10, or 16
Known on Windows as Kerberos AES 256 bit encryption
·
aes256-cts-hmac-sha1-96-sk, aes256-cts-sk, 0x20, or 32
Allow AES session keys. When this is set, it indicates to the KDC that AES session keys can be used, even when aes256-cts and aes128-cts are not set. This allows use of AES keys against hosts otherwise only configured with RC4 for ticket keys (which is the default).
Default: kdc default domain supported enctypes = 0 # maps to what the software supports currently: arcfour-hmac-md5 aes256-cts-hmac-sha1-96-sk

kdc enable fast (G)

With the Samba 4.16 the embedded Heimdal KDC brings support for RFC6113 FAST, which wasnt available in older Samba versions.
This option is mostly for testing and currently only applies if the embedded Heimdal KDC is used.
Default: kdc enable fast = yes

kdc force enable rc4 weak session keys (G)

RFC8429 declares that rc4-hmac Kerberos ciphers are weak and there are known attacks on Active Directory use of this cipher suite.
However for compatibility with Microsoft Windows this option allows the KDC to assume that regardless of the value set in a service accounts msDS-SupportedEncryptionTypes attribute that a rc4-hmac Kerberos session key (as distinct from the ticket key, as found in a service keytab) can be used if the potentially older client requests it.
Default: kdc force enable rc4 weak session keys = no

kdc supported enctypes (G)

On an active directory domain controller, this is the list of supported encryption types for local running kdc.
This allows Samba administrators to remove support for weak/unused encryption types, similar the configuration flexibility provided by the Network security: Configure encryption types allowed for Kerberos GPO/Local Policies/Security Options Value, which results in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\SupportedEncryptionTypes Registry Value on Windows.
Unlike the Windows registry key (which only takes an base-10 number), in Samba this may also be expressed as hexadecimal or a list of Kerberos encryption type names.
Specified values are ORed together bitwise, and those currently supported consist of:
·
arcfour-hmac-md5, rc4-hmac, 0x4, or 4
Known on Windows as Kerberos RC4 encryption
·
aes128-cts-hmac-sha1-96, aes128-cts, 0x8, or 8
Known on Windows as Kerberos AES 128 bit encryption
·
aes256-cts-hmac-sha1-96, aes256-cts, 0x10, or 16
Known on Windows as Kerberos AES 256 bit encryption
Default: kdc supported enctypes = 0 # maps to what the software supports currently: arcfour-hmac-md5 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96

keepalive (G)

The value of the parameter (an integer) represents the number of seconds between keepalive packets. If this parameter is zero, no keepalive packets will be sent. Keepalive packets, if sent, allow the server to tell whether a client is still present and responding.
Keepalives should, in general, not be needed if the socket has the SO_KEEPALIVE attribute set on it by default. (see socket options). Basically you should only use this option if you strike difficulties.
Please note this option only applies to SMB1 client connections, and has no effect on SMB2 clients.
Default: keepalive = 300
Example: keepalive = 600

kerberos encryption types (G)

This parameter determines the encryption types to use when operating as a Kerberos client. Possible values are all, strong, and legacy.
Samba uses a Kerberos library (MIT or Heimdal) to obtain Kerberos tickets. This library is normally configured outside of Samba, using the krb5.conf file. This file may also include directives to configure the encryption types to be used. However, Samba implements Active Directory protocols and algorithms to locate a domain controller. In order to force the Kerberos library into using the correct domain controller, some Samba processes, such as winbindd(8) and net(8), build a private krb5.conf file for use by the Kerberos library while being invoked from Samba. This private file controls all aspects of the Kerberos library operation, and this parameter controls how the encryption types are configured within this generated file, and therefore also controls the encryption types negotiable by Samba.
When set to all, all active directory encryption types are allowed.
When set to strong, only AES-based encryption types are offered. This can be used in hardened environments to prevent downgrade attacks.
When set to legacy, only RC4-HMAC-MD5 is allowed. AVOID using this option, because of CVE-2022-37966 see https://bugzilla.samba.org/show_bug.cgi?id=15237.
Default: kerberos encryption types = all

kerberos method (G)

Controls how kerberos tickets are verified.
Valid options are:
·
secrets only - use only the secrets.tdb for ticket verification (default)
·
system keytab - use only the system keytab for ticket verification
·
dedicated keytab - use a dedicated keytab for ticket verification
·
secrets and keytab - use the secrets.tdb first, then the system keytab
The major difference between “system keytab” and “dedicated keytab” is that the latter method relies on kerberos to find the correct keytab entry instead of filtering based on expected principals.
When the kerberos method is in “dedicated keytab” mode, dedicated keytab file must be set to specify the location of the keytab file.
Default: kerberos method = default

kernel change notify (G)

This parameter specifies whether Samba should ask the kernel for change notifications in directories so that SMB clients can refresh whenever the data on the server changes.
This parameter is only used when your kernel supports change notification to user programs using the inotify interface.
Default: kernel change notify = yes

kernel oplocks (S)

For UNIXes that support kernel based oplocks (currently only Linux), this parameter allows the use of them to be turned on or off. However, this disables Level II oplocks for clients as the Linux kernel does not support them properly.
Kernel oplocks support allows Samba oplocks to be broken whenever a local UNIX process or NFS operation accesses a file that smbd(8) has oplocked. This allows complete data consistency between SMB/CIFS, NFS and local file access (and is a very cool feature :-).
If you do not need this interaction, you should disable the parameter on Linux to get Level II oplocks and the associated performance benefit.
This parameter defaults to no and is translated to a no-op on systems that do not have the necessary kernel support.
Default: kernel oplocks = no

kernel share modes (S)

This parameter controls whether SMB share modes are translated into file system specific sharemode calls.
Kernel share modes provide a minimal level of interoperability with local UNIX processes and NFS operations by preventing access corresponding to the SMB share modes. This requires a file system specific VFS module with proper support.
Note that in order to use SMB2 durable file handles on a share, you have to turn kernel share modes off.
This parameter defaults to no. Setting it to yes requires a file system module that supports file system sharemodes, otherwise attempts to access files will fail with a sharing violation.
Default: kernel share modes = no

kpasswd port (G)

Specifies which ports the Kerberos server should listen on for password changes.
Default: kpasswd port = 464

krb5 port (G)

Specifies which port the KDC should listen on for Kerberos traffic.
Default: krb5 port = 88

lanman auth (G)

This parameter has been deprecated since Samba 4.11 and support for LanMan (as distinct from NTLM, NTLMv2 or Kerberos authentication) will be removed in a future Samba release.
That is, in the future, the current default of lanman auth = no will be the enforced behaviour.
This parameter determines whether or not smbd(8) will attempt to authenticate users or permit password changes using the LANMAN password hash. If disabled, only clients which support NT password hashes (e.g. Windows NT/2000 clients, smbclient, but not Windows 95/98 or the MS DOS network client) will be able to connect to the Samba host.
The LANMAN encrypted response is easily broken, due to its case-insensitive nature, and the choice of algorithm. Servers without Windows 95/98/ME or MS DOS clients are advised to disable this option.
When this parameter is set to no this will also result in sambaLMPassword in Sambas passdb being blanked after the next password change. As a result of that lanman clients wont be able to authenticate, even if lanman auth is re-enabled later on.
Unlike the encrypt passwords option, this parameter cannot alter client behaviour, and the LANMAN response will still be sent over the network. See the client lanman auth to disable this for Sambas clients (such as smbclient)
This parameter is overridden by ntlm auth, so unless that it is also set to ntlmv1-permitted or yes, then only NTLMv2 logins will be permitted and no LM hash will be stored. All modern clients support NTLMv2, and but some older clients require special configuration to use it.
This parameter has no impact on the Samba AD DC, LM authentication is always disabled and no LM password is ever stored.
Default: lanman auth = no

large readwrite (G)

This parameter determines whether or not smbd(8) supports the new 64k streaming read and write variant SMB requests introduced with Windows 2000. Note that due to Windows 2000 client redirector bugs this requires Samba to be running on a 64-bit capable operating system such as IRIX, Solaris or a Linux 2.4 kernel. Can improve performance by 10% with Windows 2000 clients. Defaults to on. Not as tested as some other Samba code paths.
Default: large readwrite = yes

ldap admin dn (G)

The ldap admin dn defines the Distinguished Name (DN) name used by Samba to contact the ldap server when retrieving user account information. The ldap admin dn is used in conjunction with the admin dn password stored in the private/secrets.tdb file. See the smbpasswd(8) man page for more information on how to accomplish this.
The ldap admin dn requires a fully specified DN. The ldap suffix is not appended to the ldap admin dn.
No default

ldap connection timeout (G)

This parameter tells the LDAP library calls which timeout in seconds they should honor during initial connection establishments to LDAP servers. It is very useful in failover scenarios in particular. If one or more LDAP servers are not reachable at all, we do not have to wait until TCP timeouts are over. This feature must be supported by your LDAP library.
This parameter is different from ldap timeout which affects operations on LDAP servers using an existing connection and not establishing an initial connection.
Default: ldap connection timeout = 2

ldap debug level (G)

This parameter controls the debug level of the LDAP library calls. In the case of OpenLDAP, it is the same bit-field as understood by the server and documented in the slapd.conf(5) manpage. A typical useful value will be 1 for tracing function calls.
The debug output from the LDAP libraries appears with the prefix [LDAP] in Sambas logging output. The level at which LDAP logging is printed is controlled by the parameter ldap debug threshold.
Default: ldap debug level = 0
Example: ldap debug level = 1

ldap debug threshold (G)

This parameter controls the Samba debug level at which the ldap library debug output is printed in the Samba logs. See the description of ldap debug level for details.
Default: ldap debug threshold = 10
Example: ldap debug threshold = 5

ldap delete dn (G)

This parameter specifies whether a delete operation in the ldapsam deletes the complete entry or only the attributes specific to Samba.
Default: ldap delete dn = no

ldap deref (G)

This option controls whether Samba should tell the LDAP library to use a certain alias dereferencing method. The default is auto, which means that the default setting of the ldap client library will be kept. Other possible values are never, finding, searching and always. Grab your LDAP manual for more information.
Default: ldap deref = auto
Example: ldap deref = searching

ldap follow referral (G)

This option controls whether to follow LDAP referrals or not when searching for entries in the LDAP database. Possible values are on to enable following referrals, off to disable this, and auto, to use the libldap default settings. libldaps choice of following referrals or not is set in /etc/openldap/ldap.conf with the REFERRALS parameter as documented in ldap.conf(5).
Default: ldap follow referral = auto
Example: ldap follow referral = off

ldap group suffix (G)

This parameter specifies the suffix that is used for groups when these are added to the LDAP directory. If this parameter is unset, the value of ldap suffix will be used instead. The suffix string is prepended to the ldap suffix string so use a partial DN.
Default: ldap group suffix =
Example: ldap group suffix = ou=Groups

ldap idmap suffix (G)

This parameters specifies the suffix that is used when storing idmap mappings. If this parameter is unset, the value of ldap suffix will be used instead. The suffix string is prepended to the ldap suffix string so use a partial DN.
Default: ldap idmap suffix =
Example: ldap idmap suffix = ou=Idmap

ldap machine suffix (G)

It specifies where machines should be added to the ldap tree. If this parameter is unset, the value of ldap suffix will be used instead. The suffix string is prepended to the ldap suffix string so use a partial DN.
Default: ldap machine suffix =
Example: ldap machine suffix = ou=Computers

ldap max anonymous request size (G)

This parameter specifies the maximum permitted size (in bytes) for an LDAP request received on an anonymous connection.
If the request size exceeds this limit the request will be rejected.
Default: ldap max anonymous request size = 256000
Example: ldap max anonymous request size = 500000

ldap max authenticated request size (G)

This parameter specifies the maximum permitted size (in bytes) for an LDAP request received on an authenticated connection.
If the request size exceeds this limit the request will be rejected.
Default: ldap max authenticated request size = 16777216
Example: ldap max authenticated request size = 4194304

ldap max search request size (G)

This parameter specifies the maximum permitted size (in bytes) for an LDAP search request.
If the request size exceeds this limit the request will be rejected.
Default: ldap max search request size = 256000
Example: ldap max search request size = 4194304

ldap page size (G)

This parameter specifies the number of entries per page.
If the LDAP server supports paged results, clients can request subsets of search results (pages) instead of the entire list. This parameter specifies the size of these pages.
Default: ldap page size = 1000
Example: ldap page size = 512

ldap password sync

This parameter is a synonym for ldap passwd sync.

ldap passwd sync (G)

This option is used to define whether or not Samba should sync the LDAP password with the NT and LM hashes for normal accounts (NOT for workstation, server or domain trusts) on a password change via SAMBA.
The ldap passwd sync can be set to one of three values:
·
Yes = Try to update the LDAP, NT and LM passwords and update the pwdLastSet time.
·
No = Update NT and LM passwords and update the pwdLastSet time.
·
Only = Only update the LDAP password and let the LDAP server do the rest.
Default: ldap passwd sync = no

ldap replication sleep (G)

When Samba is asked to write to a read-only LDAP replica, we are redirected to talk to the read-write master server. This server then replicates our changes back to the local server, however the replication might take some seconds, especially over slow links. Certain client activities, particularly domain joins, can become confused by the success that does not immediately change the LDAP back-ends data.
This option simply causes Samba to wait a short time, to allow the LDAP server to catch up. If you have a particularly high-latency network, you may wish to time the LDAP replication with a network sniffer, and increase this value accordingly. Be aware that no checking is performed that the data has actually replicated.
The value is specified in milliseconds, the maximum value is 5000 (5 seconds).
Default: ldap replication sleep = 1000

ldapsam:editposix (G)

Editposix is an option that leverages ldapsam:trusted to make it simpler to manage a domain controller eliminating the need to set up custom scripts to add and manage the posix users and groups. This option will instead directly manipulate the ldap tree to create, remove and modify user and group entries. This option also requires a running winbindd as it is used to allocate new uids/gids on user/group creation. The allocation range must be therefore configured.
To use this option, a basic ldap tree must be provided and the ldap suffix parameters must be properly configured. On virgin servers the default users and groups (Administrator, Guest, Domain Users, Domain Admins, Domain Guests) can be precreated with the command net sam provision. To run this command the ldap server must be running, Winbindd must be running and the smb.conf ldap options must be properly configured. The typical ldap setup used with the ldapsam:trusted = yes option is usually sufficient to use ldapsam:editposix = yes as well.
An example configuration can be the following:
encrypt passwords = true
	passdb backend = ldapsam

	ldapsam:trusted=yes
	ldapsam:editposix=yes

	ldap admin dn = cn=admin,dc=samba,dc=org
	ldap delete dn = yes
	ldap group suffix = ou=groups
	ldap idmap suffix = ou=idmap
	ldap machine suffix = ou=computers
	ldap user suffix = ou=users
	ldap suffix = dc=samba,dc=org

	idmap backend = ldap:"ldap://localhost"

	idmap uid = 5000-50000
	idmap gid = 5000-50000
This configuration assumes a directory layout like described in the following ldif:
dn: dc=samba,dc=org
	objectClass: top
	objectClass: dcObject
	objectClass: organization
	o: samba.org
	dc: samba

	dn: cn=admin,dc=samba,dc=org
	objectClass: simpleSecurityObject
	objectClass: organizationalRole
	cn: admin
	description: LDAP administrator
	userPassword: secret

	dn: ou=users,dc=samba,dc=org
	objectClass: top
	objectClass: organizationalUnit
	ou: users

	dn: ou=groups,dc=samba,dc=org
	objectClass: top
	objectClass: organizationalUnit
	ou: groups

	dn: ou=idmap,dc=samba,dc=org
	objectClass: top
	objectClass: organizationalUnit
	ou: idmap

	dn: ou=computers,dc=samba,dc=org
	objectClass: top
	objectClass: organizationalUnit
	ou: computers
Default: ldapsam:editposix = no

ldapsam:trusted (G)

By default, Samba as a Domain Controller with an LDAP backend needs to use the Unix-style NSS subsystem to access user and group information. Due to the way Unix stores user information in /etc/passwd and /etc/group this inevitably leads to inefficiencies. One important question a user needs to know is the list of groups he is member of. The plain UNIX model involves a complete enumeration of the file /etc/group and its NSS counterparts in LDAP. UNIX has optimized functions to enumerate group membership. Sadly, other functions that are used to deal with user and group attributes lack such optimization.
To make Samba scale well in large environments, the ldapsam:trusted = yes option assumes that the complete user and group database that is relevant to Samba is stored in LDAP with the standard posixAccount/posixGroup attributes. It further assumes that the Samba auxiliary object classes are stored together with the POSIX data in the same LDAP object. If these assumptions are met, ldapsam:trusted = yes can be activated and Samba can bypass the NSS system to query user group memberships. Optimized LDAP queries can greatly speed up domain logon and administration tasks. Depending on the size of the LDAP database a factor of 100 or more for common queries is easily achieved.
Default: ldapsam:trusted = no

ldap server require strong auth (G)

The ldap server require strong auth defines whether the ldap server requires ldap traffic to be signed or signed and encrypted (sealed). Possible values are no, allow_sasl_over_tls and yes.
A value of no allows simple and sasl binds over all transports.
A value of allow_sasl_over_tls allows simple and sasl binds (without sign or seal) over TLS encrypted connections. Unencrypted connections only allow sasl binds with sign or seal.
A value of yes allows only simple binds over TLS encrypted connections. Unencrypted connections only allow sasl binds with sign or seal.
Default: ldap server require strong auth = yes

ldap ssl (G)

This option is used to define whether or not Samba should use SSL when connecting to the ldap server This is NOT related to Sambas previous SSL support which was enabled by specifying the –with-ssl option to the configure script.
LDAP connections should be secured where possible. This may be done setting either this parameter to start tls or by specifying ldaps:// in the URL argument of passdb backend.
The ldap ssl can be set to one of two values:
·
Off = Never use SSL when querying the directory.
·
start tls = Use the LDAPv3 StartTLS extended operation (RFC2830) for communicating with the directory server.
Please note that this parameter does only affect rpc methods.
Default: ldap ssl = start tls

ldap suffix (G)

Specifies the base for all ldap suffixes and for storing the sambaDomain object.
The ldap suffix will be appended to the values specified for the ldap user suffix, ldap group suffix, ldap machine suffix, and the ldap idmap suffix. Each of these should be given only a DN relative to the ldap suffix.
Default: ldap suffix =
Example: ldap suffix = dc=samba,dc=org

ldap timeout (G)

This parameter defines the number of seconds that Samba should use as timeout for LDAP operations.
Default: ldap timeout = 15

ldap user suffix (G)

This parameter specifies where users are added to the tree. If this parameter is unset, the value of ldap suffix will be used instead. The suffix string is prepended to the ldap suffix string so use a partial DN.
Default: ldap user suffix =
Example: ldap user suffix = ou=people

level2 oplocks (S)

This parameter controls whether Samba supports level2 (read-only) oplocks on a share.
Level2, or read-only oplocks allow Windows NT clients that have an oplock on a file to downgrade from a read-write oplock to a read-only oplock once a second client opens the file (instead of releasing all oplocks on a second open, as in traditional, exclusive oplocks). This allows all openers of the file that support level2 oplocks to cache the file for read-ahead only (ie. they may not cache writes or lock requests) and increases performance for many accesses of files that are not commonly written (such as application .EXE files).
Once one of the clients which have a read-only oplock writes to the file all clients are notified (no reply is needed or waited for) and told to break their oplocks to “none” and delete any read-ahead caches.
It is recommended that this parameter be turned on to speed access to shared executables.
For more discussions on level2 oplocks see the CIFS spec.
Currently, if kernel oplocks are supported then level2 oplocks are not granted (even if this parameter is set to yes). Note also, the oplocks parameter must be set to yes on this share in order for this parameter to have any effect.
Default: level2 oplocks = yes

lm announce (G)

This parameter determines if nmbd(8) will produce Lanman announce broadcasts that are needed by OS/2 clients in order for them to see the Samba server in their browse list. This parameter can have three values, yes, no, or auto. The default is auto. If set to no Samba will never produce these broadcasts. If set to yes Samba will produce Lanman announce broadcasts at a frequency set by the parameter lm interval. If set to auto Samba will not send Lanman announce broadcasts by default but will listen for them. If it hears such a broadcast on the wire it will then start sending them at a frequency set by the parameter lm interval.
Default: lm announce = auto
Example: lm announce = yes

lm interval (G)

If Samba is set to produce Lanman announce broadcasts needed by OS/2 clients (see the lm announce parameter) then this parameter defines the frequency in seconds with which they will be made. If this is set to zero then no Lanman announcements will be made despite the setting of the lm announce parameter.
Default: lm interval = 60
Example: lm interval = 120

load printers (G)

A boolean variable that controls whether all printers in the printcap will be loaded for browsing by default. See the printers section for more details.
Default: load printers = yes

local master (G)

This option allows nmbd(8) to try and become a local master browser on a subnet. If set to no then nmbd will not attempt to become a local master browser on a subnet and will also lose in all browsing elections. By default this value is set to yes. Setting this value to yes doesnt mean that Samba will become the local master browser on a subnet, just that nmbd will participate in elections for local master browser.
Setting this value to no will cause nmbd never to become a local master browser.
Default: local master = yes

lock dir

This parameter is a synonym for lock directory.

lock directory (G)

This option specifies the directory where lock files will be placed. The lock files are used to implement the max connections option.
Note: This option can not be set inside registry configurations.
The files placed in this directory are not required across service restarts and can be safely placed on volatile storage (e.g. tmpfs in Linux)
Default: lock directory = /run/samba
Example: lock directory = /var/run/samba/locks

locking (S)

This controls whether or not locking will be performed by the server in response to lock requests from the client.
If locking = no, all lock and unlock requests will appear to succeed and all lock queries will report that the file in question is available for locking.
If locking = yes, real locking will be performed by the server.
This option may be useful for read-only filesystems which may not need locking (such as CDROM drives), although setting this parameter of no is not really recommended even in this case.
Be careful about disabling locking either globally or in a specific service, as lack of locking may result in data corruption. You should never need to set this parameter.
Default: locking = yes

lock spin time (G)

The time in milliseconds that smbd should keep waiting to see if a failed lock request can be granted. This parameter has changed in default value from Samba 3.0.23 from 10 to 200. The associated lock spin count parameter is no longer used in Samba 3.0.24. You should not need to change the value of this parameter.
Default: lock spin time = 200

log file (G)

This option allows you to override the name of the Samba log file (also known as the debug file).
This option takes the standard substitutions, allowing you to have separate log files for each user or machine.
No default
Example: log file = /usr/local/samba/var/log.%m

logging (G)

This parameter configures logging backends. Multiple backends can be specified at the same time, with different log levels for each backend. The parameter is a list of backends, where each backend is specified as backend[:option][@loglevel].
The option parameter can be used to pass backend-specific options.
The log level for a backend is optional, if it is not set for a backend, all messages are sent to this backend. The parameter log level determines overall log levels, while the log levels specified here define what is sent to the individual backends.
When logging is set, it overrides the syslog and syslog only parameters.
Some backends are only available when Samba has been compiled with the additional libraries. The overall list of logging backends:
·
syslog
·
file
·
systemd
·
lttng
·
gpfs
·
ringbuf
The ringbuf backend supports an optional size argument to change the buffer size used, the default is 1 MB: ringbuf:size=NBYTES
Default: logging =
Example: logging = syslog@1 file

debuglevel

This parameter is a synonym for log level.

log level (G)

The value of the parameter (a string) allows the debug level (logging level) to be specified in the smb.conf file.
This parameter has been extended since the 2.2.x series, now it allows one to specify the debug level for multiple debug classes and distinct logfiles for debug classes. This is to give greater flexibility in the configuration of the system. The following debug classes are currently implemented:
·
all
·
tdb
·
printdrivers
·
lanman
·
smb
·
rpc_parse
·
rpc_srv
·
rpc_cli
·
passdb
·
sam
·
auth
·
winbind
·
vfs
·
idmap
·
quota
·
acls
·
locking
·
msdfs
·
dmapi
·
registry
·
scavenger
·
dns
·
ldb
·
tevent
·
auth_audit
·
auth_json_audit
·
kerberos
·
drs_repl
·
smb2
·
smb2_credits
·
dsdb_audit
·
dsdb_json_audit
·
dsdb_password_audit
·
dsdb_password_json_audit
·
dsdb_transaction_audit
·
dsdb_transaction_json_audit
·
dsdb_group_audit
·
dsdb_group_json_audit
Various modules register dynamic debug classes at first usage:
·
catia
·
dfs_samba4
·
extd_audit
·
fileid
·
fruit
·
full_audit
·
media_harmony
·
preopen
·
recycle
·
shadow_copy
·
shadow_copy
·
unityed_media
·
virusfilter
To configure the logging for specific classes to go into a different file then log file, you can append @PATH to the class, eg log level = 1 full_audit:1@/var/log/audit.log.
Authentication and authorization audit information is logged under the auth_audit, and if Samba was not compiled with –without-json, a JSON representation is logged under auth_json_audit.
Support is comprehensive for all authentication and authorisation of user accounts in the Samba Active Directory Domain Controller, as well as the implicit authentication in password changes. In the file server, NTLM authentication, SMB and RPC authorization is covered.
Log levels for auth_audit and auth_audit_json are:
·
2: Authentication Failure
·
3: Authentication Success
·
4: Authorization Success
·
5: Anonymous Authentication and Authorization Success
Changes to the AD DC sam.ldb database are logged under the dsdb_audit and a JSON representation is logged under dsdb_json_audit.
Group membership changes to the AD DC sam.ldb database are logged under the dsdb_group_audit and a JSON representation is logged under dsdb_group_json_audit.
Log levels for dsdb_audit, dsdb_json_audit, dsdb_group_audit, dsdb_group_json_audit and dsdb_json_audit are:
·
5: Database modifications
·
5: Replicated updates from another DC
Password changes and Password resets in the AD DC are logged under dsdb_password_audit and a JSON representation is logged under the dsdb_password_json_audit. Password changes will also appears as authentication events via auth_audit and auth_audit_json.
Log levels for dsdb_password_audit and dsdb_password_json_audit are:
·
5: Successful password changes and resets
Transaction rollbacks and prepare commit failures are logged under the dsdb_transaction_audit and a JSON representation is logged under the dsdb_transaction_json_audit.
Log levels for dsdb_transaction_audit and dsdb_transaction_json are:
·
5: Transaction failure (rollback)
·
10: Transaction success (commit)
Transaction roll-backs are possible in Samba, and whilst they rarely reflect anything more than the failure of an individual operation (say due to the add of a conflicting record), they are possible. Audit logs are already generated and sent to the system logs before the transaction is complete. Logging the transaction details allows the identification of password and sam.ldb operations that have been rolled back, and so have not actually persisted.
Warning
Changes to sam.ldb made locally by the root user with direct access to the database are not logged to the system logs, but to the administrators own console. While less than ideal, any user able to make such modifications could disable the audit logging in any case.
Default: log level = 0
Example: log level = 3 passdb:5 auth:10 winbind:2
Example: log level = 1 full_audit:1@/var/log/audit.log winbind:2

log nt token command (G)

This option can be set to a command that will be called when new nt tokens are created.
This is only useful for development purposes.
Default: log nt token command =

logon drive (G)

This parameter specifies the local path to which the home directory will be connected (see logon home) and is only used by NT Workstations.
Note that this option is only useful if Samba is set up as a logon server.
Default: logon drive =
Example: logon drive = h:

logon home (G)

This parameter specifies the home directory location when a Win95/98 or NT Workstation logs into a Samba PDC. It allows you to do
C:*NET USE H: /HOME*
from a command prompt, for example.
This option takes the standard substitutions, allowing you to have separate logon scripts for each user or machine.
This parameter can be used with Win9X workstations to ensure that roaming profiles are stored in a subdirectory of the users home directory. This is done in the following way:
logon home = %N\U\profile
This tells Samba to return the above string, with substitutions made when a client requests the info, generally in a NetUserGetInfo request. Win9X clients truncate the info to \server\share when a user does net use /home but use the whole string when dealing with profiles.
Note that in prior versions of Samba, the logon path was returned rather than logon home. This broke net use /home but allowed profiles outside the home directory. The current implementation is correct, and can be used for profiles if you use the above trick.
Disable this feature by setting logon home = “” - using the empty string.
This option is only useful if Samba is set up as a logon server.
Default: logon home = %N\U
Example: logon home = \remote_smb_server\U

logon path (G)

This parameter specifies the directory where roaming profiles (Desktop, NTuser.dat, etc) are stored. Contrary to previous versions of these manual pages, it has nothing to do with Win 9X roaming profiles. To find out how to handle roaming profiles for Win 9X system, see the logon home parameter.
This option takes the standard substitutions, allowing you to have separate logon scripts for each user or machine. It also specifies the directory from which the “Application Data”, desktop, start menu, network neighborhood, programs and other folders, and their contents, are loaded and displayed on your Windows NT client.
The share and the path must be readable by the user for the preferences and directories to be loaded onto the Windows NT client. The share must be writeable when the user logs in for the first time, in order that the Windows NT client can create the NTuser.dat and other directories. Thereafter, the directories and any of the contents can, if required, be made read-only. It is not advisable that the NTuser.dat file be made read-only - rename it to NTuser.man to achieve the desired effect (a MANdatory profile).
Windows clients can sometimes maintain a connection to the [homes] share, even though there is no user logged in. Therefore, it is vital that the logon path does not include a reference to the homes share (i.e. setting this parameter to %N\homes\profile_path will cause problems).
This option takes the standard substitutions, allowing you to have separate logon scripts for each user or machine.
Warning
Do not quote the value. Setting this as “%N\profile\U” will break profile handling. Where the tdbsam or ldapsam passdb backend is used, at the time the user account is created the value configured for this parameter is written to the passdb backend and that value will over-ride the parameter value present in the smb.conf file. Any error present in the passdb backend account record must be edited using the appropriate tool (pdbedit on the command-line, or any other locally provided system tool).
Note that this option is only useful if Samba is set up as a domain controller.
Disable the use of roaming profiles by setting the value of this parameter to the empty string. For example, logon path = “”. Take note that even if the default setting in the smb.conf file is the empty string, any value specified in the user account settings in the passdb backend will over-ride the effect of setting this parameter to null. Disabling of all roaming profile use requires that the user account settings must also be blank.
An example of use is:
logon path = \PROFILESERVER\PROFILE%U
Default: logon path = %N\U\profile

logon script (G)

This parameter specifies the batch file (.bat) or NT command file (.cmd) to be downloaded and run on a machine when a user successfully logs in. The file must contain the DOS style CR/LF line endings. Using a DOS-style editor to create the file is recommended.
The script must be a relative path to the [netlogon] service. If the [netlogon] service specifies a path of /usr/local/samba/netlogon, and logon script = STARTUP.BAT, then the file that will be downloaded is:
/usr/local/samba/netlogon/STARTUP.BAT
The contents of the batch file are entirely your choice. A suggested command would be to add NET TIME \SERVER /SET /YES, to force every machine to synchronize clocks with the same time server. Another use would be to add NET USE U: \SERVER\UTILS for commonly used utilities, or
NET USE Q: \SERVER\ISO9001_QA
for example.
Note that it is particularly important not to allow write access to the [netlogon] share, or to grant users write permission on the batch files in a secure environment, as this would allow the batch files to be arbitrarily modified and security to be breached.
This option takes the standard substitutions, allowing you to have separate logon scripts for each user or machine.
This option is only useful if Samba is set up as a logon server in a classic domain controller role. If Samba is set up as an Active Directory domain controller, LDAP attribute scriptPath is used instead. For configurations where passdb backend = ldapsam is in use, this option only defines a default value in case LDAP attribute sambaLogonScript is missing.
Default: logon script =
Example: logon script = scripts\U.bat

log writeable files on exit (G)

When the network connection between a CIFS client and Samba dies, Samba has no option but to simply shut down the server side of the network connection. If this happens, there is a risk of data corruption because the Windows client did not complete all write operations that the Windows application requested. Setting this option to “yes” makes smbd log with a level 0 message a list of all files that have been opened for writing when the network connection died. Those are the files that are potentially corrupted. It is meant as an aid for the administrator to give him a list of files to do consistency checks on.
Default: log writeable files on exit = no

lppause command (S)

This parameter specifies the command to be executed on the server host in order to stop printing or spooling a specific print job.
This command should be a program or script which takes a printer name and job number to pause the print job. One way of implementing this is by using job priorities, where jobs having a too low priority wont be sent to the printer.
If a %p is given then the printer name is put in its place. A %j is replaced with the job number (an integer). On HPUX (see printing=hpux ), if the -p%p option is added to the lpq command, the job will show up with the correct status, i.e. if the job priority is lower than the set fence priority it will have the PAUSED status, whereas if the priority is equal or higher it will have the SPOOLED or PRINTING status.
Note that it is good practice to include the absolute path in the lppause command as the PATH may not be available to the server.
Currently no default value is given to this string, unless the value of the printing parameter is SYSV, in which case the default is : lp -i %p-%j -H hold or if the value of the printing parameter is SOFTQ, then the default is: qstat -s -j%j -h.
Default: lppause command = # determined by printing parameter
Example: lppause command = /usr/bin/lpalt %p-%j -p0

lpq cache time (G)

This controls how long lpq info will be cached for to prevent the lpq command being called too often. A separate cache is kept for each variation of the lpq command used by the system, so if you use different lpq commands for different users then they wont share cache information.
The cache files are stored in /tmp/lpq.xxxx where xxxx is a hash of the lpq command in use.
The default is 30 seconds, meaning that the cached results of a previous identical lpq command will be used if the cached data is less than 30 seconds old. A large value may be advisable if your lpq command is very slow.
A value of 0 will disable caching completely.
Default: lpq cache time = 30
Example: lpq cache time = 10

lpq command (S)

This parameter specifies the command to be executed on the server host in order to obtain lpq-style printer status information.
This command should be a program or script which takes a printer name as its only parameter and outputs printer status information.
Currently nine styles of printer status information are supported; BSD, AIX, LPRNG, PLP, SYSV, HPUX, QNX, CUPS, and SOFTQ. This covers most UNIX systems. You control which type is expected using the printing = option.
Some clients (notably Windows for Workgroups) may not correctly send the connection number for the printer they are requesting status information about. To get around this, the server reports on the first printer service connected to by the client. This only happens if the connection number sent is invalid.
If a %p is given then the printer name is put in its place. Otherwise it is placed at the end of the command.
Note that it is good practice to include the absolute path in the lpq command as the $PATH may not be available to the server. When compiled with the CUPS libraries, no lpq command is needed because smbd will make a library call to obtain the print queue listing.
Default: lpq command = # determined by printing parameter
Example: lpq command = /usr/bin/lpq -P%p

lpresume command (S)

This parameter specifies the command to be executed on the server host in order to restart or continue printing or spooling a specific print job.
This command should be a program or script which takes a printer name and job number to resume the print job. See also the lppause command parameter.
If a %p is given then the printer name is put in its place. A %j is replaced with the job number (an integer).
Note that it is good practice to include the absolute path in the lpresume command as the PATH may not be available to the server.
See also the printing parameter.
Default: Currently no default value is given to this string, unless the value of the printing parameter is SYSV, in which case the default is:
lp -i %p-%j -H resume
or if the value of the printing parameter is SOFTQ, then the default is:
qstat -s -j%j -r
Default: lpresume command = # determined by printing parameter
Example: lpresume command = /usr/bin/lpalt %p-%j -p2

lprm command (S)

This parameter specifies the command to be executed on the server host in order to delete a print job.
This command should be a program or script which takes a printer name and job number, and deletes the print job.
If a %p is given then the printer name is put in its place. A %j is replaced with the job number (an integer).
Note that it is good practice to include the absolute path in the lprm command as the PATH may not be available to the server.
Examples of use are:
lprm command = /usr/bin/lprm -P%p %j
or

lprm command = /usr/bin/cancel %p-%j
Default: lprm command = # determined by printing parameter

lsa over netlogon (G)

Setting this deprecated option will allow the RPC server in the AD DC to answer the LSARPC interface on the \pipe etlogon IPC pipe.
When enabled, this matches the behaviour of Microsofts Windows, due to their internal implementation choices.
If it is disabled (the default), the AD DC can offer improved performance, as the netlogon server is decoupled and can run as multiple processes.
Default: lsa over netlogon = no

machine password timeout (G)

If a Samba server is a member of a Windows NT or Active Directory Domain (see the security = domain and security = ads parameters), then periodically a running winbindd process will try and change the MACHINE ACCOUNT PASSWORD stored in the TDB called secrets.tdb. This parameter specifies how often this password will be changed, in seconds. The default is one week (expressed in seconds), the same as a Windows NT Domain member server.
See also smbpasswd(8), and the security = domain and security = ads parameters.
Default: machine password timeout = 604800

magic output (S)

This parameter specifies the name of a file which will contain output created by a magic script (see the magic script parameter below).
Warning
If two clients use the same magic script in the same directory the output file content is undefined.
Default: magic output = # <magic script name>.out
Example: magic output = myfile.txt

magic script (S)

This parameter specifies the name of a file which, if opened, will be executed by the server when the file is closed. This allows a UNIX script to be sent to the Samba host and executed on behalf of the connected user.
Scripts executed in this way will be deleted upon completion assuming that the user has the appropriate level of privilege and the file permissions allow the deletion.
If the script generates output, output will be sent to the file specified by the magic output parameter (see above).
Note that some shells are unable to interpret scripts containing CR/LF instead of CR as the end-of-line marker. Magic scripts must be executable as is on the host, which for some hosts and some shells will require filtering at the DOS end.
Magic scripts are EXPERIMENTAL and should NOT be relied upon.
Default: magic script =
Example: magic script = user.csh

mangled names (S)

This controls whether non-DOS names under UNIX should be mapped to DOS-compatible names (“mangled”) and made visible, or whether non-DOS names should simply be ignored.
See the section on name mangling for details on how to control the mangling process.
Possible option settings are
·
yes - enables name mangling for all not DOS 8.3 conforming names.
·
no - disables any name mangling.
·
illegal (default) - does mangling for names with illegal NTFS characters. This is the most sensible setting for modern clients that dont use the shortname anymore.
If mangling is used then the mangling method is as follows:
·
The first (up to) five alphanumeric characters before the rightmost dot of the filename are preserved, forced to upper case, and appear as the first (up to) five characters of the mangled name.
·
A tilde “~” is appended to the first part of the mangled name, followed by a two-character unique sequence, based on the original root name (i.e., the original filename minus its final extension). The final extension is included in the hash calculation only if it contains any upper case characters or is longer than three characters.
Note that the character to use may be specified using the mangling char option, if you dont like ~.
·
Files whose UNIX name begins with a dot will be presented as DOS hidden files. The mangled name will be created as for other filenames, but with the leading dot removed and “___” as its extension regardless of actual original extension (thats three underscores).
The two-digit hash value consists of upper case alphanumeric characters.
This algorithm can cause name collisions only if files in a directory share the same first five alphanumeric characters. The probability of such a clash is 1/1300.
The name mangling (if enabled) allows a file to be copied between UNIX directories from Windows/DOS while retaining the long UNIX filename. UNIX files can be renamed to a new extension from Windows/DOS and will retain the same basename. Mangled names do not change between sessions.
Default: mangled names = illegal
Example: mangled names = no

mangle prefix (G)

controls the number of prefix characters from the original name used when generating the mangled names. A larger value will give a weaker hash and therefore more name collisions. The minimum value is 1 and the maximum value is 6.
mangle prefix is effective only when mangling method is hash2.
Default: mangle prefix = 1
Example: mangle prefix = 4

mangling char (S)

This controls what character is used as the magic character in name mangling. The default is a ~ but this may interfere with some software. Use this option to set it to whatever you prefer. This is effective only when mangling method is hash.
Default: mangling char = ~
Example: mangling char = ^

mangling method (G)

controls the algorithm used for the generating the mangled names. Can take two different values, “hash” and “hash2”. “hash” is the algorithm that was used in Samba for many years and was the default in Samba 2.2.x “hash2” is now the default and is newer and considered a better algorithm (generates less collisions) in the names. Many Win32 applications store the mangled names and so changing to algorithms must not be done lightly as these applications may break unless reinstalled.
Default: mangling method = hash2
Example: mangling method = hash

map acl inherit (S)

This boolean parameter is only relevant for systems that do not support standardized NFS4 ACLs but only a POSIX draft implementation of ACLs. Linux is the only common UNIX system which does still not offer standardized NFS4 ACLs actually. On such systems this parameter controls whether smbd(8) will attempt to map the protected (dont inherit) flags of the Windows ACLs into an extended attribute called user.SAMBA_PAI (POSIX draft ACL Inheritance). This parameter requires support for extended attributes on the filesystem and allows the Windows ACL editor to store (non-)inheritance information while NT ACLs are mapped best-effort to the POSIX draft ACLs that the OS and filesystem implements.
Default: map acl inherit = no

map archive (S)

This controls whether the DOS archive attribute should be mapped to the UNIX owner execute bit. The DOS archive bit is set when a file has been modified since its last backup. One motivation for this option is to keep Samba/your PC from making any file it touches from becoming executable under UNIX. This can be quite annoying for shared source code, documents, etc…
Note that this parameter will be ignored if the store dos attributes parameter is set, as the DOS archive attribute will then be stored inside a UNIX extended attribute.
Note that this requires the create mask parameter to be set such that owner execute bit is not masked out (i.e. it must include 100). See the parameter create mask for details.
Default: map archive = yes

map hidden (S)

This controls whether DOS style hidden files should be mapped to the UNIX world execute bit.
Note that this parameter will be ignored if the store dos attributes parameter is set, as the DOS hidden attribute will then be stored inside a UNIX extended attribute.
Note that this requires the create mask to be set such that the world execute bit is not masked out (i.e. it must include 001). See the parameter create mask for details.
Default: map hidden = no

map readonly (S)

This controls how the DOS read only attribute should be mapped from a UNIX filesystem.
This parameter can take three different values, which tell smbd(8) how to display the read only attribute on files, where either store dos attributes is set to No, or no extended attribute is present. If store dos attributes is set to yes then this parameter is ignored. This is a new parameter introduced in Samba version 3.0.21.
The three settings are :
·
Yes - The read only DOS attribute is mapped to the inverse of the user or owner write bit in the unix permission mode set. If the owner write bit is not set, the read only attribute is reported as being set on the file. If the read only DOS attribute is set, Samba sets the owner, group and others write bits to zero. Write bits set in an ACL are ignored by Samba. If the read only DOS attribute is unset, Samba simply sets the write bit of the owner to one.
·
Permissions - The read only DOS attribute is mapped to the effective permissions of the connecting user, as evaluated by smbd(8) by reading the unix permissions and filesystem ACL (if present). If the connecting user does not have permission to modify the file, the read only attribute is reported as being set on the file.
·
No - The read only DOS attribute is unaffected by permissions, and can only be set by the store dos attributes method. This may be useful for exporting mounted CDs.
Note that this parameter will be ignored if the store dos attributes parameter is set, as the DOS read-only attribute will then be stored inside a UNIX extended attribute.
The default has changed to no in Samba release 4.9.0 and above to allow better Windows fileserver compatibility in a default install. In addition the default setting of store dos attributes has been changed to Yes in Samba release 4.9.0 and above.
Default: map readonly = no

map system (S)

This controls whether DOS style system files should be mapped to the UNIX group execute bit.
Note that this parameter will be ignored if the store dos attributes parameter is set, as the DOS system attribute will then be stored inside a UNIX extended attribute.
Note that this requires the create mask to be set such that the group execute bit is not masked out (i.e. it must include 010). See the parameter create mask for details.
Default: map system = no

map to guest (G)

This parameter can take four different values, which tell smbd(8) what to do with user login requests that dont match a valid UNIX user in some way.
The four settings are :
·
Never - Means user login requests with an invalid password are rejected. This is the default.
·
Bad User - Means user logins with an invalid password are rejected, unless the username does not exist, in which case it is treated as a guest login and mapped into the guest account.
·
Bad Password - Means user logins with an invalid password are treated as a guest login and mapped into the guest account. Note that this can cause problems as it means that any user incorrectly typing their password will be silently logged on as “guest” - and will not know the reason they cannot access files they think they should - there will have been no message given to them that they got their password wrong. Helpdesk services will hate you if you set the map to guest parameter this way :-).
·
Bad Uid - Is only applicable when Samba is configured in some type of domain mode security (security = {domain|ads}) and means that user logins which are successfully authenticated but which have no valid Unix user account (and smbd is unable to create one) should be mapped to the defined guest account. This was the default behavior of Samba 2.x releases. Note that if a member server is running winbindd, this option should never be required because the nss_winbind library will export the Windows domain users and groups to the underlying OS via the Name Service Switch interface.
Note that this parameter is needed to set up “Guest” share services. This is because in these modes the name of the resource being requested is not sent to the server until after the server has successfully authenticated the client so the server cannot make authentication decisions at the correct time (connection to the share) for “Guest” shares.
Default: map to guest = Never
Example: map to guest = Bad User

max connections (S)

This option allows the number of simultaneous connections to a service to be limited. If max connections is greater than 0 then connections will be refused if this number of connections to the service are already open. A value of zero mean an unlimited number of connections may be made.
Record lock files are used to implement this feature. The lock files will be stored in the directory specified by the lock directory option.
Default: max connections = 0
Example: max connections = 10

max disk size (G)

This option allows you to put an upper limit on the apparent size of disks. If you set this option to 100 then all shares will appear to be not larger than 100 MB in size.
Note that this option does not limit the amount of data you can put on the disk. In the above case you could still store much more than 100 MB on the disk, but if a client ever asks for the amount of free disk space or the total disk size then the result will be bounded by the amount specified in max disk size.
This option is primarily useful to work around bugs in some pieces of software that cant handle very large disks, particularly disks over 1GB in size.
A max disk size of 0 means no limit.
Default: max disk size = 0
Example: max disk size = 1000

max log size (G)

This option (an integer in kilobytes) specifies the max size the log file should grow to. Samba periodically checks the size and if it is exceeded it will rename the file, adding a .old extension.
A size of 0 means no limit.
Default: max log size = 5000
Example: max log size = 1000

max mux (G)

This option controls the maximum number of outstanding simultaneous SMB operations that Samba tells the client it will allow. You should never need to set this parameter.
Default: max mux = 50

max open files (G)

This parameter limits the maximum number of open files that one smbd(8) file serving process may have open for a client at any one time. This parameter can be set very high (16384) as Samba uses only one bit per unopened file. Setting this parameter lower than 16384 will cause Samba to complain and set this value back to the minimum of 16384, as Windows 7 depends on this number of open file handles being available.
The limit of the number of open files is usually set by the UNIX per-process file descriptor limit rather than this parameter so you should never need to touch this parameter.
Default: max open files = 16384

max print jobs (S)

This parameter limits the maximum number of jobs allowable in a Samba printer queue at any given moment. If this number is exceeded, smbd(8) will remote “Out of Space” to the client.
Default: max print jobs = 1000
Example: max print jobs = 5000

max reported print jobs (S)

This parameter limits the maximum number of jobs displayed in a port monitor for Samba printer queue at any given moment. If this number is exceeded, the excess jobs will not be shown. A value of zero means there is no limit on the number of print jobs reported.
Default: max reported print jobs = 0
Example: max reported print jobs = 1000

max smbd processes (G)

This parameter limits the maximum number of smbd(8) processes concurrently running on a system and is intended as a stopgap to prevent degrading service to clients in the event that the server has insufficient resources to handle more than this number of connections. Remember that under normal operating conditions, each user will have an smbd(8) associated with him or her to handle connections to all shares from a given host.
For a Samba ADDC running the standard process model this option limits the number of processes forked to handle requests. Currently new processes are only forked for ldap and netlogon requests.
Default: max smbd processes = 0
Example: max smbd processes = 1000

max stat cache size (G)

This parameter limits the size in memory of any stat cache being used to speed up case insensitive name mappings. It represents the number of kilobyte (1024) units the stat cache can use. A value of zero, meaning unlimited, is not advisable due to increased memory usage. You should not need to change this parameter.
Default: max stat cache size = 512
Example: max stat cache size = 100

max ttl (G)

This option tells nmbd(8) what the default time to live of NetBIOS names should be (in seconds) when nmbd is requesting a name using either a broadcast packet or from a WINS server. You should never need to change this parameter. The default is 3 days.
Default: max ttl = 259200

max wins ttl (G)

This option tells smbd(8) when acting as a WINS server (wins support = yes) what the maximum time to live of NetBIOS names that nmbd will grant will be (in seconds). You should never need to change this parameter. The default is 6 days (518400 seconds).
Default: max wins ttl = 518400

max xmit (G)

This option controls the maximum packet size that will be negotiated by Sambas smbd(8) for the SMB1 protocol. The default is 16644, which matches the behavior of Windows 2000. A value below 2048 is likely to cause problems. You should never need to change this parameter from its default value.
Default: max xmit = 16644
Example: max xmit = 8192

mdns name (G)

This parameter controls the name that multicast DNS support advertises as its hostname.
The default is to use the NETBIOS name which is typically the hostname in all capital letters.
A setting of mdns will defer the hostname configuration to the MDNS library that is used.
Default: mdns name = netbios

message command (G)

This specifies what command to run when the server receives a WinPopup style message.
This would normally be a command that would deliver the message somehow. How this is to be done is up to your imagination.
An example is:
message command = csh -c xedit %s;rm %s &
This delivers the message using xedit, then removes it afterwards. NOTE THAT IT IS VERY IMPORTANT THAT THIS COMMAND RETURN IMMEDIATELY. Thats why I have the & on the end. If it doesnt return immediately then your PCs may freeze when sending messages (they should recover after 30 seconds, hopefully).
All messages are delivered as the global guest user. The command takes the standard substitutions, although %u wont work (%U may be better in this case).
Apart from the standard substitutions, some additional ones apply. In particular:
·
%s = the filename containing the message.
·
%t = the destination that the message was sent to (probably the server name).
·
%f = who the message is from.
You could make this command send mail, or whatever else takes your fancy. Please let us know of any really interesting ideas you have.
Heres a way of sending the messages as mail to root:
message command = /bin/mail -s message from %f on %m root < %s; rm %s
If you dont have a message command then the message wont be delivered and Samba will tell the sender there was an error. Unfortunately WfWg totally ignores the error code and carries on regardless, saying that the message was delivered.
If you want to silently delete it then try:
message command = rm %s
Default: message command =
Example: message command = csh -c xedit %s; rm %s &

min domain uid (G)

The integer parameter specifies the minimum uid allowed when mapping a local account to a domain account.
Note that this option interacts with the configured idmap ranges!
Default: min domain uid = 1000

min print space (S)

This sets the minimum amount of free disk space that must be available before a user will be able to spool a print job. It is specified in kilobytes. The default is 0, which means a user can always spool a print job.
Default: min print space = 0
Example: min print space = 2000

min receivefile size (G)

This option changes the behavior of smbd(8) when processing SMBwriteX calls. Any incoming SMBwriteX call on a non-signed SMB/CIFS connection greater than this value will not be processed in the normal way but will be passed to any underlying kernel recvfile or splice system call (if there is no such call Samba will emulate in user space). This allows zero-copy writes directly from network socket buffers into the filesystem buffer cache, if available. It may improve performance but user testing is recommended. If set to zero Samba processes SMBwriteX calls in the normal way. To enable POSIX large write support (SMB/CIFS writes up to 16Mb) this option must be nonzero. The maximum value is 128k. Values greater than 128k will be silently set to 128k.
Note this option will have NO EFFECT if set on a SMB signed connection.
The default is zero, which disables this option.
Default: min receivefile size = 0

min wins ttl (G)

This option tells nmbd(8) when acting as a WINS server (wins support = yes) what the minimum time to live of NetBIOS names that nmbd will grant will be (in seconds). You should never need to change this parameter. The default is 6 hours (21600 seconds).
Default: min wins ttl = 21600

mit kdc command (G)

This option specifies the path to the MIT kdc binary.
If the KDC is not installed in the default location and wasnt correctly detected during build then you should modify this variable and point it to the correct binary.
Default: mit kdc command =
Example: mit kdc command = /opt/mit/sbin/krb5kdc

msdfs proxy (S)

This parameter indicates that the share is a stand-in for another CIFS share whose location is specified by the value of the parameter. When clients attempt to connect to this share, they are redirected to one or multiple, comma separated proxied shares using the SMB-Dfs protocol.
Only Dfs roots can act as proxy shares. Take a look at the msdfs root and host msdfs options to find out how to set up a Dfs root share.
No default
Example: msdfs proxy = \otherserver\someshare,\otherserver2\someshare

msdfs root (S)

If set to yes, Samba treats the share as a Dfs root and allows clients to browse the distributed file system tree rooted at the share directory. Dfs links are specified in the share directory by symbolic links of the form msdfs:serverA\shareA,serverB\shareB and so on. For more information on setting up a Dfs tree on Samba, refer to the MSDFS chapter in the Samba3-HOWTO book.
Default: msdfs root = no

msdfs shuffle referrals (S)

If set to yes, Samba will shuffle Dfs referrals for a given Dfs link if multiple are available, allowing for load balancing across clients. For more information on setting up a Dfs tree on Samba, refer to the MSDFS chapter in the Samba3-HOWTO book.
Default: msdfs shuffle referrals = no

multicast dns register (G)

If compiled with proper support for it, Samba will announce itself with multicast DNS services like for example provided by the Avahi daemon.
This parameter allows disabling Samba to register itself.
Default: multicast dns register = yes

name cache timeout (G)

Specifies the number of seconds it takes before entries in sambas hostname resolve cache time out. If the timeout is set to 0. the caching is disabled.
Default: name cache timeout = 660
Example: name cache timeout = 0

name resolve order (G)

This option is used by the programs in the Samba suite to determine what naming services to use and in what order to resolve host names to IP addresses. Its main purpose to is to control how netbios name resolution is performed. The option takes a space separated string of name resolution options.
The options are: “lmhosts”, “host”, “wins” and “bcast”. They cause names to be resolved as follows:
·
lmhosts : Lookup an IP address in the Samba lmhosts file. If the line in lmhosts has no name type attached to the NetBIOS name (see the manpage for lmhosts for details) then any name type matches for lookup.
·
host : Do a standard host name to IP address resolution, using the system /etc/hosts or DNS lookups. This method of name resolution is operating system depended for instance on IRIX or Solaris this may be controlled by the /etc/nsswitch.conf file. Note that this method is used only if the NetBIOS name type being queried is the 0x20 (server) name type or 0x1c (domain controllers). The latter case is only useful for active directory domains and results in a DNS query for the SRV RR entry matching _ldap._tcp.domain.
·
wins : Query a name with the IP address listed in the WINSSERVER parameter. If no WINS server has been specified this method will be ignored.
·
bcast : Do a broadcast on each of the known local interfaces listed in the interfaces parameter. This is the least reliable of the name resolution methods as it depends on the target host being on a locally connected subnet.
The example below will cause the local lmhosts file to be examined first, followed by a broadcast attempt, followed by a normal system hostname lookup.
When Samba is functioning in ADS security mode (security = ads) it is advised to use following settings for name resolve order:
name resolve order = wins bcast
DC lookups will still be done via DNS, but fallbacks to netbios names will not inundate your DNS servers with needless queries for DOMAIN<0x1c> lookups.
Default: name resolve order = lmhosts wins host bcast
Example: name resolve order = lmhosts bcast host

socket address

This parameter is a synonym for nbt client socket address.

nbt client socket address (G)

This option allows you to control what address Samba will send NBT client packets from, and process replies using, including in nmbd.
Setting this option should never be necessary on usual Samba servers running only one nmbd.
By default Samba will send UDP packets from the OS default address for the destination, and accept replies on 0.0.0.0.
This parameter is deprecated. See bind interfaces only = Yes and interfaces for the previous behaviour of controlling the normal listening sockets.
Default: nbt client socket address = 0.0.0.0
Example: nbt client socket address = 192.168.2.20

nbtd:wins_prepend1Bto1Cqueries (G)

Normally queries for 0x1C names (all logon servers for a domain) will return the first address of the 0x1B names (domain master browser and PDC) as first address in the result list. As many client only use the first address in the list by default, all clients will use the same server (the PDC). Windows servers have an option to disable this behavior (since Windows 2000 Service Pack 2).
Default: nbtd:wins_prepend1Bto1Cqueries = yes

nbtd:wins_wins_randomize1Clist (G)

Normally queries for 0x1C names will return the addresses in the same order as theyre stored in the database, that means first all addresses which have been directly registered at the local wins server and then all addresses registered at other servers. Windows servers have an option to change this behavior and randomize the returned addresses. Set this parameter to “yes” and Samba will sort the address list depending on the client address and the matching bits of the addresses, the first address is randomized based on depending on the “nbtd:wins_randomize1Clist_mask” parameter.
Default: nbtd:wins_wins_randomize1Clist = no

nbtd:wins_randomize1Clist_mask (G)

If the “nbtd:wins_randomize1Clist” parameter is set to “yes”, then randomizing of the first returned address is based on the specified netmask. If there are addresses which are in the same subnet as the client address, the first returned address is randomly chosen out them. Otherwise the first returned address is randomly chosen out of all addresses.
Default: nbtd:wins_randomize1Clist_mask = 255.255.255.0

nbt port (G)

Specifies which port the server should use for NetBIOS over IP name services traffic.
Default: nbt port = 137

ncalrpc dir (G)

This directory will hold a series of named pipes to allow RPC over inter-process communication.
This will allow Samba and other unix processes to interact over DCE/RPC without using TCP/IP. Additionally a sub-directory np has restricted permissions, and allows a trusted communication channel between Samba processes
Default: ncalrpc dir = /run/samba/ncalrpc
Example: ncalrpc dir = /var/run/samba/ncalrpc

netbios aliases (G)

This is a list of NetBIOS names that nmbd will advertise as additional names by which the Samba server is known. This allows one machine to appear in browse lists under multiple names. If a machine is acting as a browse server or logon server none of these names will be advertised as either browse server or logon servers, only the primary name of the machine will be advertised with these capabilities.
Default: netbios aliases = # empty string (no additional names)
Example: netbios aliases = TEST TEST1 TEST2

netbios name (G)

This sets the NetBIOS name by which a Samba server is known. By default it is the same as the first component of the hosts DNS name. If a machine is a browse server or logon server this name (or the first component of the hosts DNS name) will be the name that these services are advertised under.
Note that the maximum length for a NetBIOS name is 15 characters.
There is a bug in Samba that breaks operation of browsing and access to shares if the netbios name is set to the literal name PIPE. To avoid this problem, do not name your Samba server PIPE.
Default: netbios name = # machine DNS name
Example: netbios name = MYNAME

netbios scope (G)

This sets the NetBIOS scope that Samba will operate under. This should not be set unless every machine on your LAN also sets this value.
Default: netbios scope =

neutralize nt4 emulation (G)

This option controls whether winbindd sends the NETLOGON_NEG_NEUTRALIZE_NT4_EMULATION flag in order to bypass the NT4 emulation of a domain controller.
Typically you should not need set this. It can be useful for upgrades from NT4 to AD domains.
The behavior can be controlled per netbios domain by using neutralize nt4 emulation:NETBIOSDOMAIN = yes as option.
Default: neutralize nt4 emulation = no

nmbd bind explicit broadcast (G)

This option causes nmbd(8) to explicitly bind to the broadcast address of the local subnets. This is needed to make nmbd work correctly in combination with the socket address option. You should not need to unset this option.
Default: nmbd bind explicit broadcast = yes

nsupdate command (G)

This option sets the path to the nsupdate command which is used for GSS-TSIG dynamic DNS updates.
Default: nsupdate command = /usr/bin/nsupdate -g

nt hash store (G)

This parameter determines whether or not samba(8) will, as an AD DC, attempt to store the NT password hash used in NTLM and NTLMv2 authentication for users in this domain.
If so configured, the Samba Active Directory Domain Controller, will, except for trust accounts (computers, domain controllers and inter-domain trusts) the NOT store the NT hash for new and changed accounts in the sam.ldb database.
This avoids the storage of an unsalted hash for these user-created passwords. As a consequence the arcfour-hmac-md5 Kerberos key type is also unavailable in the KDC for these users - thankfully modern clients will select an AES based key instead.
NOTE: As the password history in Active Directory is stored as an NT hash (and thus unavailable), a workaround is used, relying instead on Kerberos password hash values. This stores three passwords, the current, previous and second previous password. This allows some checking against reuse.
However as these values are salted, changing the sAMAccountName, userAccountControl or userPrincipalName of an account will cause the salt to change. After the rare combination of both a rename and a password change only the current password will be recognised for password history purposes.
The available settings are:
·
always - Always store the NT hash (as machine accounts will also always store an NT hash, a hash will be stored for all accounts).
This setting may be useful if ntlm auth is set to disabled for a trial period
·
never - Never store the NT hash for user accounts, only for machine accounts
·
auto - Store an NT hash if ntlm auth is not set to disabled.
Default: nt hash store = always

nt acl support (S)

This boolean parameter controls whether smbd(8) will attempt to map UNIX permissions into Windows NT access control lists. The UNIX permissions considered are the traditional UNIX owner and group permissions, as well as filesystem ACLs set on any files or directories. This parameter was formally a global parameter in releases prior to 2.2.2.
Default: nt acl support = yes

ntlm auth (G)

This parameter determines whether or not smbd(8) will attempt to authenticate users using the NTLM encrypted password response for this local passdb (SAM or account database).
If disabled, both NTLM and LanMan authentication against the local passdb is disabled.
Note that these settings apply only to local users, authentication will still be forwarded to and NTLM authentication accepted against any domain we are joined to, and any trusted domain, even if disabled or if NTLMv2-only is enforced here. To control NTLM authentication for domain users, this option must be configured on each DC.
By default with ntlm auth set to ntlmv2-only only NTLMv2 logins will be permitted. All modern clients support NTLMv2 by default, but some older clients will require special configuration to use it.
The primary user of NTLMv1 is MSCHAPv2 for VPNs and 802.1x.
The available settings are:
·
ntlmv1-permitted (alias yes) - Allow NTLMv1 and above for all clients.
This is the required setting to enable the lanman auth parameter.
·
ntlmv2-only (alias no) - Do not allow NTLMv1 to be used, but permit NTLMv2.
·
mschapv2-and-ntlmv2-only - Only allow NTLMv1 when the client promises that it is providing MSCHAPv2 authentication (such as the ntlm_auth tool).
·
disabled - Do not accept NTLM (or LanMan) authentication of any level, nor permit NTLM password changes.
WARNING: Both Microsoft Windows and Samba Read Only Domain Controllers (RODCs) convert a plain-text LDAP Simple Bind into an NTLMv2 authentication to forward to a full DC. Setting this option to disabled will cause these forwarded authentications to fail.
Additionally, for Samba acting as an Active Directory Domain Controller, for user accounts, if nt hash store is set to the default setting of auto, the NT hash will not be stored in the sam.ldb database for new users and after a password change.
The default changed from yes to no with Samba 4.5. The default changed again to ntlmv2-only with Samba 4.7, however the behaviour is unchanged.
Default: ntlm auth = ntlmv2-only

nt pipe support (G)

This boolean parameter controls whether smbd(8) will allow Windows NT clients to connect to the NT SMB specific IPC$ pipes. This is a developer debugging option and can be left alone.
Default: nt pipe support = yes

ntp signd socket directory (G)

This setting controls the location of the socket that the NTP daemon uses to communicate with Samba for signing packets.
If a non-default path is specified here, then it is also necessary to make NTP aware of the new path using the ntpsigndsocket directive in ntp.conf.
Default: ntp signd socket directory = /var/lib/samba/ntp_signd

nt status support (G)

This boolean parameter controls whether smbd(8) will negotiate NT specific status support with Windows NT/2k/XP clients. This is a developer debugging option and should be left alone. If this option is set to no then Samba offers exactly the same DOS error codes that versions prior to Samba 2.2.3 reported.
You should not need to ever disable this parameter.
Default: nt status support = yes

ntvfs handler (S)

This specifies the NTVFS handlers for this share.
·
unixuid: Sets up user credentials based on POSIX gid/uid.
·
cifs: Proxies a remote CIFS FS. Mainly useful for testing.
·
nbench: Filter module that saves data useful to the nbench benchmark suite.
·
ipc: Allows using SMB for inter process communication. Only used for the IPC$ share.
·
posix: Maps POSIX FS semantics to NT semantics
·
print: Allows printing over SMB. This is LANMAN-style printing, not the be confused with the spoolss DCE/RPC interface used by later versions of Windows.
Note that this option is only used when the NTVFS file server is in use. It is not used with the (default) s3fs file server.
Default: ntvfs handler = unixuid, default

null passwords (G)

Allow or disallow client access to accounts that have null passwords.
See also smbpasswd(5).
Default: null passwords = no

obey pam restrictions (G)

When Samba 3.0 is configured to enable PAM support (i.e. –with-pam), this parameter will control whether or not Samba should obey PAMs account and session management directives. The default behavior is to use PAM for clear text authentication only and to ignore any account or session management. Note that Samba always ignores PAM for authentication in the case of encrypt passwords = yes. The reason is that PAM modules cannot support the challenge/response authentication mechanism needed in the presence of SMB password encryption.
Default: obey pam restrictions = no

old password allowed period (G)

Number of minutes to permit an NTLM login after a password change or reset using the old password. This allows the user to re-cache the new password on multiple clients without disrupting a network reconnection in the meantime.
This parameter only applies when server role is set to Active Directory Domain Controller.
Default: old password allowed period = 60

oplock break wait time (G)

This is a tuning parameter added due to bugs in both Windows 9x and WinNT. If Samba responds to a client too quickly when that client issues an SMB that can cause an oplock break request, then the network client can fail and not respond to the break request. This tuning parameter (which is set in milliseconds) is the amount of time Samba will wait before sending an oplock break request to such (broken) clients.
Warning
DO NOT CHANGE THIS PARAMETER UNLESS YOU HAVE READ AND UNDERSTOOD THE SAMBA OPLOCK CODE.
Default: oplock break wait time = 0

oplocks (S)

This boolean option tells smbd whether to issue oplocks (opportunistic locks) to file open requests on this share. The oplock code can dramatically (approx. 30% or more) improve the speed of access to files on Samba servers. It allows the clients to aggressively cache files locally and you may want to disable this option for unreliable network environments (it is turned on by default in Windows NT Servers).
Oplocks may be selectively turned off on certain files with a share. See the veto oplock files parameter. On some systems oplocks are recognized by the underlying operating system. This allows data synchronization between all access to oplocked files, whether it be via Samba or NFS or a local UNIX process. See the kernel oplocks parameter for details.
Default: oplocks = yes

os2 driver map (G)

The parameter is used to define the absolute path to a file containing a mapping of Windows NT printer driver names to OS/2 printer driver names. The format is:
<nt driver name> = <os2 driver name>.<device name>
For example, a valid entry using the HP LaserJet 5 printer driver would appear as HP LaserJet 5L = LASERJET.HP LaserJet 5L.
The need for the file is due to the printer driver namespace problem described in the chapter on Classical Printing in the Samba3-HOWTO book. For more details on OS/2 clients, please refer to chapter on other clients in the Samba3-HOWTO book.
Default: os2 driver map =

os level (G)

This integer value controls what level Samba advertises itself as for browse elections. The value of this parameter determines whether nmbd(8) has a chance of becoming a local master browser for the workgroup in the local broadcast area.
Note: By default, Samba will win a local master browsing election over all Microsoft operating systems except a Windows NT 4.0/2000 Domain Controller. This means that a misconfigured Samba host can effectively isolate a subnet for browsing purposes. This parameter is largely auto-configured in the Samba-3 release series and it is seldom necessary to manually override the default setting. Please refer to the chapter on Network Browsing in the Samba-3 HOWTO document for further information regarding the use of this parameter. Note: The maximum value for this parameter is 255. If you use higher values, counting will start at 0!
Default: os level = 20
Example: os level = 65

pam password change (G)

With the addition of better PAM support in Samba 2.2, this parameter, it is possible to use PAMs password change control flag for Samba. If enabled, then PAM will be used for password changes when requested by an SMB client instead of the program listed in passwd program. It should be possible to enable this without changing your passwd chat parameter for most setups.
Default: pam password change = no

panic action (G)

This is a Samba developer option that allows a system command to be called when either smbd(8) or nmbd(8) crashes. This is usually used to draw attention to the fact that a problem occurred.
Default: panic action =
Example: panic action = /bin/sleep 90000

passdb backend (G)

This option allows the administrator to chose which backend will be used for storing user and possibly group information. This allows you to swap between different storage mechanisms without recompile.
The parameter value is divided into two parts, the backends name, and a location string that has meaning only to that particular backed. These are separated by a : character.
Available backends can include:
·
smbpasswd - The old plaintext passdb backend. Some Samba features will not work if this passdb backend is used. Takes a path to the smbpasswd file as an optional argument.
·
tdbsam - The TDB based password storage backend. Takes a path to the TDB as an optional argument (defaults to passdb.tdb in the private dir directory.
·
ldapsam - The LDAP based passdb backend. Takes an LDAP URL as an optional argument (defaults to ldap://localhost)
LDAP connections should be secured where possible. This may be done using either Start-TLS (see ldap ssl) or by specifying ldaps:// in the URL argument.
Multiple servers may also be specified in double-quotes. Whether multiple servers are supported or not and the exact syntax depends on the LDAP library you use.
Examples of use are:
passdb backend = tdbsam:/etc/samba/private/passdb.tdb
or multi server LDAP URL with OpenLDAP library:

passdb backend = ldapsam:"ldap://ldap-1.example.com ldap://ldap-2.example.com"

or multi server LDAP URL with Netscape based LDAP library:

passdb backend = ldapsam:"ldap://ldap-1.example.com ldap-2.example.com"
Default: passdb backend = tdbsam

passdb expand explicit (G)

This parameter controls whether Samba substitutes %-macros in the passdb fields if they are explicitly set. We used to expand macros here, but this turned out to be a bug because the Windows client can expand a variable %G_osver% in which %G would have been substituted by the users primary group.
Default: passdb expand explicit = no

passwd chat (G)

This string controls the “chat” conversation that takes places between smbd(8) and the local password changing program to change the users password. The string describes a sequence of response-receive pairs that smbd(8) uses to determine what to send to the passwd program and what to expect back. If the expected output is not received then the password is not changed.
This chat sequence is often quite site specific, depending on what local methods are used for password control.
Note that this parameter only is used if the unix password sync parameter is set to yes. This sequence is then called AS ROOT when the SMB password in the smbpasswd file is being changed, without access to the old password cleartext. This means that root must be able to reset the users password without knowing the text of the previous password.
The string can contain the macro %n which is substituted for the new password. The old password (%o) is only available when encrypt passwords has been disabled. The chat sequence can also contain the standard macros , , and \s to give line-feed, carriage-return, tab and space. The chat sequence string can also contain a * which matches any sequence of characters. Double quotes can be used to collect strings with spaces in them into a single string.
If the send string in any part of the chat sequence is a full stop “.”, then no string is sent. Similarly, if the expect string is a full stop then no string is expected.
If the pam password change parameter is set to yes, the chat pairs may be matched in any order, and success is determined by the PAM result, not any particular output. The macro is ignored for PAM conversions.
Default: passwd chat = *new*password* %n *new*password* %n *changed*
Example: passwd chat = "*Enter NEW password*" %n “*Reenter NEW password*” %n “*Password changed*”

passwd chat debug (G)

This boolean specifies if the passwd chat script parameter is run in debug mode. In this mode the strings passed to and received from the passwd chat are printed in the smbd(8) log with a debug level of 100. This is a dangerous option as it will allow plaintext passwords to be seen in the smbd log. It is available to help Samba admins debug their passwd chat scripts when calling the passwd program and should be turned off after this has been done. This option has no effect if the pam password change parameter is set. This parameter is off by default.
Default: passwd chat debug = no

passwd chat timeout (G)

This integer specifies the number of seconds smbd will wait for an initial answer from a passwd chat script being run. Once the initial answer is received the subsequent answers must be received in one tenth of this time. The default it two seconds.
Default: passwd chat timeout = 2

passwd program (G)

The name of a program that can be used to set UNIX user passwords. Any occurrences of %u will be replaced with the user name. The user name is checked for existence before calling the password changing program.
Also note that many passwd programs insist in reasonable passwords, such as a minimum length, or the inclusion of mixed case chars and digits. This can pose a problem as some clients (such as Windows for Workgroups) uppercase the password before sending it.
Note that if the unix password sync parameter is set to yes then this program is called AS ROOT before the SMB password in the smbpasswd file is changed. If this UNIX password change fails, then smbd will fail to change the SMB password also (this is by design).
If the unix password sync parameter is set this parameter MUST USE ABSOLUTE PATHS for ALL programs called, and must be examined for security implications. Note that by default unix password sync is set to no.
Default: passwd program =
Example: passwd program = /bin/passwd %u

password hash gpg key ids (G)

If samba is running as an active directory domain controller, it is possible to store the cleartext password of accounts in a PGP/OpenGPG encrypted form.
You can specify one or more recipients by key id or user id. Note that 32bit key ids are not allowed, specify at least 64bit.
The value is stored as Primary:SambaGPG in the supplementalCredentials attribute.
As password changes can occur on any domain controller, you should configure this on each of them. Note that this feature is currently available only on Samba domain controllers.
This option is only available if samba was compiled with gpgme support.
You may need to export the GNUPGHOME environment variable before starting samba. It is strongly recommended to only store the public key in this location. The private key is not used for encryption and should be only stored where decryption is required.
Being able to restore the cleartext password helps, when they need to be imported into other authentication systems later (see samba-tool user getpassword) or you want to keep the passwords in sync with another system, e.g. an OpenLDAP server (see samba-tool user syncpasswords).
While this option needs to be configured on all domain controllers, the samba-tool user syncpasswords command should run on a single domain controller only (typically the PDC-emulator).
Default: password hash gpg key ids =
Example: password hash gpg key ids = 4952E40301FAB41A
Example: password hash gpg key ids = [email protected]
Example: password hash gpg key ids = [email protected], 4952E40301FAB41A

password hash userPassword schemes (G)

This parameter determines whether or not samba(8) acting as an Active Directory Domain Controller will attempt to store additional passwords hash types for the user
The values are stored as Primary:userPassword in the supplementalCredentials attribute. The value of this option is a hash type.
The currently supported hash types are:
·
CryptSHA256
·
CryptSHA512
Multiple instances of a hash type may be computed and stored. The password hashes are calculated using the crypt(3) call. The number of rounds used to compute the hash can be specified by adding :rounds=xxxx to the hash type, i.e. CryptSHA512:rounds=4500 would calculate an SHA512 hash using 4500 rounds. If not specified the Operating System defaults for crypt(3) are used.
As password changes can occur on any domain controller, you should configure this on each of them. Note that this feature is currently available only on Samba domain controllers.
Currently the NT Hash of the password is recorded when these hashes are calculated and stored. When retrieving the hashes the current value of the NT Hash is checked against the stored NT Hash. This detects password changes that have not updated the password hashes. In this case samba-tool user will ignore the stored hash values.
Being able to obtain the hashed password helps, when they need to be imported into other authentication systems later (see samba-tool user getpassword) or you want to keep the passwords in sync with another system, e.g. an OpenLDAP server (see samba-tool user syncpasswords).
Related command: unix password sync
Default: password hash userPassword schemes =
Example: password hash userPassword schemes = CryptSHA256
Example: password hash userPassword schemes = CryptSHA256 CryptSHA512
Example: password hash userPassword schemes = CryptSHA256:rounds=5000 CryptSHA512:rounds=7000

password server (G)

By specifying the name of a domain controller with this option, and using security = [ads|domain] it is possible to get Samba to do all its username/password validation using a specific remote server.
Ideally, this option should not be used, as the default * indicates to Samba to determine the best DC to contact dynamically, just as all other hosts in an AD domain do. This allows the domain to be maintained (addition and removal of domain controllers) without modification to the smb.conf file. The cryptographic protection on the authenticated RPC calls used to verify passwords ensures that this default is safe.
It is strongly recommended that you use the default of *, however if in your particular environment you have reason to specify a particular DC list, then the list of machines in this option must be a list of names or IP addresses of Domain controllers for the Domain. If you use the default of *, or list several hosts in the password server option then smbd will try each in turn till it finds one that responds. This is useful in case your primary server goes down.
If the list of servers contains both names/IPs and the * character, the list is treated as a list of preferred domain controllers, but an auto lookup of all remaining DCs will be added to the list as well. Samba will not attempt to optimize this list by locating the closest DC.
If parameter is a name, it is looked up using the parameter name resolve order and so may resolved by any method and order described in that parameter.
Default: password server = *
Example: password server = NT-PDC, NT-BDC1, NT-BDC2, *
Example: password server = windc.mydomain.com:389 192.168.1.101 *

WARNINGS

Although the configuration file permits service names to contain spaces, your client software may not. Spaces will be ignored in comparisons anyway, so it shouldnt be a problem - but be aware of the possibility.

On a similar note, many clients - especially DOS clients - limit service names to eight characters. smbd(8) has no such limitation, but attempts to connect from such clients will fail if they truncate the service names. For this reason you should probably keep your service names down to eight characters in length.

Use of the [homes] and [printers] special sections make life for an administrator easy, but the various combinations of default attributes can be tricky. Take extreme care when designing these sections. In particular, ensure that the permissions on spool directories are correct.

VERSION

This man page is part of version 4.20.1-Debian of the Samba suite.

AUTHOR

The original Samba software and related utilities were created by Andrew Tridgell. Samba is now developed by the Samba Team as an Open Source project similar to the way the Linux kernel is developed.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

336 - Linux cli command deb-shlibs

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command deb-shlibs and provides detailed information about the command deb-shlibs, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the deb-shlibs.

NAME 🖥️ deb-shlibs 🖥️

shlibs - Debian shared library information file

SYNOPSIS

debian/shlibs, debian/binary-name.shlibs, DEBIAN/shlibs

DESCRIPTION

shlibs files map shared library names and versions (SONAMEs) to dependencies suitable for a package control file. There is one entry per line. Blank lines are not allowed. Lines beginning with a # character are considered commentary, and are ignored. All other lines must have the format:

[type**:**] library version dependencies

The library and version fields are whitespace-delimited, but the dependencies field extends to the end of the line. The type field is optional and normally not needed.

The dependencies field has the same syntax as the Depends field in a binary control file, see deb-control (5).

SONAME FORMATS

The SONAME formats supported are:

name.so.version

and

name-version.so

where name is usually prefixed by lib.

The former tends to be used by shared libraries with stable interfaces. The latter by shared libraries with unstable interfaces, where the whole version becomes part of the SONAME and needs to be specified in full when linking against those libraries.

EXAMPLES

The shlibs file for a typical library package, named libcrunch1, that provides one library whose SONAME is libcrunch.so.1, might read libcrunch 1 libcrunch1 (>= 1.2-1)

The dependencies must mention the most recent version of the package that added new symbols to the library: in the above example, new symbols were added to version 1.2 of libcrunch. This is not the only reason the dependencies might need to be tightened.

337 - Linux cli command sudoers

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command sudoers and provides detailed information about the command sudoers, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the sudoers.

The

policy plugin determines a user’s

privileges. It is the default

policy plugin. The policy is driven by the

file or, optionally, in LDAP. The policy format is described in detail in the

section. For information on storing

policy information in LDAP, see

consults the

file to determine which plugins to load. If no

file is present, or if it contains no

lines,

will be used for auditing, policy decisions and I/O logging. To explicitly configure

to use the

plugin, the following configuration can be used.

Plugin sudoers_audit sudoers.so Plugin sudoers_policy sudoers.so Plugin sudoers_io sudoers.so

Starting with

1.8.5, it is possible to specify optional arguments to the

plugin in the

file. Plugin arguments, if any, should be listed after the path to the plugin (i.e., after

The arguments are only effective for the plugin that opens (and parses) the

file.

For

version 1.9.1 and higher, this is the

plugin. For older versions, it is the

plugin. Multiple arguments may be specified, separated by white space. For example:

Plugin sudoers_audit sudoers.so sudoers_mode=0400 error_recovery=false

The following plugin arguments are supported:

The

argument can be used to control whether

should attempt to recover from syntax errors in the

file. If set to

(the default),

will try to recover from a syntax error by discarding the portion of the line that contains the error until the end of the line. A value of

will disable error recovery. Prior to version 1.9.3, no error recovery was performed.

The

argument can be used to disable security checks when loading the

file. If enabled, the

file will be loaded regardless of the owner or file mode. This argument is intended to be used for testing purposes and should not be enabled on production systems.

The

argument can be used to override the default path to the

file.

The

argument can be used to override the default path to the

file.

The

argument can be used to override the default path to the

file.

The

argument can be used to override the default owner of the sudoers file. It should be specified as a numeric user-ID.

The

argument can be used to override the default group of the sudoers file. It must be specified as a numeric group-ID (not a group name).

The

argument can be used to override the default file mode for the sudoers file. It should be specified as an octal value.

For more information on configuring

refer to its manual.

The

security policy requires that most users authenticate themselves before they can use

A password is not required if the invoking user is

if the target user is the same as the invoking user, or if the policy has disabled authentication for the user or command. Unlike

when

requires authentication, it validates the invoking user’s credentials, not the target user’s (or

credentials. This can be changed via the

and

flags, described later.

If a user who is not listed in the policy tries to run a command via

mail is sent to the proper authorities. The address used for such mail is configurable via the

Defaults entry (described later) and defaults to

No mail will be sent if an unauthorized user tries to run

with the

option unless there is an authentication error and either the

flags are enabled. This allows users to determine for themselves whether or not they are allowed to use

By default, all attempts to run

(successful or not) are logged, regardless of whether or not mail is sent.

is run by

and the

environment variable is set, the

policy will use this value to determine who the actual user is. This can be used by a user to log commands through sudo even when a

shell has been invoked. It also allows the

option to remain useful even when invoked via a sudo-run script or program. Note, however, that the

file lookup is still done for

not the user specified by

uses per-user time stamp files for credential caching. Once a user has been authenticated, a record is written containing the user-ID that was used to authenticate, the terminal session ID, the start time of the session leader (or parent process) and a time stamp (using a monotonic clock if one is available). The user may then use

without a password for a short period of time (15 minutes unless overridden by the

option). By default,

uses a separate record for each terminal, which means that a user’s login sessions are authenticated separately. The

option can be used to select the type of time stamp record

will use.

By default,

logs both successful and unsuccessful attempts (as well as errors). The

and

flags can be used to control this behavior. Messages can be logged to

a log file, or both. The default is to log to

but this is configurable via the

and

settings. See

for a description of the log file format.

is also capable of running a command in a pseudo-terminal and logging input and/or output. The standard input, standard output, and standard error can be logged even when not associated with a terminal. For more information about I/O logging, see the

section.

Starting with version 1.9, the

setting may be used to send event and I/O log data to a remote server running

or another service that implements the protocol described by

Since environment variables can influence program behavior,

provides a means to restrict which variables from the user’s environment are inherited by the command to be run. There are two distinct ways

can deal with environment variables.

By default, the

flag is enabled. This causes commands to be executed with a new, minimal environment. On AIX (and Linux systems without PAM), the environment is initialized with the contents of the

file.

The

and

environment variables are initialized based on the target user and the

variables are set based on the invoking user. Additional variables, such as

and

are preserved from the invoking user’s environment if permitted by the

options. A few environment variables are treated specially. If the

and

variables are not preserved from the user’s environment, they will be set to default values. The

and

are handled as a single entity. If one of them is preserved (or removed) from the user’s environment, the other will be as well. If

and

are to be preserved but only one of them is present in the user’s environment, the other will be set to the same value. This avoids an inconsistent environment where one of the variables describing the user name is set to the invoking user and one is set to the target user. Environment variables with a value beginning with

are removed unless both the name and value parts are matched by

as they may be interpreted as functions by the

shell. Prior to version 1.8.11, such variables were always removed.

If, however, the

flag is disabled, any variables not explicitly denied by the

and

options are allowed and their values are inherited from the invoking process. Prior to version 1.8.21, environment variables with a value beginning with

were always removed. Beginning with version 1.8.21, a pattern in

is used to match

shell functions instead. Since it is not possible to block all potentially dangerous environment variables, use of the default

behavior is encouraged.

Environment variables specified by

may include one or more

characters which will match zero or more characters. No other wildcard characters are supported.

By default, environment variables are matched by name. However, if the pattern includes an equal sign

both the variables name and value must match. For example, a

shell function could be matched as follows:

env_keep += “BASH_FUNC_my_func%%=()*”

Without the

suffix, this would not match, as

shell functions are not preserved by default.

The complete list of environment variables that are preserved or removed, as modified by global Defaults parameters in

is displayed when

is run by

with the

option. The list of environment variables to remove varies based on the operating system

is running on.

Other settings may influence the command environment:

options such as

and

Command tags, such as

and

Note that

is implied if the command matched is

options, such as

and

On systems that support PAM where the

module is enabled for

variables in the PAM environment may be merged in to the environment. If a variable in the PAM environment is already present in the user’s environment, the value will only be overridden if the variable was not preserved by

When

is enabled, variables preserved from the invoking user’s environment by the

list take precedence over those in the PAM environment. When

is disabled, variables present the invoking user’s environment take precedence over those in the PAM environment unless they match a pattern in the

list.

The dynamic linker on most operating systems will remove variables that can control dynamic linking from the environment of set-user-ID executables, including

Depending on the operating system this may include

and others. These type of variables are removed from the environment before

even begins execution and, as such, it is not possible for

to preserve them.

As a special case, if the

option (initial login) is specified,

will initialize the environment regardless of the value of

The

and

variables remain unchanged;

and

are set based on the target user. On AIX (and Linux systems without PAM), the contents of

are also included.

All other environment variables are removed unless permitted by

described above.

Finally, the

and

files are applied, if present. The variables in

are applied first and are subject to the same restrictions as the invoking user’s environment, as detailed above. The variables in

are applied last and are not subject to these restrictions. In both cases, variables present in the files will only be set to their specified values if they would not conflict with an existing environment variable.

The

file is composed of two types of entries: aliases (basically variables) and user specifications (which specify who may run what).

When multiple entries match for a user, they are applied in order. Where there are multiple matches, the last match is used (which is not necessarily the most specific match).

The

file grammar will be described below in Extended Backus-Naur Form (EBNF). Don’t despair if you are unfamiliar with EBNF; it is fairly simple, and the definitions below are annotated.

By default,

uses the operating system’s native method of setting resource limits for the target user. On Linux systems, resource limits are usually set by the

PAM module. On some BSD systems, the

file specifies resource limits for the user. On AIX systems, resource limits are configured in the

file. If there is no system mechanism to set per-user resource limits, the command will run with the same limits as the invoking user. The one exception to this is the core dump file size, which is set by

to 0 by default. Disabling core dumps by default makes it possible to avoid potential security problems where the core file is treated as trusted input.

Resource limits may also be set in the

file itself, in which case they override those set by the system. See the

options described below. Resource limits in

may be specified in one of the following formats:

Both the soft and hard resource limits are set to the same value. The special value

can be used to indicate that the value is unlimited.

Two comma-separated values. The soft limit is set to the first value and the hard limit is set to the second. Both values must either be enclosed in a set of double quotes, or the comma must be escaped with a backslash

The special value

may be used in place of either value.

The default resource limit for the user will be used. This may be a user-specific value (see above) or the value of the resource limit when

was invoked for systems that don’t support per-user limits.

The invoking user’s resource limits will be preserved when running the command.

For example, to restore the historic core dump file size behavior, a line like the following may be used.

Resource limits in

are only supported by version 1.8.7 or higher.

EBNF is a concise and exact way of describing the grammar of a language. Each EBNF definition is made up of

For example:

symbol ::= definition | alternate1 | alternate2 …

Each

references others and thus makes up a grammar for the language. EBNF also contains the following operators, which many readers will recognize from regular expressions. Do not, however, confuse them with

characters, which have different meanings.

Means that the preceding symbol (or group of symbols) is optional. That is, it may appear once or not at all.

Means that the preceding symbol (or group of symbols) may appear zero or more times.

Means that the preceding symbol (or group of symbols) may appear one or more times.

Parentheses may be used to group symbols together. For clarity, we will use single quotes

to designate what is a verbatim character string (as opposed to a symbol name).

There are four kinds of aliases:

and

Beginning with

1.9.0,

may be used in place of

if desired.

Alias ::= ‘User_Alias’ User_Alias_Spec (’:’ User_Alias_Spec)* | ‘Runas_Alias’ Runas_Alias_Spec (’:’ Runas_Alias_Spec)* | ‘Host_Alias’ Host_Alias_Spec (’:’ Host_Alias_Spec)* | ‘Cmnd_Alias’ Cmnd_Alias_Spec (’:’ Cmnd_Alias_Spec)* | ‘Cmd_Alias’ Cmnd_Alias_Spec (’:’ Cmnd_Alias_Spec)*

User_Alias ::= NAME

User_Alias_Spec ::= User_Alias ‘=’ User_List

Runas_Alias ::= NAME

Runas_Alias_Spec ::= Runas_Alias ‘=’ Runas_List

Host_Alias ::= NAME

Host_Alias_Spec ::= Host_Alias ‘=’ Host_List

Cmnd_Alias ::= NAME

Cmnd_Alias_Spec ::= Cmnd_Alias ‘=’ Cmnd_List

NAME ::= [A-Z]([A-Z][0-9]_)*

Each

definition is of the form

Alias_Type NAME = item1, item2, …

where

is one of

is a string of uppercase letters, numbers, and underscore characters

start with an uppercase letter. It is possible to put several alias definitions of the same type on a single line, joined by a colon

For example:

Alias_Type NAME = item1, item2, item3 : NAME = item4, item5

It is a syntax error to redefine an existing

It is possible to use the same name for

of different types, but this is not recommended.

The definitions of what constitutes a valid

member follow.

User_List ::= User | User ‘,’ User_List

is made up of one or more user names, user-IDs (prefixed with

system group names and IDs (prefixed with

and

respectively), netgroups (prefixed with

non-Unix group names and IDs (prefixed with

and

respectively), and

Each list item may be prefixed with zero or more

operators. An odd number of

operators negate the value of the item; an even number just cancel each other out. User netgroups are matched using the user and domain members only; the host member is not used when matching.

may be enclosed in double quotes to avoid the need for escaping special characters. Alternately, special characters may be specified in escaped hex mode, e.g., for space. When using double quotes, any prefix characters must be included inside the quotes.

The actual

and

syntax depends on the underlying group provider plugin. For instance, the QAS AD plugin supports the following formats:

Group in the same domain: “%:Group Name”

Group in any domain: “%:Group [email protected]”

Group SID: “%:S-1-2-34-5678901234-5678901234-5678901234-567”

See

for more information.

Quotes around group names are optional. Unquoted strings must use a backslash

to escape spaces and special characters. See

for a list of characters that need to be escaped.

Runas_List ::= Runas_Member | Runas_Member ‘,’ Runas_List

is similar to a

except that instead of

it can contain

User names and groups are matched as strings. In other words, two users (groups) with the same user (group) ID are considered to be distinct. If you wish to match all user names with the same user-ID (e.g.,

and

you can use a user-ID instead of a name (#0 in the example given). The user-ID or group-ID specified in a

need not be listed in the password or group database.

Host_List ::= Host | Host ‘,’ Host_List

is made up of one or more host names, IP addresses, network numbers, netgroups (prefixed with

and other aliases. Again, the value of an item may be negated with the

operator. Host netgroups are matched using the host (both qualified and unqualified) and domain members only; the user member is not used when matching. If you specify a network number without a netmask,

will query each of the local host’s network interfaces and, if the network number corresponds to one of the hosts’s network interfaces, will use the netmask of that interface. The netmask may be specified either in standard IP address notation (e.g., 255.255.255.0 or ffff:ffff:ffff:ffff::), or CIDR notation (number of bits, e.g., 24 or 64). A host name may include shell-style wildcards (see the

section below), but unless the

command on your machine returns the fully qualified host name, you’ll need to use the

flag for wildcards to be useful.

only inspects actual network interfaces; this means that IP address 127.0.0.1 (localhost) will never match. Also, the host name

will only match if that is the actual host name, which is usually only the case for non-networked systems.

digest ::= [A-Fa-f0-9]+ | [A-Za-z0-9/=]+

Digest_Spec ::= “sha224” ‘:’ digest | “sha256” ‘:’ digest | “sha384” ‘:’ digest | “sha512” ‘:’ digest

Digest_List ::= Digest_Spec | Digest_Spec ‘,’ Digest_List

Cmnd_List ::= Cmnd | Cmnd ‘,’ Cmnd_List

command name ::= regex | file name

command ::= command name | command name args | command name regex | command name ‘""’ | ALL

Edit_Spec ::= “sudoedit” file name+ | “sudoedit” regex | “sudoedit”

List_Spec ::= “list”

Cmnd ::= Digest_List? ‘!’* command | ‘!’* directory | ‘!’* Edit_Spec | ‘!’* List_Spec | ‘!’* Cmnd_Alias

is a list of one or more commands, directories, or aliases. A command is a fully qualified file name, which may include shell-style wildcards (see the

section below), or a regular expression that starts with

and ends with

(see the

section below). A directory is a fully qualified path name ending in a

When you specify a directory in a

the user will be able to run any file within that directory (but not in any sub-directories therein). If no command line arguments are specified, the user may run the command with any arguments they choose. Command line arguments can include wildcards or be a regular expression that starts with

and ends with

If the command line arguments consist of

the command may only be run with

arguments.

If a

has associated command line arguments, the arguments in the

must match those given by the user on the command line. If the arguments in a

begin with the

character, they will be interpreted as a regular expression and matched accordingly. Otherwise, shell-style wildcards are used when matching. Unless a regular expression is specified, the following characters must be escaped with a

if they are used in command arguments:

To prevent arguments in a

that begin with a

character from being interpreted as a regular expression, the

must be escaped with a

There are two commands built into

itself:

and

Unlike other commands, these two must be specified in the

file

a leading path.

The

built-in can be used to permit a user to list another user’s privileges with

option. For example,

A user with the

privilege is able to list another user’s privileges even if they don’t have permission to run commands as that user. By default, only root or a user with the ability to run any command as either root or the specified

on the current host may use the

option. No command line arguments may be specified with the

built-in.

The

built-in is used to permit a user to run

with the

option (or as

It may take command line arguments just as a normal command does. Unlike other commands,

is built into

itself and must be specified in the

file

a leading path. If a leading path is present, for example

the path name will be silently converted to

A fully-qualified path for

is treated as an error by

may be preceded by a

a comma-separated list of one or more

entries. If a

is present, the command will only match successfully if it can be verified using one of the SHA-2 digests in the list. Starting with version 1.9.0, the

reserved word can be used in conjunction with a

The following digest formats are supported: sha224, sha256, sha384, and sha512. The string may be specified in either hex or base64 format (base64 is more compact). There are several utilities capable of generating SHA-2 digests in hex format such as openssl, shasum, sha224sum, sha256sum, sha384sum, sha512sum.

For example, using openssl:

$ openssl dgst -sha224 /bin/ls SHA224(/bin/ls)= 118187da8364d490b4a7debbf483004e8f3e053ec954309de2c41a25

It is also possible to use openssl to generate base64 output:

$ openssl dgst -binary -sha224 /bin/ls | openssl base64 EYGH2oNk1JC0p9679IMATo8+BT7JVDCd4sQaJQ==

Warning, if the user has write access to the command itself (directly or via a

command), it may be possible for the user to replace the command after the digest check has been performed but before the command is executed. A similar race condition exists on systems that lack the

system call when the directory in which the command is located is writable by the user. See the description of the

setting for more information on how

executes commands that have an associated digest.

Command digests are only supported by version 1.8.7 or higher.

Certain configuration options may be changed from their default values at run-time via one or more

lines. These may affect all users on any host

all users on a specific host

a specific user

a specific command

or commands being run as a specific user

White space is not permitted between

and the

characters. While a comma-separated list may be used in place of a single value after the

character, using an alias instead of a list is often improve readability. Per-command entries may not include command line arguments. If you need to specify arguments, define a

and reference that instead.

Default_Type ::= ‘Defaults’ | ‘Defaults@’ Host_List | ‘Defaults:’ User_List | ‘Defaults!’ Cmnd_List | ‘Defaults>’ Runas_List

Default_Entry ::= Default_Type Parameter_List

Parameter_List ::= Parameter | Parameter ‘,’ Parameter_List

Parameter ::= Parameter ‘=’ Value | Parameter ‘+=’ Value | Parameter ‘-=’ Value | ‘!’* Parameter

Parameters may be

values,

Flags are implicitly boolean and can be turned off via the

operator. Some integer, string and list parameters may also be used in a boolean context to disable them. Values may be enclosed in double quotes

when they contain multiple words. Special characters may be escaped with a backslash

To include a literal backslash character in a command line argument you must escape the backslash twice. For example, to match

as part of a command line argument, you must use

in the

file. This is due to there being two levels of escaping, one in the

parser itself and another when command line arguments are matched by the

function.

Lists have two additional assignment operators,

and

These operators are used to add to and delete from a list respectively. It is not an error to use the

operator to remove an element that does not exist in a list.

Defaults entries are parsed in the following order: global, host, user, and runas Defaults first, then command defaults. If there are multiple Defaults settings of the same type, the last matching setting is used. The following Defaults settings are parsed before all others since they may affect subsequent entries:

See

for a list of supported Defaults parameters.

User_Spec ::= User_List Host_List ‘=’ Cmnd_Spec_List \ (’:’ Host_List ‘=’ Cmnd_Spec_List)*

Cmnd_Spec_List ::= Cmnd_Spec | Cmnd_Spec ‘,’ Cmnd_Spec_List

Cmnd_Spec ::= Runas_Spec? Option_Spec* (Tag_Spec ‘:’)* Cmnd

Runas_Spec ::= ‘(’ Runas_List? (’:’ Runas_List)? ‘)’

Date_Spec ::= (‘NOTBEFORE=timestamp’ | ‘NOTAFTER=timestamp’)

Timeout_Spec ::= ‘TIMEOUT=timeout’

Chdir_Spec ::= ‘CWD=directory’

Chroot_Spec ::= ‘CHROOT=directory’

determines which commands a user may run (and as what user) on specified hosts. By default, commands are run as

(unless

has been set to a different value) but this can also be changed on a per-command basis.

The basic structure of a user specification is

Let’s break that down into its constituent parts:

determines the user and/or the group that a command may be run as. A fully-specified

consists of two

(as defined above) separated by a colon

and enclosed in a set of parentheses. The first

indicates which users the command may be run as via the

option. The second defines a list of groups that may be specified via the

option (in addition to any of the target user’s groups). If both

are specified, the command may be run with any combination of users and groups listed in their respective

If only the first is specified, the command may be run as any user in the list and, optionally, with any group the target user belongs to. If the first

is empty but the second is specified, the command may be run as the invoking user with the group set to any listed in the

If both

are empty, the command may only be run as the invoking user and the group, if specified, must be one that the invoking user is a member of. If no

is specified, the command may only be run as the

user

by default) and the group, if specified, must be one that the

user is a member of.

sets the default for the commands that follow it. What this means is that for the entry:

dgb boulder = (operator) /bin/ls, /bin/kill, /usr/bin/lprm

The user

may run

and

on the host

only as

For example:

$ sudo -u operator /bin/ls

It is also possible to override a

later on in an entry. If we modify the entry like so:

dgb boulder = (operator) /bin/ls, (root) /bin/kill, /usr/bin/lprm

Then user

is now allowed to run

but

and

We can extend this to allow

to run

with either the user or group set to

dgb boulder = (operator : operator) /bin/ls, (root) /bin/kill,\ /usr/bin/lprm

While the group portion of the

permits the user to run as command with that group, it does not force the user to do so. If no group is specified on the command line, the command will run with the group listed in the target user’s password database entry. The following would all be permitted by the sudoers entry above:

$ sudo -u operator /bin/ls $ sudo -u operator -g operator /bin/ls $ sudo -g operator /bin/ls

In the following example, user

may run commands that access a modem device file with the dialer group.

tcm boulder = (:dialer) /usr/bin/tip, /usr/bin/cu,\ /usr/local/bin/minicom

In this example only the group will be set, the command still runs as user

For example:

$ sudo -g dialer /usr/bin/cu

Multiple users and groups may be present in a

in which case the user may select any combination of users and groups via the

and

options. In this example:

alan ALL = (root, bin : operator, system) ALL

user

may run any command as either user

optionally setting the group to operator or system.

may have zero or more options associated with it. Options may consist of

start and/or end dates and command timeouts. Once an option is set for a

subsequent

in the

inherit that option unless it is overridden by another option. Option names are reserved words in

This means that none of the valid option names (see below) can be used when declaring an alias.

rules can be specified with a start and end date via the

and

settings. The time stamp must be specified in

as defined by RFC 4517. The format is effectively

where the minutes and seconds are optional. The

suffix indicates that the time stamp is in Coordinated Universal Time (UTC). It is also possible to specify a timezone offset from UTC in hours and minutes instead of a

For example,

would correspond to Eastern Standard time in the US. As an extension, if no

or timezone offset is specified, local time will be used.

The following are all valid time stamps:

20170214083000Z 2017021408Z 20160315220000-0500 20151201235900

A command may have a timeout associated with it. If the timeout expires before the command has exited, the command will be terminated. The timeout may be specified in combinations of days, hours, minutes, and seconds with a single-letter case-insensitive suffix that indicates the unit of time. For example, a timeout of 7 days, 8 hours, 30 minutes, and 10 seconds would be written as

If a number is specified without a unit, seconds are assumed. Any of the days, minutes, hours, or seconds may be omitted. The order must be from largest to smallest unit and a unit may not be specified more than once.

The following are all

timeout values:

The following are

timeout values:

This setting is only supported by version 1.8.20 or higher.

The working directory that the command will be run in can be specified using the

setting. The

must be a fully-qualified path name beginning with a

character, or the special value

A value of

indicates that the user may specify the working directory by running

with the

option. By default, commands are run from the invoking user’s current working directory, unless the

option is given. Path names of the form

are interpreted as being relative to the named user’s home directory. If the user name is omitted, the path will be relative to the runas user’s home directory.

This setting is only supported by version 1.9.3 or higher.

The root directory that the command will be run in can be specified using the

setting. The

must be a fully-qualified path name beginning with a

character, or the special value

A value of

indicates that the user may specify the root directory by running

with the

option. This setting can be used to run the command in a

similar to the

utility. Path names of the form

are interpreted as being relative to the named user’s home directory. If the user name is omitted, the path will be relative to the runas user’s home directory.

This setting is only supported by version 1.9.3 or higher.

A command may have zero or more tags associated with it. The following tag values are supported:

and

Once a tag is set on a

subsequent

in the

inherit the tag unless it is overridden by the opposite tag (in other words,

overrides

and

overrides

has been compiled with

support and the underlying operating system supports it, the

tag can be used to prevent a dynamically-linked executable from running further commands itself.

In the following example, user

may run

and

on the host shanty, but shell escapes will be disabled.

aaron shanty = NOEXEC: /usr/bin/more, /usr/bin/vi

See the

section below for more details on how

works and whether or not it will work on your system.

Starting with version 1.8.15,

will not open a file that is a symbolic link unless the

flag is enabled. The

and

tags override the value of

and can be used to permit (or deny) the editing of symbolic links on a per-command basis. These tags are only effective for the

command and are ignored for all other commands.

These tags override the value of the

flag on a per-command basis. For more information, see

These tags override the value of the

flag on a per-command basis. For more information, see

These tags provide fine-grained control over whether mail will be sent when a user runs a command by overriding the value of the

flag on a per-command basis. They have no effect when

is run with the

options. A

tag will also override the

and

options. For more information, see the descriptions of

and

in the

section below.

By default,

requires that a user authenticate before running a command. This behavior can be modified via the

tag. Like a

the

tag sets a default for the commands that follow it in the

Conversely, the

tag can be used to reverse things. For example:

ray rushmore = NOPASSWD: /bin/kill, /bin/ls, /usr/bin/lprm

would allow the user

to run

and

on the machine

without authenticating himself. If we only want

to be able to run

without a password the entry would be:

ray rushmore = NOPASSWD: /bin/kill, PASSWD: /bin/ls, /usr/bin/lprm

Note, however, that the

tag has no effect on users who are in the group specified by the

setting.

By default, if the

tag is applied to any of a user’s entries for the current host, the user will be able to run

without a password. Additionally, a user may only run

without a password if all of the user’s entries for the current host have the

tag. This behavior may be overridden via the

and

options.

These tags override the value of the

flag on a per-command basis. If

has been set for a command, the user may disable the

flag from the command line via the

option. Additionally, environment variables set on the command line are not subject to the restrictions imposed by

As such, only trusted users should be allowed to set variables in this manner. If the command matched is

the

tag is implied for that command; this default may be overridden by use of the

tag.

has been compiled with

support and the underlying operating system supports it, the

tag can be used to cause programs spawned by a command to be validated against

and logged just like they would be if run through

directly. This is useful in conjunction with commands that allow shell escapes such as editors, shells, and paginators. There is additional overhead due to the policy check that may add latency when running commands such as shell scripts that execute a large number of sub-commands. For interactive commands, such as a shell or editor, the overhead is not usually noticeable.

In the following example, user

may run any command on the machine

in intercept mode.

chuck research = INTERCEPT: ALL

See the

section below for more details on how

works and whether or not it will work on your system.

allows shell-style

(aka meta or glob characters) to be used in host names, path names, and command line arguments in the

file. Wildcard matching is done via the

and

functions as specified by

Matches any set of zero or more characters (including white space).

Matches any single character (including white space).

Matches any character in the specified range.

Matches any character

in the specified range.

For any character

evaluates to

This is used to escape special characters such as:

and

These are not regular expressions.

Unlike a regular expression there is no way to match one or more characters within a range.

Character classes may be used if your system’s

and

functions support them. However, because the

character has special meaning in

it must be escaped. For example:

/bin/ls [[\alpha\]]*

Would match any file name beginning with a letter.

A forward slash

will

be matched by wildcards used in the file name portion of the command. This is to make a path like:

/usr/bin/*

match

but not

When matching the command line arguments, however, a slash

get matched by wildcards since command line arguments may contain arbitrary strings and not just path names.

Wildcards in command line arguments should be used with care.

Wildcards can match any character, including white space. In most cases, it is safer to use a regular expression to match command line arguments. For more information, see

below.

The following exceptions apply to the above rules:

If the empty string

is the only command line argument in the

file entry it means that command is not allowed to be run with

arguments.

Command line arguments to the

built-in command should always be path names, so a forward slash

will not be matched by a wildcard.

Starting with version 1.9.10, it is possible to use regular expressions for path names and command line arguments. Regular expressions are more expressive than shell-style

and are usually safer because they provide a greater degree of control when matching. The type of regular expressions supported by

are POSIX extended regular expressions, similar to those used by the

utility. They are usually documented in the

manual, depending on the system. As an extension, if the regular expression begins with

it will be matched in a case-insensitive manner.

regular expressions must start with a

character and end with a

This makes it explicit what is, or is not, a regular expression. Either the path name, the command line arguments or both may be regular expressions. Because the path name and arguments are matched separately, it is even possible to use wildcards for the path name and regular expressions for the arguments. It is not possible to use a single regular expression to match both the command and its arguments. Regular expressions in

are limited to 1024 characters.

There is no need to escape

special characters in a regular expression other than the pound sign

In the following example, user

can run the

command as

on any host but is not allowed to change

password. This kind of rule is impossible to express safely using wildcards.

john ALL = /usr/bin/passwd ^[a-zA-Z0-9_]+$,\ !/usr/bin/passwd root

It is also possible to use a regular expression in conjunction with

rules. The following rule would give user bob the ability to edit the

and

files only.

bob ALL = sudoedit ^/etc/(motd|issue|hosts)$

Regular expressions may also be used to match the command itself. In this example, a regular expression is used to allow user

to run the

and

commands as

sid ALL = ^/usr/sbin/(group|user)(add|mod|del)$

One disadvantage of using a regular expression to match the command name is that it is not possible to match relative paths such as

This has security implications when a regular expression is used for the command name in conjunction with the negation operator,

as such rules can be trivially bypassed. Because of this, using a negated regular expression for the command name is

This does not apply to negated commands that only use a regular expression to match the command arguments. See

below for more information.

It is possible to include other

files from within the

file currently being parsed using the

and

directives. For compatibility with sudo versions prior to 1.9.1,

and

are also accepted.

An include file can be used, for example, to keep a site-wide

file in addition to a local, per-machine file. For the sake of this example the site-wide

file will be

and the per-machine one will be

To include

from within

one would use the following line in

@include /etc/sudoers.local

When

reaches this line it will suspend processing of the current file

and switch to

Upon reaching the end of

the rest of

will be processed. Files that are included may themselves include other files. A hard limit of 128 nested include files is enforced to prevent include file loops.

Starting with version 1.9.1, the path to the include file may contain white space if it is escaped with a backslash

Alternately, the entire path may be enclosed in double quotes

in which case no escaping is necessary. To include a literal backslash in the path,

should be used.

If the path to the include file is not fully-qualified (does not begin with a

it must be located in the same directory as the sudoers file it was included from. For example, if

contains the line:

@include sudoers.local

the file that will be included is

The file name may also include the

escape, signifying the short form of the host name. In other words, if the machine’s host name is

then

@include /etc/sudoers.%h

will cause

to include the file

Any path name separator characters

present in the host name will be replaced with an underbar

during expansion.

The

directive can be used to create a

directory that the system package manager can drop

file rules into as part of package installation. For example, given:

@includedir /etc/sudoers.d

will suspend processing of the current file and read each file in

skipping file names that end in

or contain a

character to avoid causing problems with package manager or editor temporary/backup files.

Files are parsed in sorted lexical order. That is,

will be parsed before

Be aware that because the sorting is lexical, not numeric,

would be loaded

Using a consistent number of leading zeroes in the file names can be used to avoid such problems. After parsing the files in the directory, control returns to the file that contained the

directive.

Unlike files included via

will not edit the files in a

directory unless one of them contains a syntax error. It is still possible to run

with the

flag to edit the files directly, but this will not catch the redefinition of an

that is also present in a different file.

The pound sign

is used to indicate a comment (unless it is part of a #include directive or unless it occurs in the context of a user name and is followed by one or more digits, in which case it is treated as a user-ID). Both the comment character and any text after it, up to the end of the line, are ignored.

The reserved word

is a built-in

that always causes a match to succeed. It can be used wherever one might otherwise use a

Attempting to define an

named

will result in a syntax error. Using

can be dangerous since in a command context, it allows the user to run

command on the system.

The following option names permitted in an

are also considered reserved words:

and

Attempting to define an

with the same name as one of the options will result in a syntax error.

An exclamation point

can be used as a logical

operator in a list or

as well as in front of a

This allows one to exclude certain values. For the

operator to be effective, there must be something for it to exclude. For example, to match all users except for

one would use:

ALL, !root

If the

is omitted, as in:

!root

it would explicitly deny

but not match any other users. This is different from a true

operator.

Note, however, that using a

in conjunction with the built-in

alias to allow a user to run

commands rarely works as intended (see

below).

Long lines can be continued with a backslash

as the last character on the line.

White space between elements in a list as well as special syntactic characters in a

is optional.

The following characters must be escaped with a backslash

when used as part of a word (e.g., a user name or host name):

behavior can be modified by

lines, as explained earlier. A list of all supported Defaults parameters, grouped by type, are listed below.

If a

is configured, use it to resolve groups of the form

as long as there is not also a system group of the same name. Normally, only groups of the form

are passed to the

This flag is

by default.

If enabled,

will set the

environment variable to the home directory of the target user (which is the

user unless the

option is used). This flag is largely obsolete and has no effect unless the

flag has been disabled or

is present in the

list, both of which are strongly discouraged. This flag is

by default.

If set, users must authenticate themselves via a password (or other means of authentication) before they may run commands. This default may be overridden via the

and

tags. This flag is

by default.

If enabled, group names in

will be matched in a case insensitive manner. This may be necessary when users are stored in LDAP or AD. This flag is

by default.

If enabled, user names in

will be matched in a case insensitive manner. This may be necessary when groups are stored in LDAP or AD. This flag is

by default.

If set, the user may use the

option which overrides the default starting point at which

begins closing open file descriptors. This flag is

by default.

If set, and

is configured to log a command’s input or output, the I/O logs will be compressed using

This flag is

by default when

is compiled with

support.

By default,

runs a command as the foreground process as long as

itself is running in the foreground. When the

flag is enabled and the command is being run in a pseudo-terminal (due to I/O logging or the

flag), the command will be run as a background process. Attempts to read from the controlling terminal (or to change terminal settings) will result in the command being suspended with the

signal (or

in the case of terminal settings). If this happens when

behavior or when the command is not being run in a pseudo-terminal.

and

functions (this is a bug in macOS). Furthermore, because this behavior depends on the command stopping with the

signals, programs that catch these signals and suspend themselves with a different signal (usually

will not be automatically foregrounded. Some versions of the linux

command behave this way. This flag is

by default.

This setting is only supported by version 1.8.7 or higher. It has no effect unless I/O logging is enabled or the

flag is enabled.

If set,

will use the value of the

environment variables before falling back on the default editor list.

is typically run as

so this flag may allow a user with

privileges to run arbitrary commands as

without logging. An alternative is to place a colon-separated list of

editors int the

setting.

will then only use

if they match a value specified in

If the

flag is enabled, the

and/or

environment variables must be present in the

list for the

flag to function when

is invoked via

This flag is

by default.

If set,

will run the command in a minimal environment containing the

and

variables. Any variables in the caller’s environment or in the file specified by the

setting that match the

and

lists are then added, followed by any variables present in the file specified by the

setting (if any). The contents of the

and

lists, as modified by global Defaults parameters in

are displayed when

is run by

with the

option. If the

setting is enabled, its value will be used for the

environment variable. This flag is

by default.

Normally,

uses the

function to do shell-style globbing when matching path names. However, since it accesses the file system,

can take a long time to complete for some patterns, especially when the pattern references a network file system that is mounted on demand (auto mounted). The

flag causes

to use the

function, which does not access the file system to do its matching. The disadvantage of

is that it is unable to match relative paths such as

This has security implications when path names that include globbing characters are used with the negation operator,

as such rules can be trivially bypassed. As such, this flag should not be used when the

file contains rules that contain negated path names which include globbing characters. This flag is

by default.

Most programs that require a user’s password will disable echo before reading the password to avoid displaying the plaintext password on the screen. However, if terminal input is being logged (see

the password will still be present in the I/O log. If the

option is disabled,

will attempt to prevent passwords from being logged. It does this by using the regular expressions in

to match a password prompt in the terminal output buffer. When a match is found, input characters in the I/O log will be replaced with

until either a line feed or carriage return is found in the terminal input or a new terminal output buffer is received. If, however, a program displays characters as the user types (such as

when

is set), only the first character of the password will be replaced in the I/O log. This option has no effect unless

are also set. This flag is

by default.

This setting is only supported by version 1.9.10 or higher.

Set this flag if you want to put fully qualified host names in the

file when the local host name (as returned by the

command) does not contain the domain name. In other words, instead of myhost you would use myhost.mydomain.edu. You may still use the short form if you wish (and even mix the two). This flag is only effective when the

host name, as returned by the

function, is a fully-qualified domain name. This is usually the case when the system is configured to use DNS for host name resolution.

If the system is configured to use the

file in preference to DNS, the

host name may not be fully-qualified. The order that sources are queried for host name resolution is usually specified in the

or, in some cases,

file. In the

file, the first host name of the entry is considered to be the

name; subsequent names are aliases that are not used by

For example, the following hosts file line for the machine

has the fully-qualified domain name as the

host name, and the short version as an alias.

If the machine’s hosts file entry is not formatted properly, the

flag will not be effective if it is queried before DNS.

Beware that when using DNS for host name resolution, turning on

requires

to make DNS lookups which renders

unusable if DNS stops working (for example if the machine is disconnected from the network). Just like with the hosts file, you must use the

name as DNS knows it. That is, you may not use a host alias (CNAME entry) due to performance issues and the fact that there is no way to get all aliases from DNS.

This flag is

by default.

Allow commands to be run even if

cannot write to the audit log. If enabled, an audit log write failure is not treated as a fatal error. If disabled, a command may only be run after the audit event is successfully written. This flag is only effective on systems for which

supports audit logging, including

Linux, macOS, and Solaris. This flag is

by default.

If set,

will ignore “.” or "" (both denoting the current directory) in the

environment variable; the

itself is not modified. This flag is

by default.

Allow commands to be run even if

cannot write to the I/O log (local or remote). If enabled, an I/O log write failure is not treated as a fatal error. If disabled, the command will be terminated if the I/O log cannot be written to. This flag is

by default.

Allow commands to be run even if

cannot write to the log file. If enabled, a log file write failure is not treated as a fatal error. If disabled, a command may only be run after the log file entry is successfully written. This flag only has an effect when

is configured to use file-based logging via the

setting. This flag is

by default.

If set via LDAP, parsing of

will be skipped. This is intended for sites that wish to prevent the usage of local sudoers files so that only LDAP is used. This thwarts the efforts of rogue operators who would attempt to add roles to

When this flag is enabled,

does not even need to exist. Since this flag tells

how to behave when no specific LDAP entries have been matched, this sudoOption is only meaningful for the

section. This flag is

by default.

If set,

will not produce a warning if it encounters an unknown Defaults entry in the

file or an unknown sudoOption in LDAP. This flag is

by default.

If set,

will insult users when they enter an incorrect password. This flag is

by default.

If set,

will log commands allowed by the policy to the system audit log (where supported) as well as to syslog and/or a log file. This flag is

by default.

This setting is only supported by version 1.8.29 or higher.

If set,

will log commands denied by the policy to the system audit log (where supported) as well as to syslog and/or a log file. This flag is

by default.

This setting is only supported by version 1.8.29 or higher.

If set,

will log the exit value of commands that are run to syslog and/or a log file. If a command was terminated by a signal, the signal name is logged as well. This flag is

by default.

This setting is only supported by version 1.9.8 or higher.

If set, the host name will be included in log entries written to the file configured by the

setting. This flag is

by default.

If set,

will run the command in a pseudo-terminal (if

was run from a terminal) and log all user input. If the standard input is not connected to the user’s terminal, due to I/O redirection or because the command is part of a pipeline, that input is also logged. For more information about I/O logging, see the

section. This flag is

by default.

If set,

will run the command in a pseudo-terminal (if

was run from a terminal) and log all output that is sent to the user’s terminal, the standard output or the standard error. If the standard output or standard error is not connected to the user’s terminal, due to I/O redirection or because the command is part of a pipeline, that output is also logged. For more information about I/O logging, see the

section. This flag is

by default.

If set,

will enable the TCP keepalive socket option on the connection to the log server. This enables the periodic transmission of keepalive messages to the server. If the server does not respond to a message, the connection will be closed and the running command will be terminated unless the

flag (I/O logging enabled) or the

flag (I/O logging disabled) is set. This flag is

by default.

This setting is only supported by version 1.9.0 or higher.

If set, the server certificate received during the TLS handshake must be valid and it must contain either the server name (from

or its IP address. If either of these conditions is not met, the TLS handshake will fail. This flag is

by default.

This setting is only supported by version 1.9.0 or higher.

If set,

will log the standard error if it is not connected to the user’s terminal. This can be used to log output to a pipe or redirected to a file. This flag is

by default but is enabled when either the

flag or the

command tag is set.

If set,

will log the standard input if it is not connected to the user’s terminal. This can be used to log input from a pipe or redirected from a file. This flag is

by default but is enabled when either the

flag or the

command tag is set.

If set,

will log the standard output if it is not connected to the user’s terminal. This can be used to log output to a pipe or redirected to a file. This flag is

by default but is enabled when either the

flag or the

command tag is set.

If set,

will log when a command spawns a child process and executes a program using the

library functions. For example, if a shell is run by

the individual commands run via the shell will be logged. This flag is

by default.

The

flag uses the same underlying mechanism as the

setting. Some commands may not work properly when

is enabled, due to the way it intercepts sub-commands. See

for more information on what systems support this option and its limitations. This setting is only supported by version 1.9.8 or higher and is incompatible with SELinux RBAC support unless the system supports

filter mode.

If set,

will run the command in a pseudo-terminal and log user keystrokes sent to the user’s terminal, if one is present. This flag is

by default but is enabled when either the

flag or the

command tag is set. If no terminal is present, for example when running a remote command using

this flag will have no effect.

If set,

will run the command in a pseudo-terminal and log all output displayed on the user’s terminal, if one is present. This flag is

by default but is enabled when either the

flag or the

command tag is set. If no terminal is present, for example when running a remote command using

this flag will have no effect.

If set, the four-digit year will be logged in the (non-syslog)

log file. This flag is

by default.

When validating with a One Time Password (OTP) scheme such as

a two-line prompt is used to make it easier to cut and paste the challenge to a local window. It’s not as pretty as the default but some people find it more convenient. This flag is

by default.

Send mail to the

user every time a user attempts to run a command via

(this includes

No mail will be sent if the user runs

with the

option unless there is an authentication error and the

flag is also set. This flag is

by default.

Send mail to the

user every time a user runs

This flag is

by default.

Send mail to the

user if the user running

does not enter the correct password. If the command the user is attempting to run is not permitted by

and one of the

flags are set, this flag will have no effect. This flag is

by default.

If set, mail will be sent to the

user if the invoking user exists in the

file, but is not allowed to run commands on the current host. This flag is

by default.

If set, mail will be sent to the

user if the invoking user is allowed to use

but the command they are trying is not listed in their

file entry or is explicitly denied. This flag is

by default.

If set, mail will be sent to the

user if the invoking user is not in the

file. This flag is

by default.

By default,

will look up each group the user is a member of by group-ID to determine the group name (this is only done once). The resulting list of the user’s group names is used when matching groups listed in the

file. This works well on systems where the number of groups listed in the

file is larger than the number of groups a typical user belongs to. On systems where group lookups are slow, where users may belong to a large number of groups, or where the number of groups listed in the

file is relatively small, it may be prohibitively expensive and running commands via

may take longer than normal. On such systems it may be faster to use the

flag to avoid resolving the user’s group-IDs to group names. In this case,

must look up any group name listed in the

file and use the group-ID instead of the group name when determining whether the user is a member of the group.

is enabled, group database lookups performed by

will be keyed by group name as opposed to group-ID. On systems where there are multiple sources for the group database, it is possible to have conflicting group names or group-IDs in the local

file and the remote group database. On such systems, enabling or disabling

can be used to choose whether group database queries are performed by name (enabled) or ID (disabled), which may aid in working around group entry conflicts.

The

flag has no effect when

data is stored in LDAP. This flag is

by default.

This setting is only supported by version 1.8.18 or higher.

If set, all commands run via

will behave as if the

tag has been set, unless overridden by an

tag. Some commands may not work properly when

is enabled, due to the way it intercept sub-commands. See the description of

above as well as the

section at the end of this manual. This flag is

by default.

This setting is only supported by version 1.9.8 or higher and is incompatible with SELinux RBAC support unless the system supports

filter mode.

On most systems, the dynamic loader will ignore

(or the equivalent) when running set-user-ID and set-group-ID programs, effectively disabling intercept mode. To prevent this from happening,

will not permit a set-user-ID or set-group-ID program to be run in intercept mode unless

is enable. This flag has no effect unless the

flag is enabled or the

tag has been set for the command. This flag is

by default when the

option is set to

otherwise it default to

This setting is only supported by version 1.9.8 or higher.

If set, commands run by an intercepted process must be authenticated when the user’s time stamp is not current. For example, if a shell is run with

enabled, as soon as the invoking user’s time stamp is out of date, subsequent commands will need to be authenticated. This flag has no effect unless the

flag is enabled or the

tag has been set for the command. This flag is

by default.

This setting is only supported by version 1.9.8 or higher.

If set,

will attempt to verify that a command run in intercept mode has the expected path name, command line arguments and environment.

The process will be stopped after

has completed but before the new command has had a chance to run. To verify the command,

will read the command’s path from

the command line arguments and environment from the process’s memory, and compare them against the arguments that were passed to

In the event of a mismatch, the command will be sent a

signal and terminated.

This can help prevent a time of check versus time of use issue with intercept mode where the

arguments could be altered after the

policy check. The checks can only be performed if the

file system is available. This flag has no effect unless the

flag is enabled or the

tag has been set for the command and the

option is set to

This setting is incompatible with programs that change their root directory via

If a program changes its root directory, path names will no longer match those seen by the

parent process and sub-commands will be terminated before they have a chance to run. This flag is

by default.

This setting is only supported by version 1.9.12 or higher.

If set, netgroup lookups will be performed using the full netgroup tuple: host name, user name, and domain (if one is set). Historically,

only matched the user name and domain for netgroups used in a

and only matched the host name and domain for netgroups used in a

This flag is

by default.

If set, all commands run via

will behave as if the

tag has been set, unless overridden by an

tag. See the description of

above as well as the

section at the end of this manual. This flag is

by default.

If set, authentication will be attempted even in non-interactive mode (when

option is specified). This allows authentication methods that don’t require user interaction to succeed. Authentication methods that require input from the user’s terminal will still fail. If disabled, authentication will not be attempted in non-interactive mode. This flag is

by default.

This setting is only supported by version 1.9.10 or higher.

On systems that use PAM for authentication,

will perform PAM account validation for the invoking user by default. The actual checks performed depend on which PAM modules are configured. If enabled, account validation will be performed regardless of whether or not a password is required. This flag is

by default.

This setting is only supported by version 1.8.28 or higher.

On systems that use PAM for authentication,

will set the PAM remote host value to the name of the local host when the

flag is enabled. On Linux systems, enabling

may result in DNS lookups of the local host name when PAM is initialized. On Solaris versions prior to Solaris 8,

must be enabled if

is also enabled to avoid a crash in the Solaris PAM implementation.

This flag is

by default on systems other than Solaris.

This setting is only supported by version 1.9.0 or higher.

On systems that use PAM for authentication,

will set the PAM remote user value to the name of the user that invoked sudo when the

flag is enabled. This flag is

by default.

This setting is only supported by version 1.9.0 or higher.

On systems that use PAM for authentication,

will create a new PAM session for the command to be run in. Unless

is given the

options, PAM session modules are run with the

flag enabled. This prevents last login information from being displayed for every command on some systems. Disabling

may be needed on older PAM implementations or on operating systems where opening a PAM session changes the utmp or wtmp files. If PAM session support is disabled, resource limits may not be updated for the command being run. If

and

are disabled,

has not been set and I/O logging has not been configured,

will execute the command directly instead of running it as a child process. This flag is

by default.

This setting is only supported by version 1.8.7 or higher.

On systems that use PAM for authentication,

will attempt to establish credentials for the target user by default, if supported by the underlying authentication system. One example of a credential is a Kerberos ticket. If

and

are disabled,

has not been set and I/O logging has not been configured,

will execute the command directly instead of running it as a child process. This flag is

by default.

This setting is only supported by version 1.8.8 or higher.

If set, the prompt specified by

or the

environment variable will always be used and will replace the prompt provided by a PAM module or other authentication method. This flag is

by default.

Normally,

will tell the user when a command could not be found in their

environment variable. Some sites may wish to disable this as it could be used to gather information on the location of executables that the normal user does not have access to. The disadvantage is that if the executable is simply not in the user’s

will tell the user that they are not allowed to run it, which can be confusing. This flag is

by default.

By default,

will initialize the group vector to the list of groups the target user is in. When

is set, the user’s existing group vector is left unaltered. The real and effective group-IDs, however, are still set to match the target user. This flag is

by default.

By default,

reads the password like most other Unix programs, by turning off echo until the user hits the return (or enter) key. Some users become confused by this as it appears to them that

has hung at this point. When

is set,

will provide visual feedback when the user presses a key. This does have a security impact as an onlooker may be able to determine the length of the password being entered. This flag is

by default.

If set,

will only run when the user is logged in to a real tty. When this flag is set,

can only be run from a login session and not via other means such as

or cgi-bin scripts. This flag is

by default.

If set,

is allowed to run

too. Disabling this prevents users from

commands to get a

shell by doing something like

Note, however, that turning off

will also prevent

from running

Disabling

provides no real additional security; it exists purely for historical reasons. This flag is

by default.

If set,

will prompt for the

password instead of the password of the invoking user when running a command or editing a file. This flag is

by default.

If enabled, allow matching of runas user and group IDs that are not present in the password or group databases. In addition to explicitly matching unknown user or group IDs in a

this option also allows the

alias to match unknown IDs. This flag is

by default.

This setting is only supported by version 1.8.30 or higher. Older versions of

always allowed matching of unknown user and group IDs.

If enabled,

will only run commands as a user whose shell appears in the

file, even if the invoking user’s

would otherwise permit it. If no

file is present, a system-dependent list of built-in default shells is used. On many operating systems, system users such as

do not have a valid shell and this flag can be used to prevent commands from being run as those users. This flag is

by default.

This setting is only supported by version 1.8.30 or higher.

If set,

will prompt for the password of the user defined by the

option (defaults to

instead of the password of the invoking user when running a command or editing a file. This flag is

by default.

If enabled and

is invoked with the

option, the

environment variable will be set to the home directory of the target user (which is the

user unless the

option is used). This flag is largely obsolete and has no effect unless the

flag has been disabled or

is present in the

list, both of which are strongly discouraged. This flag is

by default.

Normally,

will set the

and

environment variables to the name of the target user (the user specified by

unless the

option is given). However, since some programs (including the RCS revision control system) use

to determine the real identity of the user, it may be desirable to change this behavior. This can be done by negating the set_logname option. The

option will have no effect if the

option has not been disabled and the

list contains

This flag is

by default.

When enabled,

will create an entry in the utmp (or utmpx) file when a pseudo-terminal is allocated. A pseudo-terminal is allocated by

when it is running in a terminal and one or more of the

flags is enabled. By default, the new entry will be a copy of the user’s existing utmp entry (if any), with the tty, time, type, and pid fields updated. This flag is

by default.

Allow the user to disable the

option from the command line via the

option. Additionally, environment variables set via the command line are not subject to the restrictions imposed by

As such, only trusted users should be allowed to set variables in this manner. This flag is

by default.

If set and

is invoked with no arguments it acts as if the

option had been given. That is, it runs a shell as

(the shell is determined by the

environment variable if it is set, falling back on the shell listed in the invoking user’s /etc/passwd entry if not). This flag is

by default.

Normally, when

executes a command the real and effective user-IDs are set to the target user

by default). This option changes that behavior such that the real user-ID is left as the invoking user’s user-ID. In other words, this makes

act as a set-user-ID wrapper. This can be useful on systems that disable some potentially dangerous functionality when a program is run set-user-ID. This option is only effective on systems that support either the

system call. This flag is

by default.

If set,

will check all directory components of the path to be edited for writability by the invoking user. Symbolic links will not be followed in writable directories and

will refuse to edit a file located in a writable directory. These restrictions are not enforced when

is run by

On some systems, if all directory components of the path to be edited are not readable by the target user,

will be unable to edit the file. This flag is

by default.

This setting was first introduced in version 1.8.15 but initially suffered from a race condition. The check for symbolic links in writable intermediate directories was added in version 1.8.16.

By default,

will not follow symbolic links when opening files. The

option can be enabled to allow

to open symbolic links. It may be overridden on a per-command basis by the

and

tags. This flag is

by default.

This setting is only supported by version 1.8.15 or higher.

When logging via

include the process ID in the log entry. This flag is

by default.

This setting is only supported by version 1.8.21 or higher.

If set,

will prompt for the password of the user specified by the

option (defaults to the value of

instead of the password of the invoking user when running a command or editing a file. This flag precludes the use of a user-ID not listed in the passwd database as an argument to the

option. This flag is

by default.

If set, users must authenticate on a per-tty basis. With this flag enabled,

will use a separate record in the time stamp file for each terminal. If disabled, a single record is used for all login sessions.

This option has been superseded by the

option.

If set,

will set the umask as specified in the

file without modification. This makes it possible to specify a umask in the

file that is more permissive than the user’s own umask and matches historical behavior. If

is not set,

will set the umask to be the union of the user’s umask and what is specified in

This flag is

by default.

If set, netgroups (prefixed with

may be used in place of a user or host. For LDAP-based sudoers, netgroup support requires an expensive sub-string match on the server unless the

directive is present in the

file. If netgroups are not needed, this option can be disabled to reduce the load on the LDAP server. This flag is

by default.

If set, and

is running in a terminal, the command will be run in a new pseudo-terminal. If the

process is not attached to a terminal,

has no effect.

A malicious program run under

may be capable of injecting commands into the user’s terminal or running a background process that retains access to the user’s terminal device even after the main program has finished executing. By running the command in a separate pseudo-terminal, this attack is no longer possible. This flag is

by default for

1.9.14 and above.

If set, the user may specify a timeout on the command line. If the timeout expires before the command has exited, the command will be terminated. If a timeout is specified both in the

file and on the command line, the smaller of the two timeouts will be used. See the

section for a description of the timeout syntax. This flag is

by default.

This setting is only supported by version 1.8.20 or higher.

If set,

will store the name of the runas user when updating the utmp (or utmpx) file. By default,

stores the name of the invoking user. This flag is

by default.

By default,

will refuse to run if the user must enter a password but it is not possible to disable echo on the terminal. If the

flag is set,

will prompt for a password even when it would be visible on the screen. This makes it possible to run things like

since by default,

does not allocate a tty when running a command. This flag is

by default.

Before it executes a command,

will close all open file descriptors other than standard input, standard output, and standard error (file descriptors 0-2). The

option can be used to specify a different file descriptor at which to start closing. The default is 3.

The maximum amount of time a command is allowed to run before it is terminated. See the

section for a description of the timeout syntax.

This setting is only supported by version 1.8.20 or higher.

The maximum amount of time to wait when connecting to a log server or waiting for a server response. See the

section for a description of the timeout syntax. The default value is 30 seconds.

This setting is only supported by version 1.9.0 or higher.

The maximum sequence number that will be substituted for the

escape in the I/O log file (see the

description below for more information). While the value substituted for

is in base 36,

itself should be expressed in decimal. Values larger than 2176782336 (which corresponds to the base 36 sequence number

will be silently truncated to 2176782336. The default value is 2176782336.

Once the local sequence number reaches the value of

it will

to zero, after which

will truncate and re-use any existing I/O log path names.

This setting is only supported by version 1.8.7 or higher.

The number of tries a user gets to enter his/her password before

logs the failure and exits. The default is 3.

On many systems,

has a relatively small log buffer. IETF RFC 5424 states that syslog servers must support messages of at least 480 bytes and should support messages up to 2048 bytes. By default,

creates log messages up to 980 bytes which corresponds to the historic

syslog implementation which used a 1024 byte buffer to store the message, date, hostname, and program name. To prevent syslog messages from being truncated,

will split up log messages that are larger than

bytes. When a message is split, additional parts will include the string

after the user name and before the continued command line arguments.

This setting is only supported by version 1.8.19 or higher.

Number of characters per line for the file log. This value is used to decide when to wrap lines for nicer log files. This has no effect on the syslog log file, only the file log. The default is 80 (use 0 or negate the option to disable word wrap).

Number of minutes before the

password prompt times out, or 0 for no timeout. The timeout may include a fractional component if minute granularity is insufficient, for example 2.5. The default is 0.

Number of minutes that can elapse before

will ask for a password again. The timeout may include a fractional component if minute granularity is insufficient, for example 2.5. The default is 15. Set this to 0 to always prompt for a password. If set to a value less than 0 the user’s time stamp will not expire until the system is rebooted. This can be used to allow users to create or delete their own time stamps via

and

respectively.

File mode creation mask to use when running the command. Negate this option or set it to 0777 to prevent

from changing the umask. Unless the

flag is set, the actual umask will be the union of the user’s umask and the value of the

setting, which defaults to 0022. This guarantees that

never lowers the umask when running a command.

is explicitly set in

it will override any umask setting in PAM or login.conf. If

is not set in

the umask specified by PAM or login.conf will take precedence. The umask setting in PAM is not used for

which does not create a new PAM session.

Message that is displayed after a user fails to authenticate. The message may include the

escape which will expand to the number of failed password attempts. If set, it overrides the default message,

Message that is displayed if a user enters an incorrect password. The default is

unless insults are enabled.

A colon

separated list of editor path names used by

and

For

this list is used to find an editor when none of the

environment variables are set to an editor that exists and is executable. For

it is used as a white list of allowed editors;

will choose the editor that matches the user’s

environment variable if possible, or the first editor in the list that exists and is executable if not. Unless invoked as

does not preserve the

environment variables unless they are present in the

list or the

option is disabled. The default is

The underlying mechanism used by the

and

options. It has the following possible values:

Preload a dynamic shared object (shared library) that intercepts the

and

library functions. A value of

is incompatible with

SELinux RBAC support.

Use

to intercept the

system call. This is only supported on Linux systems where

filtering is enabled. If the

file is missing or does not contain a

element, setting

will have no effect and

will be used instead.

The default is to use

if it is supported by the system and

if it is not.

The top-level directory to use when constructing the path name for the input/output log directory. Only used if the

options are enabled or when the

tags are present for a command. The session sequence number, if any, is stored in the directory. The default is

The following percent

escape sequences are supported:

expanded to a monotonically increasing base-36 sequence number, such as 0100A5, where every two digits are used to form a new directory, e.g.,

expanded to the invoking user’s login name

expanded to the name of the invoking user’s real group-ID

expanded to the login name of the user the command will be run as (e.g.,

expanded to the group name of the user the command will be run as (e.g.,

expanded to the local host name without the domain name

expanded to the base name of the command being run

In addition, any escape sequences supported by the system’s

function will be expanded.

To include a literal

character, the string

should be used.

Any path name separator characters

present in the user, group or host name will be replaced with an underbar

during expansion.

The path name, relative to

in which to store input/output logs when the

options are enabled or when the

tags are present for a command.

may contain directory components. The default is

See the

option above for a list of supported percent

escape sequences.

In addition to the escape sequences, path names that end in six or more

will have the

replaced with a unique combination of digits and letters, similar to the

function.

If the path created by concatenating

and

already exists, the existing I/O log file will be truncated and overwritten unless

ends in six or more

If set,

will flush I/O log data to disk after each write instead of buffering it. This makes it possible to view the logs in real-time as the program is executing but may significantly reduce the effectiveness of I/O log compression. This flag is

by default.

This setting is only supported by version 1.8.20 or higher.

The group name to look up when setting the group-ID on new I/O log files and directories. If

is not set, the primary group-ID of the user specified by

is used. If neither

nor

are set, I/O log files and directories are created with group-ID 0.

This setting is only supported by version 1.8.19 or higher.

Defaults to 0600 (read and write by user only).

This setting is only supported by version 1.8.19 or higher.

The user name to look up when setting the user and group-IDs on new I/O log files and directories. If

is set, it will be used instead of the user’s primary group-ID. By default, I/O log files and directories are created with user and group-ID 0.

This setting can be useful when the I/O logs are stored on a Network File System (NFS) share. Having a dedicated user own the I/O log files means that

does not write to the log files as user-ID 0, which is usually not permitted by NFS.

This setting is only supported by version 1.8.19 or higher.

The directory in which

stores per-user lecture status files. Once a user has received the lecture, a zero-length file is created in this directory so that

will not lecture the user again. This directory should

be cleared when the system reboots. The default is

The path to a certificate authority bundle file, in PEM format, to use instead of the system’s default certificate authority database when authenticating the log server. The default is to use the system’s default certificate authority database. This setting has no effect unless

is set and the remote log server is secured with TLS.

This setting is only supported by version 1.9.0 or higher.

The path to the

client’s certificate file, in PEM format. This setting is required when the remote log server is secured with TLS and client certificate validation is enabled. For

client certificate validation is controlled by the

option, which defaults to

This setting is only supported by version 1.9.0 or higher.

The path to the

client’s private key file, in PEM format. This setting is required when the remote log server is secured with TLS and client certificate validation is enabled. For

client certificate validation is controlled by the

flag, which defaults to

This setting is only supported by version 1.9.0 or higher.

Subject of the mail sent to the

user. The escape

will expand to the host name of the machine. Default is

As of

version 1.8.1 this option is no longer supported. The path to the noexec file should now be set in the

file.

On systems that use PAM for authentication, this is the service name used when the

option is specified. The default value is either

depending on whether or not the

option is also specified. See the description of

for more information.

This setting is only supported by version 1.9.9 or higher.

On systems that use PAM for authentication, this is the service name used when the

option is specified. The default value is

See the description of

for more information.

This setting is only supported by version 1.8.8 or higher.

On systems that use PAM for authentication, the service name specifies the PAM policy to apply. This usually corresponds to an entry in the

file or a file in the

directory. The default value is

This setting is only supported by version 1.8.8 or higher.

The default prompt to use when asking for a password; can be overridden via the

option or the

environment variable. The following percent

escape sequences are supported:

expanded to the local host name including the domain name (only if the machine’s host name is fully qualified or the

option is set)

expanded to the local host name without the domain name

expanded to the user whose password is being asked for (respects the

and

flags in

expanded to the login name of the user the command will be run as (defaults to

expanded to the invoking user’s login name

two consecutive

characters are collapsed into a single

character

On systems that use PAM for authentication,

will only be used if the prompt provided by the PAM module matches the string

This ensures that the

setting does not interfere with challenge-response style authentication. The

flag can be used to change this behavior.

The default value is

The default user to run commands as if the

option is not specified on the command line. This defaults to

Locale to use when parsing the sudoers file, logging commands, and sending email. Changing the locale may affect how sudoers is interpreted. Defaults to

uses per-user time stamp files for credential caching. The

option can be used to specify the type of time stamp record used. It has the following possible values:

A single time stamp record is used for all of a user’s login sessions, regardless of the terminal or parent process ID. An additional record is used to serialize password prompts when

is used multiple times in a pipeline, but this does not affect authentication.

A single time stamp record is used for all processes with the same parent process ID (usually the shell). Commands run from the same shell (or other common parent process) will not require a password for

minutes (15 by default). Commands run via

with a different parent process ID, for example from a shell script, will be authenticated separately.

One time stamp record is used for each terminal, which means that a user’s login sessions are authenticated separately. If no terminal is present, the behavior is the same as

Commands run from the same terminal will not require a password for

minutes (15 by default).

The time stamp is stored in the kernel as an attribute of the terminal device. If no terminal is present, the behavior is the same as

Negative

values are not supported and positive values are limited to a maximum of 60 minutes. This is currently only supported on

The default value is

This setting is only supported by version 1.8.21 or higher.

The directory in which

stores its time stamp files. This directory should be cleared when the system reboots. The default is

The owner of the lecture status directory, time stamp directory and all files stored therein. The default is

The

option specifies the path to a file that is created the first time a user that is a member of the

groups runs

Only available if

is configured with the

option. The default value is

The

option specifies the fully qualified path to a file containing variables to be set in the environment of the program being run. Entries in this file should either be of the form

The value may optionally be enclosed in single or double quotes. Variables in this file are only added if the variable does not already exist in the environment. This file is considered to be part of the security policy, its contents are not subject to other

environment restrictions such as

and

Users in this group are exempt from password and PATH requirements. The group name specified should not include a

prefix. This is not set by default.

Determines whether

will execute a command by its path or by an open file descriptor. It has the following possible values:

Always execute by file descriptor.

Never execute by file descriptor.

Only execute by file descriptor if the command has an associated digest in the

file.

The default value is

This avoids a time of check versus time of use race condition when the command is located in a directory writable by the invoking user.

will change the first element of the argument vector for scripts ($0 in the shell) due to the way the kernel runs script interpreters. Instead of being a normal path, it will refer to a file descriptor. For example,

on Solaris and

on Linux. A workaround is to use the

environment variable instead.

The

setting is only used when the command is matched by path name. It has no effect if the command is matched by the built-in

alias.

This setting is only supported by version 1.8.20 or higher. If the operating system does not support the

system call, this setting has no effect.

A string containing a

group plugin with optional arguments. The string should consist of the plugin path, either fully-qualified or relative to the

directory, followed by any configuration arguments the plugin requires. These arguments (if any) will be passed to the plugin’s initialization function. If arguments are present, the string must be enclosed in double quotes

On 64-bit systems, if the plugin is present but cannot be loaded,

will look for a 64-bit version and, if it exists, load that as a fallback. The exact rules for this vary by system. On Solaris, if the plugin is stored in a directory ending in

will create a fallback path by appending

to the directory name;

becomes

On Linux, a directory ending in

will be transformed to

as the fallback path;

becomes

On all other systems, the fallback path is generated by adding a

before the file extension;

becomes

On AIX systems, the plugin may be either a shared object ending in

or an archive file containing a shared object ending in

with the name of the shared object in parentheses at the end.

For more information see

This option controls when a short lecture will be printed along with the password prompt. It has the following possible values:

Always lecture the user.

Never lecture the user.

Only lecture the user the first time they run

If no value is specified, a value of

is implied. Negating the option results in a value of

being used. The default value is

Path to a file containing an alternate

lecture that will be used in place of the standard lecture if the named file exists. By default,

uses a built-in lecture.

This option controls when a password will be required when a user runs

with the

option. It has the following possible values:

All the user’s

file entries for the current host must have the

flag set to avoid entering a password.

The user must always enter a password to use the

option.

At least one of the user’s

file entries for the current host must have the

flag set to avoid entering a password.

The user need never enter a password to use the

option.

If no value is specified, a value of

is implied. Negating the option results in a value of

being used. The default value is

The event log format. Supported log formats are:

Logs in JSON format. JSON log entries contain the full user details as well as the execution environment if the command was allowed. Due to limitations of the protocol, JSON events sent via

may be truncated.

Traditional sudo-style logs, see

for a description of the log file format.

This setting affects logs sent via

as well as the file specified by the

setting, if any. The default value is

Path to the

log file (not the syslog log file). Setting a path turns on logging to a file; negating this option turns it off. By default,

logs via syslog.

Flags to use when invoking mailer. Defaults to

Path to mail program used to send warning mail (negate to prevent

from sending mail). Defaults to the path to sendmail found at configure time.

Address to use for the

address when sending warning and error mail. The address should be enclosed in double quotes

to protect against

interpreting the

sign. Defaults to the name of the user running

Address to send warning and error mail to (negate to prevent

from sending mail). The address should be enclosed in double quotes

to protect against

interpreting the

sign. Defaults to root.

The maximum size to which the process’s address space may grow (in bytes), if supported by the operating system. See

for more information.

The largest size core dump file that may be created (in bytes). See

for more information. Defaults to 0 (no core dump created).

The maximum amount of CPU time that the process may use (in seconds). See

for more information.

The maximum size of the data segment for the process (in bytes). See

for more information.

The largest size file that the process may create (in bytes). See

for more information.

The maximum number of locks that the process may establish, if supported by the operating system. See

for more information.

The maximum size that the process may lock in memory (in bytes), if supported by the operating system. See

for more information.

The maximum number of files that the process may have open. See

for more information.

The maximum number of processes that the user may run simultaneously. See

for more information.

The maximum size to which the process’s resident set size may grow (in bytes). See

for more information.

The maximum size to which the process’s stack may grow (in bytes). See

for more information.

The

option specifies the fully qualified path to a file containing variables to be set in the environment of the program being run. Entries in this file should either be of the form

The value may optionally be enclosed in single or double quotes. Variables in this file are only added if the variable does not already exist in the environment. Unlike

the file’s contents are not trusted and are processed in a manner similar to that of the invoking user’s environment. If

is enabled, variables in the file will only be added if they are matched by either the

list. If

is disabled, variables in the file are added as long as they are not matched by the

list. In either case, the contents of

are processed before the contents of

If set,

will use this value for the root directory when running a command. The special value

will allow the user to specify the root directory via

option. See the

section for more details.

It is only possible to use

as a command-specific Defaults setting if the command exists with the same path both inside and outside the chroot jail. This restriction does not apply to global, host, or user-based Defaults settings or to a

that includes a

This setting is only supported by version 1.9.3 or higher.

If set,

will use this value for the working directory when running a command. The special value

will allow the user to specify the working directory via

option. See the

section for more details.

This setting is only supported by version 1.9.3 or higher.

If set,

will use this value in place of the user’s

environment variable. This option can be used to reset the

to a known good value that contains directories for system administrator commands such as

Users in the group specified by the

option are not affected by

This option is not set by default.

Syslog facility if syslog is being used for logging (negate to disable syslog logging). Defaults to authpriv.

The following syslog facilities are supported:

(if your OS supports it),

and

Syslog priority to use when the user is not allowed to run a command or when authentication is unsuccessful. Defaults to alert.

The following syslog priorities are supported:

and

Negating the option or setting it to a value of

will disable logging of unsuccessful commands.

Syslog priority to use when the user is allowed to run a command and authentication is successful. Defaults to notice.

See

for the list of supported syslog priorities. Negating the option or setting it to a value of

will disable logging of successful commands.

This option controls when a password will be required when a user runs

with the

option. It has the following possible values:

All the user’s

file entries for the current host must have the

flag set to avoid entering a password.

The user must always enter a password to use the

option.

At least one of the user’s

file entries for the current host must have the

flag set to avoid entering a password.

The user need never enter a password to use the

option.

If no value is specified, a value of

is implied. Negating the option results in a value of

being used. The default value is

Environment variables to be removed from the user’s environment unless they are considered

For all variables except

means that the variable’s value does not contain any

characters. This can be used to guard against printf-style format vulnerabilities in poorly-written programs. The

variable is considered unsafe if any of the following are true:

It consists of a fully-qualified path name, optionally prefixed with a colon

that does not match the location of the

directory.

It contains a

path element.

It contains white space or non-printable characters.

It is longer than the value of

The argument may be a double-quoted, space-separated list or a single value without double-quotes. The list can be replaced, added to, deleted from, or disabled by using the

and

operators respectively. Regardless of whether the

option is enabled or disabled, variables specified by

will be preserved in the environment if they pass the aforementioned check. The global list of environment variables to check is displayed when

is run by

with the

option.

Environment variables to be removed from the user’s environment when the

option is not in effect. The argument may be a double-quoted, space-separated list or a single value without double-quotes. The list can be replaced, added to, deleted from, or disabled by using the

and

operators respectively. The global list of environment variables to remove is displayed when

is run by

with the

option. Many operating systems will remove potentially dangerous variables from the environment of any set-user-ID process (such as

Environment variables to be preserved in the user’s environment when the

option is in effect. This allows fine-grained control over the environment

processes will receive. The argument may be a double-quoted, space-separated list or a single value without double-quotes. The list can be replaced, added to, deleted from, or disabled by using the

and

operators respectively. The global list of variables to keep is displayed when

is run by

with the

option.

Preserving the

environment variable has security implications since many programs use it when searching for configuration or data files. Adding

may enable a user to run unrestricted commands via

and is strongly discouraged. Users wishing to edit files with

should run

(or

to get their accustomed editor configuration instead of invoking the editor directly.

A list of one or more servers to use for remote event and I/O log storage, separated by white space. Log servers must be running

or another service that implements the protocol described by

Server addresses should be of the form

The host portion may be a host name, an IPv4 address, or an IPv6 address in square brackets.

If the optional

flag is present, the connection will be secured with Transport Layer Security (TLS) version 1.2 or 1.3. Versions of TLS prior to 1.2 are not supported.

If a port is specified, it may either be a port number or a well-known service name as defined by the system service name database. If no port is specified, port 30343 will be used for plaintext connections and port 30344 will be used for TLS connections.

When

is set, event log data will be logged both locally (see the

and

settings) as well as remotely, but I/O log data will only be logged remotely. If multiple hosts are specified, they will be attempted in reverse order. If no log servers are available, the user will not be able to run a command unless either the

flag (I/O logging enabled) or the

flag (I/O logging disabled) is set. Likewise, if the connection to the log server is interrupted while

is running, the command will be terminated unless the

flag (I/O logging enabled) or the

flag (I/O logging disabled) is set.

This setting is only supported by version 1.9.0 or higher.

A list of POSIX extended regular expressions used to match password prompts in the terminal output. As an extension, if the regular expression begins with

it will be matched in a case-insensitive manner. Each regular expression is limited to 1024 characters. This option is only used when

has been disabled. The default value is

This setting is only supported by version 1.9.10 or higher.

The

plugin supports its own plugin interface to allow non-Unix group lookups which can query a group source other than the standard Unix group database. This can be used to implement support for the

syntax described earlier.

Group provider plugins are specified via the

setting. The argument to

should consist of the plugin path, either fully-qualified or relative to the

directory, followed by any configuration options the plugin requires. These options (if specified) will be passed to the plugin’s initialization function. If options are present, the string must be enclosed in double quotes

The following group provider plugins are installed by default:

The

plugin supports an alternate group file that uses the same syntax as the

file. The path to the group file should be specified as an option to the plugin. For example, if the group file to be used is

Defaults group_plugin=“group_file.so /etc/sudo-group”

The

plugin supports group lookups via the standard C library functions

and

This plugin can be used in instances where the user belongs to groups not present in the user’s supplemental group vector. This plugin takes no options:

Defaults group_plugin=system_group.so

The group provider plugin API is described in detail in

can log events in either JSON or

format, this section describes the

log format. Depending on

configuration,

can log events via

to a local log file, or both. The log format is almost identical in both cases. Any control characters present in the log data are formatted in octal with a leading

character. For example, a horizontal tab is stored as

and an embedded carriage return is stored as

In addition, space characters in the command path are stored as

Command line arguments that contain spaces are enclosed in single quotes

This makes it possible to distinguish multiple command line arguments from a single argument that contains spaces. Literal single quotes and backslash characters

in command line arguments are escaped with a backslash.

Commands that sudo runs are logged using the following format (split into multiple lines for readability):

date hostname progname: username : TTY=ttyname ; CHROOT=chroot ; \ PWD=cwd ; USER=runasuser ; GROUP=runasgroup ; TSID=logid ; \ ENV=env_vars COMMAND=command

Where the fields are as follows:

The date the command was run. Typically, this is in the format

If logging via

the actual date format is controlled by the syslog daemon. If logging to a file and the

option is enabled, the date will also include the year.

The name of the host

was run on. This field is only present when logging via

The name of the program, usually

This field is only present when logging via

The login name of the user who ran

The short name of the terminal (e.g.,

was run on, or

if there was no terminal present.

The root directory that the command was run in, if one was specified.

The current working directory that

was run in.

The user the command was run as.

The group the command was run as if one was specified on the command line.

An I/O log identifier that can be used to replay the command’s output. This is only present when the

option is enabled.

A list of environment variables specified on the command line, if specified.

The actual command that was executed, including any command line arguments.

Messages are logged using the locale specified by

which defaults to the

locale.

If the user is not allowed to run the command, the reason for the denial will follow the user name. Possible reasons include:

The user is not listed in the

file.

The user is listed in the

file but is not allowed to run commands on the host.

The user is listed in the

file for the host but they are not allowed to run the specified command.

The user failed to enter their password after 3 tries. The actual number of tries will vary based on the number of failed attempts and the value of the

option.

The

option was specified but a password was required.

The user specified environment variables on the command line that were not allowed by

If an error occurs,

will log a message and, in most cases, send a message to the administrator via email. Possible errors include:

encountered an error when parsing the specified file. In some cases, the actual error may be one line above or below the line number listed, depending on the type of error.

The

file contains one or more unknown Defaults settings. This does not prevent

from running, but the

file should be checked using

The time stamp directory owner, as specified by the

setting, could not be found in the password database.

The

file could not be opened for reading. This can happen when the

file is located on a remote file system that maps user-ID 0 to a different value. Normally,

tries to open the

file using group permissions to avoid this problem. Consider either changing the ownership of

or adding an argument like

(where

is the user-ID that owns the

file) to the end of the

line in the

file.

The

file is missing.

The

file exists but is not a regular file or symbolic link.

The

file has the wrong owner. If you wish to change the

file owner, add

(where

is the user-ID that owns the

file) to the

line in the

file.

The permissions on the

file allow all users to write to it. The

file must not be world-writable, the default file mode is 0440 (readable by owner and group, writable by none). The default mode may be changed via the

option to the

line in the

file.

The

file has the wrong group ownership. If you wish to change the

file group ownership, add

(where

is the group-ID that owns the

file) to the

line in the

file.

was unable to read or create the user’s time stamp file. This can happen when

is set to a user other than

and the mode on

is not searchable by group or other. The default mode for

is 0711.

was unable to write to the user’s time stamp file.

The time stamp directory is owned by a user other than

This can occur when the value of

has been changed.

will ignore the time stamp directory until the owner is corrected.

The time stamp directory is group-writable; it should be writable only by

The default mode for the time stamp directory is 0700.

will ignore the time stamp directory until the mode is corrected.

By default,

logs messages via

The

and

fields are added by the system’s

function, not

itself. As such, they may vary in format on different systems.

The maximum size of syslog messages varies from system to system. The

setting can be used to change the maximum syslog message size from the default value of 980 bytes. For more information, see the description of

If the

option is set,

will log to a local file, such as

When logging to a file,

uses a format similar to

with a few important differences:

The

field is not present.

The

is only logged if the

option is enabled.

The date does not include the year unless the

option is enabled.

Lines that are longer than

characters (80 by default) are word-wrapped and continued on the next line with a four character indent. This makes entries easier to read for a human being, but makes it more difficult to use

on the log files. If the

option is set to 0 (or negated with a

word wrap will be disabled.

When I/O logging is enabled,

will runs the command in a pseudo-terminal, logging user input and/or output, depending on which

flags are enabled. There are five distinct types of I/O that can be logged, each with a corresponding

flag.

In addition to flags described the above, the

flag and

command tag set both

and

The

flag and

command tag set

and

To capture terminal input and output,

run the command in a pseudo-terminal, logging the input and output before passing it on to the user. To capture the standard input, standard output or standard error,

uses a pipe to interpose itself between the input or output stream, logging the I/O before passing it to the other end of the pipe.

I/O can be logged either to the local machine or to a remote log server. For local logs, I/O is logged to the directory specified by the

option

by default

using a unique session ID that is included in the

log line, prefixed with

The

option may be used to control the format of the session ID. For remote logs, the

setting is used to specify one or more log servers running

or another server that implements the protocol described by

When logging standard input, anything sent to the standard input will be consumed, regardless of whether or not the command run via

is actively reading the standard input. This may have unexpected results when using

in a shell script that expects to process the standard input. For example, given the following shell script:

#!/bin/sh sudo echo testing echo done

It will behave as expected when the script is passed to the shell as a an argument:

$ sh test.sh testing done

However, if the script is passed to the shell on the standard input, the

command will consume the rest of the script. This means that the

statement is never executed.

$ sh -s < test.sh testing

There are several ways to work around this problem:

Redirect the standard input from

when running a command via

that does not need to read the standard input.

sudo echo testing < /dev/null

Pass the script to the shell by path name instead of via the standard input.

sh test.sh

Disable logging the standard input for commands that do not need to read the standard input.

Defaults!/bin/echo !log_stdin

Depending on the command, it may not be desirable to log the standard input or standard output. For example, I/O logging of commands that send or receive large amount of data via the standard output or standard input such as

and

could fill up the log file system with superfluous data. It is possible to disable logging of the standard input and standard output for such commands as follows:

Cmnd_Alias COPY_CMDS = /usr/bin/tar, /usr/bin/cpio, /usr/bin/rsync

# Log input and output but omit stdin and stdout when copying files. Defaults log_input, log_output Defaults!COPY_CMDS !log_stdin, !log_stdout

However, be aware that using the

flag or the

command tag will also enable

Likewise, the

flag or the

command tag will enable

and

Careful ordering of rules may be necessary to achieve the results that you expect.

For both local and remote I/O logs, each log is stored in a separate directory that contains the following files:

A text file containing information about the command. The first line consists of the following colon-delimited fields: the time the command was run, the name of the user who ran

the name of the target user, the name of the target group (optional), the terminal that

was run from, and the number of lines and columns of the terminal. The second and third lines contain the working directory the command was run from and the path name of the command itself (with arguments if present).

A JSON-formatted file containing information about the command. This is similar to the

file but contains additional information and is easily extensible. The

file will be used by

in preference to the

file if it exists. The file may contain the following elements:

A JSON object containing time the command was run. It consists of two values,

and

The number of columns of the terminal the command ran on, or zero if no terminal was present.

The fully-qualified path of the command that was run.

The number of lines of the terminal the command ran on, or zero if no terminal was present.

A JSON array representing the command’s argument vector as passed to the

system call.

A JSON array representing the command’s environment as passed to the

system call.

The group ID the command ran as. This element is only present when the user specifies a group on the command line.

The name of the group the command ran as. This element is only present when the user specifies a group on the command line.

The user ID the command ran as.

The name of the user the command ran as.

The current working directory at the time

was run.

The name of the host the command was run on.

The name of the user who ran the command via

The path name of the terminal the user invoked

from. If the command was run in a pseudo-terminal,

will be different from the terminal the command actually ran in.

Timing information used to replay the session. Each line consists of the I/O log entry type and amount of time since the last entry, followed by type-specific data. The I/O log entry types and their corresponding type-specific data are:

standard input, number of bytes in the entry

standard output, number of bytes in the entry

standard error, number of bytes in the entry

terminal input, number of bytes in the entry

terminal output, number of bytes in the entry

window change, new number lines and columns

bug compatibility for

1.8.7 terminal output

command suspend or resume, signal received

Raw input from the user’s terminal, exactly as it was received. This file is only present if the

flags are set and

was run from a terminal. No post-processing is performed. For manual viewing, you may wish to convert carriage return characters in the log to line feeds. For example:

The standard input when no terminal is present, or input redirected from a pipe or file. This file is only present if the

flags are set and the standard input is not connected to a terminal.

Output from the pseudo-terminal (what the command writes to the screen). Terminal-specific post-processing is performed before the data is logged. This means that, for example, line feeds are usually converted to line feed/carriage return pairs and tabs may be expanded to spaces. This file is only present if the

flags are set and

was run from a terminal.

The standard output when no terminal is present, or output redirected to a pipe or file. This file is only present if the

flags are set and the standard output is not connected to a terminal.

The standard error when no terminal is present, or output redirected to a pipe or file. This file is only present if the

flags are set and the standard error is not connected to a terminal.

All files other than

are compressed in gzip format unless the

flag has been disabled. Due to buffering, it is not normally possible to display the I/O logs in real-time as the program is executing. The I/O log data will not be complete until the program run by

has exited or has been terminated by a signal. The

flag can be used to disable buffering, in which case I/O log data is written to disk as soon as it is available. The output portion of an I/O log file can be viewed with the

utility, which can also be used to list or search the available logs.

User input may contain sensitive information such as passwords (even if they are not echoed to the screen), which will be stored in the log file unencrypted. In most cases, logging the command output via

is all that is required. When logging input, consider disabling the

flag.

Since each session’s I/O logs are stored in a separate directory, traditional log rotation utilities cannot be used to limit the number of I/O logs. The simplest way to limit the number of I/O is by setting the

option to the maximum number of logs you wish to store. Once the I/O log sequence number reaches

it will be reset to zero and

will truncate and re-use any existing I/O logs.

Sudo front-end configuration

List of who can run what

Local groups file

List of network groups

I/O log files

Directory containing time stamps for the

security policy

Directory containing lecture status files for the

security policy

Initial environment for

mode on AIX and Linux systems

Below are example

file entries. Admittedly, some of these are a bit contrived. First, we allow a few environment variables to pass and then define our

# Run X applications through sudo; HOME is used to find the # .Xauthority file. Other programs use HOME to locate configuration # files and this may lead to privilege escalation! Defaults env_keep += “DISPLAY HOME”

# User alias specification User_Alias FULLTIMERS = millert, mikef, dowdy User_Alias PARTTIMERS = bostley, jwfox, crawl User_Alias WEBADMIN = will, wendy, wim

# Runas alias specification Runas_Alias OP = root, operator Runas_Alias DB = oracle, sybase Runas_Alias ADMINGRP = adm, oper

# Host alias specification Host_Alias SPARC = bigtime, eclipse, moet, anchor :\ SGI = grolsch, dandelion, black :\ ALPHA = widget, thalamus, foobar :\ HPPA = boa, nag, python Host_Alias CUNETS = 128.138.0.0/255.255.0.0 Host_Alias CSNETS = 128.138.243.0, 128.138.204.0/24, 128.138.242.0 Host_Alias SERVERS = primary, mail, www, ns Host_Alias CDROM = orion, perseus, hercules

# Cmnd alias specification Cmnd_Alias DUMPS = /usr/bin/mt, /usr/sbin/dump, /usr/sbin/rdump,\ /usr/sbin/restore, /usr/sbin/rrestore,\ sha224:0GomF8mNN3wlDt1HD9XldjJ3SNgpFdbjO1+NsQ== \ /home/operator/bin/start_backups Cmnd_Alias KILL = /usr/bin/kill Cmnd_Alias PRINTING = /usr/sbin/lpc, /usr/bin/lprm Cmnd_Alias SHUTDOWN = /usr/sbin/shutdown Cmnd_Alias HALT = /usr/sbin/halt Cmnd_Alias REBOOT = /usr/sbin/reboot Cmnd_Alias SHELLS = /usr/bin/sh, /usr/bin/csh, /usr/bin/ksh,\ /usr/local/bin/tcsh, /usr/bin/rsh,\ /usr/local/bin/zsh Cmnd_Alias SU = /usr/bin/su Cmnd_Alias PAGERS = /usr/bin/more, /usr/bin/pg, /usr/bin/less

Here we override some of the compiled in default values. We want

to log via

using the

facility in all cases and for commands to be run with the target user’s home directory as the working directory. We don’t want to subject the full time staff to the

lecture and we want to allow them to run commands in a

via the

option. User

need not provide a password and we don’t want to reset the

environment variables when running commands as

Additionally, on the machines in the

we keep an additional local log file and make sure we log the year in each log line since the log entries will be kept around for several years. Lastly, we disable shell escapes for the commands in the PAGERS

and

This will not effectively constrain users with

privileges.

# Override built-in defaults Defaults syslog=auth,runcwd=~ Defaults>root !set_logname Defaults:FULLTIMERS !lecture,runchroot=* Defaults:millert !authenticate Defaults@SERVERS log_year, logfile=/var/log/sudo.log Defaults!PAGERS noexec

The

is the part that actually determines who may run what.

root ALL = (ALL) ALL %wheel ALL = (ALL) ALL

We let

and any user in group

run any command on any host as any user.

FULLTIMERS ALL = NOPASSWD: ALL

Full time sysadmins

and

may run any command on any host without authenticating themselves.

PARTTIMERS ALL = ALL

Part time sysadmins

and

may run any command on any host but they must authenticate themselves first (since the entry lacks the

tag).

jack CSNETS = ALL

The user

may run any command on the machines in the

alias (the networks 128.138.243.0, 128.138.204.0, and 128.138.242.0). Of those networks, only 128.138.204.0 has an explicit netmask (in CIDR notation) indicating it is a class C network. For the other networks in

the local machine’s netmask will be used during matching.

lisa CUNETS = ALL

The user

may run any command on any host in the

alias (the class B network 128.138.0.0).

operator ALL = DUMPS, KILL, SHUTDOWN, HALT, REBOOT, PRINTING,\ sudoedit /etc/printcap, /usr/oper/bin/

The

user may run commands limited to simple maintenance. Here, those are commands related to backups, killing processes, the printing system, shutting down the system, and any commands in the directory

One command in the

Cmnd_Alias includes a sha224 digest,

This is because the directory containing the script is writable by the operator user. If the script is modified (resulting in a digest mismatch) it will no longer be possible to run it via

joe ALL = /usr/bin/su operator

The user

may only

to operator.

pete HPPA = /usr/bin/passwd [A-Za-z]*, !/usr/bin/passwd *root*

%opers ALL = (: ADMINGRP) /usr/sbin/

Users in the

group may run commands in

as themselves with any group in the

(the

and

groups).

The user

is allowed to change anyone’s password except for

on the

machines. Because command line arguments are matched as a single, concatenated string, the

wildcard will match

words. This example assumes that

does not take multiple user names on the command line. On systems with GNU

options to

may be specified after the user argument. As a result, this rule will also allow:

passwd username –expire

which may not be desirable.

bob SPARC = (OP) ALL : SGI = (OP) ALL

The user

may run anything on the

and

machines as any user listed in the

and

jim +biglab = ALL

The user

may run any command on machines in the

netgroup.

knows that

is a netgroup due to the

prefix.

+secretaries ALL = PRINTING, /usr/bin/adduser, /usr/bin/rmuser

Users in the

netgroup need to help manage the printers as well as add and remove users, so they are allowed to run those commands on all machines.

fred ALL = (DB) NOPASSWD: ALL

The user

can run commands as any user in the

without giving a password.

john ALPHA = /usr/bin/su [!-]*, !/usr/bin/su *root*

On the

machines, user

may su to anyone except

but he is not allowed to specify any options to the

command.

jen ALL, !SERVERS = ALL

The user

may run any command on any machine except for those in the

(primary, mail, www, and ns).

jill SERVERS = /usr/bin/, !SU, !SHELLS

For any machine in the

may run any commands in the directory

except for those commands belonging to the

and

While not specifically mentioned in the rule, the commands in the

all reside in

and have the

option set.

steve CSNETS = (operator) /usr/local/op_commands/

The user

may run any command in the directory /usr/local/op_commands/ but only as user operator.

matt valkyrie = KILL

On his personal workstation, valkyrie,

needs to be able to kill hung processes.

WEBADMIN www = (www) ALL, (root) /usr/bin/su www

On the host www, any user in the

(will, wendy, and wim), may run any command as user www (which owns the web pages) or simply

to www.

ALL CDROM = NOPASSWD: /sbin/umount /CDROM,\ /sbin/mount -o nosuid\nodev /dev/cd0a /CDROM

Any user may mount or unmount a CD-ROM on the machines in the CDROM

(orion, perseus, hercules) without entering a password. This is a bit tedious for users to type, so it is a prime candidate for encapsulating in a shell script.

It is generally not effective to

commands from

using the

operator. A user can trivially circumvent this by copying the desired command to a different name and then executing that. For example:

bill ALL = ALL, !SU, !SHELLS

Doesn’t really prevent

from running the commands listed in

since he can simply copy those commands to a different name, or use a shell escape from an editor or other program. Therefore, these kind of restrictions should be considered advisory at best (and reinforced by policy).

In general, if a user has sudo

there is nothing to prevent them from creating their own program that gives them a

shell (or making their own copy of a shell) regardless of any

elements in the user specification.

If the

option is in use, it is not possible to reliably negate commands where the path name includes globbing (aka wildcard) characters. This is because the C library’s

function cannot resolve relative paths. While this is typically only an inconvenience for rules that grant privileges, it can result in a security issue for rules that subtract or revoke privileges.

For example, given the following

file entry:

john ALL = /usr/bin/passwd [a-zA-Z0-9]*, /usr/bin/chsh [a-zA-Z0-9]*,\ /usr/bin/chfn [a-zA-Z0-9]*, !/usr/bin/* root

User

can still run

is enabled by changing to

and running

instead.

Another potential issue is that when

executes the command, it must use the command or path specified by the user instead of a path listed in the

file. This may lead to a time of check versus time of use race condition.

Command line arguments are matched as a single, concatenated string. This mean a wildcard character such as

will match across word boundaries, which may be unexpected. For example, while a sudoers entry like:

%operator ALL = /bin/cat /var/log/messages*

will allow command like:

$ sudo cat /var/log/messages.1

It will also allow:

$ sudo cat /var/log/messages /etc/shadow

which is probably not what was intended. A safer alternative is to use a regular expression for matching command line arguments. The above example can be rewritten as a regular expression:

%operator ALL = /bin/cat ^/var/log/messages[^[:space:]]*$

The regular expression will only match a single file with a name that begins with

and does not include any white space in the name. It is often better to do command line processing outside of the

file in a scripting language for anything non-trivial.

Using a regular expression to match a command name has the same security implications as using the

option:

It is not possible to reliably negate commands when the path name is a regular expression.

When

executes the command, it must use the command or path specified by the user instead of a path listed in the

file. This may lead to a time of check versus time of use race condition.

These issues do not apply to rules where only the command line options are matched using a regular expression.

Once

executes a program, that program is free to do whatever it pleases, including run other programs. This can be a security issue since it is not uncommon for a program to allow shell escapes, which lets a user bypass

access control and logging. Common programs that permit shell escapes include shells (obviously), editors, paginators, mail, and terminal programs.

There are four basic approaches to this problem:

Avoid giving users access to commands that allow the user to run arbitrary commands. Many editors have a restricted mode where shell escapes are disabled, though

is a better solution to running editors via

Due to the large number of programs that offer shell escapes, restricting users to the set of programs that do not is often unworkable.

On most systems,

functionality can be used to transparently intercept an attempt to run a new command, allow or deny it based on

rules, and log the result. For example, this can be used to restrict the commands run from within a privileged shell or editor. However, not all programs operate correctly when

is enabled.

There are two underlying mechanisms that may be used to implement

mode:

and

The

setting can be used to select between them.

The first mechanism,

overrides the standard C library functions that are used to execute a command. It does this by setting an environment variable (usually

to the path of a dynamic shared object, or shared library, containing custom versions of the

and

library functions that connect back to

for a policy decision. Note, however, that this applies only to dynamically-linked executables. It is not possible to intercept commands for statically-linked executables or executables that run under binary emulation this way. Because most dynamic loaders ignore

(or the equivalent) when running set-user-ID and set-group-ID programs,

will not permit such programs to be run in

mode by default. The

mechanism is incompatible with

SELinux RBAC support (but see below). SELinux disables

by default and interferes with file descriptor inheritance, which

relies on.

The second mechanism,

is available on Linux systems that support

filtering. It uses

and

to intercept the

system call instead of pre-loading a dynamic shared object. Both static and dynamic executables are supported and it is compatible with

SELinux RBAC mode. Functions utilizing the

system call, such as

are not currently intercepted. Programs that rely on

themselves, such as debuggers and system call tracers

such as

and

will be unable to function if

is enabled in

mode. This same restriction applies to the

sudoers option.

The

feature is known to work on Solaris, *BSD, Linux, macOS, HP-UX 11.x and AIX 5.3 and above. It should be supported on most operating systems that support the

environment variable or an equivalent. It is not possible to intercept shell built-in commands or restrict the ability to read or write sensitive files from within a shell.

To enable intercept mode on a per-command basis, use the

tag as documented in the User Specification section above. Here is that example again:

chuck research = INTERCEPT: ALL

This allows user

to run any command on the machine

in intercept mode. Any commands run via shell escapes will be validated and logged by

If you are unsure whether or not your system is capable of supporting

you can always just try it out and check whether or not external commands run via a shell are logged when

is enabled.

There is an inherent race condition between when a command is checked against

rules and when it is actually executed. If a user is allowed to run arbitrary commands, they may be able to change the

arguments in the program after the

policy check has completed but before the new command is executed. Starting with version 1.9.12, the

method will verify that the command and its arguments have not changed after

has completed but before execution of the new program has had a chance to run. This is not the case with the

method. See the description of the

setting for more information.

There are two separate but related ways to log additional commands. The first is to enable I/O logging using the

flag. This will log the command’s output but will not create an event log entry when the additional command is run. The second is to enable the

flag in

which will create an event log entry every time a new command is run. If I/O logging is also enabled, the log entry will include a time offset into the I/O log to indicate when the command was run. This offset can be passed to the

utility to replay the I/O log at the exact moment when the command was run. The

flag uses the same mechanism as

(see above) and has the same limitations.

functionality can be used to prevent a program run by

from executing any other programs. On most systems, it uses the same

mechanism as

(see above) and thus the same caveats apply. The

functionality is capable of blocking execution of commands run via the

and

functions. On Linux, a

filter is used to implement

On Solaris 10 and higher,

uses Solaris privileges instead of the

environment variable.

To enable

for a command, use the

tag as documented in the User Specification section above. Here is that example again:

aaron shanty = NOEXEC: /usr/bin/more, /usr/bin/vi

This allows user

to run

and

with

enabled. This will prevent those two commands from executing other commands (such as a shell). If you are unsure whether or not your system is capable of supporting

you can always just try it out and check whether shell escapes work when

is enabled.

Restricting shell escapes is not a panacea. Programs running as

are still capable of many potentially hazardous operations (such as changing or overwriting files) that could lead to unintended privilege escalation. In the specific case of an editor, a safer approach is to give the user permission to run

(see below).

The

plugin includes

support which allows users to securely edit files with the editor of their choice. As

is a built-in command, it must be specified in the

file without a leading path. However, it may take command line arguments just as a normal command does. Wildcards used in

command line arguments are expected to be path names, so a forward slash

will not be matched by a wildcard.

Unlike other

commands, the editor is run with the permissions of the invoking user and with the environment unmodified. More information may be found in the description of the

option in

For example, to allow user operator to edit the

file on any machine:

operator ALL = sudoedit /etc/motd

The operator user then runs

as follows:

$ sudoedit /etc/motd

The editor will run as the operator user, not

on a temporary copy of

After the file has been edited,

will be updated with the contents of the temporary copy.

Users should

be granted

permission to edit a file that resides in a directory the user has write access to, either directly or via a wildcard. If the user has write access to the directory it is possible to replace the legitimate file with a link to another file, allowing the editing of arbitrary files. To prevent this, starting with version 1.8.16, symbolic links will not be followed in writable directories and

will refuse to edit a file located in a writable directory unless the

option has been disabled or the invoking user is

Additionally, in version 1.8.15 and higher,

will refuse to open a symbolic link unless either the

option is enabled or the

command is prefixed with the

tag in the

file.

will check the ownership of its time stamp directory

by default

and ignore the directory’s contents if it is not owned by

or if it is writable by a user other than

Older versions of

stored time stamp files in

this is no longer recommended as it may be possible for a user to create the time stamp themselves on systems that allow unprivileged users to change the ownership of files they create.

While the time stamp directory

be cleared at reboot time, not all systems contain a

directory. To avoid potential problems,

will ignore time stamp files that date from before the machine booted on systems where the boot time is available.

Some systems with graphical desktop environments allow unprivileged users to change the system clock. Since

relies on the system clock for time stamp validation, it may be possible on such systems for a user to run

for longer than

by setting the clock back. To combat this,

uses a monotonic clock (which never moves backwards) for its time stamps if the system supports it.

will not honor time stamps set far in the future. Time stamps with a date greater than current_time + 2 *

will be ignored and

will log and complain.

If the

option is set to

the time stamp record includes the device number of the terminal the user authenticated with. This provides per-terminal granularity but time stamp records may still outlive the user’s session.

Unless the

option is set to

the time stamp record also includes the session ID of the process that last authenticated. This prevents processes in different terminal sessions from using the same time stamp record. On systems where a process’s start time can be queried, the start time of the session leader is recorded in the time stamp record. If no terminal is present or the

option is set to

the start time of the parent process is used instead. In most cases this will prevent a time stamp record from being re-used without the user entering a password when logging out and back in again.

Versions 1.8.4 and higher of the

plugin support a flexible debugging framework that can help track down what the plugin is doing internally if there is a problem. This can be configured in the

file.

The

plugin uses the same debug flag format as the

front-end:

The priorities used by

in order of decreasing severity, are:

and

Each priority, when specified, also includes all priorities higher than it. For example, a priority of

would include debug messages logged at

and higher.

The following subsystems are used by the

plugin:

and

processing

matches every subsystem

BSM and Linux audit code

user authentication

file

settings

environment handling

LDAP-based sudoers

logging support

matching of users, groups, hosts, and netgroups in the

file

network interface handling

network service switch handling in

file parsing

permission setting

The equivalent of

for the plugin.

pseudo-terminal related code

redblack tree internals

SSSD-based sudoers

utility functions

For example:

Debug sudoers.so /var/log/sudoers_debug match@info,nss@info

For more information, see the

manual.

Many people have worked on

over the years; this version consists of code written primarily by:

See the CONTRIBUTORS.md file in the

distribution (https://www.sudo.ws/about/contributors/) for an exhaustive list of people who have contributed to

The

file should

be edited by the

utility which locks the file and checks for syntax errors. If

contains syntax errors,

may refuse to run, which is a serious problem if

is your only method of obtaining superuser privileges. Recent versions of

will attempt to recover after a syntax error by ignoring the rest of the line after encountering an error. Older versions of

will not run if

contains a syntax error.

When using netgroups of machines (as opposed to users), if you store fully qualified host name in the netgroup (as is usually the case), you either need to have the machine’s host name be fully qualified as returned by the

command or use the

option in

If you believe you have found a bug in

you can submit a bug report at https://bugzilla.sudo.ws/

Limited free support is available via the sudo-users mailing list, see https://www.sudo.ws/mailman/listinfo/sudo-users to subscribe or search the archives.

is provided

or https://www.sudo.ws/about/license/ for complete details.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

338 - Linux cli command systemd.preset

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.preset and provides detailed information about the command systemd.preset, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.preset.

NAME 🖥️ systemd.preset 🖥️

Service enablement presets

SYNOPSIS

/etc/systemd/system-preset/*.preset

/run/systemd/system-preset/*.preset

/usr/local/lib/systemd/system-preset/*.preset

/usr/lib/systemd/system-preset/*.preset

/etc/systemd/user-preset/*.preset

/run/systemd/user-preset/*.preset

/usr/local/lib/systemd/user-preset/*.preset

/usr/lib/systemd/user-preset/*.preset

DESCRIPTION

Preset files may be used to encode policy which units shall be enabled by default and which ones shall be disabled. They are read by systemctl preset which uses this information to enable or disable a unit. Depending on that policy, systemctl preset is identical to systemctl enable or systemctl disable. systemctl preset is used by the post install scriptlets of rpm packages (or other OS package formats), to enable/disable specific units by default on package installation, enforcing distribution, spin, or administrator preset policy. This allows choosing a certain set of units to be enabled/disabled even before installing the actual package. For more information, see systemctl(1).

It is not recommended to ship preset files within the respective software packages implementing the units, but rather centralize them in a distribution or spin default policy, which can be amended by administrator policy, see below.

If no preset files exist, preset operations will enable all units that are installed by default. If this is not desired and all units shall rather be disabled, it is necessary to ship a preset file with a single, catchall “disable *” line. (See example 1, below.)

When the machine is booted for the first time, systemd(1) will enable/disable all units according to preset policy, similarly to systemctl preset-all. Also see ConditionFirstBoot= in systemd.unit(5) and “First Boot Semantics” in machine-id(5).

PRESET FILE FORMAT

The preset files contain a list of directives, one per line. Empty lines and lines whose first non-whitespace character is “#” or “;” are ignored. Each directive consists of one of the words “enable”, “disable”, or “ignore”, followed by whitespace and a unit name. The unit name may contain shell-style wildcards.

For the enable directive for template units, one or more instance names may be specified as a space-separated list after the unit name. In this case, those instances will be enabled instead of the instance specified via DefaultInstance= in the unit.

Presets must refer to the “real” unit file, and not to any aliases. See systemd.unit(5) for a description of unit aliasing.

Three different directives are understood: “enable” may be used to enable units by default, “disable” to disable units by default, and “ignore” to ignore units and leave existing configuration intact.

If multiple lines apply to a unit name, the first matching one takes precedence over all others.

Each preset file shall be named in the style of <priority>-<policy-name>.preset. Files in /etc/ override files with the same name in /usr/lib/ and /run/. Files in /run/ override files with the same name in /usr/lib/. Packages should install their preset files in /usr/lib/. Files in /etc/ are reserved for the local administrator, who may use this logic to override the preset files installed by vendor packages. All preset files are sorted by their filename in lexicographic order, regardless of which of the directories they reside in. If multiple files specify the same unit name, the entry in the file with the lexicographically earliest name will be applied. It is recommended to prefix all filenames with a two-digit number and a dash, to simplify the ordering of the files.

If the administrator wants to disable a preset file supplied by the vendor, the recommended way is to place a symlink to /dev/null in /etc/systemd/system-preset/ bearing the same filename.

EXAMPLES

Example 1. Default to off

/usr/lib/systemd/system-preset/99-default.preset
disable *

This disables all units. Due to the filename prefix “99-”, it will be read last and hence can easily be overridden by spin or administrator preset policy.

Example 2. Enable multiple template instances

/usr/lib/systemd/system-preset/80-dirsrv.preset
enable [email protected] foo bar baz

This enables all three of [email protected], [email protected] and [email protected].

Example 3. A GNOME spin

/usr/lib/systemd/system-preset/50-gnome.preset
enable gdm.service
enable colord.service
enable accounts-daemon.service
enable avahi-daemon.*

This enables the three mentioned units, plus all avahi-daemon regardless of which unit type. A file like this could be useful for inclusion in a GNOME spin of a distribution. It will ensure that the units necessary for GNOME are properly enabled as they are installed. It leaves all other units untouched, and subject to other (later) preset files, for example like the one from the first example above.

Example 4. Administrator policy

/etc/systemd/system-preset/00-lennart.preset
enable httpd.service
enable sshd.service
enable postfix.service
disable *

This enables three specific services and disables all others. This is useful for administrators to specifically select the units to enable, and disable all others. Due to the filename prefix “00-” it will be read early and override all other preset policy files.

MOTIVATION FOR THE PRESET LOGIC

Different distributions have different policies on which services shall be enabled by default when the package they are shipped in is installed. On Fedora all services stay off by default, so that installing a package will not cause a service to be enabled (with some exceptions). On Debian all services are immediately enabled by default, so that installing a package will cause its services to be enabled right-away.

Even within a single distribution, different spins (flavours, remixes, whatever you might want to call them) of a distribution also have different policies on what services to enable, and what services to leave off. For example, Fedora Workstation will enable gdm as display manager by default, while the Fedora KDE spin will enable sddm instead.

Different sites might also have different policies what to turn on by default and what to turn off. For example, one administrator would prefer to enforce the policy of “sshd should be always on, but everything else off”, while another one might say “snmpd always on, and for everything else use the distribution policy defaults”.

Traditionally, policy about which services shall be enabled were implemented in each package individually. This made it cumbersome to implement different policies per spin or per site, or to create software packages that do the right thing on more than one distribution. The enablement mechanism was also encoding the enablement policy.

The preset mechanism allows clean separation of the enablement mechanism (inside the package scriptlets, by invoking systemctl preset) and enablement policy (centralized in the preset files), and lifts the configuration out of individual packages. Preset files may be written for specific distributions, for specific spins or for specific sites, in order to enforce different policies as needed. It is recommended to apply the policy encoded in preset files in package installation scriptlets.

NOTES

Features/PackagePresets

https://fedoraproject.org/wiki/Features/PackagePresets

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

339 - Linux cli command [email protected]

NAME 🖥️ [email protected] 🖥️

[email protected], systemd-user-runtime-dir - System units to start the user manager

SYNOPSIS

user@UID.service

user-runtime-dir@UID.service

/usr/lib/systemd/systemd-user-runtime-dir

user-UID.slice

DESCRIPTION

Individual user-UID.slice slices are collected under user.slice, see systemd.special(7).

CONTROLLING RESOURCES FOR LOGGED-IN USERS

In general any resources that apply to units may be set for user@UID.service and the slice units discussed above, see systemd.resource-control(5) for an overview.

EXAMPLES

Example 1. Hierarchy of control groups with two logged in users

$ systemd-cgls Control group /: -.slice ├─user.slice │ ├─user-1000.slice │ │ ├─[email protected] │ │ │ ├─pulseaudio.service │ │ │ │ └─2386 /usr/bin/pulseaudio –daemonize=no │ │ │ └─gnome-terminal-server.service │ │ │ └─init.scope │ │ │ ├─ 4127 /usr/libexec/gnome-terminal-server │ │ │ └─ 4198 zsh │ │ … │ │ └─session-4.scope │ │ ├─ 1264 gdm-session-worker [pam/gdm-password] │ │ ├─ 2339 /usr/bin/gnome-shell │ │ … │ │ ├─session-19.scope │ │ ├─6497 sshd: zbyszek [priv] │ │ ├─6502 sshd: zbyszek@pts/6 │ │ ├─6509 -zsh │ │ └─6602 systemd-cgls –no-pager │ … │ └─user-1001.slice │ ├─session-20.scope │ │ ├─6675 sshd: guest [priv] │ │ ├─6708 sshd: guest@pts/6 │ │ └─6717 -bash │ └─[email protected] │ ├─init.scope │ │ ├─6680 /usr/lib/systemd/systemd –user │ │ └─6688 (sd-pam) │ └─sleep.service │ └─6706 /usr/bin/sleep 30 …

Example 2. Default user resource limits

$ systemctl cat user-1000.slice # /usr/lib/systemd/system/user-.slice.d/10-defaults.conf # … [Unit] Description=User Slice of UID %j After=systemd-user-sessions.service
[Slice]
TasksMax=33%

340 - Linux cli command org.bluez.GattManager

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.GattManager and provides detailed information about the command org.bluez.GattManager, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.GattManager.

NAME 🖥️ org.bluez.GattManager 🖥️

BlueZ D-Bus GattManager API documentation

DESCRIPTION

GATT Manager allows external applications to register GATT services and profiles.

Registering a profile allows applications to subscribe to remote/client services.

Registering a service allows applications to publish a local/server GATT service, which then becomes available to remote devices. A GATT service is represented by a D-Bus object hierarchy where the root node corresponds to a service and the child nodes represent characteristics and descriptors that belong to that service. Each node must implement one of org.bluez.GattService(5), org.bluez.GattCharacteristic(5) or org.bluez.GattDescriptor(5) interfaces, based on the attribute it represents. Each node must also implement the standard D-Bus Properties interface to expose their properties. These objects collectively represent a GATT service definition.

To make service registration simple, bluetoothd(8) requires that all objects that belong to a GATT service be grouped under a D-Bus Object Manager that solely manages the objects of that service. Hence, the standard DBus.ObjectManager interface must be available on the root service path. An example application hierarchy containing two separate GATT services may look like this:

-> /com/example | - org.freedesktop.DBus.ObjectManager | -> /com/example/service0 | | - org.freedesktop.DBus.Properties | | - org.bluez.GattService1 | | | -> /com/example/service0/char0 | | - org.freedesktop.DBus.Properties | | - org.bluez.GattCharacteristic1 | | | -> /com/example/service0/char1 | | - org.freedesktop.DBus.Properties | | - org.bluez.GattCharacteristic1 | | | -> /com/example/service0/char1/desc0 | - org.freedesktop.DBus.Properties | - org.bluez.GattDescriptor1 | -> /com/example/service1 | - org.freedesktop.DBus.Properties | - org.bluez.GattService1 | -> /com/example/service1/char0 - org.freedesktop.DBus.Properties - org.bluez.GattCharacteristic1

When a service is registered, bluetoothd(8) will automatically obtain information about all objects using the service’s Object Manager. Once a service has been registered, the objects of a service should not be removed. If bluetoothd(8) receives an InterfacesRemoved signal from a service’s Object Manager, it will immediately unregister the service. Similarly, if the application disconnects from the bus, all of its registered services will be automatically unregistered. InterfacesAdded signals will be ignored.

INTERFACE

Service
org.bluez
Interface
org.bluez.GattManager1
Object path
[variable prefix]/{hci0,hci1,…}

Methods

void RegisterApplication(object application, dict options)

Registers a local GATT services hierarchy as described above (GATT Server) and/or GATT profiles (GATT Client).
The application object path together with the D-Bus system bus connection ID define the identification of the application registering a GATT based service (org.bluez.GattService(5)) and/or profile (org.bluez.GattProfile(5)).
Possible errors:
org.bluez.Error.InvalidArguments
org.bluez.Error.AlreadyExists

void UnregisterApplication(object application)

This unregisters the services and/or profiles that has been previously registered using RegisterApplication(). The object path parameter must match the same value that has been used on registration.
Possible errors:
org.bluez.Error.InvalidArguments
org.bluez.Error.DoesNotExist

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

341 - Linux cli command [email protected]

NAME 🖥️ [email protected] 🖥️

Journal service configuration files

SYNOPSIS

/etc/systemd/journald.conf

/run/systemd/journald.conf

/usr/local/lib/systemd/journald.conf

/usr/lib/systemd/journald.conf

/etc/systemd/journald.conf.d/*.conf

/run/systemd/journald.conf.d/*.conf

/usr/local/lib/systemd/journald.conf.d/*.conf

/usr/lib/systemd/journald.conf.d/*.conf

/etc/systemd/journald@NAMESPACE.conf

/etc/systemd/journald@NAMESPACE.conf.d/*.conf

/run/systemd/journald@NAMESPACE.conf.d/*.conf

/usr/local/lib/systemd/journald@NAMESPACE.conf.d/*.conf

/usr/lib/systemd/journald@NAMESPACE.conf.d/*.conf

DESCRIPTION

These files configure various parameters of the systemd journal service, systemd-journald.service(8). See systemd.syntax(7) for a general description of the syntax.

CONFIGURATION DIRECTORIES AND PRECEDENCE

OPTIONS

All options are configured in the [Journal] section:

Storage=

Controls where to store journal data. One of “volatile”, “persistent”, “auto” and “none”. If “volatile”, journal log data will be stored only in memory, i.e. below the /run/log/journal hierarchy (which is created if needed). If “persistent”, data will be stored preferably on disk, i.e. below the /var/log/journal hierarchy (which is created if needed), with a fallback to /run/log/journal (which is created if needed), during early boot and if the disk is not writable. “auto” behaves like “persistent” if the /var/log/journal directory exists, and “volatile” otherwise (the existence of the directory controls the storage mode). “none” turns off all storage, all log data received will be dropped (but forwarding to other targets, such as the console, the kernel log buffer, or a syslog socket will still work). Defaults to “auto” in the default journal namespace, and “persistent” in all others.
Note that journald will initially use volatile storage, until a call to journalctl –flush (or sending SIGUSR1 to journald) will cause it to switch to persistent logging (under the conditions mentioned above). This is done automatically on boot via “systemd-journal-flush.service”.
Note that when this option is changed to “volatile”, existing persistent data is not removed. In the other direction, journalctl(1) with the –flush option may be used to move volatile data to persistent storage.
When journal namespacing (see LogNamespace= in systemd.exec(5)) is used, setting Storage= to “volatile” or “auto” will not have an effect on the creation of the per-namespace logs directory in /var/log/journal/, as the [email protected] service file by default carries LogsDirectory=. To turn that off, add a unit file drop-in file that sets LogsDirectory= to an empty string.
Note that per-user journal files are not supported unless persistent storage is enabled, thus making journalctl –user unavailable.
The storage to use can also be specified via the “journal.storage” credential. Values configured via configuration files take priority over values configured via the credential.
Added in version 186.

Compress=

Can take a boolean value. If enabled (the default), data objects that shall be stored in the journal and are larger than the default threshold of 512 bytes are compressed before they are written to the file system. It can also be set to a number of bytes to specify the compression threshold directly. Suffixes like K, M, and G can be used to specify larger units.

Seal=

Takes a boolean value. If enabled (the default), and a sealing key is available (as created by journalctl(1)s –setup-keys command), Forward Secure Sealing (FSS) for all persistent journal files is enabled. FSS is based on Seekable Sequential Key Generators[2] by G. A. Marson and B. Poettering (doi:10.1007/978-3-642-40203-6_7) and may be used to protect journal files from unnoticed alteration.
Added in version 189.

SplitMode=

Controls whether to split up journal files per user, either “uid” or “none”. Split journal files are primarily useful for access control: on UNIX/Linux access control is managed per file, and the journal daemon will assign users read access to their journal files. If “uid”, all regular users (with UID outside the range of system users, dynamic service users, and the nobody user) will each get their own journal files, and system users will log to the system journal. See Users, Groups, UIDs and GIDs on systemd systems[3] for more details about UID ranges. If “none”, journal files are not split up by user and all messages are instead stored in the single system journal. In this mode unprivileged users generally do not have access to their own log data. Note that splitting up journal files by user is only available for journals stored persistently. If journals are stored on volatile storage (see Storage= above), only a single journal file is used. Defaults to “uid”.
Added in version 190.

RateLimitIntervalSec=, RateLimitBurst=

Configures the rate limiting that is applied to all messages generated on the system. If, in the time interval defined by RateLimitIntervalSec=, more messages than specified in RateLimitBurst= are logged by a service, all further messages within the interval are dropped until the interval is over. A message about the number of dropped messages is generated. This rate limiting is applied per-service, so that two services which log do not interfere with each others limits. Defaults to 10000 messages in 30s. The time specification for RateLimitIntervalSec= may be specified in the following units: “s”, “min”, “h”, “ms”, “us”. To turn off any kind of rate limiting, set either value to 0.
Note that the effective rate limit is multiplied by a factor derived from the available free disk space for the journal. Currently, this factor is calculated using the base 2 logarithm.
Table 1. Example RateLimitBurst= rate modifications by the available disk space
Available Disk Space Burst Multiplier
<= 1MB 1
<= 16MB 2
<= 256MB 3
<= 4GB 4
<= 64GB 5
<= 1TB 6
If a service provides rate limits for itself through LogRateLimitIntervalSec= and/or LogRateLimitBurst= in systemd.exec(5), those values will override the settings specified here.

SystemMaxUse=, SystemKeepFree=, SystemMaxFileSize=, SystemMaxFiles=, RuntimeMaxUse=, RuntimeKeepFree=, RuntimeMaxFileSize=, RuntimeMaxFiles=

Enforce size limits on the journal files stored. The options prefixed with “System” apply to the journal files when stored on a persistent file system, more specifically /var/log/journal. The options prefixed with “Runtime” apply to the journal files when stored on a volatile in-memory file system, more specifically /run/log/journal. The former is used only when /var/ is mounted, writable, and the directory /var/log/journal exists. Otherwise, only the latter applies. Note that this means that during early boot and if the administrator disabled persistent logging, only the latter options apply, while the former apply if persistent logging is enabled and the system is fully booted up. journalctl and systemd-journald ignore all files with names not ending with “.journal” or “.journal~”, so only such files, located in the appropriate directories, are taken into account when calculating current disk usage.
SystemMaxUse= and RuntimeMaxUse= control how much disk space the journal may use up at most. SystemKeepFree= and RuntimeKeepFree= control how much disk space systemd-journald shall leave free for other uses. systemd-journald will respect both limits and use the smaller of the two values.
The first pair defaults to 10% and the second to 15% of the size of the respective file system, but each value is capped to 4G. If the file system is nearly full and either SystemKeepFree= or RuntimeKeepFree= are violated when systemd-journald is started, the limit will be raised to the percentage that is actually free. This means that if there was enough free space before and journal files were created, and subsequently something else causes the file system to fill up, journald will stop using more space, but it will not be removing existing files to reduce the footprint again, either. Also note that only archived files are deleted to reduce the space occupied by journal files. This means that, in effect, there might still be more space used than SystemMaxUse= or RuntimeMaxUse= limit after a vacuuming operation is complete.
SystemMaxFileSize= and RuntimeMaxFileSize= control how large individual journal files may grow at most. This influences the granularity in which disk space is made available through rotation, i.e. deletion of historic data. Defaults to one eighth of the values configured with SystemMaxUse= and RuntimeMaxUse= capped to 128M, so that usually seven rotated journal files are kept as history. If the journal compact mode is enabled (enabled by default), the maximum file size is capped to 4G.
Specify values in bytes or use K, M, G, T, P, E as units for the specified sizes (equal to 1024, 1024², … bytes). Note that size limits are enforced synchronously when journal files are extended, and no explicit rotation step triggered by time is needed.
SystemMaxFiles= and RuntimeMaxFiles= control how many individual journal files to keep at most. Note that only archived files are deleted to reduce the number of files until this limit is reached; active files will stay around. This means that, in effect, there might still be more journal files around in total than this limit after a vacuuming operation is complete. This setting defaults to 100.

MaxFileSec=

The maximum time to store entries in a single journal file before rotating to the next one. Normally, time-based rotation should not be required as size-based rotation with options such as SystemMaxFileSize= should be sufficient to ensure that journal files do not grow without bounds. However, to ensure that not too much data is lost at once when old journal files are deleted, it might make sense to change this value from the default of one month. Set to 0 to turn off this feature. This setting takes time values which may be suffixed with the units “year”, “month”, “week”, “day”, “h” or “m” to override the default time unit of seconds.
Added in version 195.

MaxRetentionSec=

The maximum time to store journal entries. This controls whether journal files containing entries older than the specified time span are deleted. Normally, time-based deletion of old journal files should not be required as size-based deletion with options such as SystemMaxUse= should be sufficient to ensure that journal files do not grow without bounds. However, to enforce data retention policies, it might make sense to change this value from the default of 0 (which turns off this feature). This setting also takes time values which may be suffixed with the units “year”, “month”, “week”, “day”, “h” or " m" to override the default time unit of seconds.
Added in version 195.

SyncIntervalSec=

The timeout before synchronizing journal files to disk. After syncing, journal files are placed in the OFFLINE state. Note that syncing is unconditionally done immediately after a log message of priority CRIT, ALERT or EMERG has been logged. This setting hence applies only to messages of the levels ERR, WARNING, NOTICE, INFO, DEBUG. The default timeout is 5 minutes.
Added in version 199.

ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole=, ForwardToWall=, ForwardToSocket=

Control whether log messages received by the journal daemon shall be forwarded to a traditional syslog daemon, to the kernel log buffer (kmsg), to the system console, sent as wall messages to all logged-in users or sent over a socket. These options take boolean arguments except for “ForwardToSocket=” which takes an address instead. If forwarding to syslog is enabled but nothing reads messages from the socket, forwarding to syslog has no effect. By default, only forwarding to wall is enabled. These settings may be overridden at boot time with the kernel command line options “systemd.journald.forward_to_syslog”, “systemd.journald.forward_to_kmsg”, “systemd.journald.forward_to_console”, and “systemd.journald.forward_to_wall”. If the option name is specified without “=” and the following argument, true is assumed. Otherwise, the argument is parsed as a boolean.
The socket forwarding address can be specified with the credential “journal.forward_to_socket”. The following socket types are supported:
AF_INET (e.g. “192.168.0.11:4444”), AF_INET6 (e.g. “[2001:db8::ff00:42:8329]:4444”), AF_UNIX (e.g. “/run/host/journal/socket”), AF_VSOCK (e.g. “vsock:2:1234”)
When forwarding to the console, the TTY to log to can be changed with TTYPath=, described below.
When forwarding to the kernel log buffer (kmsg), make sure to select a suitably large size for the log buffer, for example by adding “log_buf_len=8M” to the kernel command line. systemd will automatically disable kernels rate-limiting applied to userspace processes (equivalent to setting “printk.devkmsg=on”).
When forwarding over a socket the Journal Export Format[4] is used when sending over the wire. Notably this includes the metadata field __REALTIME_TIMESTAMP so that systemd-journal-remote (see systemd-journal-remote.service(8)) can be used to receive the forwarded journal entries.
Note: Forwarding is performed synchronously within journald, and may significantly affect its performance. This is particularly relevant when using ForwardToConsole=yes in cloud environments, where the console is often a slow, virtual serial port. Since journald is implemented as a conventional single-process daemon, forwarding to a completely hung console will block journald. This can have a cascading effect resulting in any services synchronously logging to the blocked journal also becoming blocked. Unless actively debugging/developing something, its generally preferable to setup a journalctl –follow style service redirected to the console, instead of ForwardToConsole=yes, for production use.
Note: Using ForwardToSocket= over IPv4/IPv6 links can be very slow due to the synchronous nature of the sockets. Take care to ensure your link is a low-latency local link if possible. Typically IP networking is not available everywhere journald runs, e.g. in the initrd during boot. Consider using AF_VSOCK/AF_UNIX sockets for this if possible.

MaxLevelStore=, MaxLevelSyslog=, MaxLevelKMsg=, MaxLevelConsole=, MaxLevelWall=, MaxLevelSocket=

Controls the maximum log level of messages that are stored in the journal, forwarded to syslog, kmsg, the console, the wall, or a socket (if that is enabled, see above). As argument, takes one of “emerg”, “alert”, “crit”, “err”, “warning”, “notice”, “info”, “debug”, or integer values in the range of 0–7 (corresponding to the same levels). Messages equal or below the log level specified are stored/forwarded, messages above are dropped. Defaults to “debug” for MaxLevelStore=, MaxLevelSyslog= and MaxLevelSocket=, to ensure that the all messages are stored in the journal, forwarded to syslog and the socket if one exists. Defaults to “notice” for MaxLevelKMsg=, “info” for MaxLevelConsole=, and “emerg” for MaxLevelWall=. These settings may be overridden at boot time with the kernel command line options “systemd.journald.max_level_store=”, “systemd.journald.max_level_syslog=”, “systemd.journald.max_level_kmsg=”, “systemd.journald.max_level_console=”, “systemd.journald.max_level_wall=”, “systemd.journald.max_level_socket=”.
Added in version 185.

ReadKMsg=

Takes a boolean value. If enabled systemd-journal processes /dev/kmsg messages generated by the kernel. In the default journal namespace this option is enabled by default, it is disabled in all others.
Added in version 235.

Audit=

Takes a boolean value. If enabled systemd-journald will turn on kernel auditing on start-up. If disabled it will turn it off. If unset it will neither enable nor disable it, leaving the previous state unchanged. This means if another tool turns on auditing even if systemd-journald left it off, it will still collect the generated messages. Defaults to on.
Note that this option does not control whether systemd-journald collects generated audit records, it just controls whether it tells the kernel to generate them. If you need to prevent systemd-journald from collecting the generated messages, the socket unit “systemd-journald-audit.socket” can be disabled and in this case this setting is without effect.
Added in version 246.

TTYPath=

Change the console TTY to use if ForwardToConsole=yes is used. Defaults to /dev/console.
Added in version 185.

LineMax=

The maximum line length to permit when converting stream logs into record logs. When a systemd units standard output/error are connected to the journal via a stream socket, the data read is split into individual log records at newline (" “, ASCII 10) and NUL characters. If no such delimiter is read for the specified number of bytes a hard log record boundary is artificially inserted, breaking up overly long lines into multiple log records. Selecting overly large values increases the possible memory usage of the Journal daemon for each stream client, as in the worst case the journal daemon needs to buffer the specified number of bytes in memory before it can flush a new log record to disk. Also note that permitting overly large line maximum line lengths affects compatibility with traditional log protocols as log records might not fit anymore into a single AF_UNIX or AF_INET datagram. Takes a size in bytes. If the value is suffixed with K, M, G or T, the specified size is parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. Defaults to 48K, which is relatively large but still small enough so that log records likely fit into network datagrams along with extra room for metadata. Note that values below 79 are not accepted and will be bumped to 79.
Added in version 235.

FORWARDING TO TRADITIONAL SYSLOG DAEMONS

NOTES

Seekable Sequential Key Generators

https://eprint.iacr.org/2013/397

Users, Groups, UIDs and GIDs on systemd systems

https://systemd.io/UIDS-GIDS

Journal Export Format

https://systemd.io/JOURNAL_EXPORT_FORMATS/#journal-export-format

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

342 - Linux cli command pam.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command pam.conf and provides detailed information about the command pam.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the pam.conf.

NAME 🖥️ pam.conf 🖥️

PAM configuration files

DESCRIPTION

When a PAM aware privilege granting application is started, it activates its attachment to the PAM-API. This activation performs a number of tasks, the most important being the reading of the configuration file(s): /etc/pam.conf. Alternatively and preferably, the configuration can be set by individual configuration files located in a pam.d directory. The presence of this directory will cause Linux-PAM to ignore /etc/pam.conf.

These files list the PAMs that will do the authentication tasks required by this service, and the appropriate behavior of the PAM-API in the event that individual PAMs fail.

The syntax of the /etc/pam.conf configuration file is as follows. The file is made up of a list of rules, each rule is typically placed on a single line, but may be extended with an escaped end of line: `\LF>. Comments are preceded with `# marks and extend to the next end of line.

The format of each rule is a space separated collection of tokens, the first three being case-insensitive:

service type control module-path module-arguments

The syntax of files contained in the /etc/pam.d/ directory, are identical except for the absence of any service field. In this case, the service is the name of the file in the /etc/pam.d/ directory. This filename must be in lower case.

An important feature of PAM, is that a number of rules may be stacked to combine the services of a number of PAMs for a given authentication task.

The service is typically the familiar name of the corresponding application: login and su are good examples. The service-name, other, is reserved for giving default rules. Only lines that mention the current service (or in the absence of such, the other entries) will be associated with the given service-application.

The type is the management group that the rule corresponds to. It is used to specify which of the management groups the subsequent module is to be associated with. Valid entries are:

account

this module type performs non-authentication based account management. It is typically used to restrict/permit access to a service based on the time of day, currently available system resources (maximum number of users) or perhaps the location of the applicant user – root login only on the console.

auth

this module type provides two aspects of authenticating the user. Firstly, it establishes that the user is who they claim to be, by instructing the application to prompt the user for a password or other means of identification. Secondly, the module can grant group membership or other privileges through its credential granting properties.

password

this module type is required for updating the authentication token associated with the user. Typically, there is one module for each challenge/response based authentication (auth) type.

session

this module type is associated with doing things that need to be done for the user before/after they can be given service. Such things include the logging of information concerning the opening/closing of some data exchange with a user, mounting directories, etc.

If the type value from the list above is prepended with a - character the PAM library will not log to the system log if it is not possible to load the module because it is missing in the system. This can be useful especially for modules which are not always installed on the system and are not required for correct authentication and authorization of the login session.

The third field, control, indicates the behavior of the PAM-API should the module fail to succeed in its authentication task. There are two types of syntax for this control field: the simple one has a single simple keyword; the more complicated one involves a square-bracketed selection of value=action pairs.

For the simple (historical) syntax valid control values are:

required

failure of such a PAM will ultimately lead to the PAM-API returning failure but only after the remaining stacked modules (for this service and type) have been invoked.

requisite

like required, however, in the case that such a module returns a failure, control is directly returned to the application or to the superior PAM stack. The return value is that associated with the first required or requisite module to fail. Note, this flag can be used to protect against the possibility of a user getting the opportunity to enter a password over an unsafe medium. It is conceivable that such behavior might inform an attacker of valid accounts on a system. This possibility should be weighed against the not insignificant concerns of exposing a sensitive password in a hostile environment.

sufficient

if such a module succeeds and no prior required module has failed the PAM framework returns success to the application or to the superior PAM stack immediately without calling any further modules in the stack. A failure of a sufficient module is ignored and processing of the PAM module stack continues unaffected.

optional

the success or failure of this module is only important if it is the only module in the stack associated with this service+type.

include

include all lines of given type from the configuration file specified as an argument to this control.

substack

include all lines of given type from the configuration file specified as an argument to this control. This differs from include in that evaluation of the done and die actions in a substack does not cause skipping the rest of the complete module stack, but only of the substack. Jumps in a substack also can not make evaluation jump out of it, and the whole substack is counted as one module when the jump is done in a parent stack. The reset action will reset the state of a module stack to the state it was in as of beginning of the substack evaluation.

For the more complicated syntax valid control values have the following form:

  [value1=action1 value2=action2 ...]

Where valueN corresponds to the return code from the function invoked in the module for which the line is defined. It is selected from one of these: success, open_err, symbol_err, service_err, system_err, buf_err, perm_denied, auth_err, cred_insufficient, authinfo_unavail, user_unknown, maxtries, new_authtok_reqd, acct_expired, session_err, cred_unavail, cred_expired, cred_err, no_module_data, conv_err, authtok_err, authtok_recover_err, authtok_lock_busy, authtok_disable_aging, try_again, ignore, abort, authtok_expired, module_unknown, bad_item, conv_again, incomplete, and default.

The last of these, default, implies all valueNs not mentioned explicitly. Note, the full list of PAM errors is available in /usr/include/security/_pam_types.h. The actionN can take one of the following forms:

ignore

when used with a stack of modules, the modules return status will not contribute to the return code the application obtains.

bad

this action indicates that the return code should be thought of as indicative of the module failing. If this module is the first in the stack to fail, its status value will be used for that of the whole stack. This is the default action for all return codes.

die

equivalent to bad with the side effect of terminating the module stack and PAM immediately returning to the application.

this tells PAM that the administrator thinks this return code should contribute directly to the return code of the full stack of modules. In other words, if the former state of the stack would lead to a return of PAM_SUCCESS, the modules return code will override this value. Note, if the former state of the stack holds some value that is indicative of a modules failure, this ok value will not be used to override that value.

done

equivalent to ok with the side effect of terminating the module stack and PAM immediately returning to the application unless there was a non-ignored module failure before.

N (an unsigned integer)

jump over the next N modules in the stack. Note that N equal to 0 is not allowed, it would be treated as ignore in such case. The side effect depends on the PAM function call: for pam_authenticate, pam_acct_mgmt, pam_chauthtok, and pam_open_session it is ignore; for pam_setcred and pam_close_session it is one of ignore, ok, or bad depending on the modules return value.

reset

clear all memory of the state of the module stack and start again with the next stacked module.

If a return codes action is not specifically defined via a valueN token, and the default value is not specified, that return codes action defaults to bad.

Each of the four keywords: required; requisite; sufficient; and optional, have an equivalent expression in terms of the […] syntax. They are as follows:

required

[success=ok new_authtok_reqd=ok ignore=ignore default=bad]

requisite

[success=ok new_authtok_reqd=ok ignore=ignore default=die]

sufficient

[success=done new_authtok_reqd=done default=ignore]

optional

[success=ok new_authtok_reqd=ok default=ignore]

module-path is either the full filename of the PAM to be used by the application (it begins with a /), or a relative pathname from the default module location: /lib/security/ or /lib64/security/, depending on the architecture.

module-arguments are a space separated list of tokens that can be used to modify the specific behavior of the given PAM. Such arguments will be documented for each individual module. Note, if you wish to include spaces in an argument, you should surround that argument with square brackets.

squid auth required pam_mysql.so user=passwd_query passwd=mada \
          db=eminence [query=select user_name from internet_service \
          where user_name=%u and password=PASSWORD(%p) and \
        service=web_proxy]

When using this convention, you can include `[ characters inside the string, and if you wish to include a `] character inside the string that will survive the argument parsing, you should use `. In other words:

[..[..\]..]    -->   ..[..]..

Any line in (one of) the configuration file(s), that is not formatted correctly, will generally tend (erring on the side of caution) to make the authentication process fail. A corresponding error is written to the system log files with a call to syslog(3).

More flexible than the single configuration file is it to configure libpam via the contents of pam.d directories. In this case the directories are filled with files each of which has a filename equal to a service-name (in lower-case): it is the personal configuration file for the named service.

Vendor-supplied PAM configuration files might be installed in the system directory /usr/lib/pam.d/ or a configurable vendor specific directory instead of the machine configuration directory /etc/pam.d/. If no machine configuration file is found, the vendor-supplied file is used. All files in /etc/pam.d/ override files with the same name in other directories.

The syntax of each file in pam.d is similar to that of the /etc/pam.conf file and is made up of lines of the following form:

type control module-path module-arguments

The only difference being that the service-name is not present. The service-name is of course the name of the given configuration file. For example, /etc/pam.d/login contains the configuration for the login service.

FILES

/etc/pam.conf

the configuration file

/etc/pam.d

the Linux-PAM configuration directory. Generally, if this directory is present, the /etc/pam.conf file is ignored.

/usr/lib/pam.d

the Linux-PAM vendor configuration directory. Files in /etc/pam.d override files with the same name in this directory.

343 - Linux cli command proc_vmstat

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_vmstat and provides detailed information about the command proc_vmstat, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_vmstat.

NAME 🖥️ proc_vmstat 🖥️

virtual memory statistics

DESCRIPTION

/proc/vmstat (since Linux 2.6.0)
This file displays various virtual memory statistics. Each line of this file contains a single name-value pair, delimited by white space. Some lines are present only if the kernel was configured with suitable options. (In some cases, the options required for particular files have changed across kernel versions, so they are not listed here. Details can be found by consulting the kernel source code.) The following fields may be present:

nr_free_pages (since Linux 2.6.31)
nr_alloc_batch (since Linux 3.12)
nr_inactive_anon (since Linux 2.6.28)
nr_active_anon (since Linux 2.6.28)
nr_inactive_file (since Linux 2.6.28)
nr_active_file (since Linux 2.6.28)
nr_unevictable (since Linux 2.6.28)
nr_mlock (since Linux 2.6.28)
nr_anon_pages (since Linux 2.6.18)
nr_mapped (since Linux 2.6.0)
nr_file_pages (since Linux 2.6.18)
nr_dirty (since Linux 2.6.0)
nr_writeback (since Linux 2.6.0)
nr_slab_reclaimable (since Linux 2.6.19)
nr_slab_unreclaimable (since Linux 2.6.19)
nr_page_table_pages (since Linux 2.6.0)
nr_kernel_stack (since Linux 2.6.32)
Amount of memory allocated to kernel stacks.

nr_unstable (since Linux 2.6.0)
nr_bounce (since Linux 2.6.12)
nr_vmscan_write (since Linux 2.6.19)
nr_vmscan_immediate_reclaim (since Linux 3.2)
nr_writeback_temp (since Linux 2.6.26)
nr_isolated_anon (since Linux 2.6.32)
nr_isolated_file (since Linux 2.6.32)
nr_shmem (since Linux 2.6.32)
Pages used by shmem and tmpfs(5).

nr_dirtied (since Linux 2.6.37)
nr_written (since Linux 2.6.37)
nr_pages_scanned (since Linux 3.17)
numa_hit (since Linux 2.6.18)
numa_miss (since Linux 2.6.18)
numa_foreign (since Linux 2.6.18)
numa_interleave (since Linux 2.6.18)
numa_local (since Linux 2.6.18)
numa_other (since Linux 2.6.18)
workingset_refault (since Linux 3.15)
workingset_activate (since Linux 3.15)
workingset_nodereclaim (since Linux 3.15)
nr_anon_transparent_hugepages (since Linux 2.6.38)
nr_free_cma (since Linux 3.7)
Number of free CMA (Contiguous Memory Allocator) pages.

nr_dirty_threshold (since Linux 2.6.37)
nr_dirty_background_threshold (since Linux 2.6.37)
pgpgin (since Linux 2.6.0)
pgpgout (since Linux 2.6.0)
pswpin (since Linux 2.6.0)
pswpout (since Linux 2.6.0)
pgalloc_dma (since Linux 2.6.5)
pgalloc_dma32 (since Linux 2.6.16)
pgalloc_normal (since Linux 2.6.5)
pgalloc_high (since Linux 2.6.5)
pgalloc_movable (since Linux 2.6.23)
pgfree (since Linux 2.6.0)
pgactivate (since Linux 2.6.0)
pgdeactivate (since Linux 2.6.0)
pgfault (since Linux 2.6.0)
pgmajfault (since Linux 2.6.0)
pgrefill_dma (since Linux 2.6.5)
pgrefill_dma32 (since Linux 2.6.16)
pgrefill_normal (since Linux 2.6.5)
pgrefill_high (since Linux 2.6.5)
pgrefill_movable (since Linux 2.6.23)
pgsteal_kswapd_dma (since Linux 3.4)
pgsteal_kswapd_dma32 (since Linux 3.4)
pgsteal_kswapd_normal (since Linux 3.4)
pgsteal_kswapd_high (since Linux 3.4)
pgsteal_kswapd_movable (since Linux 3.4)
pgsteal_direct_dma
pgsteal_direct_dma32 (since Linux 3.4)
pgsteal_direct_normal (since Linux 3.4)
pgsteal_direct_high (since Linux 3.4)
pgsteal_direct_movable (since Linux 2.6.23)
pgscan_kswapd_dma
pgscan_kswapd_dma32 (since Linux 2.6.16)
pgscan_kswapd_normal (since Linux 2.6.5)
pgscan_kswapd_high
pgscan_kswapd_movable (since Linux 2.6.23)
pgscan_direct_dma
pgscan_direct_dma32 (since Linux 2.6.16)
pgscan_direct_normal
pgscan_direct_high
pgscan_direct_movable (since Linux 2.6.23)
pgscan_direct_throttle (since Linux 3.6)
zone_reclaim_failed (since linux 2.6.31)
pginodesteal (since linux 2.6.0)
slabs_scanned (since linux 2.6.5)
kswapd_inodesteal (since linux 2.6.0)
kswapd_low_wmark_hit_quickly (since Linux 2.6.33)
kswapd_high_wmark_hit_quickly (since Linux 2.6.33)
pageoutrun (since Linux 2.6.0)
allocstall (since Linux 2.6.0)
pgrotated (since Linux 2.6.0)
drop_pagecache (since Linux 3.15)
drop_slab (since Linux 3.15)
numa_pte_updates (since Linux 3.8)
numa_huge_pte_updates (since Linux 3.13)
numa_hint_faults (since Linux 3.8)
numa_hint_faults_local (since Linux 3.8)
numa_pages_migrated (since Linux 3.8)
pgmigrate_success (since Linux 3.8)
pgmigrate_fail (since Linux 3.8)
compact_migrate_scanned (since Linux 3.8)
compact_free_scanned (since Linux 3.8)
compact_isolated (since Linux 3.8)
compact_stall (since Linux 2.6.35)
See the kernel source file Documentation/admin-guide/mm/transhuge.rst.

compact_fail (since Linux 2.6.35)
See the kernel source file Documentation/admin-guide/mm/transhuge.rst.

compact_success (since Linux 2.6.35)
See the kernel source file Documentation/admin-guide/mm/transhuge.rst.

htlb_buddy_alloc_success (since Linux 2.6.26)
htlb_buddy_alloc_fail (since Linux 2.6.26)
unevictable_pgs_culled (since Linux 2.6.28)
unevictable_pgs_scanned (since Linux 2.6.28)
unevictable_pgs_rescued (since Linux 2.6.28)
unevictable_pgs_mlocked (since Linux 2.6.28)
unevictable_pgs_munlocked (since Linux 2.6.28)
unevictable_pgs_cleared (since Linux 2.6.28)
unevictable_pgs_stranded (since Linux 2.6.28)
thp_fault_alloc (since Linux 2.6.39)
See the kernel source file Documentation/admin-guide/mm/transhuge.rst.

thp_fault_fallback (since Linux 2.6.39)
See the kernel source file Documentation/admin-guide/mm/transhuge.rst.

thp_collapse_alloc (since Linux 2.6.39)
See the kernel source file Documentation/admin-guide/mm/transhuge.rst.

thp_collapse_alloc_failed (since Linux 2.6.39)
See the kernel source file Documentation/admin-guide/mm/transhuge.rst.

thp_split (since Linux 2.6.39)
See the kernel source file Documentation/admin-guide/mm/transhuge.rst.

thp_zero_page_alloc (since Linux 3.8)
See the kernel source file Documentation/admin-guide/mm/transhuge.rst.

thp_zero_page_alloc_failed (since Linux 3.8)
See the kernel source file Documentation/admin-guide/mm/transhuge.rst.

balloon_inflate (since Linux 3.18)
balloon_deflate (since Linux 3.18)
balloon_migrate (since Linux 3.18)
nr_tlb_remote_flush (since Linux 3.12)
nr_tlb_remote_flush_received (since Linux 3.12)
nr_tlb_local_flush_all (since Linux 3.12)
nr_tlb_local_flush_one (since Linux 3.12)
vmacache_find_calls (since Linux 3.16)
vmacache_find_hits (since Linux 3.16)
vmacache_full_flushes (since Linux 3.19)

344 - Linux cli command miredo.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command miredo.conf and provides detailed information about the command miredo.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the miredo.conf.

NAME 🖥️ miredo.conf 🖥️

configuration for Miredo

SYNOPSIS

miredo.conf

DESCRIPTON

miredo.conf is the configuration file for Miredo. Each configuration directive consists of one directive name, possibly followed by one or several spaces and a value for the directive. White spaces, empty lines and lines starting with ‘#’ are ignored.

Directives are case-insensitive. A comprehensive list of the supported directives follows:

MODES

RelayType (client|autoclient|relay|cone|restricted)
Specifies what type of Teredo relay/client Miredo will serve as. There are three possible choices:

client mode (the default)
In client mode, Miredo acts as a Teredo client. Miredo will first authenticate with a Teredo server (see ServerAddress), and if successful, will setup a Teredo tunneling interface with a public Teredo IPv6 address and a default IPv6 route. That virtual networking interface can be used to reach the IPv6 Internet as well as Teredo clients.

The use of Miredo as a Teredo client allows nodes to get an IPv6 connectivity from behind a NAT router device, as it tunnels IPv6 packets over UDP/IPv4 with special support for NAT routers. Routers of that kind usually only forward TCP, UDP, and some ICMP, IPv4 packets (with some limitation).

NOTE: Use of Miredo as a Teredo client is possible even if the system already has IPv6 connectivity through another way (native, 6to4, TSP, etc). In that case, Miredo will only be used to reach other Teredo clients, as its tunneling interface has a default route with a higher metric (which is to say a lower priority) than the other network interfaces.

autoclient is currently an alias for client mode.
cone mode (relay also works)
In cone mode, Miredo acts as a Teredo relay. It will assume that it has public global IPv4 connectivity with no firewall. In other words, the UDP port used by Miredo must receive unsoliticited traffic from the IPv4 Internet (see also BindPort). Miredo will create a virtual networking interface with a route toward Teredo clients.

Teredo relays forward IPv6 packets between Teredo clients and the IPv6 Internet. For that to work, Teredo relays MUST have a working IPv6 connectivity through a way distinct from Teredo tunneling (native, 6to4, ISATAP, etc).

Warning: This mode should only be used if the node has a public IPv4 address, or if it is behind a full cone NAT-router with proper port forwarding rules. Otherwise the tunnel will NOT WORK PROPERLY. Note that many NAT port forwarding implementations are broken.

restricted mode
This mode is identical to the cone mode documented above, with the exception that direct Teredo bubbles will be sent. Theoretically (see RFC4380) this permits operation of a Teredo relay from behind a restricted-port NAT. In practice, this makes NAT traversal extremely unreliable. This setting is present for backward syntax compatibility of the miredo.conf file. PLEASE DO NOT USE THIS MODE.

CLIENT OPTIONS

The following directives are only available in (auto)client mode.

**ServerAddress **hostname
The ServerAddress directive specifies the hostname or numerical IPv4 address of the Teredo server to use. Teredo clients needs a Teredo server to establish and maintain their IPv6 over UDP/IPv4 tunnel across a NAT device.

This directive MUST be specified when Miredo is in client mode. hostname must resolve to a valid IPv4 address. If it is not present, and no server hostname is specified on the command line when starting miredo either, the program will fail.

**ServerAddress2 **hostname2
Miredo assumes that the secondary Teredo server address equals the primary server address plus one. If that is not the case, this directive must be used.

RELAY OPTIONS

The following directives are only available in relay mode. They are not available in (auto)client mode.

**Prefix **teredo_prefix
This directive specifies the Teredo prefix which the Teredo relay and/or server will advertise. teredo_prefix must be a valid IPv6 prefix.

The default value is 2001:0000::.

Do not use that directive if you don’t know what you are doing, as it is more than likely to break your Teredo connectivity. That option must not be used when Miredo serves as a Teredo client.

**InterfaceMTU **mtu
This directive overrides the default MTU size of 1280 bytes for the Teredo tunneling interface. It should not be used if the default Teredo prefix is used.

GENERAL OPTIONS

**InterfaceName **ifname
Specify the name of the Teredo tunneling interface which Miredo will create (“miredo” by default). On some systems, it is not possible to redefine the tunnel name.

**BindAddress **bind_address
Bind the Teredo relay or Teredo client to a specific IPv4 address. By default, it is not bound to any particular IPv4 address.

Use this option if you have trouble with the default value, such as if you have a multi-homed host with equal-cost IPv4 routing, or if you have specific firewalling constraints.

**BindPort **udp_port
Define the UDP (IPv4) port number to be used by the relay or client. By default, the operating system allocates an unused port automatically.

Use this option if you have firewalling constraints which can cause Miredo to fail when not using a fixed predefined port.

**SyslogFacility **facility
Specify which syslog’s facility is to be used by Miredo for logging. Possible values are: daemon (the default), local0, … local7, kern and user (see syslog(2)).

AUTHOR

R�mi Denis-Courmont <remi at remlab dot net>

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

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

345 - Linux cli command proc_kpagecount

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_kpagecount and provides detailed information about the command proc_kpagecount, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_kpagecount.

NAME 🖥️ proc_kpagecount 🖥️

count of mappings of physical pages

DESCRIPTION

/proc/kpagecount (since Linux 2.6.25)
This file contains a 64-bit count of the number of times each physical page frame is mapped, indexed by page frame number (see the discussion of /proc/pid/pagemap).

The /proc/kpagecount file is present only if the CONFIG_PROC_PAGE_MONITOR kernel configuration option is enabled.

346 - Linux cli command groff_out

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command groff_out and provides detailed information about the command groff_out, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the groff_out.

Name

groff_out - GNU roff intermediate output format

Unfortunately, old versions of groff used an illogical position change after some D commands (Dp, DP, Dt). If the register @STUPID_DRAWING_POSITIONING is 1 (current default) then change position after these commands, otherwise the position is not changed.

Description

The fundamental operation of the

formatter is the translation of the

input language into a series of instructions concerned primarily with placing glyphs or geometric objects at specific positions on a rectangular page. In the following discussion, the term command refers to this intermediate output language, never to the

language intended for use by document authors. Intermediate output commands comprise several categories: glyph output; font, color, and text size selection; motion of the printing position; page advancement; drawing of geometric primitives; and device control commands, a catch-all for other operations. The last includes directives to start and stop output, identify the intended output device, and embed URL hyperlinks in supported output formats.

Because the front-end command

is a wrapper that normally runs the troff formatter to generate intermediate output and an output driver (“postprocessor”) to consume it, users normally do not encounter this language. The groff program’s -Z option inhibits postprocessing such that this intermediate output is sent to the standard output stream as when troff is run manually.

groff’s intermediate output facilitates the development of output drivers and other postprocessors by offering a common programming interface. It is an extension of the page description language developed by Brian Kernighan for AT&T device-independent troff circa 1980. Where a distinction is necessary, we will say “troff output” to describe the output of GNU troff, and “intermediate output” to denote the language accepted by the parser implemented in groff’s internal C++ library used by most of its output drivers.

Language concepts

During the run of troff, the roff input is cracked down to the information on what has to be printed at what position on the intended device. So the language of the intermediate output format can be quite small. Its only elements are commands with or without arguments. In this document, the term “command” always refers to the intermediate output language, never to the roff language used for document formatting. There are commands for positioning and text writing, for drawing, and for device controlling.

Separation

Classical troff output had strange requirements on whitespace. The groff output parser, however, is smart about whitespace by making it maximally optional. The whitespace characters, i.e., the tab, space, and newline characters, always have a syntactical meaning. They are never printable because spacing within the output is always done by positioning commands.

Any sequence of space or tab characters is treated as a single syntactical space. It separates commands and arguments, but is only required when there would occur a clashing between the command code and the arguments without the space. Most often, this happens when variable length command names, arguments, argument lists, or command clusters meet. Commands and arguments with a known, fixed length need not be separated by syntactical space.

A line break is a syntactical element, too. Every command argument can be followed by whitespace, a comment, or a newline character. Thus a syntactical line break is defined to consist of optional syntactical space that is optionally followed by a comment, and a newline character.

The normal commands, those for positioning and text, consist of a single letter taking a fixed number of arguments. For historical reasons, the parser allows stacking of such commands on the same line, but fortunately, in groff intermediate output, every command with at least one argument is followed by a line break, thus providing excellent readability.

The other commands — those for drawing and device controlling — have a more complicated structure; some recognize long command names, and some take a variable number of arguments. So all D and x commands were designed to request a syntactical line break after their last argument. Only one command, ‘x X’ has an argument that can stretch over several lines, all other commands must have all of their arguments on the same line as the command, i.e., the arguments may not be split by a line break.

Lines containing only spaces and/or a comment are treated as empty and ignored.

Argument units

Some commands accept integer arguments that represent measurements, but the scaling units of the formatter’s language are never used. Most commands assume a scaling unit of “u” (basic units), and others use “z” (scaled points); These are defined by the parameters specified in the device’s DESC file; see

and, for more on scaling units,

and Groff: The GNU Implementation of troff, the groff Texinfo manual. Color-related commands use dimensionless integers.

Note that single characters can have the eighth bit set, as can the names of fonts and special characters (this is, glyphs). The names of glyphs and fonts can be of arbitrary length. A glyph that is to be printed will always be in the current font.

A string argument is always terminated by the next whitespace character (space, tab, or newline); an embedded # character is regarded as part of the argument, not as the beginning of a comment command. An integer argument is already terminated by the next non-digit character, which then is regarded as the first character of the next argument or command.

Document parts

A correct intermediate output document consists of two parts, the prologue and the body.

The task of the prologue is to set the general device parameters using three exactly specified commands. The groff prologue is guaranteed to consist of the following three lines (in that order):

x T device
x res n h v
x init

with the arguments set as outlined in subsection “Device Control Commands” below. However, the parser for the intermediate output format is able to swallow additional whitespace and comments as well.

The body is the main section for processing the document data. Syntactically, it is a sequence of any commands different from the ones used in the prologue. Processing is terminated as soon as the first x stop command is encountered; the last line of any groff intermediate output always contains such a command.

Semantically, the body is page oriented. A new page is started by a p command. Positioning, writing, and drawing commands are always done within the current page, so they cannot occur before the first p command. Absolute positioning (by the H and V commands) is done relative to the current page, all other positioning is done relative to the current location within this page.

Command reference

This section describes all intermediate output commands, the classical commands as well as the groff extensions.

Comment command

**#**anything
⟨line-break⟩ A comment. Ignore any characters from the # character up to the next newline. Each comment can be preceded by arbitrary syntactical space; every command can be terminated by a comment.

Simple commands

The commands in this subsection have a command code consisting of a single character, taking a fixed number of arguments. Most of them are commands for positioning and text writing. These commands are smart about whitespace. Optionally, syntactical space can be inserted before, after, and between the command letter and its arguments. All of these commands are stackable, i.e., they can be preceded by other simple commands or followed by arbitrary other commands on the same line. A separating syntactical space is necessary only when two integer arguments would clash or if the preceding argument ends with a string argument.

C id⟨white-space⟩
Typeset the glyph of the special character id. Trailing syntactical space is necessary to allow special character names of arbitrary length. The drawing position is not advanced.

c c
Typeset the glyph of the ordinary character character c. The drawing position is not advanced.

f n
Select the font mounted at position n. *n *cannot be negative.

H n
Horizontally move the drawing position to *n *basic units from the left edge of the page. *n *cannot be negative.

h n
Move the drawing position right n basic units. AT&T troff allowed negative n; GNU troff does not produce such values, but groff’s output driver library handles them.

m scheme [component . . .]
Select the stroke color using the components in the color space scheme. Each component is an integer between 0 and . The quantity of components and their meanings vary with each scheme. This command is a groff extension.

mc cyan magenta yellow
Use the CMY color scheme with components cyan, magenta, and yellow.

md
Use the default color (no components; black in most cases).

mg gray
Use a grayscale color scheme with a component ranging between 0 (black) and (white).

mk cyan magenta yellow black
Use the CMYK color scheme with components cyan, magenta, yellow, and black.

mr red green blue
Use the RGB color scheme with components red, green, and blue.

N n
Typeset the glyph with index n in the current font. *n *is normally a non-negative integer. The drawing position is not advanced. The html and xhtml devices use this command with negative n to produce unbreakable space; the absolute value of n is taken and interpreted in basic units.

n b a
Indicate a break. No action is performed; the command is present to make the output more easily parsed. The integers b and a describe the vertical space amounts before and after the break, respectively. GNU troff issues this command but groff’s output driver library ignores it. See v and V.

p n
Begin a new page, setting its number to n. Each page is independent, even from those using the same number. The vertical drawing position is set to 0. All positioning, writing, and drawing commands are interpreted in the context of a page, so a p command must precede them.

s n
Set type size to n scaled points (unit z in GNU troff). AT&T troff used unscaled points (p) instead; see section “Compatibility” below.

t xyz . . .⟨white-space⟩
t xyz . . . dummy-arg⟨white-space⟩
Typeset word xyz; that is, set a sequence of ordinary glyphs named x, y, z, . . . , terminated by a space or newline; an optional second integer argument is ignored (this allows the formatter to generate an even number of arguments). Each glyph is set at the current drawing position, and the position is then advanced horizontally by the glyph’s width. A glyph’s width is read from its metrics in the font description file, scaled to the current type size, and rounded to a multiple of the horizontal motion quantum. Use the C command to emplace glyphs of special characters. The t command is a groff extension and is output only for devices whose DESC file contains the tcommand directive; see

u n xyz . . .
u xyz . . . dummy-arg⟨white-space⟩
Typeset word xyz with track kerning. As t, but after placing each glyph, the drawing position is further advanced horizontally by n basic units. The u command is a groff extension and is output only for devices whose DESC file contains the tcommand directive; see

V n
Vertically move the drawing position to *n *basic units from the top edge of the page. *n *cannot be negative.

v n
Move the drawing position down n basic units. AT&T troff allowed negative n; GNU troff does not produce such values, but groff’s output driver library handles them.

w
Indicate an inter-word space. No action is performed; the command is present to make the output more easily parsed. Only adjustable, breakable inter-word spaces are thus described; those resulting from ** or horizontal motion escape sequences are not. GNU troff issues this command but groff’s output driver library ignores it. See h and H.

Graphics commands

Each graphics or drawing command in the intermediate output starts with the letter D followed by one or two characters that specify a subcommand; this is followed by a fixed or variable number of integer arguments that are separated by a single space character. A D command may not be followed by another command on the same line (apart from a comment), so each D command is terminated by a syntactical line break.

troff output follows the classical spacing rules (no space between command and subcommand, all arguments are preceded by a single space character), but the parser allows optional space between the command letters and makes the space before the first argument optional. As usual, each space can be any sequence of tab and space characters.

Some graphics commands can take a variable number of arguments. In this case, they are integers representing a size measured in basic units u. The h arguments stand for horizontal distances where positive means right, negative left. The v arguments stand for vertical distances where positive means down, negative up. All these distances are offsets relative to the current location.

Unless indicated otherwise, each graphics command directly corresponds to a similar groff \D escape sequence; see

Unknown D commands are assumed to be device-specific. Its arguments are parsed as strings; the whole information is then sent to the postprocessor.

In the following command reference, the syntax element ⟨line-break⟩ means a syntactical line break as defined in subsection “Separation” above.

Draw B-spline from current position to offset

then to offset

if given, etc., up to

This command takes a variable number of argument pairs; the current position is moved to the terminal point of the drawn curve.

Draw arc from current position to

with center at

then move the current position to the final point of the arc.

Draw a solid circle using the current fill color with diameter d (integer in basic units u) with leftmost point at the current position; then move the current position to the rightmost point of the circle. An optional second integer argument is ignored (this allows the formatter to generate an even number of arguments). This command is a groff extension.

Draw circle line with diameter d (integer in basic units u) with leftmost point at the current position; then move the current position to the rightmost point of the circle.

Draw a solid ellipse in the current fill color with a horizontal diameter of h and a vertical diameter of v (both integers in basic units u) with the leftmost point at the current position; then move to the rightmost point of the ellipse. This command is a groff extension.

Draw an outlined ellipse with a horizontal diameter of h and a vertical diameter of v (both integers in basic units u) with the leftmost point at current position; then move to the rightmost point of the ellipse.

Set fill color for solid drawing objects using different color schemes; the analogous command for setting the color of text, line graphics, and the outline of graphic objects is m. The color components are specified as integer arguments between 0 and . The number of color components and their meaning vary for the different color schemes. These commands are generated by the groff escape sequences \D’F . . .’ and \M (with no other corresponding graphics commands). This command is a groff extension.

Set fill color for solid drawing objects using the CMY color scheme, having the 3 color components cyan, magenta, and yellow.
Set fill color for solid drawing objects to the default fill color value (black in most cases). No component arguments.
Set fill color for solid drawing objects to the shade of gray given by the argument, an integer between 0 (black) and (white).
Set fill color for solid drawing objects using the CMYK color scheme, having the 4 color components cyan, magenta, yellow, and black.
Set fill color for solid drawing objects using the RGB color scheme, having the 3 color components red, green, and blue.

The argument n must be an integer in the range -32767 to 32767.

0 ≤ n ≤ 1000
Set the color for filling solid drawing objects to a shade of gray, where 0 corresponds to solid white, 1000 (the default) to solid black, and values in between to intermediate shades of gray; this is obsoleted by command DFg.
n < 0 or n > 1000
Set the filling color to the color that is currently being used for the text and the outline, see command m. For example, the command sequence
mg 0 0 
Df -1
sets all colors to blue.
This command is a groff extension.

Draw line from current position to offset (, ) (integers in basic units u); then set current position to the end of the drawn line.

Draw a polygon line from current position to offset

from there to offset

etc., up to offset

and from there back to the starting position.

This command is a groff extension.

The same macro as the corresponding Dp command with the same arguments, but draws a solid polygon in the current fill color rather than an outlined polygon.

This command is a groff extension.

Set the current line thickness to n (an integer in basic units u) if n > 0; if n = 0 select the smallest available line thickness; otherwise, the line thickness is made proportional to the type size, which is the default.

This command is a groff extension.

Device control commands

Each device control command starts with the letter x followed by a space character (optional or arbitrary space/tab in groff) and a subcommand letter or word; each argument (if any) must be preceded by a syntactical space. All x commands are terminated by a syntactical line break; no device control command can be followed by another command on the same line (except a comment).

The subcommand is basically a single letter, but to increase readability, it can be written as a word, i.e., an arbitrary sequence of characters terminated by the next tab, space, or newline character. All characters of the subcommand word but the first are simply ignored. For example, troff outputs the initialization command x i as x init and the resolution command x r as x res. But writings like x i_like_groff and x roff_is_groff are accepted as well to mean the same commands.

In the following, the syntax element ⟨line-break⟩ means a syntactical line break as defined in subsection “Separation” above.

( control command)
Use name as the intended name for the current file in error reports. This is useful for remembering the original file name when groff uses an internal piping mechanism. The input file is not changed by this command. This command is a groff extension.

( control command)
Mount font position n (a non-negative integer) with font named s (a text word); see

( control command)
Set character height to n (a positive integer in scaled points z). Classical troff used the unit points ( p) instead; see section “Compatibility” below.

( control command)
Initialize device. This is the third command of the prologue.

( control command)
Parsed but ignored. The classical documentation reads pause device, can be restarted.

( control command)
Resolution is n, while h is the minimal horizontal motion, and v the minimal vertical motion possible with this device; all arguments are positive integers in basic units u per inch. This is the second command of the prologue.

( control command)
Set slant to n degrees (an integer in basic units u).

( control command)
Terminates the processing of the current file; issued as the last command of any intermediate troff output.

( control command)
Generate trailer information, if any. In groff, this is currently ignored.

( control command)
Set the name of the output driver to xxx, a sequence of non-whitespace characters terminated by whitespace. The possible names correspond to those of groff’s -T option. This is the first command of the prologue.

( control command)
Configure underlining of spaces. If n is 1, start underlining of spaces; if n is 0, stop underlining of spaces. This is needed for the cu request in nroff mode and is ignored otherwise. This command is a groff extension.

( control command)
Send string anything uninterpreted to the device. If the line following this command starts with a + character this line is interpreted as a continuation line in the following sense. The + is ignored, but a newline character is sent instead to the device, the rest of the line is sent uninterpreted. The same applies to all following lines until the first character of a line is not a + character. This command is generated by the groff escape sequence \X. The line-continuing feature is a groff extension.

Obsolete command

In classical troff output, emitting a single glyph was mostly done by a very strange command that combined a horizontal move and the printing of a glyph. It didn’t have a command code, but is represented by a 3-character argument consisting of exactly 2 digits and a character.

ddc
Move right dd (exactly two decimal digits) basic units u, then print glyph with single-letter name c.

In groff, arbitrary syntactical space around and within this command is allowed to be added. Only when a preceding command on the same line ends with an argument of variable length a separating space is obligatory. In classical troff, large clusters of these and other commands were used, mostly without spaces; this made such output almost unreadable.

For modern high-resolution devices, this command does not make sense because the width of the glyphs can become much larger than two decimal digits. In groff, it is used only for output to the X75, X75-12, X100, and X100-12 devices. For others, the commands t and u provide greater functionality and superior troubleshooting capacity.

Postprocessing

The roff postprocessors are programs that have the task to translate the intermediate output into actions that are sent to a device. A device can be some piece of hardware such as a printer, or a software file format suitable for graphical or text processing. The groff system provides powerful means that make the programming of such postprocessors an easy task.

There is a library function that parses the intermediate output and sends the information obtained to the device via methods of a class with a common interface for each device. So a groff postprocessor must only redefine the methods of this class. For details, see the reference in section “Files” below.

Example

This section presents the intermediate output generated from the same input for three different devices. The input is the sentence hell world fed into groff on the command line.

High-resolution device ps

shell> echo "hell world" | groff -Z -T ps

x T ps
x res 72000 1 1
x init
p1
x font 5 TR
f5
s10000
V12000
H72000
thell
wh2500
tw
H96620
torld
n12000 0
x trailer
V792000
x stop

This output can be fed into the postprocessor

to get its representation as a PostScript file, or

to output directly to PDF.

Low-resolution device latin1

This is similar to the high-resolution device except that the positioning is done at a minor scale. Some comments (lines starting with #) were added for clarification; they were not generated by the formatter.

shell> "hell world" | groff -Z -T latin1

# prologue
x T latin1
x res 240 24 40
x init
# begin a new page
p1
# font setup
x font 1 R
f1
s10
# initial positioning on the page
V40
H0
# write text 'hell'
thell
# inform about a space, and do it by a horizontal jump
wh24
# write text 'world'
tworld
# announce line break, but do nothing because ...
n40 0
# ... the end of the document has been reached
x trailer
V2640
x stop

This output can be fed into the postprocessor

to get a formatted text document.

Classical style output

As a computer monitor has a very low resolution compared to modern printers the intermediate output for the X devices can use the jump-and-write command with its 2-digit displacements.

shell> "hell world" | groff -Z -T X100

x T X100
x res 100 1 1
x init
p1
x font 5 TR
f5
s10
V16
H100
# write text with old-style jump-and-write command
ch07e07l03lw06w11o07r05l03dh7
n16 0
x trailer
V1100
x stop

This output can be fed into the postprocessor

for displaying in X.

Due to the obsolete jump-and-write command, the text clusters in the classical output are almost unreadable.

Compatibility

The intermediate output language of the classical troff was first documented in [CSTR #97]. The groff intermediate output format is compatible with this specification except for the following features.

The classical quasi device independence is not yet implemented.
The old hardware was very different from what we use today. So the groff devices are also fundamentally different from the ones in classical troff. For example, the classical PostScript device was called post and had a resolution of 720 units per inch, while groff’s ps device has a resolution of 72000 units per inch. Maybe, by implementing some rescaling mechanism similar to the classical quasi device independence, these could be integrated into modern groff.
The B-spline command D~ is correctly handled by the intermediate output parser, but the drawing routines aren’t implemented in some of the postprocessor programs.
The argument of the commands s and x H has the implicit unit scaled point z in groff, while classical troff had point ( p). This isn’t an incompatibility, but a compatible extension, for both units coincide for all devices without a sizescale parameter, including all classical and the groff text devices. The few groff devices with a sizescale parameter either did not exist, had a different name, or seem to have had a different resolution. So conflicts with classical devices are very unlikely.

The differences between groff and classical troff are documented in

Files

/usr/share/groff/1.23.0/font/devname*/DESC*
describes the output device name.

Authors

James Clark wrote an early version of this document, which described only the differences between AT&T device-independent troff’s output format and that of GNU roff. The present version was completely rewritten in 2001 by Bernd Warken.

347 - Linux cli command systemd.timer

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.timer and provides detailed information about the command systemd.timer, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.timer.

NAME 🖥️ systemd.timer 🖥️

Timer unit configuration

SYNOPSIS

timer.timer

DESCRIPTION

A unit configuration file whose name ends in “.timer” encodes information about a timer controlled and supervised by systemd, for timer-based activation.

This man page lists the configuration options specific to this unit type. See systemd.unit(5) for the common options of all unit configuration files. The common configuration items are configured in the generic [Unit] and [Install] sections. The timer specific configuration options are configured in the [Timer] section.

For each timer file, a matching unit file must exist, describing the unit to activate when the timer elapses. By default, a service by the same name as the timer (except for the suffix) is activated. Example: a timer file foo.timer activates a matching service foo.service. The unit to activate may be controlled by Unit= (see below).

Note that in case the unit to activate is already active at the time the timer elapses it is not restarted, but simply left running. There is no concept of spawning new service instances in this case. Due to this, services with RemainAfterExit=yes set (which stay around continuously even after the services main process exited) are usually not suitable for activation via repetitive timers, as they will only be activated once, and then stay around forever. Target units, which by default do not deactivate on their own, can be activated repeatedly by timers by setting StopWhenUnneeded=yes on them. This will cause a target unit to be stopped immediately after its activation, if it is not a dependency of another running unit.

AUTOMATIC DEPENDENCIES

Implicit Dependencies

The following dependencies are implicitly added:

·
Timer units automatically gain a Before= dependency on the service they are supposed to activate.

Default Dependencies

The following dependencies are added unless DefaultDependencies=no is set:

·
Timer units will automatically have dependencies of type Requires= and After= on sysinit.target, a dependency of type Before= on timers.target, as well as Conflicts= and Before= on shutdown.target to ensure that they are stopped cleanly prior to system shutdown. Only timer units involved with early boot or late system shutdown should disable the DefaultDependencies= option.

·
Timer units with at least one OnCalendar= directive acquire a pair of additional After= dependencies on time-set.target and time-sync.target, in order to avoid being started before the system clock has been correctly set. See systemd.special(7) for details on these two targets.

OPTIONS

Timer unit files may include [Unit] and [Install] sections, which are described in systemd.unit(5).

Timer unit files must include a [Timer] section, which carries information about the timer it defines. The options specific to the [Timer] section of timer units are the following:

OnActiveSec=, OnBootSec=, OnStartupSec=, OnUnitActiveSec=, OnUnitInactiveSec=

Defines monotonic timers relative to different starting points:
Table 1. Settings and their starting points
Setting Meaning
OnActiveSec= Defines a timer relative to the moment the timer unit itself is activated.
OnBootSec= Defines a timer relative to when the machine was booted up. In containers, for the system manager instance, this is mapped to OnStartupSec=, making both equivalent.
OnStartupSec= Defines a timer relative to when the service manager was first started. For system timer units this is very similar to OnBootSec= as the system service manager is generally started very early at boot. Its primarily useful when configured in units running in the per-user service manager, as the user service manager is generally started on first login only, not already during boot.
OnUnitActiveSec= Defines a timer relative to when the unit the timer unit is activating was last activated.
OnUnitInactiveSec= Defines a timer relative to when the unit the timer unit is activating was last deactivated.
Multiple directives may be combined of the same and of different types, in which case the timer unit will trigger whenever any of the specified timer expressions elapse. For example, by combining OnBootSec= and OnUnitActiveSec=, it is possible to define a timer that elapses in regular intervals and activates a specific service each time. Moreover, both monotonic time expressions and OnCalendar= calendar expressions may be combined in the same timer unit.
The arguments to the directives are time spans configured in seconds. Example: “OnBootSec=50” means 50s after boot-up. The argument may also include time units. Example: “OnBootSec=5h 30min” means 5 hours and 30 minutes after boot-up. For details about the syntax of time spans, see systemd.time(7).
If a timer configured with OnBootSec= or OnStartupSec= is already in the past when the timer unit is activated, it will immediately elapse and the configured unit is started. This is not the case for timers defined in the other directives.
These are monotonic timers, independent of wall-clock time and timezones. If the computer is temporarily suspended, the monotonic clock generally pauses, too. Note that if WakeSystem= is used, a different monotonic clock is selected that continues to advance while the system is suspended and thus can be used as the trigger to resume the system.
If the empty string is assigned to any of these options, the list of timers is reset (both monotonic timers and OnCalendar= timers, see below), and all prior assignments will have no effect.
Note that timers do not necessarily expire at the precise time configured with these settings, as they are subject to the AccuracySec= setting below.

OnCalendar=

Defines realtime (i.e. wallclock) timers with calendar event expressions. See systemd.time(7) for more information on the syntax of calendar event expressions. Otherwise, the semantics are similar to OnActiveSec= and related settings.
Note that timers do not necessarily expire at the precise time configured with this setting, as it is subject to the AccuracySec= setting below.
May be specified more than once, in which case the timer unit will trigger whenever any of the specified expressions elapse. Moreover calendar timers and monotonic timers (see above) may be combined within the same timer unit.
If the empty string is assigned to any of these options, the list of timers is reset (both OnCalendar= timers and monotonic timers, see above), and all prior assignments will have no effect.
Note that calendar timers might be triggered at unexpected times if the systems realtime clock is not set correctly. Specifically, on systems that lack a battery-buffered Realtime Clock (RTC) it might be wise to enable systemd-time-wait-sync.service to ensure the clock is adjusted to a network time source before the timer event is set up. Timer units with at least one OnCalendar= expression are automatically ordered after time-sync.target, which systemd-time-wait-sync.service is ordered before.
When a system is temporarily put to sleep (i.e. system suspend or hibernation) the realtime clock does not pause. When a calendar timer elapses while the system is sleeping it will not be acted on immediately, but once the system is later resumed it will catch up and process all timers that triggered while the system was sleeping. Note that if a calendar timer elapsed more than once while the system was continuously sleeping the timer will only result in a single service activation. If WakeSystem= (see below) is enabled a calendar time event elapsing while the system is suspended will cause the system to wake up (under the condition the systems hardware supports time-triggered wake-up functionality).
Added in version 197.

AccuracySec=

Specify the accuracy the timer shall elapse with. Defaults to 1min. The timer is scheduled to elapse within a time window starting with the time specified in OnCalendar=, OnActiveSec=, OnBootSec=, OnStartupSec=, OnUnitActiveSec= or OnUnitInactiveSec= and ending the time configured with AccuracySec= later. Within this time window, the expiry time will be placed at a host-specific, randomized, but stable position that is synchronized between all local timer units. This is done in order to optimize power consumption to suppress unnecessary CPU wake-ups. To get best accuracy, set this option to 1us. Note that the timer is still subject to the timer slack configured via systemd-system.conf(5)s TimerSlackNSec= setting. See prctl(2) for details. To optimize power consumption, make sure to set this value as high as possible and as low as necessary.
Note that this setting is primarily a power saving option that allows coalescing CPU wake-ups. It should not be confused with RandomizedDelaySec= (see below) which adds a random value to the time the timer shall elapse next and whose purpose is the opposite: to stretch elapsing of timer events over a longer period to reduce workload spikes. For further details and explanations and how both settings play together, see below.
Added in version 209.

RandomizedDelaySec=

Delay the timer by a randomly selected, evenly distributed amount of time between 0 and the specified time value. Defaults to 0, indicating that no randomized delay shall be applied. Each timer unit will determine this delay randomly before each iteration, and the delay will simply be added on top of the next determined elapsing time, unless modified with FixedRandomDelay=, see below.
This setting is useful to stretch dispatching of similarly configured timer events over a certain time interval, to prevent them from firing all at the same time, possibly resulting in resource congestion.
Note the relation to AccuracySec= above: the latter allows the service manager to coalesce timer events within a specified time range in order to minimize wakeups, while this setting does the opposite: it stretches timer events over an interval, to make it unlikely that they fire simultaneously. If RandomizedDelaySec= and AccuracySec= are used in conjunction, first the randomized delay is added, and then the result is possibly further shifted to coalesce it with other timer events happening on the system. As mentioned above AccuracySec= defaults to 1 minute and RandomizedDelaySec= to 0, thus encouraging coalescing of timer events. In order to optimally stretch timer events over a certain range of time, set AccuracySec=1us and RandomizedDelaySec= to some higher value.
Added in version 229.

FixedRandomDelay=

Takes a boolean argument. When enabled, the randomized offset specified by RandomizedDelaySec= is reused for all firings of the same timer. For a given timer unit, the offset depends on the machine ID, user identifier and timer name, which means that it is stable between restarts of the manager. This effectively creates a fixed offset for an individual timer, reducing the jitter in firings of this timer, while still avoiding firing at the same time as other similarly configured timers.
This setting has no effect if RandomizedDelaySec= is set to 0. Defaults to false.
Added in version 247.

OnClockChange=, OnTimezoneChange=

These options take boolean arguments. When true, the service unit will be triggered when the system clock (CLOCK_REALTIME) jumps relative to the monotonic clock (CLOCK_MONOTONIC), or when the local system timezone is modified. These options can be used alone or in combination with other timer expressions (see above) within the same timer unit. These options default to false.
Added in version 242.

Unit=

The unit to activate when this timer elapses. The argument is a unit name, whose suffix is not “.timer”. If not specified, this value defaults to a service that has the same name as the timer unit, except for the suffix. (See above.) It is recommended that the unit name that is activated and the unit name of the timer unit are named identically, except for the suffix.

Persistent=

Takes a boolean argument. If true, the time when the service unit was last triggered is stored on disk. When the timer is activated, the service unit is triggered immediately if it would have been triggered at least once during the time when the timer was inactive. Such triggering is nonetheless subject to the delay imposed by RandomizedDelaySec=. This is useful to catch up on missed runs of the service when the system was powered down. Note that this setting only has an effect on timers configured with OnCalendar=. Defaults to false.
Use systemctl clean –what=state … on the timer unit to remove the timestamp file maintained by this option from disk. In particular, use this command before uninstalling a timer unit. See systemctl(1) for details.
Added in version 212.

WakeSystem=

Takes a boolean argument. If true, an elapsing timer will cause the system to resume from suspend, should it be suspended and if the system supports this. Note that this option will only make sure the system resumes on the appropriate times, it will not take care of suspending it again after any work that is to be done is finished. Defaults to false.
Note that this functionality requires privileges and is thus generally only available in the system service manager.
Note that behaviour of monotonic clock timers (as configured with OnActiveSec=, OnBootSec=, OnStartupSec=, OnUnitActiveSec=, OnUnitInactiveSec=, see above) is altered depending on this option. If false, a monotonic clock is used that is paused during system suspend (CLOCK_MONOTONIC), if true a different monotonic clock is used that continues advancing during system suspend (CLOCK_BOOTTIME), see clock_getres(2) for details.
Added in version 212.

RemainAfterElapse=

Takes a boolean argument. If true, a timer will stay loaded, and its state remains queryable even after it elapsed and the associated unit (as configured with Unit=, see above) deactivated again. If false, an elapsed timer unit that cannot elapse anymore is unloaded once its associated unit deactivated again. Turning this off is particularly useful for transient timer units. Note that this setting has an effect when repeatedly starting a timer unit: if RemainAfterElapse= is on, starting the timer a second time has no effect. However, if RemainAfterElapse= is off and the timer unit was already unloaded, it can be started again, and thus the service can be triggered multiple times. Defaults to true.
Added in version 229.

Check systemd.unit(5), systemd.exec(5), and systemd.kill(5) for more settings.

348 - Linux cli command gitattributes

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitattributes and provides detailed information about the command gitattributes, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitattributes.

NAME 🖥️ gitattributes 🖥️

Defining attributes per path

SYNOPSIS

$GIT_DIR/info/attributes, .gitattributes

DESCRIPTION

A gitattributes file is a simple text file that gives attributes to pathnames.

Each line in gitattributes file is of form:

pattern attr1 attr2 …

That is, a pattern followed by an attributes list, separated by whitespaces. Leading and trailing whitespaces are ignored. Lines that begin with # are ignored. Patterns that begin with a double quote are quoted in C style. When the pattern matches the path in question, the attributes listed on the line are given to the path.

Each attribute can be in one of these states for a given path:

Set

The path has the attribute with special value “true”; this is specified by listing only the name of the attribute in the attribute list.

Unset

The path has the attribute with special value “false”; this is specified by listing the name of the attribute prefixed with a dash - in the attribute list.

Set to a value

The path has the attribute with specified string value; this is specified by listing the name of the attribute followed by an equal sign = and its value in the attribute list.

Unspecified

No pattern matches the path, and nothing says if the path has or does not have the attribute, the attribute for the path is said to be Unspecified.

When more than one pattern matches the path, a later line overrides an earlier line. This overriding is done per attribute.

The rules by which the pattern matches paths are the same as in .gitignore files (see gitignore(5)), with a few exceptions:

·
negative patterns are forbidden

·
patterns that match a directory do not recursively match paths inside that directory (so using the trailing-slash path/ syntax is pointless in an attributes file; use path/** instead)

When deciding what attributes are assigned to a path, Git consults $GIT_DIR/info/attributes file (which has the highest precedence), .gitattributes file in the same directory as the path in question, and its parent directories up to the toplevel of the work tree (the further the directory that contains .gitattributes is from the path in question, the lower its precedence). Finally global and system-wide files are considered (they have the lowest precedence).

When the .gitattributes file is missing from the work tree, the path in the index is used as a fall-back. During checkout process, .gitattributes in the index is used and then the file in the working tree is used as a fall-back.

If you wish to affect only a single repository (i.e., to assign attributes to files that are particular to one user’s workflow for that repository), then attributes should be placed in the $GIT_DIR/info/attributes file. Attributes which should be version-controlled and distributed to other repositories (i.e., attributes of interest to all users) should go into .gitattributes files. Attributes that should affect all repositories for a single user should be placed in a file specified by the core.attributesFile configuration option (see git-config(1)). Its default value is $XDG_CONFIG_HOME/git/attributes. If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/attributes is used instead. Attributes for all users on a system should be placed in the $(prefix)/etc/gitattributes file.

Sometimes you would need to override a setting of an attribute for a path to Unspecified state. This can be done by listing the name of the attribute prefixed with an exclamation point !.

EFFECTS

Certain operations by Git can be influenced by assigning particular attributes to a path. Currently, the following operations are attributes-aware.

Checking-out and checking-in

These attributes affect how the contents stored in the repository are copied to the working tree files when commands such as git switch, git checkout and git merge run. They also affect how Git stores the contents you prepare in the working tree in the repository upon git add and git commit.

text

This attribute marks the path as a text file, which enables end-of-line conversion: When a matching file is added to the index, the file’s line endings are normalized to LF in the index. Conversely, when the file is copied from the index to the working directory, its line endings may be converted from LF to CRLF depending on the eol attribute, the Git config, and the platform (see explanation of eol below).
Set
Setting the text attribute on a path enables end-of-line conversion on checkin and checkout as described above. Line endings are normalized to LF in the index every time the file is checked in, even if the file was previously added to Git with CRLF line endings.
Unset
Unsetting the text attribute on a path tells Git not to attempt any end-of-line conversion upon checkin or checkout.
Set to string value “auto”
When text is set to “auto”, Git decides by itself whether the file is text or binary. If it is text and the file was not already in Git with CRLF endings, line endings are converted on checkin and checkout as described above. Otherwise, no conversion is done on checkin or checkout.
Unspecified
If the text attribute is unspecified, Git uses the core.autocrlf configuration variable to determine if the file should be converted.
Any other value causes Git to act as if text has been left unspecified.

eol

This attribute marks a path to use a specific line-ending style in the working tree when it is checked out. It has effect only if text or text=auto is set (see above), but specifying eol automatically sets text if text was left unspecified.
Set to string value “crlf”
This setting converts the file’s line endings in the working directory to CRLF when the file is checked out.
Set to string value “lf”
This setting uses the same line endings in the working directory as in the index when the file is checked out.
Unspecified
If the eol attribute is unspecified for a file, its line endings in the working directory are determined by the core.autocrlf or core.eol configuration variable (see the definitions of those options in git-config(1)). If text is set but neither of those variables is, the default is eol=crlf on Windows and eol=lf on all other platforms.

Backwards compatibility with crlf attribute

For backwards compatibility, the crlf attribute is interpreted as follows:
crlf text -crlf -text crlf=input eol=lf

End-of-line conversion

While Git normally leaves file contents alone, it can be configured to normalize line endings to LF in the repository and, optionally, to convert them to CRLF when files are checked out.
If you simply want to have CRLF line endings in your working directory regardless of the repository you are working with, you can set the config variable “core.autocrlf” without using any attributes.
[core] autocrlf = true
This does not force normalization of text files, but does ensure that text files that you introduce to the repository have their line endings normalized to LF when they are added, and that files that are already normalized in the repository stay normalized.
If you want to ensure that text files that any contributor introduces to the repository have their line endings normalized, you can set the text attribute to “auto” for all files.
  text=auto
The attributes allow a fine-grained control, how the line endings are converted. Here is an example that will make Git normalize .txt, .vcproj and .sh files, ensure that .vcproj files have CRLF and .sh files have LF in the working directory, and prevent .jpg files from being normalized regardless of their content.
          text=auto
*.txt text *.vcproj text eol=crlf *.sh text eol=lf *.jpg -text
Note
When text=auto conversion is enabled in a cross-platform project using push and pull to a central repository the text files containing CRLFs should be normalized.
From a clean working directory:
$ echo “* text=auto” >.gitattributes $ git add –renormalize . $ git status # Show files that will be normalized $ git commit -m “Introduce end-of-line normalization”
If any files that should not be normalized show up in git status, unset their text attribute before running git add -u.
manual.pdf -text
Conversely, text files that Git does not detect can have normalization enabled manually.
weirdchars.txt text
If core.safecrlf is set to “true” or “warn”, Git verifies if the conversion is reversible for the current setting of core.autocrlf. For “true”, Git rejects irreversible conversions; for “warn”, Git only prints a warning but accepts an irreversible conversion. The safety triggers to prevent such a conversion done to the files in the work tree, but there are a few exceptions. Even though…
·
git add itself does not touch the files in the work tree, the next checkout would, so the safety triggers;
·
git apply to update a text file with a patch does touch the files in the work tree, but the operation is about text files and CRLF conversion is about fixing the line ending inconsistencies, so the safety does not trigger;
·
git diff itself does not touch the files in the work tree, it is often run to inspect the changes you intend to next git add. To catch potential problems early, safety triggers.

working-tree-encoding

Git recognizes files encoded in ASCII or one of its supersets (e.g. UTF-8, ISO-8859-1, …) as text files. Files encoded in certain other encodings (e.g. UTF-16) are interpreted as binary and consequently built-in Git text processing tools (e.g. git diff) as well as most Git web front ends do not visualize the contents of these files by default.
In these cases you can tell Git the encoding of a file in the working directory with the working-tree-encoding attribute. If a file with this attribute is added to Git, then Git re-encodes the content from the specified encoding to UTF-8. Finally, Git stores the UTF-8 encoded content in its internal data structure (called “the index”). On checkout the content is re-encoded back to the specified encoding.
Please note that using the working-tree-encoding attribute may have a number of pitfalls:
·
Alternative Git implementations (e.g. JGit or libgit2) and older Git versions (as of March 2018) do not support the working-tree-encoding attribute. If you decide to use the working-tree-encoding attribute in your repository, then it is strongly recommended to ensure that all clients working with the repository support it.
For example, Microsoft Visual Studio resources files (*.rc) or PowerShell script files (*.ps1) are sometimes encoded in UTF-16. If you declare *.ps1 as files as UTF-16 and you add foo.ps1 with a working-tree-encoding enabled Git client, then foo.ps1 will be stored as UTF-8 internally. A client without working-tree-encoding support will checkout foo.ps1 as UTF-8 encoded file. This will typically cause trouble for the users of this file.
If a Git client that does not support the working-tree-encoding attribute adds a new file bar.ps1, then bar.ps1 will be stored “as-is” internally (in this example probably as UTF-16). A client with working-tree-encoding support will interpret the internal contents as UTF-8 and try to convert it to UTF-16 on checkout. That operation will fail and cause an error.
·
Reencoding content to non-UTF encodings can cause errors as the conversion might not be UTF-8 round trip safe. If you suspect your encoding to not be round trip safe, then add it to core.checkRoundtripEncoding to make Git check the round trip encoding (see git-config(1)). SHIFT-JIS (Japanese character set) is known to have round trip issues with UTF-8 and is checked by default.
·
Reencoding content requires resources that might slow down certain Git operations (e.g git checkout or git add).
Use the working-tree-encoding attribute only if you cannot store a file in UTF-8 encoding and if you want Git to be able to process the content as text.
As an example, use the following attributes if your *.ps1 files are UTF-16 encoded with byte order mark (BOM) and you want Git to perform automatic line ending conversion based on your platform.
*.ps1 text working-tree-encoding=UTF-16
Use the following attributes if your *.ps1 files are UTF-16 little endian encoded without BOM and you want Git to use Windows line endings in the working directory (use UTF-16LE-BOM instead of UTF-16LE if you want UTF-16 little endian with BOM). Please note, it is highly recommended to explicitly define the line endings with eol if the working-tree-encoding attribute is used to avoid ambiguity.
*.ps1 text working-tree-encoding=UTF-16LE eol=CRLF
You can get a list of all available encodings on your platform with the following command:
iconv –list
If you do not know the encoding of a file, then you can use the file command to guess the encoding:
file foo.ps1

ident

When the attribute ident is set for a path, Git replaces $Id$ in the blob object with $Id:, followed by the 40-character hexadecimal blob object name, followed by a dollar sign $ upon checkout. Any byte sequence that begins with $Id: and ends with $ in the worktree file is replaced with $Id$ upon check-in.

filter

A filter attribute can be set to a string value that names a filter driver specified in the configuration.
A filter driver consists of a clean command and a smudge command, either of which can be left unspecified. Upon checkout, when the smudge command is specified, the command is fed the blob object from its standard input, and its standard output is used to update the worktree file. Similarly, the clean command is used to convert the contents of worktree file upon checkin. By default these commands process only a single blob and terminate. If a long running process filter is used in place of clean and/or smudge filters, then Git can process all blobs with a single filter command invocation for the entire life of a single Git command, for example git add –all. If a long running process filter is configured then it always takes precedence over a configured single blob filter. See section below for the description of the protocol used to communicate with a process filter.
One use of the content filtering is to massage the content into a shape that is more convenient for the platform, filesystem, and the user to use. For this mode of operation, the key phrase here is “more convenient” and not “turning something unusable into usable”. In other words, the intent is that if someone unsets the filter driver definition, or does not have the appropriate filter program, the project should still be usable.
Another use of the content filtering is to store the content that cannot be directly used in the repository (e.g. a UUID that refers to the true content stored outside Git, or an encrypted content) and turn it into a usable form upon checkout (e.g. download the external content, or decrypt the encrypted content).
These two filters behave differently, and by default, a filter is taken as the former, massaging the contents into more convenient shape. A missing filter driver definition in the config, or a filter driver that exits with a non-zero status, is not an error but makes the filter a no-op passthru.
You can declare that a filter turns a content that by itself is unusable into a usable content by setting the filter.<driver>.required configuration variable to true.
Note: Whenever the clean filter is changed, the repo should be renormalized: $ git add –renormalize .
For example, in .gitattributes, you would assign the filter attribute for paths.
*.c filter=indent
Then you would define a “filter.indent.clean” and “filter.indent.smudge” configuration in your .git/config to specify a pair of commands to modify the contents of C programs when the source files are checked in (“clean” is run) and checked out (no change is made because the command is “cat”).
[filter “indent”] clean = indent smudge = cat
For best results, clean should not alter its output further if it is run twice (“clean→clean” should be equivalent to “clean”), and multiple smudge commands should not alter cleans output (“smudge→smudge→clean” should be equivalent to “clean”). See the section on merging below.
The “indent” filter is well-behaved in this regard: it will not modify input that is already correctly indented. In this case, the lack of a smudge filter means that the clean filter must accept its own output without modifying it.
If a filter must succeed in order to make the stored contents usable, you can declare that the filter is required, in the configuration:
[filter “crypt”] clean = openssl enc … smudge = openssl enc -d … required
Sequence “%f” on the filter command line is replaced with the name of the file the filter is working on. A filter might use this in keyword substitution. For example:
[filter “p4”] clean = git-p4-filter –clean %f smudge = git-p4-filter –smudge %f
Note that “%f” is the name of the path that is being worked on. Depending on the version that is being filtered, the corresponding file on disk may not exist, or may have different contents. So, smudge and clean commands should not try to access the file on disk, but only act as filters on the content provided to them on standard input.

Long Running Filter Process

If the filter command (a string value) is defined via filter.<driver>.process then Git can process all blobs with a single filter invocation for the entire life of a single Git command. This is achieved by using the long-running process protocol (described in technical/long-running-process-protocol.txt).
When Git encounters the first file that needs to be cleaned or smudged, it starts the filter and performs the handshake. In the handshake, the welcome message sent by Git is “git-filter-client”, only version 2 is supported, and the supported capabilities are “clean”, “smudge”, and “delay”.
Afterwards Git sends a list of “key=value” pairs terminated with a flush packet. The list will contain at least the filter command (based on the supported capabilities) and the pathname of the file to filter relative to the repository root. Right after the flush packet Git sends the content split in zero or more pkt-line packets and a flush packet to terminate content. Please note, that the filter must not send any response before it received the content and the final flush packet. Also note that the “value” of a “key=value” pair can contain the “=” character whereas the key would never contain that character.
packet: git> command=smudge packet: git> pathname=path/testfile.dat packet: git> 0000 packet: git> CONTENT packet: git> 0000
The filter is expected to respond with a list of “key=value” pairs terminated with a flush packet. If the filter does not experience problems then the list must contain a “success” status. Right after these packets the filter is expected to send the content in zero or more pkt-line packets and a flush packet at the end. Finally, a second list of “key=value” pairs terminated with a flush packet is expected. The filter can change the status in the second list or keep the status as is with an empty list. Please note that the empty list must be terminated with a flush packet regardless.
packet: git< status=success packet: git< 0000 packet: git< SMUDGED_CONTENT packet: git< 0000 packet: git< 0000 # empty list, keep “status=success” unchanged!
If the result content is empty then the filter is expected to respond with a “success” status and a flush packet to signal the empty content.
packet: git< status=success packet: git< 0000 packet: git< 0000 # empty content! packet: git< 0000 # empty list, keep “status=success” unchanged!
In case the filter cannot or does not want to process the content, it is expected to respond with an “error” status.
packet: git< status=error packet: git< 0000
If the filter experiences an error during processing, then it can send the status “error” after the content was (partially or completely) sent.
packet: git< status=success packet: git< 0000 packet: git< HALF_WRITTEN_ERRONEOUS_CONTENT packet: git< 0000 packet: git< status=error packet: git< 0000
In case the filter cannot or does not want to process the content as well as any future content for the lifetime of the Git process, then it is expected to respond with an “abort” status at any point in the protocol.
packet: git< status=abort packet: git< 0000
Git neither stops nor restarts the filter process in case the “error”/“abort” status is set. However, Git sets its exit code according to the filter.<driver>.required flag, mimicking the behavior of the filter.<driver>.clean / filter.<driver>.smudge mechanism.
If the filter dies during the communication or does not adhere to the protocol then Git will stop the filter process and restart it with the next file that needs to be processed. Depending on the filter.<driver>.required flag Git will interpret that as error.

Delay

If the filter supports the “delay” capability, then Git can send the flag “can-delay” after the filter command and pathname. This flag denotes that the filter can delay filtering the current blob (e.g. to compensate network latencies) by responding with no content but with the status “delayed” and a flush packet.
packet: git> command=smudge packet: git> pathname=path/testfile.dat packet: git> can-delay=1 packet: git> 0000 packet: git> CONTENT packet: git> 0000 packet: git< status=delayed packet: git< 0000
If the filter supports the “delay” capability then it must support the “list_available_blobs” command. If Git sends this command, then the filter is expected to return a list of pathnames representing blobs that have been delayed earlier and are now available. The list must be terminated with a flush packet followed by a “success” status that is also terminated with a flush packet. If no blobs for the delayed paths are available, yet, then the filter is expected to block the response until at least one blob becomes available. The filter can tell Git that it has no more delayed blobs by sending an empty list. As soon as the filter responds with an empty list, Git stops asking. All blobs that Git has not received at this point are considered missing and will result in an error.
packet: git> command=list_available_blobs packet: git> 0000 packet: git< pathname=path/testfile.dat packet: git< pathname=path/otherfile.dat packet: git< 0000 packet: git< status=success packet: git< 0000
After Git received the pathnames, it will request the corresponding blobs again. These requests contain a pathname and an empty content section. The filter is expected to respond with the smudged content in the usual way as explained above.
packet: git> command=smudge packet: git> pathname=path/testfile.dat packet: git> 0000 packet: git> 0000 # empty content! packet: git< status=success packet: git< 0000 packet: git< SMUDGED_CONTENT packet: git< 0000 packet: git< 0000 # empty list, keep “status=success” unchanged!

Example

A long running filter demo implementation can be found in contrib/long-running-filter/example.pl located in the Git core repository. If you develop your own long running filter process then the GIT_TRACE_PACKET environment variables can be very helpful for debugging (see git(1)).
Please note that you cannot use an existing filter.<driver>.clean or filter.<driver>.smudge command with filter.<driver>.process because the former two use a different inter process communication protocol than the latter one.

Interaction between checkin/checkout attributes

In the check-in codepath, the worktree file is first converted with filter driver (if specified and corresponding driver defined), then the result is processed with ident (if specified), and then finally with text (again, if specified and applicable).
In the check-out codepath, the blob content is first converted with text, and then ident and fed to filter.

Merging branches with differing checkin/checkout attributes

If you have added attributes to a file that cause the canonical repository format for that file to change, such as adding a clean/smudge filter or text/eol/ident attributes, merging anything where the attribute is not in place would normally cause merge conflicts.
To prevent these unnecessary merge conflicts, Git can be told to run a virtual check-out and check-in of all three stages of a file when resolving a three-way merge by setting the merge.renormalize configuration variable. This prevents changes caused by check-in conversion from causing spurious merge conflicts when a converted file is merged with an unconverted file.
As long as a “smudge→clean” results in the same output as a “clean” even on files that are already smudged, this strategy will automatically resolve all filter-related conflicts. Filters that do not act in this way may cause additional merge conflicts that must be resolved manually.

Generating diff text

diff

The attribute diff affects how Git generates diffs for particular files. It can tell Git whether to generate a textual patch for the path or to treat the path as a binary file. It can also affect what line is shown on the hunk header @@ -k,l +n,m @@ line, tell Git to use an external command to generate the diff, or ask Git to convert binary files to a text format before generating the diff.
Set
A path to which the diff attribute is set is treated as text, even when they contain byte values that normally never appear in text files, such as NUL.
Unset
A path to which the diff attribute is unset will generate Binary files differ (or a binary patch, if binary patches are enabled).
Unspecified
A path to which the diff attribute is unspecified first gets its contents inspected, and if it looks like text and is smaller than core.bigFileThreshold, it is treated as text. Otherwise it would generate Binary files differ.
String
Diff is shown using the specified diff driver. Each driver may specify one or more options, as described in the following section. The options for the diff driver “foo” are defined by the configuration variables in the “diff.foo” section of the Git config file.

Defining an external diff driver

The definition of a diff driver is done in gitconfig, not gitattributes file, so strictly speaking this manual page is a wrong place to talk about it. However…
To define an external diff driver jcdiff, add a section to your $GIT_DIR/config file (or $HOME/.gitconfig file) like this:
[diff “jcdiff”] command = j-c-diff
When Git needs to show you a diff for the path with diff attribute set to jcdiff, it calls the command you specified with the above configuration, i.e. j-c-diff, with 7 parameters, just like GIT_EXTERNAL_DIFF program is called. See git(1) for details.

Setting the internal diff algorithm

The diff algorithm can be set through the diff.algorithm config key, but sometimes it may be helpful to set the diff algorithm per path. For example, one may want to use the minimal diff algorithm for .json files, and the histogram for .c files, and so on without having to pass in the algorithm through the command line each time.
First, in .gitattributes, assign the diff attribute for paths.
*.json diff=
Then, define a “diff.<name>.algorithm” configuration to specify the diff algorithm, choosing from myers, patience, minimal, or histogram.
[diff “”] algorithm = histogram
This diff algorithm applies to user facing diff output like git-diff(1), git-show(1) and is used for the –stat output as well. The merge machinery will not use the diff algorithm set through this method.
Note
If diff.<name>.command is defined for path with the diff=<name> attribute, it is executed as an external diff driver (see above), and adding diff.<name>.algorithm has no effect, as the algorithm is not passed to the external diff driver.

Defining a custom hunk-header

Each group of changes (called a “hunk”) in the textual diff output is prefixed with a line of the form:
@@ -k,l +n,m @@ TEXT
This is called a hunk header. The “TEXT” portion is by default a line that begins with an alphabet, an underscore or a dollar sign; this matches what GNU diff -p output uses. This default selection however is not suited for some contents, and you can use a customized pattern to make a selection.
First, in .gitattributes, you would assign the diff attribute for paths.
*.tex diff=tex
Then, you would define a “diff.tex.xfuncname” configuration to specify a regular expression that matches a line that you would want to appear as the hunk header “TEXT”. Add a section to your $GIT_DIR/config file (or $HOME/.gitconfig file) like this:
[diff “tex”] xfuncname = “^(\(sub)section{.)$”
Note. A single level of backslashes are eaten by the configuration file parser, so you would need to double the backslashes; the pattern above picks a line that begins with a backslash, and zero or more occurrences of sub followed by section followed by open brace, to the end of line.
There are a few built-in patterns to make this easier, and tex is one of them, so you do not have to write the above in your configuration file (you still need to enable this with the attribute mechanism, via .gitattributes). The following built in patterns are available:
·
ada suitable for source code in the Ada language.
·
bash suitable for source code in the Bourne-Again SHell language. Covers a superset of POSIX shell function definitions.
·
bibtex suitable for files with BibTeX coded references.
·
cpp suitable for source code in the C and C++ languages.
·
csharp suitable for source code in the C# language.
·
css suitable for cascading style sheets.
·
dts suitable for devicetree (DTS) files.
·
elixir suitable for source code in the Elixir language.
·
fortran suitable for source code in the Fortran language.
·
fountain suitable for Fountain documents.
·
golang suitable for source code in the Go language.
·
html suitable for HTML/XHTML documents.
·
java suitable for source code in the Java language.
·
kotlin suitable for source code in the Kotlin language.
·
markdown suitable for Markdown documents.
·
matlab suitable for source code in the MATLAB and Octave languages.
·
objc suitable for source code in the Objective-C language.
·
pascal suitable for source code in the Pascal/Delphi language.
·
perl suitable for source code in the Perl language.
·
php suitable for source code in the PHP language.
·
python suitable for source code in the Python language.
·
ruby suitable for source code in the Ruby language.
·
rust suitable for source code in the Rust language.
·
scheme suitable for source code in the Scheme language.
·
tex suitable for source code for LaTeX documents.

Customizing word diff

You can customize the rules that git diff –word-diff uses to split words in a line, by specifying an appropriate regular expression in the “diff.*.wordRegex” configuration variable. For example, in TeX a backslash followed by a sequence of letters forms a command, but several such commands can be run together without intervening whitespace. To separate them, use a regular expression in your $GIT_DIR/config file (or $HOME/.gitconfig file) like this:
[diff “tex”] wordRegex = “\[a-zA-Z]+|[{}]|\.|[^{}[:space:]]+”
A built-in pattern is provided for all languages listed in the previous section.

Performing text diffs of binary files

Sometimes it is desirable to see the diff of a text-converted version of some binary files. For example, a word processor document can be converted to an ASCII text representation, and the diff of the text shown. Even though this conversion loses some information, the resulting diff is useful for human viewing (but cannot be applied directly).
The textconv config option is used to define a program for performing such a conversion. The program should take a single argument, the name of a file to convert, and produce the resulting text on stdout.
For example, to show the diff of the exif information of a file instead of the binary information (assuming you have the exif tool installed), add the following section to your $GIT_DIR/config file (or $HOME/.gitconfig file):
[diff “jpg”] textconv = exif
Note
The text conversion is generally a one-way conversion; in this example, we lose the actual image contents and focus just on the text data. This means that diffs generated by textconv are not suitable for applying. For this reason, only git diff and the git log family of commands (i.e., log, whatchanged, show) will perform text conversion. git format-patch will never generate this output. If you want to send somebody a text-converted diff of a binary file (e.g., because it quickly conveys the changes you have made), you should generate it separately and send it as a comment in addition to the usual binary diff that you might send.
Because text conversion can be slow, especially when doing a large number of them with git log -p, Git provides a mechanism to cache the output and use it in future diffs. To enable caching, set the “cachetextconv” variable in your diff driver’s config. For example:
[diff “jpg”] textconv = exif cachetextconv = true
This will cache the result of running “exif” on each blob indefinitely. If you change the textconv config variable for a diff driver, Git will automatically invalidate the cache entries and re-run the textconv filter. If you want to invalidate the cache manually (e.g., because your version of “exif” was updated and now produces better output), you can remove the cache manually with git update-ref -d refs/notes/textconv/jpg (where “jpg” is the name of the diff driver, as in the example above).

Choosing textconv versus external diff

If you want to show differences between binary or specially-formatted blobs in your repository, you can choose to use either an external diff command, or to use textconv to convert them to a diff-able text format. Which method you choose depends on your exact situation.
The advantage of using an external diff command is flexibility. You are not bound to find line-oriented changes, nor is it necessary for the output to resemble unified diff. You are free to locate and report changes in the most appropriate way for your data format.
A textconv, by comparison, is much more limiting. You provide a transformation of the data into a line-oriented text format, and Git uses its regular diff tools to generate the output. There are several advantages to choosing this method:
1.
Ease of use. It is often much simpler to write a binary to text transformation than it is to perform your own diff. In many cases, existing programs can be used as textconv filters (e.g., exif, odt2txt).
2.
Git diff features. By performing only the transformation step yourself, you can still utilize many of Git’s diff features, including colorization, word-diff, and combined diffs for merges.
3.
Caching. Textconv caching can speed up repeated diffs, such as those you might trigger by running git log -p.

Marking files as binary

Git usually guesses correctly whether a blob contains text or binary data by examining the beginning of the contents. However, sometimes you may want to override its decision, either because a blob contains binary data later in the file, or because the content, while technically composed of text characters, is opaque to a human reader. For example, many postscript files contain only ASCII characters, but produce noisy and meaningless diffs.
The simplest way to mark a file as binary is to unset the diff attribute in the .gitattributes file:
*.ps -diff
This will cause Git to generate Binary files differ (or a binary patch, if binary patches are enabled) instead of a regular diff.
However, one may also want to specify other diff driver attributes. For example, you might want to use textconv to convert postscript files to an ASCII representation for human viewing, but otherwise treat them as binary files. You cannot specify both -diff and diff=ps attributes. The solution is to use the diff.*.binary config option:
[diff “ps”] textconv = ps2ascii binary = true

Performing a three-way merge

merge

The attribute merge affects how three versions of a file are merged when a file-level merge is necessary during git merge, and other commands such as git revert and git cherry-pick.
Set
Built-in 3-way merge driver is used to merge the contents in a way similar to merge command of RCS suite. This is suitable for ordinary text files.
Unset
Take the version from the current branch as the tentative merge result, and declare that the merge has conflicts. This is suitable for binary files that do not have a well-defined merge semantics.
Unspecified
By default, this uses the same built-in 3-way merge driver as is the case when the merge attribute is set. However, the merge.default configuration variable can name different merge driver to be used with paths for which the merge attribute is unspecified.
String
3-way merge is performed using the specified custom merge driver. The built-in 3-way merge driver can be explicitly specified by asking for “text” driver; the built-in “take the current branch” driver can be requested with “binary”.

Built-in merge drivers

There are a few built-in low-level merge drivers defined that can be asked for via the merge attribute.
text
Usual 3-way file level merge for text files. Conflicted regions are marked with conflict markers <<<<<<<, ======= and >>>>>>>. The version from your branch appears before the ======= marker, and the version from the merged branch appears after the ======= marker.
binary
Keep the version from your branch in the work tree, but leave the path in the conflicted state for the user to sort out.
union
Run 3-way file level merge for text files, but take lines from both versions, instead of leaving conflict markers. This tends to leave the added lines in the resulting file in random order and the user should verify the result. Do not use this if you do not understand the implications.

Defining a custom merge driver

The definition of a merge driver is done in the .git/config file, not in the gitattributes file, so strictly speaking this manual page is a wrong place to talk about it. However…
To define a custom merge driver filfre, add a section to your $GIT_DIR/config file (or $HOME/.gitconfig file) like this:
[merge “filfre”] name = feel-free merge driver driver = filfre %O %A %B %L %P recursive = binary
The merge.*.name variable gives the driver a human-readable name.
The ‘merge.*.driver` variable’s value is used to construct a command to run to merge ancestor’s version (%O), current version (%A) and the other branches’ version (%B). These three tokens are replaced with the names of temporary files that hold the contents of these versions when the command line is built. Additionally, %L will be replaced with the conflict marker size (see below).
The merge driver is expected to leave the result of the merge in the file named with %A by overwriting it, and exit with zero status if it managed to merge them cleanly, or non-zero if there were conflicts. When the driver crashes (e.g. killed by SEGV), it is expected to exit with non-zero status that are higher than 128, and in such a case, the merge results in a failure (which is different from producing a conflict).
The merge.*.recursive variable specifies what other merge driver to use when the merge driver is called for an internal merge between common ancestors, when there are more than one. When left unspecified, the driver itself is used for both internal merge and the final merge.
The merge driver can learn the pathname in which the merged result will be stored via placeholder %P.

conflict-marker-size

This attribute controls the length of conflict markers left in the work tree file during a conflicted merge. Only a positive integer has a meaningful effect.
For example, this line in .gitattributes can be used to tell the merge machinery to leave much longer (instead of the usual 7-character-long) conflict markers when merging the file Documentation/git-merge.txt results in a conflict.
Documentation/git-merge.txt conflict-marker-size=32

Checking whitespace errors

whitespace

The core.whitespace configuration variable allows you to define what diff and apply should consider whitespace errors for all paths in the project (See git-config(1)). This attribute gives you finer control per path.
Set
Notice all types of potential whitespace errors known to Git. The tab width is taken from the value of the core.whitespace configuration variable.
Unset
Do not notice anything as error.
Unspecified
Use the value of the core.whitespace configuration variable to decide what to notice as error.
String
Specify a comma separated list of common whitespace problems to notice in the same format as the core.whitespace configuration variable.

Creating an archive

export-ignore

Files and directories with the attribute export-ignore won’t be added to archive files.

export-subst

If the attribute export-subst is set for a file then Git will expand several placeholders when adding this file to an archive. The expansion depends on the availability of a commit ID, i.e., if git-archive(1) has been given a tree instead of a commit or a tag then no replacement will be done. The placeholders are the same as those for the option –pretty=format: of git-log(1), except that they need to be wrapped like this: $Format:PLACEHOLDERS$ in the file. E.g. the string $Format:%H$ will be replaced by the commit hash. However, only one %(describe) placeholder is expanded per archive to avoid denial-of-service attacks.

Packing objects

delta

Delta compression will not be attempted for blobs for paths with the attribute delta set to false.

Viewing files in GUI tools

encoding

The value of this attribute specifies the character encoding that should be used by GUI tools (e.g. gitk(1) and git-gui(1)) to display the contents of the relevant file. Note that due to performance considerations gitk(1) does not use this attribute unless you manually enable per-file encodings in its options.
If this attribute is not set or has an invalid value, the value of the gui.encoding configuration variable is used instead (See git-config(1)).

USING MACRO ATTRIBUTES

You do not want any end-of-line conversions applied to, nor textual diffs produced for, any binary file you track. You would need to specify e.g.

*.jpg -text -diff

but that may become cumbersome, when you have many attributes. Using macro attributes, you can define an attribute that, when set, also sets or unsets a number of other attributes at the same time. The system knows a built-in macro attribute, binary:

*.jpg binary

Setting the “binary” attribute also unsets the “text” and “diff” attributes as above. Note that macro attributes can only be “Set”, though setting one might have the effect of setting or unsetting other attributes or even returning other attributes to the “Unspecified” state.

DEFINING MACRO ATTRIBUTES

Custom macro attributes can be defined only in top-level gitattributes files ($GIT_DIR/info/attributes, the .gitattributes file at the top level of the working tree, or the global or system-wide gitattributes files), not in .gitattributes files in working tree subdirectories. The built-in macro attribute “binary” is equivalent to:

[attr]binary -diff -merge -text

NOTES

Git does not follow symbolic links when accessing a .gitattributes file in the working tree. This keeps behavior consistent when the file is accessed from the index or a tree versus from the filesystem.

EXAMPLES

If you have these three gitattributes file:

(in $GIT_DIR/info/attributes)

a*      foo !bar -baz

(in .gitattributes)
abc     foo bar baz

(in t/.gitattributes)
ab*     merge=filfre
abc     -foo -bar
*.c     frotz

the attributes given to path t/abc are computed as follows:

1.
By examining t/.gitattributes (which is in the same directory as the path in question), Git finds that the first line matches. merge attribute is set. It also finds that the second line matches, and attributes foo and bar are unset.

2.
Then it examines .gitattributes (which is in the parent directory), and finds that the first line matches, but t/.gitattributes file already decided how merge, foo and bar attributes should be given to this path, so it leaves foo and bar unset. Attribute baz is set.

3.
Finally it examines $GIT_DIR/info/attributes. This file is used to override the in-tree settings. The first line is a match, and foo is set, bar is reverted to unspecified state, and baz is unset.

As the result, the attributes assignment to t/abc becomes:

foo set to true bar unspecified baz set to false merge set to string value “filfre” frotz unspecified

GIT

Part of the git(1) suite

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

349 - Linux cli command proc_pid_coredump_filter

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_coredump_filter and provides detailed information about the command proc_pid_coredump_filter, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_coredump_filter.

NAME 🖥️ proc_pid_coredump_filter 🖥️

core dump filter

DESCRIPTION

/proc/pid/coredump_filter (since Linux 2.6.23)
See core(5).

350 - Linux cli command pstore.conf.d

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command pstore.conf.d and provides detailed information about the command pstore.conf.d, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the pstore.conf.d.

NAME 🖥️ pstore.conf.d 🖥️

PStore configuration file

SYNOPSIS

/etc/systemd/pstore.conf

/run/systemd/pstore.conf

/usr/local/lib/systemd/pstore.conf

/usr/lib/systemd/pstore.conf

/etc/systemd/pstore.conf.d/*.conf

/run/systemd/pstore.conf.d/*.conf

/usr/local/lib/systemd/pstore.conf.d/*.conf

/usr/lib/systemd/pstore.conf.d/*.conf

DESCRIPTION

This file configures the behavior of systemd-pstore(8), a tool for archiving the contents of the persistent storage filesystem, pstore[1].

CONFIGURATION DIRECTORIES AND PRECEDENCE

The default configuration is set during compilation, so configuration is only needed when it is necessary to deviate from those defaults. The main configuration file is loaded from one of the listed directories in order of priority, only the first file found is used: /etc/systemd/, /run/systemd/, /usr/local/lib/systemd/ [2], /usr/lib/systemd/. The vendor version of the file contains commented out entries showing the defaults as a guide to the administrator. Local overrides can also be created by creating drop-ins, as described below. The main configuration file can also be edited for this purpose (or a copy in /etc/ if its shipped under /usr/), however using drop-ins for local configuration is recommended over modifications to the main configuration file.

OPTIONS

All options are configured in the [PStore] section:

Storage=

Controls where to archive (i.e. copy) files from the pstore filesystem. One of “none”, “external”, and “journal”. When “none”, the tool exits without processing files in the pstore filesystem. When “external” (the default), files are archived into /var/lib/systemd/pstore/, and logged into the journal. When “journal”, pstore file contents are logged only in the journal.
Added in version 243.

Unlink=

Controls whether or not files are removed from pstore after processing. Takes a boolean value. When true, a pstore file is removed from the pstore once it has been archived (either to disk or into the journal). When false, processing of pstore files occurs normally, but the files remain in the pstore. The default is true in order to maintain the pstore in a nearly empty state, so that the pstore has storage available for the next kernel error event.
Added in version 243.

The defaults for all values are listed as comments in the template /etc/systemd/pstore.conf file that is installed by default.

NOTES

pstore

https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-fs-pstore

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

351 - Linux cli command journald.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command journald.conf and provides detailed information about the command journald.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the journald.conf.

NAME 🖥️ journald.conf 🖥️

Journal service configuration files

SYNOPSIS

/etc/systemd/journald.conf

/run/systemd/journald.conf

/usr/local/lib/systemd/journald.conf

/usr/lib/systemd/journald.conf

/etc/systemd/journald.conf.d/*.conf

/run/systemd/journald.conf.d/*.conf

/usr/local/lib/systemd/journald.conf.d/*.conf

/usr/lib/systemd/journald.conf.d/*.conf

/etc/systemd/journald@NAMESPACE.conf

/etc/systemd/journald@NAMESPACE.conf.d/*.conf

/run/systemd/journald@NAMESPACE.conf.d/*.conf

/usr/local/lib/systemd/journald@NAMESPACE.conf.d/*.conf

/usr/lib/systemd/journald@NAMESPACE.conf.d/*.conf

DESCRIPTION

These files configure various parameters of the systemd journal service, systemd-journald.service(8). See systemd.syntax(7) for a general description of the syntax.

CONFIGURATION DIRECTORIES AND PRECEDENCE

OPTIONS

All options are configured in the [Journal] section:

Storage=

Controls where to store journal data. One of “volatile”, “persistent”, “auto” and “none”. If “volatile”, journal log data will be stored only in memory, i.e. below the /run/log/journal hierarchy (which is created if needed). If “persistent”, data will be stored preferably on disk, i.e. below the /var/log/journal hierarchy (which is created if needed), with a fallback to /run/log/journal (which is created if needed), during early boot and if the disk is not writable. “auto” behaves like “persistent” if the /var/log/journal directory exists, and “volatile” otherwise (the existence of the directory controls the storage mode). “none” turns off all storage, all log data received will be dropped (but forwarding to other targets, such as the console, the kernel log buffer, or a syslog socket will still work). Defaults to “auto” in the default journal namespace, and “persistent” in all others.
Note that journald will initially use volatile storage, until a call to journalctl –flush (or sending SIGUSR1 to journald) will cause it to switch to persistent logging (under the conditions mentioned above). This is done automatically on boot via “systemd-journal-flush.service”.
Note that when this option is changed to “volatile”, existing persistent data is not removed. In the other direction, journalctl(1) with the –flush option may be used to move volatile data to persistent storage.
When journal namespacing (see LogNamespace= in systemd.exec(5)) is used, setting Storage= to “volatile” or “auto” will not have an effect on the creation of the per-namespace logs directory in /var/log/journal/, as the [email protected] service file by default carries LogsDirectory=. To turn that off, add a unit file drop-in file that sets LogsDirectory= to an empty string.
Note that per-user journal files are not supported unless persistent storage is enabled, thus making journalctl –user unavailable.
The storage to use can also be specified via the “journal.storage” credential. Values configured via configuration files take priority over values configured via the credential.
Added in version 186.

Compress=

Can take a boolean value. If enabled (the default), data objects that shall be stored in the journal and are larger than the default threshold of 512 bytes are compressed before they are written to the file system. It can also be set to a number of bytes to specify the compression threshold directly. Suffixes like K, M, and G can be used to specify larger units.

Seal=

Takes a boolean value. If enabled (the default), and a sealing key is available (as created by journalctl(1)s –setup-keys command), Forward Secure Sealing (FSS) for all persistent journal files is enabled. FSS is based on Seekable Sequential Key Generators[2] by G. A. Marson and B. Poettering (doi:10.1007/978-3-642-40203-6_7) and may be used to protect journal files from unnoticed alteration.
Added in version 189.

SplitMode=

Controls whether to split up journal files per user, either “uid” or “none”. Split journal files are primarily useful for access control: on UNIX/Linux access control is managed per file, and the journal daemon will assign users read access to their journal files. If “uid”, all regular users (with UID outside the range of system users, dynamic service users, and the nobody user) will each get their own journal files, and system users will log to the system journal. See Users, Groups, UIDs and GIDs on systemd systems[3] for more details about UID ranges. If “none”, journal files are not split up by user and all messages are instead stored in the single system journal. In this mode unprivileged users generally do not have access to their own log data. Note that splitting up journal files by user is only available for journals stored persistently. If journals are stored on volatile storage (see Storage= above), only a single journal file is used. Defaults to “uid”.
Added in version 190.

RateLimitIntervalSec=, RateLimitBurst=

Configures the rate limiting that is applied to all messages generated on the system. If, in the time interval defined by RateLimitIntervalSec=, more messages than specified in RateLimitBurst= are logged by a service, all further messages within the interval are dropped until the interval is over. A message about the number of dropped messages is generated. This rate limiting is applied per-service, so that two services which log do not interfere with each others limits. Defaults to 10000 messages in 30s. The time specification for RateLimitIntervalSec= may be specified in the following units: “s”, “min”, “h”, “ms”, “us”. To turn off any kind of rate limiting, set either value to 0.
Note that the effective rate limit is multiplied by a factor derived from the available free disk space for the journal. Currently, this factor is calculated using the base 2 logarithm.
Table 1. Example RateLimitBurst= rate modifications by the available disk space
Available Disk Space Burst Multiplier
<= 1MB 1
<= 16MB 2
<= 256MB 3
<= 4GB 4
<= 64GB 5
<= 1TB 6
If a service provides rate limits for itself through LogRateLimitIntervalSec= and/or LogRateLimitBurst= in systemd.exec(5), those values will override the settings specified here.

SystemMaxUse=, SystemKeepFree=, SystemMaxFileSize=, SystemMaxFiles=, RuntimeMaxUse=, RuntimeKeepFree=, RuntimeMaxFileSize=, RuntimeMaxFiles=

Enforce size limits on the journal files stored. The options prefixed with “System” apply to the journal files when stored on a persistent file system, more specifically /var/log/journal. The options prefixed with “Runtime” apply to the journal files when stored on a volatile in-memory file system, more specifically /run/log/journal. The former is used only when /var/ is mounted, writable, and the directory /var/log/journal exists. Otherwise, only the latter applies. Note that this means that during early boot and if the administrator disabled persistent logging, only the latter options apply, while the former apply if persistent logging is enabled and the system is fully booted up. journalctl and systemd-journald ignore all files with names not ending with “.journal” or “.journal~”, so only such files, located in the appropriate directories, are taken into account when calculating current disk usage.
SystemMaxUse= and RuntimeMaxUse= control how much disk space the journal may use up at most. SystemKeepFree= and RuntimeKeepFree= control how much disk space systemd-journald shall leave free for other uses. systemd-journald will respect both limits and use the smaller of the two values.
The first pair defaults to 10% and the second to 15% of the size of the respective file system, but each value is capped to 4G. If the file system is nearly full and either SystemKeepFree= or RuntimeKeepFree= are violated when systemd-journald is started, the limit will be raised to the percentage that is actually free. This means that if there was enough free space before and journal files were created, and subsequently something else causes the file system to fill up, journald will stop using more space, but it will not be removing existing files to reduce the footprint again, either. Also note that only archived files are deleted to reduce the space occupied by journal files. This means that, in effect, there might still be more space used than SystemMaxUse= or RuntimeMaxUse= limit after a vacuuming operation is complete.
SystemMaxFileSize= and RuntimeMaxFileSize= control how large individual journal files may grow at most. This influences the granularity in which disk space is made available through rotation, i.e. deletion of historic data. Defaults to one eighth of the values configured with SystemMaxUse= and RuntimeMaxUse= capped to 128M, so that usually seven rotated journal files are kept as history. If the journal compact mode is enabled (enabled by default), the maximum file size is capped to 4G.
Specify values in bytes or use K, M, G, T, P, E as units for the specified sizes (equal to 1024, 1024², … bytes). Note that size limits are enforced synchronously when journal files are extended, and no explicit rotation step triggered by time is needed.
SystemMaxFiles= and RuntimeMaxFiles= control how many individual journal files to keep at most. Note that only archived files are deleted to reduce the number of files until this limit is reached; active files will stay around. This means that, in effect, there might still be more journal files around in total than this limit after a vacuuming operation is complete. This setting defaults to 100.

MaxFileSec=

The maximum time to store entries in a single journal file before rotating to the next one. Normally, time-based rotation should not be required as size-based rotation with options such as SystemMaxFileSize= should be sufficient to ensure that journal files do not grow without bounds. However, to ensure that not too much data is lost at once when old journal files are deleted, it might make sense to change this value from the default of one month. Set to 0 to turn off this feature. This setting takes time values which may be suffixed with the units “year”, “month”, “week”, “day”, “h” or “m” to override the default time unit of seconds.
Added in version 195.

MaxRetentionSec=

The maximum time to store journal entries. This controls whether journal files containing entries older than the specified time span are deleted. Normally, time-based deletion of old journal files should not be required as size-based deletion with options such as SystemMaxUse= should be sufficient to ensure that journal files do not grow without bounds. However, to enforce data retention policies, it might make sense to change this value from the default of 0 (which turns off this feature). This setting also takes time values which may be suffixed with the units “year”, “month”, “week”, “day”, “h” or " m" to override the default time unit of seconds.
Added in version 195.

SyncIntervalSec=

The timeout before synchronizing journal files to disk. After syncing, journal files are placed in the OFFLINE state. Note that syncing is unconditionally done immediately after a log message of priority CRIT, ALERT or EMERG has been logged. This setting hence applies only to messages of the levels ERR, WARNING, NOTICE, INFO, DEBUG. The default timeout is 5 minutes.
Added in version 199.

ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole=, ForwardToWall=, ForwardToSocket=

Control whether log messages received by the journal daemon shall be forwarded to a traditional syslog daemon, to the kernel log buffer (kmsg), to the system console, sent as wall messages to all logged-in users or sent over a socket. These options take boolean arguments except for “ForwardToSocket=” which takes an address instead. If forwarding to syslog is enabled but nothing reads messages from the socket, forwarding to syslog has no effect. By default, only forwarding to wall is enabled. These settings may be overridden at boot time with the kernel command line options “systemd.journald.forward_to_syslog”, “systemd.journald.forward_to_kmsg”, “systemd.journald.forward_to_console”, and “systemd.journald.forward_to_wall”. If the option name is specified without “=” and the following argument, true is assumed. Otherwise, the argument is parsed as a boolean.
The socket forwarding address can be specified with the credential “journal.forward_to_socket”. The following socket types are supported:
AF_INET (e.g. “192.168.0.11:4444”), AF_INET6 (e.g. “[2001:db8::ff00:42:8329]:4444”), AF_UNIX (e.g. “/run/host/journal/socket”), AF_VSOCK (e.g. “vsock:2:1234”)
When forwarding to the console, the TTY to log to can be changed with TTYPath=, described below.
When forwarding to the kernel log buffer (kmsg), make sure to select a suitably large size for the log buffer, for example by adding “log_buf_len=8M” to the kernel command line. systemd will automatically disable kernels rate-limiting applied to userspace processes (equivalent to setting “printk.devkmsg=on”).
When forwarding over a socket the Journal Export Format[4] is used when sending over the wire. Notably this includes the metadata field __REALTIME_TIMESTAMP so that systemd-journal-remote (see systemd-journal-remote.service(8)) can be used to receive the forwarded journal entries.
Note: Forwarding is performed synchronously within journald, and may significantly affect its performance. This is particularly relevant when using ForwardToConsole=yes in cloud environments, where the console is often a slow, virtual serial port. Since journald is implemented as a conventional single-process daemon, forwarding to a completely hung console will block journald. This can have a cascading effect resulting in any services synchronously logging to the blocked journal also becoming blocked. Unless actively debugging/developing something, its generally preferable to setup a journalctl –follow style service redirected to the console, instead of ForwardToConsole=yes, for production use.
Note: Using ForwardToSocket= over IPv4/IPv6 links can be very slow due to the synchronous nature of the sockets. Take care to ensure your link is a low-latency local link if possible. Typically IP networking is not available everywhere journald runs, e.g. in the initrd during boot. Consider using AF_VSOCK/AF_UNIX sockets for this if possible.

MaxLevelStore=, MaxLevelSyslog=, MaxLevelKMsg=, MaxLevelConsole=, MaxLevelWall=, MaxLevelSocket=

Controls the maximum log level of messages that are stored in the journal, forwarded to syslog, kmsg, the console, the wall, or a socket (if that is enabled, see above). As argument, takes one of “emerg”, “alert”, “crit”, “err”, “warning”, “notice”, “info”, “debug”, or integer values in the range of 0–7 (corresponding to the same levels). Messages equal or below the log level specified are stored/forwarded, messages above are dropped. Defaults to “debug” for MaxLevelStore=, MaxLevelSyslog= and MaxLevelSocket=, to ensure that the all messages are stored in the journal, forwarded to syslog and the socket if one exists. Defaults to “notice” for MaxLevelKMsg=, “info” for MaxLevelConsole=, and “emerg” for MaxLevelWall=. These settings may be overridden at boot time with the kernel command line options “systemd.journald.max_level_store=”, “systemd.journald.max_level_syslog=”, “systemd.journald.max_level_kmsg=”, “systemd.journald.max_level_console=”, “systemd.journald.max_level_wall=”, “systemd.journald.max_level_socket=”.
Added in version 185.

ReadKMsg=

Takes a boolean value. If enabled systemd-journal processes /dev/kmsg messages generated by the kernel. In the default journal namespace this option is enabled by default, it is disabled in all others.
Added in version 235.

Audit=

Takes a boolean value. If enabled systemd-journald will turn on kernel auditing on start-up. If disabled it will turn it off. If unset it will neither enable nor disable it, leaving the previous state unchanged. This means if another tool turns on auditing even if systemd-journald left it off, it will still collect the generated messages. Defaults to on.
Note that this option does not control whether systemd-journald collects generated audit records, it just controls whether it tells the kernel to generate them. If you need to prevent systemd-journald from collecting the generated messages, the socket unit “systemd-journald-audit.socket” can be disabled and in this case this setting is without effect.
Added in version 246.

TTYPath=

Change the console TTY to use if ForwardToConsole=yes is used. Defaults to /dev/console.
Added in version 185.

LineMax=

The maximum line length to permit when converting stream logs into record logs. When a systemd units standard output/error are connected to the journal via a stream socket, the data read is split into individual log records at newline (" “, ASCII 10) and NUL characters. If no such delimiter is read for the specified number of bytes a hard log record boundary is artificially inserted, breaking up overly long lines into multiple log records. Selecting overly large values increases the possible memory usage of the Journal daemon for each stream client, as in the worst case the journal daemon needs to buffer the specified number of bytes in memory before it can flush a new log record to disk. Also note that permitting overly large line maximum line lengths affects compatibility with traditional log protocols as log records might not fit anymore into a single AF_UNIX or AF_INET datagram. Takes a size in bytes. If the value is suffixed with K, M, G or T, the specified size is parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. Defaults to 48K, which is relatively large but still small enough so that log records likely fit into network datagrams along with extra room for metadata. Note that values below 79 are not accepted and will be bumped to 79.
Added in version 235.

FORWARDING TO TRADITIONAL SYSLOG DAEMONS

NOTES

Seekable Sequential Key Generators

https://eprint.iacr.org/2013/397

Users, Groups, UIDs and GIDs on systemd systems

https://systemd.io/UIDS-GIDS

Journal Export Format

https://systemd.io/JOURNAL_EXPORT_FORMATS/#journal-export-format

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

352 - Linux cli command gitformat-bundle

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitformat-bundle and provides detailed information about the command gitformat-bundle, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitformat-bundle.

NAME 🖥️ gitformat-bundle 🖥️

bundle - The bundle file format

SYNOPSIS

*.bundle
*.bdl

DESCRIPTION

The Git bundle format is a format that represents both refs and Git objects. A bundle is a header in a format similar to git-show-ref(1) followed by a pack in *.pack format.

The format is created and read by the git-bundle(1) command, and supported by e.g. git-fetch(1) and git-clone(1).

FORMAT

We will use ABNF notation to define the Git bundle format. See gitprotocol-common(5) for the details.

A v2 bundle looks like this:

bundle = signature *prerequisite *reference LF pack signature = “# v2 git bundle” LF
prerequisite = "-" obj-id SP comment LF
comment      = *CHAR
reference    = obj-id SP refname LF

pack         = ... ; packfile

A v3 bundle looks like this:

bundle = signature *capability *prerequisite *reference LF pack signature = “# v3 git bundle” LF

capability   = "@" key ["=" value] LF
prerequisite = "-" obj-id SP comment LF
comment      = *CHAR
reference    = obj-id SP refname LF
key          = 1*(ALPHA / DIGIT / "-")
value        = *(%01-09 / %0b-FF)

pack         = ... ; packfile

SEMANTICS

A Git bundle consists of several parts.

·
“Capabilities”, which are only in the v3 format, indicate functionality that the bundle requires to be read properly.

·
“Prerequisites” list the objects that are NOT included in the bundle and the reader of the bundle MUST already have, in order to use the data in the bundle. The objects stored in the bundle may refer to prerequisite objects and anything reachable from them (e.g. a tree object in the bundle can reference a blob that is reachable from a prerequisite) and/or expressed as a delta against prerequisite objects.

·
“References” record the tips of the history graph, iow, what the reader of the bundle CAN “git fetch” from it.

·
“Pack” is the pack data stream “git fetch” would send, if you fetch from a repository that has the references recorded in the “References” above into a repository that has references pointing at the objects listed in “Prerequisites” above.

In the bundle format, there can be a comment following a prerequisite obj-id. This is a comment and it has no specific meaning. The writer of the bundle MAY put any string here. The reader of the bundle MUST ignore the comment.

Note on shallow clones and Git bundles

Note that the prerequisites do not represent a shallow-clone boundary. The semantics of the prerequisites and the shallow-clone boundaries are different, and the Git bundle v2 format cannot represent a shallow clone repository.

CAPABILITIES

Because there is no opportunity for negotiation, unknown capabilities cause git bundle to abort.

·
object-format specifies the hash algorithm in use, and can take the same values as the extensions.objectFormat configuration value.

·
filter specifies an object filter as in the –filter option in git-rev-list(1). The resulting pack-file must be marked as a .promisor pack-file after it is unbundled.

GIT

Part of the git(1) suite

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

353 - Linux cli command manpath

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command manpath and provides detailed information about the command manpath, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the manpath.

NAME 🖥️ manpath 🖥️

format of the /etc/manpath.config file

DESCRIPTION

The manpath configuration file is used by the manual page utilities to assess users’ manpaths at run time, to indicate which manual page hierarchies (manpaths) are to be treated as system hierarchies and to assign them directories to be used for storing cat files.

If the environment variable $MANPATH is already set, the information contained within /etc/manpath.config will not override it.

SEARCH PATH

By default, man-db examines the user’s $PATH. For each path_element found there, it adds manpath_element to the search path.

If there is no MANPATH_MAP line in the configuration file for a given path_element, then it adds all of path_element/../man, path_element/man, path_element/../share/man, and path_element/share/man that exist as directories to the search path.

It then adds any MANDATORY_MANPATH entries from the configuration file to the search path.

Finally, if the –systems option is used or the $SYSTEM environment variable is set, then that should consist of a sequence of operating system names separated by commas or colons. This acts as a template, expanding the search path once more to allow access to other operating systems’ manual pages: for each system name, man-db looks for that name as a subdirectory of each entry in the search path, and adds it to the final search path if it exists. A system name of man inserts the normal search path without subdirectories. For example, if the search path would otherwise have been /usr/share/man:/usr/local/man, and $SYSTEM is set to newOS:man, then the final search path will be /usr/share/man/newOS:/usr/share/man:/usr/local/man/newOS:/usr/local/man.

The $MANPATH environment variable overrides man-db’s default manual page search paths. Most users should not need to set it. Its syntax is similar to the $PATH environment variable: it consists of a sequence of directory names separated by colons. It overrides the default search path described above.

If the value of $MANPATH starts with a colon, then the default search path is added at its start. If the value of $MANPATH ends with a colon, then the default search path is added at its end. If the value of $MANPATH contains a double colon (::), then the default search path is inserted in the middle of the value, between the two colons.

FORMAT

The following field types are currently recognised:

#* comment*
Blank lines or those beginning with a # will be treated as comments and ignored.

MANDATORY_MANPATH* manpath_element*
Lines of this form indicate manpaths that every automatically generated $MANPATH should contain. This will typically include /usr/man.

MANPATH_MAP* path_element manpath_element*
Lines of this form set up $PATH to $MANPATH mappings. For each path_element found in the user’s $PATH, manpath_element will be added to the $MANPATH.

MANDB_MAP manpath_element [ catpath_element ]
Lines of this form indicate which manpaths are to be treated as system manpaths, and optionally where their cat files should be stored. This field type is particularly important if man is a setuid program, as (when in the system configuration file /etc/manpath.config rather than the per-user configuration file .manpath) it indicates which manual page hierarchies to access as the setuid user and which as the invoking user.

The system manual page hierarchies are usually those stored under /usr such as /usr/man, /usr/local/man and /usr/X11R6/man.

If cat pages from a particular manpath_element are not to be stored or are to be stored in the traditional location, catpath_element may be omitted.

Traditional cat placement would be impossible for read only mounted manual page hierarchies and because of this it is possible to specify any valid directory hierarchy for their storage. To observe the Linux FSSTND the keyword FSSTND can be used in place of an actual directory.

Unfortunately, it is necessary to specify all system man tree paths, including alternate operating system paths such as /usr/man/sun and any NLS locale paths such as /usr/man/de_DE.88591.

As the information is parsed line by line in the order written, it is necessary for any manpath that is a sub-hierarchy of another hierarchy to be listed first, otherwise an incorrect match will be made. An example is that /usr/man/de_DE.88591 must come before /usr/man.

DEFINE* key value*
Lines of this form define miscellaneous configuration variables; see the default configuration file for those variables used by the manual pager utilities. They include default paths to various programs (such as grep and tbl), and default sets of arguments to those programs.

SECTION section . . .

Lines of this form define the order in which manual sections should be searched. If there are no SECTION directives in the configuration file, the default is:
SECTION 1 n l 8 3 0 2 3type 5 4 9 6 7
If multiple SECTION directives are given, their section lists will be concatenated.
If a particular extension is not in this list (say, 1mh) it will be displayed with the rest of the section it belongs to. The effect of this is that you only need to explicitly list extensions if you want to force a particular order. Sections with extensions should usually be adjacent to their main section (e.g. “1 1mh 8 …”).
SECTIONS is accepted as an alternative name for this directive.

MINCATWIDTH* width*
If the terminal width is less than width, cat pages will not be created (if missing) or displayed. The default is 80.

MAXCATWIDTH* width*
If the terminal width is greater than width, cat pages will not be created (if missing) or displayed. The default is 80.

CATWIDTH* width*
If width is non-zero, cat pages will always be formatted for a terminal of the given width, regardless of the width of the terminal actually being used. This overrides MINCATWIDTH and MAXCATWIDTH.

NOCACHE
This flag prevents man(1) from creating cat pages automatically.

BUGS

Unless the rules above are followed and observed precisely, the manual pager utilities will not function as desired. The rules are overly complicated.

https://gitlab.com/man-db/man-db/-/issues
https://savannah.nongnu.org/bugs/?group=man-db

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

354 - Linux cli command org.bluez.ProfileManager

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.ProfileManager and provides detailed information about the command org.bluez.ProfileManager, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.ProfileManager.

NAME 🖥️ org.bluez.ProfileManager 🖥️

BlueZ D-Bus ProfileManager API documentation

INTERFACE

Service
org.bluez
Interface
org.bluez.ProfileManager1
Object path
/org/bluez

Methods

void RegisterProfile(object profile, string uuid, dict options)

Registers profile agent.
The object path defines the path of the profile that will be called when there is a connection and must implement org.bluez.Profile(5) interface.
If an application disconnects from the bus all its registered profiles will be removed.
Possible uuid values:
“0000111f-0000-1000-8000-00805f9b34fb”
HFP AG, default profile Version is 1.7, profile Features is 0b001001 and RFCOMM channel is 13. Authentication is required.
“0000111e-0000-1000-8000-00805f9b34fb”
HFP HS, default profile Version is 1.7, profile Features is 0b000000 and RFCOMM channel is 7. Authentication is required.
“00001112-0000-1000-8000-00805f9b34fb”
HSP AG, default profile Version is 1.2, RFCOMM channel is 12 and Authentication is required. Does not support any Features, option is ignored.
“00001108-0000-1000-8000-00805f9b34fb”
HSP HS, default profile Version is 1.2, profile Features is 0b0 and RFCOMM channel is 6. Authentication is required. Features is one bit value, specify capability of Remote Audio Volume Control (by default turned off).
"<vendor UUID>"
Vendor defined UUID, no defaults, must set options.
Possible options values:
string Name
Human readable name for the profile
string Service
The primary service class UUID (if different from the actual profile UUID).
string Role
For asymmetric profiles that do not have UUIDs available to uniquely identify each side this parameter allows specifying the precise local role.
Possible values:
“client”
“server”
uint16 Channel
RFCOMM channel number that is used for client and server UUIDs.
If applicable it will be used in the SDP record as well.
uint16 PSM
PSM number that is used for client and server UUIDs.
If applicable it will be used in the SDP record as well.
boolean RequireAuthentication
Pairing is required before connections will be established. No devices will be connected if not paired.
boolean RequireAuthorization
Request authorization before any connection will be established.
boolean AutoConnect
In case of a client UUID this will force connection of the RFCOMM or L2CAP channels when a remote device is connected.
string ServiceRecord
Provide a manual SDP record.
uint16 Version
Profile version (for SDP record)
uint16 Features
Profile features (for SDP record)
Possible errors:
org.bluez.Error.InvalidArguments
org.bluez.Error.AlreadyExists

void UnregisterProfile(object profile)

Unregisters profile object that has been previously registered using RegisterProfile.
The object path parameter must match the same value that has been used on registration.
Possible errors:
org.bluez.Error.DoesNotExist

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

355 - Linux cli command proc_pid_pagemap

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_pagemap and provides detailed information about the command proc_pid_pagemap, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_pagemap.

NAME 🖥️ proc_pid_pagemap 🖥️

mapping of virtual pages

DESCRIPTION

/proc/pid/pagemap (since Linux 2.6.25)
This file shows the mapping of each of the process’s virtual pages into physical page frames or swap area. It contains one 64-bit value for each virtual page, with the bits set as follows:

63
If set, the page is present in RAM.

62
If set, the page is in swap space

61 (since Linux 3.5)
The page is a file-mapped page or a shared anonymous page.

60–58 (since Linux 3.11)
Zero

57 (since Linux 5.14)
If set, the page is write-protected through userfaultfd(2).

56 (since Linux 4.2)
The page is exclusively mapped.

55 (since Linux 3.11)
PTE is soft-dirty (see the kernel source file Documentation/admin-guide/mm/soft-dirty.rst).

54–0
If the page is present in RAM (bit 63), then these bits provide the page frame number, which can be used to index /proc/kpageflags and /proc/kpagecount. If the page is present in swap (bit 62), then bits 4–0 give the swap type, and bits 54–5 encode the swap offset.

Before Linux 3.11, bits 60–55 were used to encode the base-2 log of the page size.

To employ /proc/pid/pagemap efficiently, use /proc/pid/maps to determine which areas of memory are actually mapped and seek to skip over unmapped regions.

The /proc/pid/pagemap file is present only if the CONFIG_PROC_PAGE_MONITOR kernel configuration option is enabled.

Permission to access this file is governed by a ptrace access mode PTRACE_MODE_READ_FSCREDS check; see ptrace(2).

356 - Linux cli command deb-src-symbols

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command deb-src-symbols and provides detailed information about the command deb-src-symbols, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the deb-src-symbols.

NAME 🖥️ deb-src-symbols 🖥️

src-symbols - Debian’s extended shared library template file

SYNOPSIS

**debian/package.symbols.**arch, **debian/symbols.**arch, debian/package.symbols, debian/symbols

DESCRIPTION

The symbol file templates are shipped in Debian source packages, and its format is a superset of the symbols files shipped in binary packages, see deb-symbols (5).

Comments

Comments are supported in template symbol files. Any line with ‘#’ as the first character is a comment except if it starts with ‘#include’ (see section “Using includes”). Lines starting with ‘#MISSING:’ are special comments documenting symbols that have disappeared.

Using #PACKAGE# substitution

In some rare cases, the name of the library varies between architectures. To avoid hardcoding the name of the package in the symbols file, you can use the marker #PACKAGE#. It will be replaced by the real package name during installation of the symbols files. Contrary to the #MINVER# marker, #PACKAGE# will never appear in a symbols file inside a binary package.

Using symbol tags

Symbol tagging is useful for marking symbols that are special in some way. Any symbol can have an arbitrary number of tags associated with it. While all tags are parsed and stored, only some of them are understood by dpkg-gensymbols and trigger special handling of the symbols. See subsection “Standard symbol tags” for reference of these tags.

Tag specification comes right before the symbol name (no whitespace is allowed in between). It always starts with an opening bracket (, ends with a closing bracket ) and must contain at least one tag. Multiple tags are separated by the | character. Each tag can optionally have a value which is separated form the tag name by the = character. Tag names and values can be arbitrary strings except they cannot contain any of the special ) | = characters. Symbol names following a tag specification can optionally be quoted with either ’ or " characters to allow whitespaces in them. However, if there are no tags specified for the symbol, quotes are treated as part of the symbol name which continues up until the first space.

(tag1=i am marked|tag name with space)“tagged quoted symbol”@Base 1.0 (optional)tagged_unquoted_symbol@Base 1.0 1 untagged_symbol@Base 1.0

The first symbol in the example is named tagged quoted symbol and has two tags: tag1 with value i am marked and tag name with space that has no value. The second symbol named tagged_unquoted_symbol is only tagged with the tag named optional. The last symbol is an example of the normal untagged symbol.

Since symbol tags are an extension of the deb-symbols (5) format, they can only be part of the symbols files used in source packages (those files should then be seen as templates used to build the symbols files that are embedded in binary packages). When dpkg-gensymbols is called without the -t option, it will output symbols files compatible to the deb-symbols (5) format: it fully processes symbols according to the requirements of their standard tags and strips all tags from the output. On the contrary, in template mode (-t) all symbols and their tags (both standard and unknown ones) are kept in the output and are written in their original form as they were loaded.

Standard symbol tags

optional
A symbol marked as optional can disappear from the library at any time and that will never cause dpkg-gensymbols to fail. However, disappeared optional symbols will continuously appear as MISSING in the diff in each new package revision. This behavior serves as a reminder for the maintainer that such a symbol needs to be removed from the symbol file or readded to the library. When the optional symbol, which was previously declared as MISSING, suddenly reappears in the next revision, it will be upgraded back to the “existing” status with its minimum version unchanged. This tag is useful for symbols which are private where their disappearance do not cause ABI breakage. For example, most of C++ template instantiations fall into this category. Like any other tag, this one may also have an arbitrary value: it could be used to indicate why the symbol is considered optional.

arch=architecture-list

arch-bits=architecture-bits

arch-endian=architecture-endianness

These tags allow one to restrict the set of architectures where the symbol is supposed to exist. The arch-bits and arch-endian tags are supported since dpkg 1.18.0. When the symbols list is updated with the symbols discovered in the library, all arch-specific symbols which do not concern the current host architecture are treated as if they did not exist. If an arch-specific symbol matching the current host architecture does not exist in the library, normal procedures for missing symbols apply and it may cause dpkg-gensymbols to fail. On the other hand, if the arch-specific symbol is found when it was not supposed to exist (because the current host architecture is not listed in the tag or does not match the endianness and bits), it is made arch neutral (i.e. the arch, arch-bits and arch-endian tags are dropped and the symbol will appear in the diff due to this change), but it is not considered as new. When operating in the default non-template mode, among arch-specific symbols only those that match the current host architecture are written to the symbols file. On the contrary, all arch-specific symbols (including those from foreign arches) are always written to the symbol file when operating in template mode. The format of architecture-list is the same as the one used in the Build-Depends field of debian/control (except the enclosing square brackets []). For example, the first symbol from the list below will be considered only on alpha, any-amd64 and ia64 architectures, the second only on linux architectures, while the third one anywhere except on armel. (arch=alpha any-amd64 ia64)64bit_specific_symbol@Base 1.0 (arch=linux-any)linux_specific_symbol@Base 1.0 (arch=!armel)symbol_armel_does_not_have@Base 1.0 The architecture-bits is either 32 or 64. (arch-bits=32)32bit_specific_symbol@Base 1.0 (arch-bits=64)64bit_specific_symbol@Base 1.0 The architecture-endianness is either little or big. (arch-endian=little)little_endian_specific_symbol@Base 1.0 (arch-endian=big)big_endian_specific_symbol@Base 1.0 Multiple restrictions can be chained. (arch-bits=32|arch-endian=little)32bit_le_symbol@Base 1.0

allow-internal
dpkg-gensymbols has a list of internal symbols that should not appear in symbols files as they are usually only side-effects of implementation details of the toolchain (since dpkg 1.20.1). If for some reason, you really want one of those symbols to be included in the symbols file, you should tag the symbol with allow-internal. It can be necessary for some low level toolchain libraries like “libgcc”.

ignore-blacklist
A deprecated alias for allow-internal (since dpkg 1.20.1, supported since dpkg 1.15.3).

c++
Denotes c++ symbol pattern. See “Using symbol patterns” subsection below.

symver
Denotes symver (symbol version) symbol pattern. See “Using symbol patterns” subsection below.

regex
Denotes regex symbol pattern. See “Using symbol patterns” subsection below.

Using symbol patterns

Unlike a standard symbol specification, a pattern may cover multiple real symbols from the library. dpkg-gensymbols will attempt to match each pattern against each real symbol that does not have a specific symbol counterpart defined in the symbol file. Whenever the first matching pattern is found, all its tags and properties will be used as a basis specification of the symbol. If none of the patterns matches, the symbol will be considered as new.

A pattern is considered lost if it does not match any symbol in the library. By default this will trigger a dpkg-gensymbols failure under -c1 or higher level. However, if the failure is undesired, the pattern may be marked with the optional tag. Then if the pattern does not match anything, it will only appear in the diff as MISSING. Moreover, like any symbol, the pattern may be limited to the specific architectures with the arch tag. Please refer to “Standard symbol tags” subsection above for more information.

Patterns are an extension of the deb-symbols (5) format hence they are only valid in symbol file templates. Pattern specification syntax is not any different from the one of a specific symbol. However, symbol name part of the specification serves as an expression to be matched against name@version of the real symbol. In order to distinguish among different pattern types, a pattern will typically be tagged with a special tag.

At the moment, dpkg-gensymbols supports three basic pattern types:

c++
This pattern is denoted by the c++ tag. It matches only C++ symbols by their demangled symbol name (as emitted by c++filt (1) utility). This pattern is very handy for matching symbols which mangled names might vary across different architectures while their demangled names remain the same. One group of such symbols is non-virtual thunks which have architecture specific offsets embedded in their mangled names. A common instance of this case is a virtual destructor which under diamond inheritance needs a non-virtual thunk symbol. For example, even if _ZThn8_N3NSB6ClassDD1Ev@Base on 32-bit architectures will probably be _ZThn16_N3NSB6ClassDD1Ev@Base on 64-bit ones, it can be matched with a single c++ pattern: libdummy.so.1 libdummy1 #MINVER# […] (c++)“non-virtual thunk to NSB::ClassD::~ClassD()@Base” 1.0 […] The demangled name above can be obtained by executing the following command: $ echo _ZThn8_N3NSB6ClassDD1Ev@Base | c++filt Please note that while mangled name is unique in the library by definition, this is not necessarily true for demangled names. A couple of distinct real symbols may have the same demangled name. For example, that’s the case with non-virtual thunk symbols in complex inheritance configurations or with most constructors and destructors (since g++ typically generates two real symbols for them). However, as these collisions happen on the ABI level, they should not degrade quality of the symbol file.

symver
This pattern is denoted by the symver tag. Well maintained libraries have versioned symbols where each version corresponds to the upstream version where the symbol got added. If that’s the case, you can use a symver pattern to match any symbol associated to the specific version. For example: libc.so.6 libc6 #MINVER# (symver)GLIBC_2.0 2.0 […] (symver)GLIBC_2.7 2.7 access@GLIBC_2.0 2.2 All symbols associated with versions GLIBC_2.0 and GLIBC_2.7 will lead to minimal version of 2.0 and 2.7 respectively with the exception of the symbol access@GLIBC_2.0. The latter will lead to a minimal dependency on libc6 version 2.2 despite being in the scope of the “(symver)GLIBC_2.0” pattern because specific symbols take precedence over patterns. Please note that while old style wildcard patterns (denoted by “*@version” in the symbol name field) are still supported, they have been deprecated by new style syntax “(symver|optional)version”. For example, “*@GLIBC_2.0 2.0” should be written as “(symver|optional)GLIBC_2.0 2.0” if the same behavior is needed.

regex
Regular expression patterns are denoted by the regex tag. They match by the perl regular expression specified in the symbol name field. A regular expression is matched as it is, therefore do not forget to start it with the ^ character or it may match any part of the real symbol name@version string. For example: libdummy.so.1 libdummy1 #MINVER# (regex)"^mystack_.*@Base$" 1.0 (regex|optional)“private” 1.0 Symbols like “mystack_new@Base”, “mystack_push@Base”, “mystack_pop@Base”, etc., will be matched by the first pattern while “ng_mystack_new@Base” would not. The second pattern will match all symbols having the string “private” in their names and matches will inherit optional tag from the pattern.

Basic patterns listed above can be combined where it makes sense. In that case, they are processed in the order in which the tags are specified. For example, both:

(c++|regex)"^NSA::ClassA::Private::privmethod\d\int@Base" 1.0 (regex|c++)N3NSA6ClassA7Private11privmethod\dEi@Base 1.0

will match symbols “_ZN3NSA6ClassA7Private11privmethod1Ei@Base” and “_ZN3NSA6ClassA7Private11privmethod2Ei@Base”. When matching the first pattern, the raw symbol is first demangled as C++ symbol, then the demangled name is matched against the regular expression. On the other hand, when matching the second pattern, regular expression is matched against the raw symbol name, then the symbol is tested if it is C++ one by attempting to demangle it. A failure of any basic pattern will result in the failure of the whole pattern. Therefore, for example, “_ _N3NSA6ClassA7Private11privmethod\dEi@Base” will not match either of the patterns because it is not a valid C++ symbol.

In general, all patterns are divided into two groups: aliases (basic c++ and symver) and generic patterns (regex, all combinations of multiple basic patterns). Matching of basic alias-based patterns is fast (O(1)) while generic patterns are O(N) (N - generic pattern count) for each symbol. Therefore, it is recommended not to overuse generic patterns.

When multiple patterns match the same real symbol, aliases (first c++, then symver) are preferred over generic patterns. Generic patterns are matched in the order they are found in the symbol file template until the first success. Please note, however, that manual reordering of template file entries is not recommended because dpkg-gensymbols generates diffs based on the alphanumerical order of their names.

Using includes

When the set of exported symbols differ between architectures, it may become inefficient to use a single symbol file. In those cases, an include directive may prove to be useful in a couple of ways:

You can factorize the common part in some external file and include that file in your package.symbols.arch file by using an include directive like this: #include “I<packages>.symbols.common”
The include directive may also be tagged like any symbol: (tag|…|tagN)#include “file-to-include” As a result, all symbols included from file-to-include will be considered to be tagged with tag … tagN by default. You can use this feature to create a common package.symbols file which includes architecture specific symbol files: common_symbol1@Base 1.0 (arch=amd64 ia64 alpha)#include “package.symbols.64-bit” (arch=!amd64 !ia64 !alpha)#include “package.symbols.32-bit” common_symbol2@Base 1.0

The symbols files are read line by line, and include directives are processed as soon as they are encountered. This means that the content of the included file can override any content that appeared before the include directive and that any content after the directive can override anything contained in the included file. Any symbol (or even another #include directive) in the included file can specify additional tags or override values of the inherited tags in its tag specification. However, there is no way for the symbol to remove any of the inherited tags.

An included file can repeat the header line containing the SONAME of the library. In that case, it overrides any header line previously read. However, in general it’s best to avoid duplicating header lines. One way to do it is the following:

#include “libsomething1.symbols.common” arch_specific_symbol@Base 1.0

357 - Linux cli command proc_devices

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_devices and provides detailed information about the command proc_devices, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_devices.

NAME 🖥️ proc_devices 🖥️

major numbers and device groups

DESCRIPTION

/proc/devices
Text listing of major numbers and device groups. This can be used by MAKEDEV scripts for consistency with the kernel.

358 - Linux cli command hosts_options

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command hosts_options and provides detailed information about the command hosts_options, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the hosts_options.

NAME 🖥️ hosts_options 🖥️

host access control language extensions

DESCRIPTION

This document describes extensions to the language described in the hosts_access(5) document.

The extensible language uses the following format:

daemon_list : client_list : option : option …

The first two fields are described in the hosts_access(5) manual page. The remainder of the rules is a list of zero or more options. Any “:” characters within options should be protected with a backslash.

An option is of the form “keyword” or “keyword value”. Options are processed in the specified order. Some options are subjected to %<letter> substitutions. For the sake of backwards compatibility with earlier versions, an “=” is permitted between keyword and value.

LOGGING

severity mail.info

severity notice
Change the severity level at which the event will be logged. Facility names (such as mail) are optional, and are not supported on systems with older syslog implementations. The severity option can be used to emphasize or to ignore specific events.

ACCESS CONTROL

allow

deny
Grant (deny) service. These options must appear at the end of a rule.

The allow and deny keywords make it possible to keep all access control rules within a single file, for example in the hosts.allow file.

To permit access from specific hosts only:

ALL: .friendly.domain: ALLOW

ALL: ALL: DENY

To permit access from all hosts except a few trouble makers:

ALL: .bad.domain: DENY

ALL: ALL: ALLOW

Notice the leading dot on the domain name patterns.

RUNNING OTHER COMMANDS

aclexec shell_command
Execute, in a child process, the specified shell command, after performing the %<letter> expansions described in the hosts_access(5) manual page. The command is executed with stdin, stdout and stderr connected to the null device, so that it won’t mess up the conversation with the client host. Example:

smtp : ALL : aclexec checkdnsbl %a

executes, in a background child process, the shell command “checkdnsbl %a” after replacing %a by the address of the remote host.

The connection will be allowed or refused depending on whether the command returns a true or false exit status.

spawn shell_command
Execute, in a child process, the specified shell command, after performing the %<letter> expansions described in the hosts_access(5) manual page. The command is executed with stdin, stdout and stderr connected to the null device, so that it won’t mess up the conversation with the client host. Example:

spawn (/usr/sbin/safe_finger -l @%h | /usr/bin/mail root) &

executes, in a background child process, the shell command “safe_finger -l @%h | mail root” after replacing %h by the name or address of the remote host.

The example uses the “safe_finger” command instead of the regular “finger” command, to limit possible damage from data sent by the finger server. The “safe_finger” command is part of the daemon wrapper package; it is a wrapper around the regular finger command that filters the data sent by the remote host.

twist shell_command
Replace the current process by an instance of the specified shell command, after performing the %<letter> expansions described in the hosts_access(5) manual page. Stdin, stdout and stderr are connected to the client process. This option must appear at the end of a rule.

To send a customized bounce message to the client instead of running the real ftp daemon:

in.ftpd : ... : twist /bin/echo 421 Some bounce message

For an alternative way to talk to client processes, see the banners option below.

To run /some/other/in.telnetd without polluting its command-line array or its process environment:

in.telnetd : ... : twist PATH=/some/other; exec in.telnetd

Warning: in case of UDP services, do not twist to commands that use the standard I/O or the read(2)/write(2) routines to communicate with the client process; UDP requires other I/O primitives.

NETWORK OPTIONS

keepalive
Causes the server to periodically send a message to the client. The connection is considered broken when the client does not respond. The keepalive option can be useful when users turn off their machine while it is still connected to a server. The keepalive option is not useful for datagram (UDP) services.

linger number_of_seconds
Specifies how long the kernel will try to deliver not-yet delivered data after the server process closes a connection.

USERNAME LOOKUP

rfc931 [ timeout_in_seconds ]
Look up the client user name with the RFC 931 (TAP, IDENT, RFC 1413) protocol. This option is silently ignored in case of services based on transports other than TCP. It requires that the client system runs an RFC 931 (IDENT, etc.) -compliant daemon, and may cause noticeable delays with connections from non-UNIX clients. The timeout period is optional. If no timeout is specified a compile-time defined default value is taken.

MISCELLANEOUS

banners /some/directory
Look for a file in `/some/directory’ with the same name as the daemon process (for example in.telnetd for the telnet service), and copy its contents to the client. Newline characters are replaced by carriage-return newline, and %<letter> sequences are expanded (see the hosts_access(5) manual page).

The tcp wrappers source code distribution provides a sample makefile (Banners.Makefile) for convenient banner maintenance.

Warning: banners are supported for connection-oriented (TCP) network services only.

nice [ number ]
Change the nice value of the process (default 10). Specify a positive value to spend more CPU resources on other processes.

setenv name value
Place a (name, value) pair into the process environment. The value is subjected to %<letter> expansions and may contain whitespace (but leading and trailing blanks are stripped off).

Warning: many network daemons reset their environment before spawning a login or shell process.

umask 022
Like the umask command that is built into the shell. An umask of 022 prevents the creation of files with group and world write permission. The umask argument should be an octal number.

user nobody

user nobody.kmem
Assume the privileges of the “nobody” userid (or user “nobody”, group “kmem”). The first form is useful with inetd implementations that run all services with root privilege. The second form is useful for services that need special group privileges only.

DIAGNOSTICS

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

AUTHOR

Wietse Venema ([email protected])
Department of Mathematics and Computing Science
Eindhoven University of Technology
Den Dolech 2, P.O. Box 513, 
5600 MB Eindhoven, The Netherlands

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

359 - Linux cli command gai.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gai.conf and provides detailed information about the command gai.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gai.conf.

NAME 🖥️ gai.conf 🖥️

getaddrinfo(3) configuration file

DESCRIPTION

A call to getaddrinfo(3) might return multiple answers. According to RFC 3484 these answers must be sorted so that the answer with the highest success rate is first in the list. The RFC provides an algorithm for the sorting. The static rules are not always adequate, though. For this reason, the RFC also requires that system administrators should have the possibility to dynamically change the sorting. For the glibc implementation, this can be achieved with the /etc/gai.conf file.

Each line in the configuration file consists of a keyword and its parameters. White spaces in any place are ignored. Lines starting with ‘#’ are comments and are ignored.

The keywords currently recognized are:

label netmask precedence
The value is added to the label table used in the RFC 3484 sorting. If any label definition is present in the configuration file, the default table is not used. All the label definitions of the default table which are to be maintained have to be duplicated. Following the keyword, the line has to contain a network mask and a precedence value.

precedence netmask precedence
This keyword is similar to label, but instead the value is added to the precedence table as specified in RFC 3484. Once again, the presence of a single precedence line in the configuration file causes the default table to not be used.

reload <yes|no>
This keyword controls whether a process checks whether the configuration file has been changed since the last time it was read. If the value is “yes”, the file is reread. This might cause problems in multithreaded applications and is generally a bad idea. The default is “no”.

scopev4 mask value
Add another rule to the RFC 3484 scope table for IPv4 address. By default, the scope IDs described in section 3.2 in RFC 3438 are used. Changing these defaults should hardly ever be necessary.

FILES

/etc/gai.conf

VERSIONS

The gai.conf file is supported since glibc 2.5.

EXAMPLES

The default table according to RFC 3484 would be specified with the following configuration file:

label  ::1/128       0
label  ::/0          1
label  2002::/16     2
label ::/96          3
label ::ffff:0:0/96  4
precedence  ::1/128       50
precedence  ::/0          40
precedence  2002::/16     30
precedence ::/96          20
precedence ::ffff:0:0/96  10

360 - Linux cli command proc_thread-self

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_thread-self and provides detailed information about the command proc_thread-self, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_thread-self.

NAME 🖥️ proc_thread-self 🖥️

self/ - thread information

DESCRIPTION

In a multithreaded process, the contents of the /proc/pid/task directory are not available if the main thread has already terminated (typically by calling pthread_exit(3)).

361 - Linux cli command request-key.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command request-key.conf and provides detailed information about the command request-key.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the request-key.conf.

NAME 🖥️ request-key.conf 🖥️

key.conf - Instantiation handler configuration file

DESCRIPTION

These files are used by the /sbin/request-key program to determine which program it should run to instantiate a key.

request-key looks for the best match, reading all the following files:

/etc/request-key.d/*.conf
/etc/request-key.conf

If it doesn’t find a match, it will return an error and the kernel will automatically negate the key.

The best match is defined as the line with the shortest wildcard skips, ranking the columns in order left to right. If two lines have the same length skips, then the first read is the one taken.

In the files, any blank line or line beginning with a hash mark ‘#’ is considered to be a comment and ignored.

All other lines are assumed to be command lines with a number of white space separated fields:

<op> <type> <description> <callout-info> <prog> <arg1> <arg2> …

The first four fields are used to match the parameters passed to request-key by the kernel. op is the operation type; currently the only supported operation is “create”.

type, description and callout-info match the three parameters passed to keyctl request2 or the request_key() system call. Each of these may contain one asterisk ‘*’ character as a wildcard anywhere within the string.

Should a match be made, the program specified by <prog> will be exec’d. This must have a fully qualified path name. argv[0] will be set from the part of the program name that follows the last slash ‘/’ character.

If the program name is prefixed with a pipe bar character ‘|’, then the program will be forked and exec’d attached to three pipes. The callout information will be piped to it on it’s stdin and the intended payload data will be retrieved from its stdout. Anything sent to stderr will be posted in syslog. If the program exits 0, then /sbin/request-key will attempt to instantiate the key with the data read from stdout. If it fails in any other way, then request-key will attempt to execute the appropriate ’negate’ operation command.

The program arguments can be substituted with various macros. Only complete argument substitution is supported - macro substitutions can’t be embedded. All macros begin with a percent character ‘%’. An argument beginning with two percent characters will have one of them discarded.

The following macros are supported:

%o Operation type
%k Key ID
%t Key type
%d Key description
%c Callout information
%u Key UID
%g Key GID
%T Requestor’s thread keyring
%P Requestor’s process keyring
%S Requestor’s session keyring

There’s another macro substitution too that permits the interpolation of the contents of a key:

%{<type>:<description>}

This performs a lookup for a key of the given type and description on the requestor’s keyrings, and if found, substitutes the contents for the macro. If not found an error will be logged and the key under construction will be negated.

EXAMPLE

A basic file will be installed in the /etc. This will contain two debugging lines that can be used to test the installation:

create user debug:* negate /bin/keyctl negate %k 30 %S
create user debug:loop:* * |/bin/cat
create user debug:* * /usr/share/keyutils/request-key-debug.sh %k %d %c %S
negate * * * /bin/keyctl negate %k 30 %S

This is set up so that something like:

keyctl request2 user debug:xxxx negate

will create a negative user-defined key, something like:

keyctl request2 user debug:yyyy spoon

will create an instantiated user-defined key with “Debug spoon” as the payload, and something like:

keyctl request2 user debug:loop:zzzz abcdefghijkl

will create an instantiated user-defined key with the callout information as the payload.

FILES

/etc/request-key.conf

/etc/request-key.d/*.conf

362 - Linux cli command gitprotocol-common

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitprotocol-common and provides detailed information about the command gitprotocol-common, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitprotocol-common.

NAME 🖥️ gitprotocol-common 🖥️

common - Things common to various protocols

SYNOPSIS

<over-the-wire-protocol>

DESCRIPTION

This document defines things common to various over-the-wire protocols and file formats used in Git.

ABNF NOTATION

ABNF notation as described by RFC 5234 is used within the protocol documents, except the following replacement core rules are used:

HEXDIG = DIGIT / “a” / “b” / “c” / “d” / “e” / “f”

We also define the following common rules:

NUL = %x00 zero-id = 40*“0” obj-id = 40*(HEXDIGIT)
  refname  =  "HEAD"
  refname /=  "refs/" <see discussion below>

A refname is a hierarchical octet string beginning with “refs/” and not violating the git-check-ref-format command’s validation rules. More specifically, they:

1.
They can include slash / for hierarchical (directory) grouping, but no slash-separated component can begin with a dot ..

2.
They must contain at least one /. This enforces the presence of a category like heads/, tags/ etc. but the actual names are not restricted.

3.
They cannot have two consecutive dots .. anywhere.

4.
They cannot have ASCII control characters (i.e. bytes whose values are lower than , or \177 DEL), space, tilde ~, caret ^, colon :, question-mark ?, asterisk *, or open bracket [ anywhere.

5.
They cannot end with a slash / or a dot ..

6.
They cannot end with the sequence .lock.

7.
They cannot contain a sequence @{.

8.
They cannot contain a ****.

PKT-LINE FORMAT

Much (but not all) of the payload is described around pkt-lines.

A pkt-line is a variable length binary string. The first four bytes of the line, the pkt-len, indicates the total length of the line, in hexadecimal. The pkt-len includes the 4 bytes used to contain the length’s hexadecimal representation.

A pkt-line MAY contain binary data, so implementors MUST ensure pkt-line parsing/formatting routines are 8-bit clean.

A non-binary line SHOULD BE terminated by an LF, which if present MUST be included in the total length. Receivers MUST treat pkt-lines with non-binary data the same whether or not they contain the trailing LF (stripping the LF if present, and not complaining when it is missing).

The maximum length of a pkt-line’s data component is 65516 bytes. Implementations MUST NOT send pkt-line whose length exceeds 65520 (65516 bytes of payload + 4 bytes of length data).

Implementations SHOULD NOT send an empty pkt-line (“0004”).

A pkt-line with a length field of 0 (“0000”), called a flush-pkt, is a special case and MUST be handled differently than an empty pkt-line (“0004”).

pkt-line = data-pkt / flush-pkt

  data-pkt     =  pkt-len pkt-payload
  pkt-len      =  4*(HEXDIG)
  pkt-payload  =  (pkt-len - 4)*(OCTET)

  flush-pkt    = "0000"

Examples (as C-style strings):

pkt-line actual value ——————————— “0006a " “a " “0005a” “a” “000bfoobar " “foobar " “0004” "”

GIT

Part of the git(1) suite

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

363 - Linux cli command deb822

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command deb822 and provides detailed information about the command deb822, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the deb822.

NAME 🖥️ deb822 🖥️

Debian RFC822 control data format

DESCRIPTION

The package management system manipulates data represented in a common format, known as control data, stored in control files. Control files are used for source packages, binary packages and the .changes files which control the installation of uploaded files (dpkg’s internal databases are in a similar format).

SYNTAX

A control file consists of one or more stanzas of fields (the stanzas sometimes used to be referred to as paragraphs). The stanzas are separated by empty lines. Parsers may accept lines consisting solely of U+0020 SPACE and U+0009 TAB as stanza separators, but control files should use empty lines. Some control files allow only one stanza; others allow several, in which case each stanza usually refers to a different package. (For example, in source packages, the first stanza refers to the source package, and later stanzas refer to binary packages generated from the source.) The ordering of the stanzas in control files is significant.

Each stanza consists of a series of data fields. Each field consists of the field name followed by a colon (U+003A ‘:’), and then the data/value associated with that field. The field name is composed of US-ASCII characters excluding control characters, space, and colon (i.e., characters in the ranges U+0021 ‘!’ through U+0039 ‘9’, and U+003B ‘;’ through U+007E ‘~’, inclusive). Field names must not begin with the comment character (U+0023 ‘#’), nor with the hyphen character (U+002D ‘-’).

The field ends at the end of the line or at the end of the last continuation line (see below). Horizontal whitespace (U+0020 SPACE and U+0009 TAB) may occur immediately before or after the value and is ignored there; it is conventional to put a single space after the colon. For example, a field might be: Package: dpkg

the field name is Package and the field value dpkg.

Empty field values are only permitted in source package control files (debian/control). Such fields are ignored.

A stanza must not contain more than one instance of a particular field name.

There are three types of fields:

simple
The field, including its value, must be a single line. Folding of the field is not permitted. This is the default field type if the definition of the field does not specify a different type.
folded
The value of a folded field is a logical line that may span several lines. The lines after the first are called continuation lines and must start with a U+0020 SPACE or a U+0009 TAB. Whitespace, including any newlines, is not significant in the field values of folded fields. This folding method is similar to RFC5322, allowing control files that contain only one stanza and no multiline fields to be read by parsers written for RFC5322.
multiline
The value of a multiline field may comprise multiple continuation lines. The first line of the value, the part on the same line as the field name, often has special significance or may have to be empty. Other lines are added following the same syntax as the continuation lines of the folded fields. Whitespace, including newlines, is significant in the values of multiline fields.

Whitespace must not appear inside names (of packages, architectures, files or anything else) or version numbers, or between the characters of multi-character version relationships. The presence and purpose of a field, and the syntax of its value may differ between types of control files. Field names are not case-sensitive, but it is usual to capitalize the field names using mixed case as shown below. Field values are case-sensitive unless the description of the field says otherwise. Stanza separators (empty lines) and lines consisting only of U+0020 SPACE and U+0009 TAB, are not allowed within field values or between fields. Empty lines in field values are usually escaped by representing them by a U+0020 SPACE followed by a dot (U+002E ‘.’). Lines starting with U+0023 ‘#’, without any preceding whitespace are comments lines that are only permitted in source package control files (debian/control) and in deb-origin (5) files. These comment lines are ignored, even between two continuation lines. They do not end logical lines. All control files must be encoded in UTF-8.

364 - Linux cli command nfs

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command nfs and provides detailed information about the command nfs, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the nfs.

NAME 🖥️ nfs 🖥️

fstab format and options for the nfs file systems

SYNOPSIS

/etc/fstab

DESCRIPTION

NFS is an Internet Standard protocol created by Sun Microsystems in 1984. NFS was developed to allow file sharing between systems residing on a local area network. Depending on kernel configuration, the Linux NFS client may support NFS versions 3, 4.0, 4.1, or 4.2.

The mount(8) command attaches a file system to the system’s name space hierarchy at a given mount point. The /etc/fstab file describes how mount(8) should assemble a system’s file name hierarchy from various independent file systems (including file systems exported by NFS servers). Each line in the /etc/fstab file describes a single file system, its mount point, and a set of default mount options for that mount point.

For NFS file system mounts, a line in the /etc/fstab file specifies the server name, the path name of the exported server directory to mount, the local directory that is the mount point, the type of file system that is being mounted, and a list of mount options that control the way the filesystem is mounted and how the NFS client behaves when accessing files on this mount point. The fifth and sixth fields on each line are not used by NFS, thus conventionally each contain the digit zero. For example:

	server:path	/mountpoint	fstype	option,option,...	0 0

The server’s hostname and export pathname are separated by a colon, while the mount options are separated by commas. The remaining fields are separated by blanks or tabs.

The server’s hostname can be an unqualified hostname, a fully qualified domain name, a dotted quad IPv4 address, or an IPv6 address enclosed in square brackets. Link-local and site-local IPv6 addresses must be accompanied by an interface identifier. See ipv6(7) for details on specifying raw IPv6 addresses.

The fstype field contains “nfs”. Use of the “nfs4” fstype in /etc/fstab is deprecated.

MOUNT OPTIONS

Refer to mount(8) for a description of generic mount options available for all file systems. If you do not need to specify any mount options, use the generic option defaults in /etc/fstab.

Options supported by all versions

These options are valid to use with any NFS version.

**nfsvers=**n
The NFS protocol version number used to contact the server’s NFS service. If the server does not support the requested version, the mount request fails. If this option is not specified, the client tries version 4.2 first, then negotiates down until it finds a version supported by the server.

**vers=**n
This option is an alternative to the nfsvers option. It is included for compatibility with other operating systems

soft / softerr / hard
Determines the recovery behavior of the NFS client after an NFS request times out. If no option is specified (or if the hard option is specified), NFS requests are retried indefinitely. If either the soft or softerr option is specified, then the NFS client fails an NFS request after retrans retransmissions have been sent, causing the NFS client to return either the error EIO (for the soft option) or ETIMEDOUT (for the softerr option) to the calling application.

NB: A so-called “soft” timeout can cause silent data corruption in certain cases. As such, use the soft or softerr option only when client responsiveness is more important than data integrity. Using NFS over TCP or increasing the value of the retrans option may mitigate some of the risks of using the soft or softerr option.

softreval / nosoftreval
In cases where the NFS server is down, it may be useful to allow the NFS client to continue to serve up paths and attributes from cache after retrans attempts to revalidate that cache have timed out. This may, for instance, be helpful when trying to unmount a filesystem tree from a server that is permanently down.

It is possible to combine softreval with the soft mount option, in which case operations that cannot be served up from cache will time out and return an error after retrans attempts. The combination with the default hard mount option implies those uncached operations will continue to retry until a response is received from the server.

Note: the default mount option is nosoftreval which disallows fallback to cache when revalidation fails, and instead follows the behavior dictated by the hard or soft mount option.

intr / nointr
This option is provided for backward compatibility. It is ignored after kernel 2.6.25.

**timeo=**n
The time in deciseconds (tenths of a second) the NFS client waits for a response before it retries an NFS request.

For NFS over TCP the default timeo value is 600 (60 seconds). The NFS client performs linear backoff: After each retransmission the timeout is increased by timeo up to the maximum of 600 seconds.

However, for NFS over UDP, the client uses an adaptive algorithm to estimate an appropriate timeout value for frequently used request types (such as READ and WRITE requests), but uses the timeo setting for infrequently used request types (such as FSINFO requests). If the timeo option is not specified, infrequently used request types are retried after 1.1 seconds. After each retransmission, the NFS client doubles the timeout for that request, up to a maximum timeout length of 60 seconds.

**retrans=**n
The number of times the NFS client retries a request before it attempts further recovery action. If the retrans option is not specified, the NFS client tries each UDP request three times and each TCP request twice.

The NFS client generates a “server not responding” message after retrans retries, then attempts further recovery (depending on whether the hard mount option is in effect).

**rsize=**n
The maximum number of bytes in each network READ request that the NFS client can receive when reading data from a file on an NFS server. The actual data payload size of each NFS READ request is equal to or smaller than the rsize setting. The largest read payload supported by the Linux NFS client is 1,048,576 bytes (one megabyte).

The rsize value is a positive integral multiple of 1024. Specified rsize values lower than 1024 are replaced with 4096; values larger than 1048576 are replaced with 1048576. If a specified value is within the supported range but not a multiple of 1024, it is rounded down to the nearest multiple of 1024.

If an rsize value is not specified, or if the specified rsize value is larger than the maximum that either client or server can support, the client and server negotiate the largest rsize value that they can both support.

The rsize mount option as specified on the mount(8) command line appears in the /etc/mtab file. However, the effective rsize value negotiated by the client and server is reported in the /proc/mounts file.

**wsize=**n
The maximum number of bytes per network WRITE request that the NFS client can send when writing data to a file on an NFS server. The actual data payload size of each NFS WRITE request is equal to or smaller than the wsize setting. The largest write payload supported by the Linux NFS client is 1,048,576 bytes (one megabyte).

Similar to rsize , the wsize value is a positive integral multiple of 1024. Specified wsize values lower than 1024 are replaced with 4096; values larger than 1048576 are replaced with 1048576. If a specified value is within the supported range but not a multiple of 1024, it is rounded down to the nearest multiple of 1024.

If a wsize value is not specified, or if the specified wsize value is larger than the maximum that either client or server can support, the client and server negotiate the largest wsize value that they can both support.

The wsize mount option as specified on the mount(8) command line appears in the /etc/mtab file. However, the effective wsize value negotiated by the client and server is reported in the /proc/mounts file.

ac / noac
Selects whether the client may cache file attributes. If neither option is specified (or if ac is specified), the client caches file attributes.

To improve performance, NFS clients cache file attributes. Every few seconds, an NFS client checks the server’s version of each file’s attributes for updates. Changes that occur on the server in those small intervals remain undetected until the client checks the server again. The noac option prevents clients from caching file attributes so that applications can more quickly detect file changes on the server.

In addition to preventing the client from caching file attributes, the noac option forces application writes to become synchronous so that local changes to a file become visible on the server immediately. That way, other clients can quickly detect recent writes when they check the file’s attributes.

Using the noac option provides greater cache coherence among NFS clients accessing the same files, but it extracts a significant performance penalty. As such, judicious use of file locking is encouraged instead. The DATA AND METADATA COHERENCE section contains a detailed discussion of these trade-offs.

**acregmin=**n
The minimum time (in seconds) that the NFS client caches attributes of a regular file before it requests fresh attribute information from a server. If this option is not specified, the NFS client uses a 3-second minimum. See the DATA AND METADATA COHERENCE section for a full discussion of attribute caching.

**acregmax=**n
The maximum time (in seconds) that the NFS client caches attributes of a regular file before it requests fresh attribute information from a server. If this option is not specified, the NFS client uses a 60-second maximum. See the DATA AND METADATA COHERENCE section for a full discussion of attribute caching.

**acdirmin=**n
The minimum time (in seconds) that the NFS client caches attributes of a directory before it requests fresh attribute information from a server. If this option is not specified, the NFS client uses a 30-second minimum. See the DATA AND METADATA COHERENCE section for a full discussion of attribute caching.

**acdirmax=**n
The maximum time (in seconds) that the NFS client caches attributes of a directory before it requests fresh attribute information from a server. If this option is not specified, the NFS client uses a 60-second maximum. See the DATA AND METADATA COHERENCE section for a full discussion of attribute caching.

**actimeo=**n
Using actimeo sets all of acregmin, acregmax, acdirmin, and acdirmax to the same value. If this option is not specified, the NFS client uses the defaults for each of these options listed above.

bg / fg
Determines how the mount(8) command behaves if an attempt to mount an export fails. The fg option causes mount(8) to exit with an error status if any part of the mount request times out or fails outright. This is called a “foreground” mount, and is the default behavior if neither the fg nor bg mount option is specified.

If the bg option is specified, a timeout or failure causes the mount(8) command to fork a child which continues to attempt to mount the export. The parent immediately returns with a zero exit code. This is known as a “background” mount.

If the local mount point directory is missing, the mount(8) command acts as if the mount request timed out. This permits nested NFS mounts specified in /etc/fstab to proceed in any order during system initialization, even if some NFS servers are not yet available. Alternatively these issues can be addressed using an automounter (refer to automount(8) for details).

**nconnect=**n
When using a connection oriented protocol such as TCP, it may sometimes be advantageous to set up multiple connections between the client and server. For instance, if your clients and/or servers are equipped with multiple network interface cards (NICs), using multiple connections to spread the load may improve overall performance. In such cases, the nconnect option allows the user to specify the number of connections that should be established between the client and server up to a limit of 16.

Note that the nconnect option may also be used by some pNFS drivers to decide how many connections to set up to the data servers.

rdirplus / nordirplus
Selects whether to use NFS v3 or v4 READDIRPLUS requests. If this option is not specified, the NFS client uses READDIRPLUS requests on NFS v3 or v4 mounts to read small directories. Some applications perform better if the client uses only READDIR requests for all directories.

**retry=**n
The number of minutes that the mount(8) command retries an NFS mount operation in the foreground or background before giving up. If this option is not specified, the default value for foreground mounts is 2 minutes, and the default value for background mounts is 10000 minutes (80 minutes shy of one week). If a value of zero is specified, the mount(8) command exits immediately after the first failure.

Note that this only affects how many retries are made and doesn’t affect the delay caused by each retry. For UDP each retry takes the time determined by the timeo and retrans options, which by default will be about 7 seconds. For TCP the default is 3 minutes, but system TCP connection timeouts will sometimes limit the timeout of each retransmission to around 2 minutes.

**sec=**flavors
A colon-separated list of one or more security flavors to use for accessing files on the mounted export. If the server does not support any of these flavors, the mount operation fails. If sec= is not specified, the client attempts to find a security flavor that both the client and the server supports. Valid flavors are none, sys, krb5, krb5i, and krb5p. Refer to the SECURITY CONSIDERATIONS section for details.

sharecache / nosharecache
Determines how the client’s data cache and attribute cache are shared when mounting the same export more than once concurrently. Using the same cache reduces memory requirements on the client and presents identical file contents to applications when the same remote file is accessed via different mount points.

If neither option is specified, or if the sharecache option is specified, then a single cache is used for all mount points that access the same export. If the nosharecache option is specified, then that mount point gets a unique cache. Note that when data and attribute caches are shared, the mount options from the first mount point take effect for subsequent concurrent mounts of the same export.

As of kernel 2.6.18, the behavior specified by nosharecache is legacy caching behavior. This is considered a data risk since multiple cached copies of the same file on the same client can become out of sync following a local update of one of the copies.

resvport / noresvport
Specifies whether the NFS client should use a privileged source port when communicating with an NFS server for this mount point. If this option is not specified, or the resvport option is specified, the NFS client uses a privileged source port. If the noresvport option is specified, the NFS client uses a non-privileged source port. This option is supported in kernels 2.6.28 and later.

Using non-privileged source ports helps increase the maximum number of NFS mount points allowed on a client, but NFS servers must be configured to allow clients to connect via non-privileged source ports.

Refer to the SECURITY CONSIDERATIONS section for important details.

**lookupcache=**mode
Specifies how the kernel manages its cache of directory entries for a given mount point. mode can be one of all, none, pos, or positive. This option is supported in kernels 2.6.28 and later.

The Linux NFS client caches the result of all NFS LOOKUP requests. If the requested directory entry exists on the server, the result is referred to as positive. If the requested directory entry does not exist on the server, the result is referred to as negative.

If this option is not specified, or if all is specified, the client assumes both types of directory cache entries are valid until their parent directory’s cached attributes expire.

If pos or positive is specified, the client assumes positive entries are valid until their parent directory’s cached attributes expire, but always revalidates negative entires before an application can use them.

If none is specified, the client revalidates both types of directory cache entries before an application can use them. This permits quick detection of files that were created or removed by other clients, but can impact application and server performance.

The DATA AND METADATA COHERENCE section contains a detailed discussion of these trade-offs.

fsc / nofsc
Enable/Disables the cache of (read-only) data pages to the local disk using the FS-Cache facility. See cachefilesd(8) and <kernel_source>/Documentation/filesystems/caching for detail on how to configure the FS-Cache facility. Default value is nofsc.

sloppy
The sloppy option is an alternative to specifying mount.nfs -s option.

**xprtsec=**policy
Specifies the use of transport layer security to protect NFS network traffic on behalf of this mount point. policy can be one of none, tls, or mtls.

If none is specified, transport layer security is forced off, even if the NFS server supports transport layer security.

If tls is specified, the client uses RPC-with-TLS to provide in-transit confidentiality.

If mtls is specified, the client uses RPC-with-TLS to authenticate itself and to provide in-transit confidentiality.

If either tls or mtls is specified and the server does not support RPC-with-TLS or peer authentication fails, the mount attempt fails.

If the xprtsec= option is not specified, the default behavior depends on the kernel version, but is usually equivalent to xprtsec=none.

Options for NFS versions 2 and 3 only

Use these options, along with the options in the above subsection, for NFS versions 2 and 3 only.

**proto=**netid
The netid determines the transport that is used to communicate with the NFS server. Available options are udp, udp6, tcp, tcp6, rdma, and rdma6. Those which end in 6 use IPv6 addresses and are only available if support for TI-RPC is built in. Others use IPv4 addresses.

Each transport protocol uses different default retrans and timeo settings. Refer to the description of these two mount options for details.

In addition to controlling how the NFS client transmits requests to the server, this mount option also controls how the mount(8) command communicates with the server’s rpcbind and mountd services. Specifying a netid that uses TCP forces all traffic from the mount(8) command and the NFS client to use TCP. Specifying a netid that uses UDP forces all traffic types to use UDP.

Before using NFS over UDP, refer to the TRANSPORT METHODS section.

If the proto mount option is not specified, the mount(8) command discovers which protocols the server supports and chooses an appropriate transport for each service. Refer to the TRANSPORT METHODS section for more details.

udp
The udp option is an alternative to specifying proto=udp. It is included for compatibility with other operating systems.

Before using NFS over UDP, refer to the TRANSPORT METHODS section.

tcp
The tcp option is an alternative to specifying proto=tcp. It is included for compatibility with other operating systems.

rdma
The rdma option is an alternative to specifying proto=rdma.

**port=**n
The numeric value of the server’s NFS service port. If the server’s NFS service is not available on the specified port, the mount request fails.

If this option is not specified, or if the specified port value is 0, then the NFS client uses the NFS service port number advertised by the server’s rpcbind service. The mount request fails if the server’s rpcbind service is not available, the server’s NFS service is not registered with its rpcbind service, or the server’s NFS service is not available on the advertised port.

**mountport=**n
The numeric value of the server’s mountd port. If the server’s mountd service is not available on the specified port, the mount request fails.

If this option is not specified, or if the specified port value is 0, then the mount(8) command uses the mountd service port number advertised by the server’s rpcbind service. The mount request fails if the server’s rpcbind service is not available, the server’s mountd service is not registered with its rpcbind service, or the server’s mountd service is not available on the advertised port.

This option can be used when mounting an NFS server through a firewall that blocks the rpcbind protocol.

**mountproto=**netid
The transport the NFS client uses to transmit requests to the NFS server’s mountd service when performing this mount request, and when later unmounting this mount point.

netid may be one of udp, and tcp which use IPv4 address or, if TI-RPC is built into the mount.nfs command, udp6, and tcp6 which use IPv6 addresses.

This option can be used when mounting an NFS server through a firewall that blocks a particular transport. When used in combination with the proto option, different transports for mountd requests and NFS requests can be specified. If the server’s mountd service is not available via the specified transport, the mount request fails.

Refer to the TRANSPORT METHODS section for more on how the mountproto mount option interacts with the proto mount option.

**mounthost=**name
The hostname of the host running mountd. If this option is not specified, the mount(8) command assumes that the mountd service runs on the same host as the NFS service.

**mountvers=**n
The RPC version number used to contact the server’s mountd. If this option is not specified, the client uses a version number appropriate to the requested NFS version. This option is useful when multiple NFS services are running on the same remote server host.

**namlen=**n
The maximum length of a pathname component on this mount. If this option is not specified, the maximum length is negotiated with the server. In most cases, this maximum length is 255 characters.

Some early versions of NFS did not support this negotiation. Using this option ensures that pathconf(3) reports the proper maximum component length to applications in such cases.

lock / nolock
Selects whether to use the NLM sideband protocol to lock files on the server. If neither option is specified (or if lock is specified), NLM locking is used for this mount point. When using the nolock option, applications can lock files, but such locks provide exclusion only against other applications running on the same client. Remote applications are not affected by these locks.

NLM locking must be disabled with the nolock option when using NFS to mount /var because /var contains files used by the NLM implementation on Linux. Using the nolock option is also required when mounting exports on NFS servers that do not support the NLM protocol.

cto / nocto
Selects whether to use close-to-open cache coherence semantics. If neither option is specified (or if cto is specified), the client uses close-to-open cache coherence semantics. If the nocto option is specified, the client uses a non-standard heuristic to determine when files on the server have changed.

Using the nocto option may improve performance for read-only mounts, but should be used only if the data on the server changes only occasionally. The DATA AND METADATA COHERENCE section discusses the behavior of this option in more detail.

acl / noacl
Selects whether to use the NFSACL sideband protocol on this mount point. The NFSACL sideband protocol is a proprietary protocol implemented in Solaris that manages Access Control Lists. NFSACL was never made a standard part of the NFS protocol specification.

If neither acl nor noacl option is specified, the NFS client negotiates with the server to see if the NFSACL protocol is supported, and uses it if the server supports it. Disabling the NFSACL sideband protocol may be necessary if the negotiation causes problems on the client or server. Refer to the SECURITY CONSIDERATIONS section for more details.

**local_lock=**mechanism
Specifies whether to use local locking for any or both of the flock and the POSIX locking mechanisms. mechanism can be one of all, flock, posix, or none. This option is supported in kernels 2.6.37 and later.

The Linux NFS client provides a way to make locks local. This means, the applications can lock files, but such locks provide exclusion only against other applications running on the same client. Remote applications are not affected by these locks.

If this option is not specified, or if none is specified, the client assumes that the locks are not local.

If all is specified, the client assumes that both flock and POSIX locks are local.

If flock is specified, the client assumes that only flock locks are local and uses NLM sideband protocol to lock files when POSIX locks are used.

If posix is specified, the client assumes that POSIX locks are local and uses NLM sideband protocol to lock files when flock locks are used.

To support legacy flock behavior similar to that of NFS clients < 2.6.12, use ’local_lock=flock’. This option is required when exporting NFS mounts via Samba as Samba maps Windows share mode locks as flock. Since NFS clients > 2.6.12 implement flock by emulating POSIX locks, this will result in conflicting locks.

NOTE: When used together, the ’local_lock’ mount option will be overridden by ’nolock’/’lock’ mount option.

Options for NFS version 4 only

Use these options, along with the options in the first subsection above, for NFS version 4.0 and newer.

**proto=**netid
The netid determines the transport that is used to communicate with the NFS server. Supported options are tcp, tcp6, rdma, and rdma6. tcp6 use IPv6 addresses and is only available if support for TI-RPC is built in. Both others use IPv4 addresses.

All NFS version 4 servers are required to support TCP, so if this mount option is not specified, the NFS version 4 client uses the TCP protocol. Refer to the TRANSPORT METHODS section for more details.

**minorversion=**n
Specifies the protocol minor version number. NFSv4 introduces “minor versioning,” where NFS protocol enhancements can be introduced without bumping the NFS protocol version number. Before kernel 2.6.38, the minor version is always zero, and this option is not recognized. After this kernel, specifying “minorversion=1” enables a number of advanced features, such as NFSv4 sessions.

Recent kernels allow the minor version to be specified using the vers= option. For example, specifying vers=4.1 is the same as specifying vers=4,minorversion=1.

**port=**n
The numeric value of the server’s NFS service port. If the server’s NFS service is not available on the specified port, the mount request fails.

If this mount option is not specified, the NFS client uses the standard NFS port number of 2049 without first checking the server’s rpcbind service. This allows an NFS version 4 client to contact an NFS version 4 server through a firewall that may block rpcbind requests.

If the specified port value is 0, then the NFS client uses the NFS service port number advertised by the server’s rpcbind service. The mount request fails if the server’s rpcbind service is not available, the server’s NFS service is not registered with its rpcbind service, or the server’s NFS service is not available on the advertised port.

cto / nocto
Selects whether to use close-to-open cache coherence semantics for NFS directories on this mount point. If neither cto nor nocto is specified, the default is to use close-to-open cache coherence semantics for directories.

File data caching behavior is not affected by this option. The DATA AND METADATA COHERENCE section discusses the behavior of this option in more detail.

**clientaddr=n.n.n.n
clientaddr=n:n:…:n
Specifies a single IPv4 address (in dotted-quad form), or a non-link-local IPv6 address, that the NFS client advertises to allow servers to perform NFS version 4.0 callback requests against files on this mount point. If the server is unable to establish callback connections to clients, performance may degrade, or accesses to files may temporarily hang. Can specify a value of IPv4_ANY (0.0.0.0) or equivalent IPv6 any address which will signal to the NFS server that this NFS client does not want delegations.

If this option is not specified, the mount(8) command attempts to discover an appropriate callback address automatically. The automatic discovery process is not perfect, however. In the presence of multiple client network interfaces, special routing policies, or atypical network topologies, the exact address to use for callbacks may be nontrivial to determine.

NFS protocol versions 4.1 and 4.2 use the client-established TCP connection for callback requests, so do not require the server to connect to the client. This option is therefore only affect NFS version 4.0 mounts.

migration / nomigration
Selects whether the client uses an identification string that is compatible with NFSv4 Transparent State Migration (TSM). If the mounted server supports NFSv4 migration with TSM, specify the migration option.

Some server features misbehave in the face of a migration-compatible identification string. The nomigration option retains the use of a traditional client indentification string which is compatible with legacy NFS servers. This is also the behavior if neither option is specified. A client’s open and lock state cannot be migrated transparently when it identifies itself via a traditional identification string.

This mount option has no effect with NFSv4 minor versions newer than zero, which always use TSM-compatible client identification strings.

**max_connect=**n
While nconnect option sets a limit on the number of connections that can be established to a given server IP, max_connect option allows the user to specify maximum number of connections to different server IPs that belong to the same NFSv4.1+ server (session trunkable connections) up to a limit of 16. When client discovers that it established a client ID to an already existing server, instead of dropping the newly created network transport, the client will add this new connection to the list of available transports for that RPC client.

trunkdiscovery / notrunkdiscovery
When the client discovers a new filesystem on a NFSv4.1+ server, the trunkdiscovery mount option will cause it to send a GETATTR for the fs_locations attribute. If is receives a non-zero length reply, it will iterate through the response, and for each server location it will establish a connection, send an EXCHANGE_ID, and test for session trunking. If the trunking test succeeds, the connection will be added to the existing set of transports for the server, subject to the limit specified by the max_connect option. The default is notrunkdiscovery.

nfs4 FILE SYSTEM TYPE

The nfs4 file system type is an old syntax for specifying NFSv4 usage. It can still be used with all NFSv4-specific and common options, excepted the nfsvers mount option.

MOUNT CONFIGURATION FILE

If the mount command is configured to do so, all of the mount options described in the previous section can also be configured in the /etc/nfsmount.conf file. See nfsmount.conf(5) for details.

EXAMPLES

To mount using NFS version 3, use the nfs file system type and specify the nfsvers=3 mount option. To mount using NFS version 4, use either the nfs file system type, with the nfsvers=4 mount option, or the nfs4 file system type.

The following example from an /etc/fstab file causes the mount command to negotiate reasonable defaults for NFS behavior.

	server:/export	/mnt	nfs	defaults	0 0

This example shows how to mount using NFS version 4 over TCP with Kerberos 5 mutual authentication.

	server:/export	/mnt	nfs4	sec=krb5	0 0

This example shows how to mount using NFS version 4 over TCP with Kerberos 5 privacy or data integrity mode.

	server:/export	/mnt	nfs4	sec=krb5p:krb5i	0 0

This example can be used to mount /usr over NFS.

	server:/export	/usr	nfs	ro,nolock,nocto,actimeo=3600	0 0

This example shows how to mount an NFS server using a raw IPv6 link-local address.

	[fe80::215:c5ff:fb3e:e2b1%eth0]:/export	/mnt	nfs	defaults	0 0

TRANSPORT METHODS

NFS clients send requests to NFS servers via Remote Procedure Calls, or RPCs. The RPC client discovers remote service endpoints automatically, handles per-request authentication, adjusts request parameters for different byte endianness on client and server, and retransmits requests that may have been lost by the network or server. RPC requests and replies flow over a network transport.

In most cases, the mount(8) command, NFS client, and NFS server can automatically negotiate proper transport and data transfer size settings for a mount point. In some cases, however, it pays to specify these settings explicitly using mount options.

Traditionally, NFS clients used the UDP transport exclusively for transmitting requests to servers. Though its implementation is simple, NFS over UDP has many limitations that prevent smooth operation and good performance in some common deployment environments. Even an insignificant packet loss rate results in the loss of whole NFS requests; as such, retransmit timeouts are usually in the subsecond range to allow clients to recover quickly from dropped requests, but this can result in extraneous network traffic and server load.

However, UDP can be quite effective in specialized settings where the networks MTU is large relative to NFSs data transfer size (such as network environments that enable jumbo Ethernet frames). In such environments, trimming the rsize and wsize settings so that each NFS read or write request fits in just a few network frames (or even in a single frame) is advised. This reduces the probability that the loss of a single MTU-sized network frame results in the loss of an entire large read or write request.

TCP is the default transport protocol used for all modern NFS implementations. It performs well in almost every conceivable network environment and provides excellent guarantees against data corruption caused by network unreliability. TCP is often a requirement for mounting a server through a network firewall.

Under normal circumstances, networks drop packets much more frequently than NFS servers drop requests. As such, an aggressive retransmit timeout setting for NFS over TCP is unnecessary. Typical timeout settings for NFS over TCP are between one and ten minutes. After the client exhausts its retransmits (the value of the retrans mount option), it assumes a network partition has occurred, and attempts to reconnect to the server on a fresh socket. Since TCP itself makes network data transfer reliable, rsize and wsize can safely be allowed to default to the largest values supported by both client and server, independent of the network’s MTU size.

Using the mountproto mount option

This section applies only to NFS version 3 mounts since NFS version 4 does not use a separate protocol for mount requests.

The Linux NFS client can use a different transport for contacting an NFS server’s rpcbind service, its mountd service, its Network Lock Manager (NLM) service, and its NFS service. The exact transports employed by the Linux NFS client for each mount point depends on the settings of the transport mount options, which include proto, mountproto, udp, and tcp.

The client sends Network Status Manager (NSM) notifications via UDP no matter what transport options are specified, but listens for server NSM notifications on both UDP and TCP. The NFS Access Control List (NFSACL) protocol shares the same transport as the main NFS service.

If no transport options are specified, the Linux NFS client uses UDP to contact the server’s mountd service, and TCP to contact its NLM and NFS services by default.

If the server does not support these transports for these services, the mount(8) command attempts to discover what the server supports, and then retries the mount request once using the discovered transports. If the server does not advertise any transport supported by the client or is misconfigured, the mount request fails. If the bg option is in effect, the mount command backgrounds itself and continues to attempt the specified mount request.

When the proto option, the udp option, or the tcp option is specified but the mountproto option is not, the specified transport is used to contact both the server’s mountd service and for the NLM and NFS services.

If the mountproto option is specified but none of the proto, udp or tcp options are specified, then the specified transport is used for the initial mountd request, but the mount command attempts to discover what the server supports for the NFS protocol, preferring TCP if both transports are supported.

If both the mountproto and proto (or udp or tcp) options are specified, then the transport specified by the mountproto option is used for the initial mountd request, and the transport specified by the proto option (or the udp or tcp options) is used for NFS, no matter what order these options appear. No automatic service discovery is performed if these options are specified.

If any of the proto, udp, tcp, or mountproto options are specified more than once on the same mount command line, then the value of the rightmost instance of each of these options takes effect.

Using NFS over UDP on high-speed links

Using NFS over UDP on high-speed links such as Gigabit can cause silent data corruption.

The problem can be triggered at high loads, and is caused by problems in IP fragment reassembly. NFS read and writes typically transmit UDP packets of 4 Kilobytes or more, which have to be broken up into several fragments in order to be sent over the Ethernet link, which limits packets to 1500 bytes by default. This process happens at the IP network layer and is called fragmentation.

In order to identify fragments that belong together, IP assigns a 16bit IP ID value to each packet; fragments generated from the same UDP packet will have the same IP ID. The receiving system will collect these fragments and combine them to form the original UDP packet. This process is called reassembly. The default timeout for packet reassembly is 30 seconds; if the network stack does not receive all fragments of a given packet within this interval, it assumes the missing fragment(s) got lost and discards those it already received.

The problem this creates over high-speed links is that it is possible to send more than 65536 packets within 30 seconds. In fact, with heavy NFS traffic one can observe that the IP IDs repeat after about 5 seconds.

This has serious effects on reassembly: if one fragment gets lost, another fragment from a different packet but with the same IP ID will arrive within the 30 second timeout, and the network stack will combine these fragments to form a new packet. Most of the time, network layers above IP will detect this mismatched reassembly - in the case of UDP, the UDP checksum, which is a 16 bit checksum over the entire packet payload, will usually not match, and UDP will discard the bad packet.

However, the UDP checksum is 16 bit only, so there is a chance of 1 in 65536 that it will match even if the packet payload is completely random (which very often isn’t the case). If that is the case, silent data corruption will occur.

This potential should be taken seriously, at least on Gigabit Ethernet. Network speeds of 100Mbit/s should be considered less problematic, because with most traffic patterns IP ID wrap around will take much longer than 30 seconds.

It is therefore strongly recommended to use NFS over TCP where possible, since TCP does not perform fragmentation.

If you absolutely have to use NFS over UDP over Gigabit Ethernet, some steps can be taken to mitigate the problem and reduce the probability of corruption:

Jumbo frames:
Many Gigabit network cards are capable of transmitting frames bigger than the 1500 byte limit of traditional Ethernet, typically 9000 bytes. Using jumbo frames of 9000 bytes will allow you to run NFS over UDP at a page size of 8K without fragmentation. Of course, this is only feasible if all involved stations support jumbo frames.

To enable a machine to send jumbo frames on cards that support it, it is sufficient to configure the interface for a MTU value of 9000.

Lower reassembly timeout:
By lowering this timeout below the time it takes the IP ID counter to wrap around, incorrect reassembly of fragments can be prevented as well. To do so, simply write the new timeout value (in seconds) to the file /proc/sys/net/ipv4/ipfrag_time.

A value of 2 seconds will greatly reduce the probability of IPID clashes on a single Gigabit link, while still allowing for a reasonable timeout when receiving fragmented traffic from distant peers.

DATA AND METADATA COHERENCE

Some modern cluster file systems provide perfect cache coherence among their clients. Perfect cache coherence among disparate NFS clients is expensive to achieve, especially on wide area networks. As such, NFS settles for weaker cache coherence that satisfies the requirements of most file sharing types.

Close-to-open cache consistency

Typically file sharing is completely sequential. First client A opens a file, writes something to it, then closes it. Then client B opens the same file, and reads the changes.

When an application opens a file stored on an NFS version 3 server, the NFS client checks that the file exists on the server and is permitted to the opener by sending a GETATTR or ACCESS request. The NFS client sends these requests regardless of the freshness of the file’s cached attributes.

When the application closes the file, the NFS client writes back any pending changes to the file so that the next opener can view the changes. This also gives the NFS client an opportunity to report write errors to the application via the return code from close(2).

The behavior of checking at open time and flushing at close time is referred to as close-to-open cache consistency, or CTO. It can be disabled for an entire mount point using the nocto mount option.

Weak cache consistency

There are still opportunities for a client’s data cache to contain stale data. The NFS version 3 protocol introduced “weak cache consistency” (also known as WCC) which provides a way of efficiently checking a file’s attributes before and after a single request. This allows a client to help identify changes that could have been made by other clients.

When a client is using many concurrent operations that update the same file at the same time (for example, during asynchronous write behind), it is still difficult to tell whether it was that client’s updates or some other client’s updates that altered the file.

Attribute caching

Use the noac mount option to achieve attribute cache coherence among multiple clients. Almost every file system operation checks file attribute information. The client keeps this information cached for a period of time to reduce network and server load. When noac is in effect, a client’s file attribute cache is disabled, so each operation that needs to check a file’s attributes is forced to go back to the server. This permits a client to see changes to a file very quickly, at the cost of many extra network operations.

Be careful not to confuse the noac option with “no data caching.” The noac mount option prevents the client from caching file metadata, but there are still races that may result in data cache incoherence between client and server.

The NFS protocol is not designed to support true cluster file system cache coherence without some type of application serialization. If absolute cache coherence among clients is required, applications should use file locking. Alternatively, applications can also open their files with the O_DIRECT flag to disable data caching entirely.

File timestamp maintenance

NFS servers are responsible for managing file and directory timestamps (atime, ctime, and mtime). When a file is accessed or updated on an NFS server, the file’s timestamps are updated just like they would be on a filesystem local to an application.

NFS clients cache file attributes, including timestamps. A file’s timestamps are updated on NFS clients when its attributes are retrieved from the NFS server. Thus there may be some delay before timestamp updates on an NFS server appear to applications on NFS clients.

To comply with the POSIX filesystem standard, the Linux NFS client relies on NFS servers to keep a file’s mtime and ctime timestamps properly up to date. It does this by flushing local data changes to the server before reporting mtime to applications via system calls such as stat(2).

The Linux client handles atime updates more loosely, however. NFS clients maintain good performance by caching data, but that means that application reads, which normally update atime, are not reflected to the server where a file’s atime is actually maintained.

Because of this caching behavior, the Linux NFS client does not support generic atime-related mount options. See mount(8) for details on these options.

In particular, the atime/noatime, diratime/nodiratime, relatime/norelatime, and strictatime/nostrictatime mount options have no effect on NFS mounts.

/proc/mounts may report that the relatime mount option is set on NFS mounts, but in fact the atime semantics are always as described here, and are not like relatime semantics.

Directory entry caching

The Linux NFS client caches the result of all NFS LOOKUP requests. If the requested directory entry exists on the server, the result is referred to as a positive"lookupresult. If the requested directory entry does not exist on the server (that is, the server returned ENOENT), the result is referred to as negative"lookupresult.

To detect when directory entries have been added or removed on the server, the Linux NFS client watches a directory’s mtime. If the client detects a change in a directory’s mtime, the client drops all cached LOOKUP results for that directory. Since the directory’s mtime is a cached attribute, it may take some time before a client notices it has changed. See the descriptions of the acdirmin, acdirmax, and noac mount options for more information about how long a directory’s mtime is cached.

Caching directory entries improves the performance of applications that do not share files with applications on other clients. Using cached information about directories can interfere with applications that run concurrently on multiple clients and need to detect the creation or removal of files quickly, however. The lookupcache mount option allows some tuning of directory entry caching behavior.

Before kernel release 2.6.28, the Linux NFS client tracked only positive lookup results. This permitted applications to detect new directory entries created by other clients quickly while still providing some of the performance benefits of caching. If an application depends on the previous lookup caching behavior of the Linux NFS client, you can use lookupcache=positive.

If the client ignores its cache and validates every application lookup request with the server, that client can immediately detect when a new directory entry has been either created or removed by another client. You can specify this behavior using lookupcache=none. The extra NFS requests needed if the client does not cache directory entries can exact a performance penalty. Disabling lookup caching should result in less of a performance penalty than using noac, and has no effect on how the NFS client caches the attributes of files.

The sync mount option

The NFS client treats the sync mount option differently than some other file systems (refer to mount(8) for a description of the generic sync and async mount options). If neither sync nor async is specified (or if the async option is specified), the NFS client delays sending application writes to the server until any of these events occur:

Memory pressure forces reclamation of system memory resources.

An application flushes file data explicitly with sync(2), msync(2), or fsync(3).

An application closes a file with close(2).

The file is locked/unlocked via fcntl(2).

In other words, under normal circumstances, data written by an application may not immediately appear on the server that hosts the file.

If the sync option is specified on a mount point, any system call that writes data to files on that mount point causes that data to be flushed to the server before the system call returns control to user space. This provides greater data cache coherence among clients, but at a significant performance cost.

Applications can use the O_SYNC open flag to force application writes to individual files to go to the server immediately without the use of the sync mount option.

Using file locks with NFS

The Network Lock Manager protocol is a separate sideband protocol used to manage file locks in NFS version 3. To support lock recovery after a client or server reboot, a second sideband protocol – known as the Network Status Manager protocol – is also required. In NFS version 4, file locking is supported directly in the main NFS protocol, and the NLM and NSM sideband protocols are not used.

In most cases, NLM and NSM services are started automatically, and no extra configuration is required. Configure all NFS clients with fully-qualified domain names to ensure that NFS servers can find clients to notify them of server reboots.

NLM supports advisory file locks only. To lock NFS files, use fcntl(2) with the F_GETLK and F_SETLK commands. The NFS client converts file locks obtained via flock(2) to advisory locks.

When mounting servers that do not support the NLM protocol, or when mounting an NFS server through a firewall that blocks the NLM service port, specify the nolock mount option. NLM locking must be disabled with the nolock option when using NFS to mount /var because /var contains files used by the NLM implementation on Linux.

Specifying the nolock option may also be advised to improve the performance of a proprietary application which runs on a single client and uses file locks extensively.

NFS version 4 caching features

The data and metadata caching behavior of NFS version 4 clients is similar to that of earlier versions. However, NFS version 4 adds two features that improve cache behavior: change attributes and file delegation.

The change attribute is a new part of NFS file and directory metadata which tracks data changes. It replaces the use of a file’s modification and change time stamps as a way for clients to validate the content of their caches. Change attributes are independent of the time stamp resolution on either the server or client, however.

A file delegation is a contract between an NFS version 4 client and server that allows the client to treat a file temporarily as if no other client is accessing it. The server promises to notify the client (via a callback request) if another client attempts to access that file. Once a file has been delegated to a client, the client can cache that file’s data and metadata aggressively without contacting the server.

File delegations come in two flavors: read and write. A read delegation means that the server notifies the client about any other clients that want to write to the file. A write delegation means that the client gets notified about either read or write accessors.

Servers grant file delegations when a file is opened, and can recall delegations at any time when another client wants access to the file that conflicts with any delegations already granted. Delegations on directories are not supported.

In order to support delegation callback, the server checks the network return path to the client during the client’s initial contact with the server. If contact with the client cannot be established, the server simply does not grant any delegations to that client.

SECURITY CONSIDERATIONS

NFS servers control access to file data, but they depend on their RPC implementation to provide authentication of NFS requests. Traditional NFS access control mimics the standard mode bit access control provided in local file systems. Traditional RPC authentication uses a number to represent each user (usually the user’s own uid), a number to represent the user’s group (the user’s gid), and a set of up to 16 auxiliary group numbers to represent other groups of which the user may be a member.

Typically, file data and user ID values appear unencrypted (i.e. “in the clear”) on the network. Moreover, NFS versions 2 and 3 use separate sideband protocols for mounting, locking and unlocking files, and reporting system status of clients and servers. These auxiliary protocols use no authentication.

In addition to combining these sideband protocols with the main NFS protocol, NFS version 4 introduces more advanced forms of access control, authentication, and in-transit data protection. The NFS version 4 specification mandates support for strong authentication and security flavors that provide per-RPC integrity checking and encryption. Because NFS version 4 combines the function of the sideband protocols into the main NFS protocol, the new security features apply to all NFS version 4 operations including mounting, file locking, and so on. RPCGSS authentication can also be used with NFS versions 2 and 3, but it does not protect their sideband protocols.

The sec mount option specifies the security flavor used for operations on behalf of users on that NFS mount point. Specifying sec=krb5 provides cryptographic proof of a user’s identity in each RPC request. This provides strong verification of the identity of users accessing data on the server. Note that additional configuration besides adding this mount option is required in order to enable Kerberos security. Refer to the rpc.gssd(8) man page for details.

Two additional flavors of Kerberos security are supported: krb5i and krb5p. The krb5i security flavor provides a cryptographically strong guarantee that the data in each RPC request has not been tampered with. The krb5p security flavor encrypts every RPC request to prevent data exposure during network transit; however, expect some performance impact when using integrity checking or encryption. Similar support for other forms of cryptographic security is also available.

NFS version 4 filesystem crossing

The NFS version 4 protocol allows a client to renegotiate the security flavor when the client crosses into a new filesystem on the server. The newly negotiated flavor effects only accesses of the new filesystem.

Such negotiation typically occurs when a client crosses from a server’s pseudo-fs into one of the server’s exported physical filesystems, which often have more restrictive security settings than the pseudo-fs.

NFS version 4 Leases

In NFS version 4, a lease is a period during which a server irrevocably grants a client file locks. Once the lease expires, the server may revoke those locks. Clients periodically renew their leases to prevent lock revocation.

After an NFS version 4 server reboots, each client tells the server about existing file open and lock state under its lease before operation can continue. If a client reboots, the server frees all open and lock state associated with that client’s lease.

When establishing a lease, therefore, a client must identify itself to a server. Each client presents an arbitrary string to distinguish itself from other clients. The client administrator can supplement the default identity string using the nfs4.nfs4_unique_id module parameter to avoid collisions with other client identity strings.

A client also uses a unique security flavor and principal when it establishes its lease. If two clients present the same identity string, a server can use client principals to distinguish between them, thus securely preventing one client from interfering with the other’s lease.

The Linux NFS client establishes one lease on each NFS version 4 server. Lease management operations, such as lease renewal, are not done on behalf of a particular file, lock, user, or mount point, but on behalf of the client that owns that lease. A client uses a consistent identity string, security flavor, and principal across client reboots to ensure that the server can promptly reap expired lease state.

When Kerberos is configured on a Linux NFS client (i.e., there is a /etc/krb5.keytab on that client), the client attempts to use a Kerberos security flavor for its lease management operations. Kerberos provides secure authentication of each client. By default, the client uses the host/ or nfs/ service principal in its /etc/krb5.keytab for this purpose, as described in rpc.gssd(8).

If the client has Kerberos configured, but the server does not, or if the client does not have a keytab or the requisite service principals, the client uses AUTH_SYS and UID 0 for lease management.

Using non-privileged source ports

NFS clients usually communicate with NFS servers via network sockets. Each end of a socket is assigned a port value, which is simply a number between 1 and 65535 that distinguishes socket endpoints at the same IP address. A socket is uniquely defined by a tuple that includes the transport protocol (TCP or UDP) and the port values and IP addresses of both endpoints.

The NFS client can choose any source port value for its sockets, but usually chooses a privileged port. A privileged port is a port value less than 1024. Only a process with root privileges may create a socket with a privileged source port.

The exact range of privileged source ports that can be chosen is set by a pair of sysctls to avoid choosing a well-known port, such as the port used by ssh. This means the number of source ports available for the NFS client, and therefore the number of socket connections that can be used at the same time, is practically limited to only a few hundred.

As described above, the traditional default NFS authentication scheme, known as AUTH_SYS, relies on sending local UID and GID numbers to identify users making NFS requests. An NFS server assumes that if a connection comes from a privileged port, the UID and GID numbers in the NFS requests on this connection have been verified by the client’s kernel or some other local authority. This is an easy system to spoof, but on a trusted physical network between trusted hosts, it is entirely adequate.

Roughly speaking, one socket is used for each NFS mount point. If a client could use non-privileged source ports as well, the number of sockets allowed, and thus the maximum number of concurrent mount points, would be much larger.

Using non-privileged source ports may compromise server security somewhat, since any user on AUTH_SYS mount points can now pretend to be any other when making NFS requests. Thus NFS servers do not support this by default. They explicitly allow it usually via an export option.

To retain good security while allowing as many mount points as possible, it is best to allow non-privileged client connections only if the server and client both require strong authentication, such as Kerberos.

Mounting through a firewall

A firewall may reside between an NFS client and server, or the client or server may block some of its own ports via IP filter rules. It is still possible to mount an NFS server through a firewall, though some of the mount(8) command’s automatic service endpoint discovery mechanisms may not work; this requires you to provide specific endpoint details via NFS mount options.

NFS servers normally run a portmapper or rpcbind daemon to advertise their service endpoints to clients. Clients use the rpcbind daemon to determine:

What network port each RPC-based service is using

What transport protocols each RPC-based service supports

The rpcbind daemon uses a well-known port number (111) to help clients find a service endpoint. Although NFS often uses a standard port number (2049), auxiliary services such as the NLM service can choose any unused port number at random.

Common firewall configurations block the well-known rpcbind port. In the absense of an rpcbind service, the server administrator fixes the port number of NFS-related services so that the firewall can allow access to specific NFS service ports. Client administrators then specify the port number for the mountd service via the mount(8) command’s mountport option. It may also be necessary to enforce the use of TCP or UDP if the firewall blocks one of those transports.

NFS Access Control Lists

Solaris allows NFS version 3 clients direct access to POSIX Access Control Lists stored in its local file systems. This proprietary sideband protocol, known as NFSACL, provides richer access control than mode bits. Linux implements this protocol for compatibility with the Solaris NFS implementation. The NFSACL protocol never became a standard part of the NFS version 3 specification, however.

The NFS version 4 specification mandates a new version of Access Control Lists that are semantically richer than POSIX ACLs. NFS version 4 ACLs are not fully compatible with POSIX ACLs; as such, some translation between the two is required in an environment that mixes POSIX ACLs and NFS version 4.

THE REMOUNT OPTION

Generic mount options such as rw and sync can be modified on NFS mount points using the remount option. See mount(8) for more information on generic mount options.

With few exceptions, NFS-specific options are not able to be modified during a remount. The underlying transport or NFS version cannot be changed by a remount, for example.

Performing a remount on an NFS file system mounted with the noac option may have unintended consequences. The noac option is a combination of the generic option sync, and the NFS-specific option actimeo=0.

Unmounting after a remount

For mount points that use NFS versions 2 or 3, the NFS umount subcommand depends on knowing the original set of mount options used to perform the MNT operation. These options are stored on disk by the NFS mount subcommand, and can be erased by a remount.

To ensure that the saved mount options are not erased during a remount, specify either the local mount directory, or the server hostname and export pathname, but not both, during a remount. For example,

	mount -o remount,ro /mnt

merges the mount option ro with the mount options already saved on disk for the NFS server mounted at /mnt.

FILES

/etc/fstab
file system table

/etc/nfsmount.conf
Configuration file for NFS mounts

NOTES

Before 2.4.7, the Linux NFS client did not support NFS over TCP.

Before 2.4.20, the Linux NFS client used a heuristic to determine whether cached file data was still valid rather than using the standard close-to-open cache coherency method described above.

Starting with 2.4.22, the Linux NFS client employs a Van Jacobsen-based RTT estimator to determine retransmit timeout values when using NFS over UDP.

Before 2.6.0, the Linux NFS client did not support NFS version 4.

Before 2.6.8, the Linux NFS client used only synchronous reads and writes when the rsize and wsize settings were smaller than the system’s page size.

The Linux client’s support for protocol versions depend on whether the kernel was built with options CONFIG_NFS_V2, CONFIG_NFS_V3, CONFIG_NFS_V4, CONFIG_NFS_V4_1, and CONFIG_NFS_V4_2.

365 - Linux cli command access.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command access.conf and provides detailed information about the command access.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the access.conf.

NAME 🖥️ access.conf 🖥️

the login access control table file

DESCRIPTION

The /etc/security/access.conf file specifies (user/group, host), (user/group, network/netmask), (user/group, tty), (user/group, X-$DISPLAY-value), or (user/group, pam-service-name) combinations for which a login will be either accepted or refused.

When someone logs in, the file access.conf is scanned for the first entry that matches the (user/group, host) or (user/group, network/netmask) combination, or, in case of non-networked logins, the first entry that matches the (user/group, tty) combination, or in the case of non-networked logins without a tty, the first entry that matches the (user/group, X-$DISPLAY-value) or (user/group, pam-service-name/) combination. The permissions field of that table entry determines whether the login will be accepted or refused.

Each line of the login access control table has three fields separated by a “:” character (colon):

permission:users/groups:origins

The first field, the permission field, can be either a “+” character (plus) for access granted or a “-” character (minus) for access denied.

The second field, the users/group field, should be a list of one or more login names, group names, or ALL (which always matches). To differentiate user entries from group entries, group entries should be written with brackets, e.g. (group).

The third field, the origins field, should be a list of one or more tty names (for non-networked logins), X $DISPLAY values or PAM service names (for non-networked logins without a tty), host names, domain names (begin with “.”), host addresses, internet network numbers (end with “.”), internet network addresses with network mask (where network mask can be a decimal number or an internet address also), ALL (which always matches) or LOCAL. The LOCAL keyword matches if and only if pam_get_item(3), when called with an item_type of PAM_RHOST, returns NULL or an empty string (and therefore the origins field is compared against the return value of pam_get_item(3) called with an item_type of PAM_TTY or, absent that, PAM_SERVICE).

If supported by the system you can use @netgroupname in host or user patterns. The @@netgroupname syntax is supported in the user pattern only and it makes the local system hostname to be passed to the netgroup match call in addition to the user name. This might not work correctly on some libc implementations causing the match to always fail.

The EXCEPT operator makes it possible to write very compact rules.

If the nodefgroup is not set, the group file is searched when a name does not match that of the logged-in user. Only groups are matched in which users are explicitly listed. However the PAM module does not look at the primary group id of a user.

The “#” character at start of line (no space at front) can be used to mark this line as a comment line.

EXAMPLES

These are some example lines which might be specified in /etc/security/access.conf.

User root should be allowed to get access via cron, X11 terminal :0, tty1, …, tty5, tty6.

+:root:crond :0 tty1 tty2 tty3 tty4 tty5 tty6

User root should be allowed to get access from hosts which own the IPv4 addresses. This does not mean that the connection have to be a IPv4 one, a IPv6 connection from a host with one of this IPv4 addresses does work, too.

+:root:192.168.200.1 192.168.200.4 192.168.200.9

+:root:127.0.0.1

User root should get access from network 192.168.201. where the term will be evaluated by string matching. But it might be better to use network/netmask instead. The same meaning of 192.168.201. is 192.168.201.0/24 or 192.168.201.0/255.255.255.0.

+:root:192.168.201.

User root should be able to have access from hosts foo1.bar.org and foo2.bar.org (uses string matching also).

+:root:foo1.bar.org foo2.bar.org

User root should be able to have access from domain foo.bar.org (uses string matching also).

+:root:.foo.bar.org

User root should be denied to get access from all other sources.

-:root:ALL

User foo and members of netgroup admins should be allowed to get access from all sources. This will only work if netgroup service is available.

+:@admins foo:ALL

User john and foo should get access from IPv6 host address.

+:john foo:2001:db8:0:101::1

User john should get access from IPv6 net/mask.

+:john:2001:db8:0:101::/64

Members of group wheel should be allowed to get access from all sources.

+:(wheel):ALL

Disallow console logins to all but the shutdown, sync and all other accounts, which are a member of the wheel group.

-:ALL EXCEPT (wheel) shutdown sync:LOCAL

All other users should be denied to get access from all sources.

-:ALL:ALL

NOTES

The default separators of list items in a field are space, ,, and tabulator characters. Thus conveniently if spaces are put at the beginning and the end of the fields they are ignored. However if the list separator is changed with the listsep option, the spaces will become part of the actual item and the line will be most probably ignored. For this reason, it is not recommended to put spaces around the : characters.

AUTHORS

Original login.access(5) manual was provided by Guido van Rooij which was renamed to access.conf(5) to reflect relation to default config file.

Network address / netmask description and example text was introduced by Mike Becher <[email protected]>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

366 - Linux cli command proc_config.gz

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_config.gz and provides detailed information about the command proc_config.gz, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_config.gz.

NAME 🖥️ proc_config.gz 🖥️

kernel build configuration

DESCRIPTION

/proc/config.gz (since Linux 2.6)
This file exposes the configuration options that were used to build the currently running kernel, in the same format as they would be shown in the .config file that resulted when configuring the kernel (using make xconfig, make config, or similar). The file contents are compressed; view or search them using zcat(1) and zgrep(1). As long as no changes have been made to the following file, the contents of /proc/config.gz are the same as those provided by:

cat /lib/modules/$(uname -r)/build/.config

/proc/config.gz is provided only if the kernel is configured with CONFIG_IKCONFIG_PROC.

367 - Linux cli command term

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command term and provides detailed information about the command term, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the term.

NAME 🖥️ term 🖥️

compiled terminfo terminal description

SYNOPSIS

term

DESCRIPTION

Storage Location

Compiled terminfo descriptions are placed under the directory /etc/terminfo. Two configurations are supported (when building the ncurses libraries):

directory tree
A two-level scheme is used to avoid a linear search of a huge Unix system directory: /etc/terminfo/c/name where name is the name of the terminal, and c is the first character of name. Thus, act4 can be found in the file /etc/terminfo/a/act4. Synonyms for the same terminal are implemented by multiple links to the same compiled file.

hashed database
Using Berkeley database, two types of records are stored: the terminfo data in the same format as stored in a directory tree with the terminfo’s primary name as a key, and records containing only aliases pointing to the primary name.

If built to write hashed databases, ncurses can still read terminfo databases organized as a directory tree, but cannot write entries into the directory tree. It can write (or rewrite) entries in the hashed database.

ncurses distinguishes the two cases in the TERMINFO and TERMINFO_DIRS environment variable by assuming a directory tree for entries that correspond to an existing directory, and hashed database otherwise.

Legacy Storage Format

The format has been chosen so that it will be the same on all hardware. An 8 or more bit byte is assumed, but no assumptions about byte ordering or sign extension are made.

The compiled file is created with the tic program, and read by the routine setupterm(3NCURSES). The file is divided into six parts:

a) header,
b) terminal names,
c) Boolean flags,
d) numbers,
e) strings, and
f) string table.
The header section begins the file. This section contains six short integers in the format described below. These integers are
(1) the magic number (octal 0432);
(2) the size, in bytes, of the terminal names section;
(3) the number of bytes in the Boolean flags section;
(4) the number of short integers in the numbers section;
(5) the number of offsets (short integers) in the strings section;
(6) the size, in bytes, of the string table.
The capabilities in the Boolean flags, numbers, and strings sections are in the same order as the file <term.h>.
Short integers are signed, in the range -32768 to 32767. They are stored as two 8-bit bytes. The first byte contains the least significant 8 bits of the value, and the second byte contains the most significant 8 bits. (Thus, the value represented is 256*second+first.) This format corresponds to the hardware of the VAX and PDP-11 (that is, little-endian machines). Machines where this does not correspond to the hardware must read the integers as two bytes and compute the little-endian value.
Numbers in a terminal description, whether they are entries in the numbers or strings table, are positive integers. Boolean flags are treated as positive one-byte integers. In each case, those positive integers represent a terminal capability. The terminal compiler tic uses negative integers to handle the cases where a capability is not available:
If a capability is absent from this terminal, tic stores a -1 in the corresponding table.
The integer value -1 is represented by two bytes 0377, 0377.
Absent Boolean values are represented by the byte 0 (false).
If a capability has been canceled from this terminal, tic stores a -2 in the corresponding table.
The integer value -2 is represented by two bytes 0377, 0376.
The Boolean value -2 is represented by the byte 0376.
Other negative values are illegal.
The terminal names section comes after the header. It contains the first line of the terminfo description, listing the various names for the terminal, separated by the | character. The terminal names section is terminated with an ASCII NUL character.
The Boolean flags section has one byte for each flag. Boolean capabilities are either 1 or 0 (true or false) according to whether the terminal supports the given capability or not.
Between the Boolean flags section and the number section, a null byte will be inserted, if necessary, to ensure that the number section begins on an even byte This is a relic of the PDP-11’s word-addressed architecture, originally designed to avoid traps induced by addressing a word on an odd byte boundary. All short integers are aligned on a short word boundary.
The numbers section is similar to the Boolean flags section. Each capability takes up two bytes, and is stored as a little-endian short integer.
The strings section is also similar. Each capability is stored as a short integer. The capability value is an index into the string table.
The string table is the last section. It contains all of the values of string capabilities referenced in the strings section. Each string is null-terminated. Special characters in X or

368 - Linux cli command ethers

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ethers and provides detailed information about the command ethers, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ethers.

NAME 🖥️ ethers 🖥️

Ethernet address to IP number database

DESCRIPTION

/etc/ethers contains 48 bit Ethernet addresses and their corresponding IP numbers, one line for each IP number:

Ethernet-address IP-number

The two items are separated by any number of SPACE and/or TAB characters. A # at the beginning of a line starts a comment which extends to the end of the line. The Ethernet-address is written as x:x:x:x:x:x, where x is a hexadecimal number between 0 and ff which represents one byte of the address, which is in network byte order (big-endian). The IP-number may be a hostname which can be resolved by DNS or a dot separated number.

EXAMPLES

08:00:20:00:61:CA pal

FILES

/etc/ethers

369 - Linux cli command proc_crypto

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_crypto and provides detailed information about the command proc_crypto, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_crypto.

NAME 🖥️ proc_crypto 🖥️

ciphers provided by kernel crypto API

DESCRIPTION

/proc/crypto
A list of the ciphers provided by the kernel crypto API. For details, see the kernel Linux Kernel Crypto API documentation available under the kernel source directory Documentation/crypto/ (or Documentation/DocBook before Linux 4.10; the documentation can be built using a command such as make htmldocs in the root directory of the kernel source tree).

370 - Linux cli command org.bluez.MediaTransport

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.MediaTransport and provides detailed information about the command org.bluez.MediaTransport, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.MediaTransport.

NAME 🖥️ org.bluez.MediaTransport 🖥️

BlueZ D-Bus MediaTransport API documentation

INTERFACE

Service
org.bluez
Interface
org.bluez.MediaTransport1
Object path
[variable prefix]/{hci0,hci1,…}/dev_XX_XX_XX_XX_XX_XX/fdX

Methods

fd, uint16, uint16 Acquire()

Acquire transport file descriptor and the MTU for read and write respectively.
Possible Errors:
org.bluez.Error.NotAuthorized
org.bluez.Error.Failed

fd, uint16, uint16 TryAcquire()

Acquire transport file descriptor only if the transport is in “pending” state at the time the message is received by BlueZ. Otherwise no request will be sent to the remote device and the function will just fail with org.bluez.Error.NotAvailable.
Possible Errors:
org.bluez.Error.NotAuthorized
org.bluez.Error.Failed
org.bluez.Error.NotAvailable

void Release()

Releases file descriptor.

Properties

object Device [readonly]

Device object which the transport is connected to.

string UUID [readonly]

UUID of the profile which the transport is for.

byte Codec [readonly]

Assigned number of codec that the transport support. The values should match the profile specification which is indicated by the UUID.

array{byte} Configuration [readonly]

Configuration blob, it is used as it is so the size and byte order must match.

string State [readonly]

Indicates the state of the transport. Possible values are:
“idle”
not streaming
“pending”
streaming but not acquired
“active”
streaming and acquired

uint16 Delay [readwrite, optional]

Transport delay in 1/10 of millisecond, this property is only writeable when the transport was acquired by the sender.

uint16 Volume [readwrite, optional]

Indicates volume level of the transport, this property is only writeable when the transport was acquired by the sender.
Possible Values: 0-127

object Endpoint [readonly, optional, experimental]

Endpoint object which the transport is associated with.

uint32 Location [readonly, ISO only, experimental]

Indicates transport Audio Location.

array{byte} Metadata [readwrite, ISO Only, experimental]

Indicates transport Metadata.

array{object} Links [readonly, optional, ISO only, experimental]

Linked transport objects which the transport is associated with.

dict QoS [readonly, optional, ISO only, experimental]

Only present when QoS is configured.
Possible values for Unicast:
byte CIG
Indicates configured CIG.
Possible values:
0x00 - 0xef
Valid ID range.
0xff
Auto allocate.
byte CIS
Indicates configured CIS.
Possible values:
0x00 - 0xef
Valid ID range.
0xff
Auto allocate.
byte Framing
Indicates configured framing.
Possible values:
0x00
Unframed.
0x01
Framed.
uint32 PresentationDelay
Indicates configured transport presentation delay (us).
byte TargetLatency
Indicates the requested target latency.
Possible values:
0x01
Low Latency.
0x02
Balanced Latency/Reliability.
0x03
High Reliability.
Possible values for Broadcast:
byte BIG
Indicates configured QoS BIG.
byte BIS
Indicates configured BIS.
byte SyncFactor
Indicates configured broadcast sync factor.
byte Packing
Indicates configured packing.
byte Framing
Indicates configured framing.
byte Options
Indicates configured broadcast options.
uint16 Skip
Indicates configured broadcast skip.
byte SyncTimeout
Indicates configured broadcast sync timeout.
byte SyncType
Indicates configured broadcast sync CTE type.
byte MSE
Indicates configured broadcast MSE.
uint16 Timeout
Indicates configured broadcast timeout.
Possible values for both Unicast and Broadcast:
uint32 Interval
Indicates configured ISO interval (us).
uint16 Latency
Indicates configured transport latency (ms).
uint16 SDU
Indicates configured maximum SDU.
byte PHY
Indicates configured PHY.
Possible values:
bit 0
LE 1M
bit 1
LE 2M
bit 2
LE Coded
byte Retransmissions
Indicates configured retransmissions.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

371 - Linux cli command org.bluez.obex.MessageAccess

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command org.bluez.obex.MessageAccess and provides detailed information about the command org.bluez.obex.MessageAccess, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the org.bluez.obex.MessageAccess.

NAME 🖥️ org.bluez.obex.MessageAccess 🖥️

BlueZ D-Bus OBEX MessageAccess API documentation

INTERFACE

Service
org.bluez.obex
Interface
org.bluez.obex.MessageAccess1
Object path
[Session object path]

Methods

void SetFolder(string name)

Set working directory for current session.
Possible name:
Directory name or ‘..[/dir]’.
Possible errors:
org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Error.Failed

array{dict} ListFolders(dict filter)

Returns a dictionary containing information about the current folder content.
Possible filter:
uint16 Offset (default 0)
Offset of the first item.
uint16 MaxCount (default 1024)
Maximum number of items.
Possible return:
string Name
Folder name
Possible errors:
org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Error.Failed

array{string} ListFilterFields()

Return all available fields that can be used in Fields filter.
Possible values:
“subject”
“timestamp”
“sender”
“sender-address”
“recipient”
“recipient-address”
“type”
“size”
“status”
“text”
“attachment”
“priority”
“read”
“sent”
“protected”
“replyto”
Possible errors: None

array{object, dict} ListMessages(string folder, dict filter)

Returns an array containing the messages objects found in the given subfolder of the current folder, or in the current folder if folder is empty.
Possible Filters:
uint16 Offset (default 0)
Offset of the first item.
uint16 MaxCount (default 1024):
Maximum number of items.
byte SubjectLength (default 256)
Maximum length of the Subject property in the message.
array{string} Fields
Message fields, default is all values.
See ListFilterFields() for possible values.
array{string} Types
Filter messages by type.
Possible values:
“sms”
“email”
“mms”
string PeriodBegin
Filter messages by starting period.
Possible values:
Date in “YYYYMMDDTHHMMSS” format.
string PeriodEnd
Filter messages by ending period.
Possible values:
Date in “YYYYMMDDTHHMMSS” format.
boolean Read
Filter messages by read flag.
Possible values:
True for read or False for unread
string Recipient
Filter messages by recipient address.
string Sender
Filter messages by sender address.
boolean Priority
Filter messages by priority flag.
Possible values:
True for high priority or False for non-high priority.
Each message is represented by an object path, which implements org.bluez.obex.Message(5) interface, followed by a dictionary of its properties.
void UpdateInbox(void)
Requests remote to update its inbox.
Possible errors:
org.bluez.obex.Error.Failed

object, dict PushMessage(string sourcefile, string folder, dict args)

Transfers a message (in bMessage format) to the remote device.
The message is transferred either to the given subfolder of the current folder, or to the current folder if folder is empty.
Possible args: Transparent, Retry, Charset
The returned path represents the newly created transfer, which should be used to find out if the content has been successfully transferred or if the operation fails.
The properties of this transfer are also returned along with the object path, to avoid a call to GetProperties, see org.bluez.obex.Transfer(5) for the possible list of properties.
Possible errors:
org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Error.Failed

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

372 - Linux cli command proc_kpagecgroup

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_kpagecgroup and provides detailed information about the command proc_kpagecgroup, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_kpagecgroup.

NAME 🖥️ proc_kpagecgroup 🖥️

memory cgroups

DESCRIPTION

/proc/kpagecgroup (since Linux 4.3)
This file contains a 64-bit inode number of the memory cgroup each page is charged to, indexed by page frame number (see the discussion of /proc/pid/pagemap).

The /proc/kpagecgroup file is present only if the CONFIG_MEMCG kernel configuration option is enabled.

373 - Linux cli command freetds.conf

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command freetds.conf and provides detailed information about the command freetds.conf, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the freetds.conf.

The

file describes Sybase and Microsoft database servers to the FreeTDS library. It comprises sections headed by a servername, followed by a list of connection properties denoted as name-value pairs. Defaults are defined via a

section. This file supersedes the

file that Sybase defines for the same purpose, although the latter is still supported.

A section begins with a servername — the name of the server — in square brackets. The servername is chosen at the client’s descretion. (One exception: with Sybase ASA the servername must match the database name to be used.)

Sections contain properties, one per line, in the form

where

is the connection property to be described. Servernames and properties are not case sensitive. Values are case-preserving i.e., copied literally. Comments begin with either a semicolon

or pound sign

and continue to end of line. Blank lines are ignored. Whitespace surrounding the

encoding of client data; overrides locale(1) settings

iconv character set names

ISO-8859-1

seconds to wait for response from connect request

0 to MAX_INT

none

logging granularity

32-bit integer

0x4fff

specifies location of a logfile and turns on logging

valid file name

none

log data appended to file instead of re-writing for each connection

yes/no

forces big endian machines to act as little endian to communicate with Microsoft Servers

yes/no

disables encryption

use if available (default when tds version greater than 7.0)

allow encrypted connections only

Name of the host the server is running on.

host name or IP address

SYBASE

maximum size of a protocol block

multiple of 512

512

name of Microsoft SQL Server instance to connect to (supersedes

instance name

none

port number that the server is listening to

any valid port

TDS 5.0, 5000; TDS 7.0 and up, 1433

TDS protocol version to use

4.2, 5.0, 7.0, 7.1, 7.2

value (5.0 if unspecified)

default value of TEXTSIZE, in bytes

0 to 4,294,967,295

4,294,967,295

seconds to wait for response to a query

0 to MAX_INT

none (wait forever)

Do not define both

and

. One implies the other.

Boolean property values may be denoted as on/off, true/false, or 1/0.

The log’s granularity can be controlled with the

property.

The file is normally named

That name can be overridden with the FREETDSCONF environment variable.

FreeTDS will search conf files for a servername in the following order:

a filename set programatically via dbsetifile() that is in .conf format

a filename in the environment variable FREETDSCONF that is in .conf format

if extant

The search stops with the first file containing the servername.

If no conf file is found, FreeTDS searches for an

file in the following order:

a filename set programatically via dbsetifile() that is in

format

(where

If the requested servername is not found in any configuration file, the fallback mechanism is:

attempt to convert the name to an IP address with inet_addr(3), else

attempt to convert the name to an IP address with gethostbyname(3), else

attempt to look up the literal name

overrides name and location of the system-wide conf file

overrides the name and location of the FreeTDS log file

specifies a name and location of a file that logs the search of configuration files

overrides the host property

overrides the port property

synonym for DSQUERY, the default servername

overrides the version specified in the freetds.conf

The environment variables

override values set by a .conf or

file.

.conf files first appeared with version 0.53 of FreeTDS.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

374 - Linux cli command scr_dump

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command scr_dump and provides detailed information about the command scr_dump, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the scr_dump.

NAME 🖥️ scr_dump 🖥️

curses screen dump

DESCRIPTION

The curses library provides applications with the ability to write the contents of a window to an external file using scr_dump or putwin, and read it back using scr_restore or getwin.

The putwin and getwin functions do the work; while scr_dump and scr_restore conveniently save and restore the whole screen, i.e., stdscr.

ncurses6

A longstanding implementation of screen-dump was revised with ncurses6 to remedy problems with the earlier approach:

A magic number is written to the beginning of the dump file, allowing applications (such as file(1)) to recognize curses dump files.
Because ncurses6 uses a new format, that requires a new magic number was unused by other applications. This 16-bit number was unused:
0x8888 (octal \210\210)
but to be more certain, this 32-bit number was chosen:
0x88888888 (octal \210\210\210\210)
This is the pattern submitted to the maintainers of the file program:
```
# ncurses5 (and before) did not use a magic number,
# making screen dumps "data".
#
# ncurses6 (2015) uses this format, ignoring byte-order
0    string    \210\210\210\210ncurses    ncurses6 screen image
#
```
The screen dumps are written in textual form, so that internal data sizes are not directly related to the dump-format, and enabling the library to read dumps from either narrow- or wide-character- configurations.
The narrow library configuration holds characters and video attributes in a 32-bit chtype, while the wide-character library stores this information in the cchar_t structure, which is much larger than 32-bits.
It is possible to read a screen dump into a terminal with a different screen-size, because the library truncates or fills the screen as necessary.
The ncurses6 getwin reads the legacy screen dumps from ncurses5.

ncurses5 (Legacy)

The screen-dump feature was added to ncurses in June 1995. While there were fixes and improvements in succeeding years, the basic scheme was unchanged:

The WINDOW structure was written in binary form.
The WINDOW structure refers to lines of data, which were written as an array of binary data following the WINDOW.
When getwin restored the window, it would keep track of offsets into the array of line-data and adjust the WINDOW structure which was read back into memory.

This is similar to Unix System V, but does not write a magic number to identify the file format.

PORTABILITY

There is no standard format for curses screen dumps. A brief survey of the existing implementations follows.

X/Open Curses

X/Open Curses, Issue 7 specifies little. It says (boldface emphasis added)

[t]he getwin() function reads window-related data stored in the file by putwin(). The function then creates and initializes a new window using that data.
The putwin() function writes all data associated with win into the stdio stream to which filep points, using an unspecified format. This information can be retrieved later using getwin().

In the mid-1990s when the X/Open Curses document was written, there were still System V systems using older, less capable curses libraries. BSD curses was not relevant to X/Open because it did not meet the criteria for base-level conformance; see ncurses(3NCURSES).

System V

System V curses identified the file format by writing a magic number at the beginning of the dump. The WINDOW data and the lines of text follow, all in binary form.

Solaris curses has the following definitions.

/* terminfo magic number */ #define MAGNUM 0432

/* curses screen dump magic number */
#define SVR2_DUMP_MAGIC_NUMBER  0433
#define SVR3_DUMP_MAGIC_NUMBER  0434

That is, the feature was likely introduced in SVr2 (1984), and improved in SVr3 (1987). Solaris curses has no magic number for SVr4 (1989). Other System V operating systems (AIX and HP-UX) use a magic number that would correspond to the following.

/* curses screen dump magic number */ #define SVR4_DUMP_MAGIC_NUMBER 0435

That octal number in bytes is 001, 035. Because most Unix vendors at the time used big-endian hardware, the magic number is written with the high-order byte first.

After the magic number, the WINDOW structure and line data are written in binary format. While the magic number used by these systems can be observed with od(1), none of them documents the format used for screen dumps.

Nor do they use an identical format, even with the System V family. The ncurses savescreen test program was used to collect information for this manual page. It produced dumps of different size (all on 64-bit hardware, on 40x80 screens):

AIX (51817 bytes)
HP-UX (90093 bytes)
Solaris 10 (13273 bytes)
ncurses5 (12888 bytes)

Solaris

As noted above, Solaris curses has no magic number corresponding to SVr4 curses. This is odd, since Solaris was the first operating system to meet the SVr4 guidelines. Solaris furthermore supplies two versions of curses.

The default curses library uses the SVr3 magic number.
An alternate curses library (which we term xcurses), available in /usr/xpg4, uses a textual format with no magic number.
According to its copyright notice, this xcurses library was developed by MKS (Mortice Kern Systems) from 1990 to 1995.
Like ncurses6, it includes a header with parameters. Unlike ncurses6, the contents of the window are written piecemeal, with coordinates and attributes for each chunk of text rather than writing the whole window from top to bottom.

PDCurses

PDCurses added support for screen dumps in version 2.7 (2005). Like System V and ncurses5, it writes the WINDOW structure in binary, but begins the file with its three-byte identifier PDC, followed by a single-byte version number.

PDC

NetBSD

As of April 2017, NetBSD curses does not support scr_dump and scr_restore (or scr_init, scr_set), although it has putwin and getwin.

Like ncurses5, NetBSD putwin does not identify its dumps with a useful magic number. It writes

the curses shared library major and minor versions as the first two bytes (for example, 7 and 1),
followed by a binary dump of the WINDOW,
some data for wide characters referenced by the WINDOW structure, and
finally, lines as done by other implementations.

EXAMPLES

Given a simple program which writes text to the screen (and for the sake of example, limiting the screen-size to 10x20):

#include <curses.h>

int
main(void)
{
    putenv("LINES=10");
    putenv("COLUMNS=20");
    initscr();
    start_color();
    init_pair(1, COLOR_WHITE, COLOR_BLUE);
    init_pair(2, COLOR_RED, COLOR_BLACK);
    bkgd(COLOR_PAIR(1));
    move(4, 5);
    attron(A_BOLD);
    addstr("Hello");
    move(5, 5);
    attroff(A_BOLD);
    attrset(A_REVERSE | COLOR_PAIR(2));
    addstr("World!");
    refresh();
    scr_dump("foo.out");
    endwin();
    return 0;
}

When run using ncurses6, the output looks like this:

\210\210\210\210ncurses 6.0.20170415 _cury=5 _curx=11 _maxy=9 _maxx=19 _flags=14 _attrs={REVERSE|C2} flag=_idcok _delay=-1 _regbottom=9 _bkgrnd={NORMAL|C1}\s rows: 1:{NORMAL|C1}\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s 2:\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s 3:\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s 4:\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s 5:\s\s\s\s\s{BOLD}Hello{NORMAL}\s\s\s\s\s\s\s\s\s\s 6:\s\s\s\s\s{REVERSE|C2}World!{NORMAL|C1}\s\s\s\s\s\s\s\s\s 7:\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s 8:\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s 9:\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s 10:\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s

The first four octal escapes are actually nonprinting characters, while the remainder of the file is printable text. You may notice:

The actual color pair values are not written to the file.
All characters are shown in printable form; spaces are \s to ensure they are not overlooked.
Attributes are written in escaped curly braces, e.g., \BOLD}, and may include a color pair (C1 or C2 in this example).
The parameters in the header are written out only if they are nonzero. When reading back, order does not matter.

Running the same program with Solaris xpg4 curses gives this dump:

MAX=10,20 BEG=0,0 SCROLL=0,10 VMIN=1 VTIME=0 FLAGS=0x1000 FG=0,0 BG=0,0, 0,0,0,1, 0,19,0,0, 1,0,0,1, 1,19,0,0, 2,0,0,1, 2,19,0,0, 3,0,0,1, 3,19,0,0, 4,0,0,1, 4,5,0x20,0,Hello 4,10,0,1, 4,19,0,0, 5,0,0,1, 5,5,0x4,2,World! 5,11,0,1, 5,19,0,0, 6,0,0,1, 6,19,0,0, 7,0,0,1, 7,19,0,0, 8,0,0,1, 8,19,0,0, 9,0,0,1, 9,19,0,0, CUR=11,5

Solaris getwin requires that all parameters are present, and in the same order. The xpg4 curses library does not know about the bce (back color erase) capability, and does not color the window background.

On the other hand, the SVr4 curses library does know about the background color. However, its screen dumps are in binary. Here is the corresponding dump (using od -t x1):

0000000 1c 01 c3 d6 f3 58 05 00 0b 00 0a 00 14 00 00 00 0000020 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 0000040 00 00 b8 1a 06 08 cc 1a 06 08 00 00 09 00 10 00 0000060 00 00 00 80 00 00 20 00 00 00 ff ff ff ff 00 00 0000100 ff ff ff ff 00 00 00 00 20 80 00 00 20 80 00 00 0000120 20 80 00 00 20 80 00 00 20 80 00 00 20 80 00 00 * 0000620 20 80 00 00 20 80 00 00 20 80 00 00 48 80 00 04 0000640 65 80 00 04 6c 80 00 04 6c 80 00 04 6f 80 00 04 0000660 20 80 00 00 20 80 00 00 20 80 00 00 20 80 00 00 * 0000740 20 80 00 00 20 80 00 00 20 80 00 00 57 00 81 00 0000760 6f 00 81 00 72 00 81 00 6c 00 81 00 64 00 81 00 0001000 21 00 81 00 20 80 00 00 20 80 00 00 20 80 00 00 0001020 20 80 00 00 20 80 00 00 20 80 00 00 20 80 00 00 * 0001540 20 80 00 00 20 80 00 00 00 00 f6 d1 01 00 f6 d1 0001560 08 00 00 00 40 00 00 00 00 00 00 00 00 00 00 07 0001600 00 04 00 01 00 01 00 00 00 01 00 00 00 00 00 00 0001620 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0002371

AUTHORS

Thomas E. Dickey
extended screen-dump format for ncurses 6.0 (2015)

Eric S. Raymond
screen dump feature in ncurses 1.9.2d (1995)

375 - Linux cli command proc_pid_projid_map

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proc_pid_projid_map and provides detailed information about the command proc_pid_projid_map, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proc_pid_projid_map.

NAME 🖥️ proc_pid_projid_map 🖥️

project ID mappings

DESCRIPTION

/proc/pid/projid_map (since Linux 3.7)
See user_namespaces(7).

376 - Linux cli command systemd.slice

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.slice and provides detailed information about the command systemd.slice, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.slice.

NAME 🖥️ systemd.slice 🖥️

Slice unit configuration

SYNOPSIS

slice.slice

DESCRIPTION

A unit configuration file whose name ends in “.slice” encodes information about a slice unit. A slice unit is a concept for hierarchically managing resources of a group of processes. This management is performed by creating a node in the Linux Control Group (cgroup) tree. Units that manage processes (primarily scope and service units) may be assigned to a specific slice. For each slice, certain resource limits may be set that apply to all processes of all units contained in that slice. Slices are organized hierarchically in a tree. The name of the slice encodes the location in the tree. The name consists of a dash-separated series of names, which describes the path to the slice from the root slice. The root slice is named -.slice. Example: foo-bar.slice is a slice that is located within foo.slice, which in turn is located in the root slice -.slice.

Note that slice units cannot be templated, nor is possible to add multiple names to a slice unit by creating additional symlinks to its unit file.

By default, service and scope units are placed in system.slice, virtual machines and containers registered with systemd-machined(8) are found in machine.slice, and user sessions handled by systemd-logind(8) in user.slice. See systemd.special(7) for more information.

See systemd.unit(5) for the common options of all unit configuration files. The common configuration items are configured in the generic [Unit] and [Install] sections. The slice specific configuration options are configured in the [Slice] section. Currently, only generic resource control settings as described in systemd.resource-control(5) are allowed.

See the New Control Group Interfaces[1] for an introduction on how to make use of slice units from programs.

AUTOMATIC DEPENDENCIES

Implicit Dependencies

The following dependencies are implicitly added:

·
Slice units automatically gain dependencies of type After= and Requires= on their immediate parent slice unit.

Default Dependencies

The following dependencies are added unless DefaultDependencies=no is set:

·
Slice units will automatically have dependencies of type Conflicts= and Before= on shutdown.target. These ensure that slice units are removed prior to system shutdown. Only slice units involved with late system shutdown should disable DefaultDependencies= option.

OPTIONS

Slice unit files may include [Unit] and [Install] sections, which are described in systemd.unit(5).

Slice files may include a [Slice] section. Options that may be used in this section are shared with other unit types. These options are documented in systemd.resource-control(5).

NOTES

New Control Group Interfaces

https://systemd.io/CONTROL_GROUP_INTERFACE

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

377 - Linux cli command resolver

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command resolver and provides detailed information about the command resolver, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the resolver.

NAME 🖥️ resolver 🖥️

resolver configuration file

SYNOPSIS

/etc/resolv.conf