# CommandSection

title: DESCRIPTION
content:
Xfburn is a straightforward and lightweight CD/DVD burning application developed specifically for the <b>Xfce desktop environment</b>. It offers a user-friendly graphical interface that simplifies the process of creating various types of optical discs.<br><br>Users can easily burn <i>data CDs and DVDs</i>, which include files and folders, suitable for backup or distribution. It also supports creating <i>audio CDs</i> from various popular audio formats, allowing users to compile their favorite tracks onto a disc. Beyond creation, Xfburn provides functionalities like <i>erasing rewritable discs</i> (CD-RW, DVD-RW) and <i>duplicating existing discs</i>. Its design philosophy emphasizes simplicity and efficiency, making it an excellent choice for users seeking a reliable and uncomplicated burning solution that integrates seamlessly into the Xfce ecosystem.


title: CAVEATS
content:
Xfburn requires a functioning CD/DVD writer drive.<br>It primarily supports CD and DVD media; <b>Blu-ray support is generally not available</b>.<br>It relies on underlying burning tools (e.g., <i>libburn</i>, <i>cdrtools</i>, <i>dvd+rw-tools</i>); any issues often stem from these backends or device permissions.<br>Users might need appropriate permissions (e.g., membership in the 'cdrom' or 'optical' group) to access and write to optical drives.


title: GRAPHICAL USER INTERFACE (GUI)
content:
Xfburn is primarily a <b>graphical application</b>, making disc burning accessible through an intuitive windowed interface rather than complex command-line arguments. While it supports command-line options to start specific project types, its main interaction is via the GUI.


title: BACKEND TECHNOLOGIES
content:
Xfburn acts as a front-end for powerful underlying burning libraries and utilities. It typically utilizes <i>libburn</i> for its core operations, which in turn might interact with tools like <i>cdrtools</i> (e.g., <b>wodim</b>) or <i>dvd+rw-tools</i> (e.g., <b>growisofs</b>) for low-level disc access and writing.


title: SUPPORTED PROJECT TYPES
content:
Xfburn allows users to create various types of optical disc projects, including: <b>Data Disc</b>: For storing files and folders.<br><b>Audio CD</b>: For creating standard audio CDs from music files.<br><b>Copy Disc</b>: For duplicating existing CDs or DVDs.<br><b>Erase Disc</b>: For erasing rewritable media (CD-RW, DVD-RW).<br><b>Burn Image</b>: For writing disc image files (like ISOs) to a disc.


title: HISTORY
content:
Xfburn was developed as an integral part of the <b>Xfce desktop environment</b> to provide a native, simple, and lightweight burning solution. Its design aligns with Xfce's philosophy of efficiency and ease of use. Early versions often leveraged established backends like <i>cdrtools</i> and <i>dvd+rw-tools</i>. In more recent developments, it has increasingly adopted <i>libburn</i> for its core burning capabilities, ensuring modern and robust disc manipulation while maintaining its characteristic simplicity and seamless integration within the Xfce ecosystem.


title: PARAMETERS
content:
<b>-c <i>CONFIG_FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative configuration file path instead of the default.<br><br><b>-m <i>MONITOR_FIFO</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a FIFO (named pipe) where executed commands will be written, allowing for monitoring.<br><br><b>-s <i>SIGNATURE_FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file where <b>sxhkd</b> will write its process ID (PID), useful for scripting.<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Test the specified configuration file for syntax errors and then exit. No commands are executed.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the version information of <b>sxhkd</b> and then exit.<br><br>


title: DESCRIPTION
content:
<b>sxhkd</b> (<i>Simple X Hotkey Daemon</i>) is a highly configurable and lightweight X hotkey daemon. Its primary function is to listen for keyboard and mouse events and execute commands defined in its configuration file. Designed for simplicity and efficiency, it integrates seamlessly with any X window manager, though it's particularly popular among users of tiling window managers like bspwm.<br><br>The configuration syntax is straightforward, allowing users to define single hotkeys or complex <i>chorded keybindings</i> (e.g., <i>super + return ; super + alt + g</i>). Upon startup, <b>sxhkd</b> reads its configuration, typically from <i>~/.config/sxhkd/sxhkdrc</i>. It can reload its configuration file on the fly without needing to be restarted, making hotkey adjustments quick and easy. This daemon provides a powerful yet minimalist way to manage application launching, window manipulation, and system actions directly from keyboard shortcuts.


title: CAVEATS
content:
Primarily designed for Xorg environments; it does not directly support Wayland. Hotkeys only work while the X server is running. Configuration file syntax must be followed precisely to avoid errors.


title: CONFIGURATION FILE (SXHKDRC)
content:
<b>sxhkd</b> reads its hotkey definitions from a plain text configuration file, typically located at <i>~/.config/sxhkd/sxhkdrc</i>. The file consists of sections defining a hotkey and the command(s) to be executed. Each hotkey definition starts with the hotkey itself, followed by the command(s) on subsequent indented lines.<br><br>Example hotkey definition:<br><b>super + Return</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>urxvt</b><br><br>It supports various modifiers like <i>super</i>, <i>alt</i>, <i>ctrl</i>, <i>shift</i>, and specific keys. <i>Chorded keybindings</i> (chained presses) are also supported, separated by a semicolon (<i>;</i>). For example: <i>super + p ; f</i> could execute a command only after <i>super+p</i> is pressed, followed by <i>f</i>.


title: AUTOMATIC CONFIGURATION RELOAD
content:
<b>sxhkd</b> can automatically reload its configuration file without needing to be restarted. This is typically achieved by defining a hotkey within <i>sxhkdrc</i> itself to send a <i>SIGUSR1</i> signal to the <b>sxhkd</b> process, which triggers the reload. This allows for quick and seamless adjustments to keybindings without interrupting your workflow.


title: HISTORY
content:
Developed by Bastian Germann, also known for the <b>bspwm</b> tiling window manager. <b>sxhkd</b> was created to provide a lightweight, flexible, and language-agnostic hotkey daemon that could complement <b>bspwm</b> but also function independently. Its design adheres to the Unix philosophy of doing one thing well, focusing solely on executing commands based on hotkey presses, and has gained significant popularity within the minimalist desktop environment community.


title: PARAMETERS
content:
<b><b>--recompile</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recompiles the <i>xmonad.hs</i> configuration file into a new executable. This is necessary for any configuration changes to take effect.<br><br><b><b>--restart</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restarts the currently running <i>xmonad</i> instance. It typically reloads the window manager using the latest compiled configuration.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version of <i>xmonad</i> and exits.<br><br><b><b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, printing additional information during operation, which can be useful for debugging.<br><br><b><b>--with-tracing</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables event tracing for debugging purposes, logging X events and other internal activities.<br><br><b><b>--replace</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs <i>xmonad</i> to replace any currently running window manager. This is commonly used when starting <i>xmonad</i> from <i>.xinitrc</i> or a display manager.<br><br>


title: DESCRIPTION
content:
<i>xmonad</i> is a dynamically tiling X11 window manager, known for its minimalism, stability, and high extensibility. Unlike traditional floating window managers (like GNOME or KDE), <i>xmonad</i> automatically arranges windows into non-overlapping layouts on the screen, maximizing screen real estate and encouraging a keyboard-driven workflow. It is uniquely written and configured in the Haskell programming language, allowing users to define their entire window management experience by modifying a single Haskell file, <i>~/.xmonad/xmonad.hs</i>. This approach provides unparalleled flexibility and power, though it comes with a steeper learning curve for those unfamiliar with Haskell. <i>xmonad</i> focuses on efficiency and reproducibility, ensuring that your desktop environment behaves predictably and reliably.


title: CAVEATS
content:
Configuring <i>xmonad</i> requires a basic understanding of the Haskell programming language. While extensive documentation and examples are available, users unfamiliar with Haskell might find the initial setup and customization challenging. All configuration changes necessitate recompiling the <i>xmonad.hs</i> file, which introduces a slight delay before changes take effect. <i>xmonad</i> inherently promotes a keyboard-centric workflow, which might be less intuitive for users accustomed to heavy mouse usage.


title: CONFIGURATION FILE (XMONAD.HS)
content:
The primary way to customize <i>xmonad</i> is by editing the <i>~/.xmonad/xmonad.hs</i> file. This file defines layouts, keybindings, hooks, and other behaviors. After making changes, the file must be recompiled and <i>xmonad</i> restarted for the changes to take effect.


title: EXTENSIBILITY WITH XMONAD-CONTRIB
content:
<i>xmonad</i> is highly extensible through the <i>xmonad-contrib</i> library, a collection of community-contributed modules. These modules provide additional layouts, status bar integration, session management, and other advanced features, allowing users to tailor <i>xmonad</i> to their exact preferences without modifying the core.


title: TILING PHILOSOPHY
content:
<i>xmonad</i> adheres to a tiling philosophy, automatically resizing and positioning windows to occupy screen space without overlap. This eliminates the need for manual window placement, focusing user attention on content rather than window management. It supports various tiling layouts, including master-stack, columns, and spiral, which can be cycled through via keybindings.


title: HISTORY
content:
<i>xmonad</i> was first released in 2007, pioneering the concept of a dynamically tiling window manager written entirely in Haskell. Its design was significantly influenced by <i>dwm</i>, but it distinguished itself through its unique configuration mechanism and strong emphasis on correctness and extensibility derived from Haskell's type system. Over the years, <i>xmonad</i> has maintained its commitment to minimalism and stability, while its companion library, <i>xmonad-contrib</i>, has grown to include a vast array of extensions and layouts, catering to a diverse user base and evolving desktop needs.


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the program's version information and exits.<br><br><b><b>--compact_mode</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches <i>bashtop</i> in a compact layout, optimized for smaller terminal windows or less information density.<br><br><b><b>--theme</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a custom theme to use. The theme file must be present in the themes directory (e.g., <i>~/.config/bashtop/themes/</i>).<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug logging for troubleshooting purposes, writing logs to a file.<br><br>


title: DESCRIPTION
content:
<i>bashtop</i> is a powerful and visually appealing resource monitor designed for Linux, macOS, and FreeBSD. Written entirely in Bash, it offers a comprehensive and interactive terminal user interface (TUI) to display various system metrics. Users can monitor CPU and memory usage, disk I/O, network activity, and a detailed list of running processes. Its key features include an easily customizable UI with multiple themes, a process list that supports filtering, sorting, and sending signals, and graphs for visual representation of resource usage. While similar to tools like <i>top</i> and <i>htop</i>, <i>bashtop</i> provides a more modern and user-friendly experience directly in the terminal, making it popular for those who prefer an aesthetically pleasing and information-rich dashboard.


title: CAVEATS
content:
<i>bashtop</i> is no longer actively maintained. Its development has transitioned to successors like <i>bpytop</i> (Python) and most notably <i>btop</i> (Rust), which offer improved performance and continued development. While still functional, users might find better performance and more up-to-date features in its newer counterparts.


title: CONFIGURATION
content:
<i>bashtop</i>'s behavior and appearance are highly configurable via a configuration file, typically located at <i>~/.config/bashtop/bashtop.conf</i>. This file allows users to set preferences such as update intervals, default sorting for processes, visible modules, and CPU temperature sensor paths.


title: KEYBINDINGS AND INTERACTIVITY
content:
The strength of <i>bashtop</i> lies in its interactive terminal interface, controlled by various keybindings. Users can navigate through different sections, sort processes, filter results, send signals to processes, and change settings on the fly. Pressing <b>'?'</b> within <i>bashtop</i> displays a comprehensive list of available keybindings for interactive control.


title: HISTORY
content:
<i>bashtop</i> was created by Aristocrats, aiming to provide a visually rich and interactive resource monitor written purely in Bash. It gained significant popularity around 2019-2020 for its unique approach and aesthetic appeal. Its success led to the development of <i>bpytop</i> (a Python rewrite) to address some performance and maintainability limitations inherent in Bash scripting. Subsequently, <i>btop</i> (a Rust rewrite) was developed, which is now the primary actively developed project in this lineage. <i>bashtop</i> effectively served as the foundational proof-of-concept for this family of modern terminal monitors.


title: SYNOPSIS
content:
crun [GLOBAL_OPTIONS] COMMAND [COMMAND_OPTIONS] [ARGUMENTS...]<br><br>Common commands:<br><B>run</B>           Create and run a container<br><B>create</B>        Create a container<br><B>start</B>         Start a created container<br><B>state</B>         Query the state of a container<br><B>kill</B>          Send a signal to a container<br><B>delete</B>        Delete a container<br><B>exec</B>          Execute a command in a running container<br><B>update</B>        Update container resources<br><B>checkpoint</B>    Checkpoint a container<br><B>restore</B>       Restore a container from checkpoint<br><B>spec</B>          Create a new bundle specification file


title: PARAMETERS
content:
<b>--root <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the root directory for <B>crun</B> state and storage.<br><br><b>--log <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the path to the log file for <B>crun</B> operations.<br><br><b>--log-format <format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Define the format for log output, e.g., <I>json</I> or <I>text</I>.<br><br><b>--systemd-cgroup</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable the <B>systemd</B> cgroup driver for container management.<br><br><b>--no-pivot</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not use <B>pivot_root</B> system call for container filesystem setup.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose debug logging for troubleshooting.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the <B>crun</B> version information and exit.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the main help message for <B>crun</B>.<br><br>


title: DESCRIPTION
content:
crun is an <I>OCI (Open Container Initiative) compliant</I> container runtime implemented in <I>C</I>. It serves as a high-performance, resource-efficient alternative to other runtimes like <B>runc</B>.<br><br>Designed with speed and a minimal memory footprint in mind, <B>crun</B> excels in environments where resource optimization is crucial, such as high-density container deployments or embedded systems. It fully adheres to the OCI Runtime Specification, enabling seamless integration with container orchestrators and managers like <B>Podman</B>, <B>Buildah</B>, and <B>CRI-O</B>.<br><br>Key features include comprehensive support for Linux namespaces and cgroups (both v1 and v2), along with robust security mechanisms such as <B>seccomp</B>, <B>AppArmor</B>, and <B>SELinux</B>. Its native C implementation contributes to faster container startup times and reduced overhead compared to runtimes written in higher-level languages. This makes <B>crun</B> a preferred choice for users prioritizing performance and efficiency in their containerized workloads.


title: CAVEATS
content:
crun requires a relatively recent Linux kernel for full functionality, especially concerning <B>cgroupv2</B> and advanced security features.<br><br>While highly optimized, direct interaction with <B>crun</B> should always be done with an understanding of container security best practices, ensuring containers are run with the principle of <I>least privilege</I>. Although largely OCI compliant, subtle differences in implementation or specific feature support might exist compared to other runtimes like <B>runc</B>, which might affect highly specialized or legacy container configurations.


title: OCI COMPLIANCE
content:
<B>crun</B> fully adheres to the <I>Open Container Initiative Runtime Specification</I>, ensuring broad compatibility and interoperability with all OCI-compliant container orchestrators and tools. This commitment guarantees that container bundles created according to the OCI spec can be reliably executed by <B>crun</B>.


title: PERFORMANCE CHARACTERISTICS
content:
A primary strength of <B>crun</B> is its exceptional performance. Benchmarks often show significantly <I>faster container startup times</I> and a <I>lower memory footprint</I> compared to other runtimes, especially when managing a large number of containers. This efficiency is largely attributed to its optimized C codebase.


title: SECURITY FEATURES INTEGRATION
content:
<B>crun</B> seamlessly integrates with core Linux security features to provide robust container isolation. It supports <B>seccomp</B> for system call filtering, <B>AppArmor</B> and <B>SELinux</B> for mandatory access control, and leverages <I>Linux namespaces</I> and <I>cgroups</I> for process and resource isolation.


title: HISTORY
content:
Developed by <B>Giuseppe Scrivano</B>, <B>crun</B> emerged as a powerful alternative to the widely used <B>runc</B> container runtime. Its development was driven by the goal of creating a faster and more resource-efficient OCI runtime, particularly beneficial for scenarios demanding high performance and low overhead, such as cloud-native applications and embedded systems.<br><br>Written entirely in <I>C</I>, <B>crun</B> leverages the language's efficiency to achieve its performance targets. It has gained significant traction within the Linux container ecosystem, being adopted by projects like <B>Podman</B> as a default or preferred runtime on various distributions (e.g., Fedora), owing to its superior startup times and reduced memory consumption.


title: PARAMETERS
content:
<b><b>-c &lt;config_file&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the <i>scalpel.conf</i> configuration file.<br><br><b><b>-o &lt;output_directory&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the output directory where carved files will be placed.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details during the carving process.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of <i>Scalpel</i> and exits.<br><br><b><b>-s &lt;bytes&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips the specified number of bytes from the beginning of the input file.<br><br><b><b>-e &lt;bytes&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops carving after processing the specified number of bytes from the input file.<br><br><b><b>-b &lt;size&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the block size in bytes for reading the input file (default is 512 bytes).<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables preview mode; lists files that would be carved but does not save them.<br><br><b><b>-t &lt;threads&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of concurrent threads to use for carving, enhancing performance.<br><br>


title: DESCRIPTION
content:
<i>Scalpel</i> is an open-source, powerful file carving utility primarily used in <b>digital forensics</b> and <b>data recovery</b>. It operates by scanning disk images or raw device files for specific file headers and footers, which are defined in a user-configurable file named <i>scalpel.conf</i>.<br><br>Originally developed as an enhanced version of <i>foremost</i>, <i>scalpel</i> introduces significant performance improvements, including <b>multithreading</b> and <b>asynchronous I/O</b>, making it much faster for large datasets. It can recover a wide variety of file types, such as images (JPG, PNG), documents (PDF, DOCX), archives (ZIP, RAR), and multimedia files, even if their file system entries have been deleted or corrupted.<br><br>The tool outputs recovered files into a specified directory, organizing them into subdirectories based on their identified file types. This systematic approach helps in managing potentially thousands of recovered files. Its effectiveness heavily relies on the accuracy and comprehensiveness of its configuration file, which dictates the signatures and characteristics of the files it should search for.


title: CAVEATS
content:
<i>Scalpel</i>'s effectiveness depends on distinct file headers and footers; heavily fragmented files may not be perfectly recovered.<br><br>Carving large disk images can consume significant processing time and generate a very large output directory, requiring substantial disk space.<br><br>Incorrect or incomplete signatures in the <i>scalpel.conf</i> file can lead to poor recovery results or missed files.


title: CONFIGURATION FILE (<I>SCALPEL.CONF</I>)
content:
The <i>scalpel.conf</i> file is <b>critical</b> for <i>Scalpel</i>'s operation. It's a plain-text file where users define the characteristics of files to be recovered, including their extensions, case sensitivity, unique header byte sequences, maximum file sizes, and optional footer byte sequences. Each line in the configuration typically represents a different file type. Without a properly configured file, <i>Scalpel</i> cannot identify and carve specific data types effectively.


title: OUTPUT STRUCTURE
content:
Upon successful carving, <i>Scalpel</i> creates a new directory (as specified by the <b>-o</b> option) with a timestamped subdirectory inside. Within this subdirectory, it generates further subdirectories for each file type found (e.g., <i>jpg</i>, <i>pdf</i>, <i>doc</i>), where the recovered files are stored. An <i>audit.txt</i> file is also created in the main output directory, providing a log of the carving process, including command-line arguments, start/end times, and a summary of recovered files.


title: HISTORY
content:
<i>Scalpel</i> was developed by Golden G. Richard III at the Naval Postgraduate School. It emerged as a successor to the earlier <i>foremost</i> utility, aiming to address its performance limitations, especially with very large disk images.<br><br>Its key innovation was the introduction of <b>multithreading</b> and <b>asynchronous I/O</b>, which dramatically improved carving speed. Since its initial release, <i>Scalpel</i> has become a widely adopted and respected tool in the digital forensics community for its efficiency and ability to recover diverse data types.


title: SYNOPSIS
content:
<b>proxychains</b> [<i>options</i>] <i><program></i> [<i>program arguments</i>]<br>Example: <b>proxychains</b> <i>firefox</i>


title: PARAMETERS
content:
<b>-f <config_file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file instead of the default (e.g., <i>/etc/proxychains.conf</i> or <i>~/.proxychains/proxychains.conf</i>).<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs in quiet mode, suppressing most output messages.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs in verbose mode, providing more detailed output for debugging and connection tracing.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with available command-line options.<br><br><b><program></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The command or application to be executed with its network traffic routed through <i>proxychains</i>.<br><br><b>[program arguments]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Any arguments that need to be passed to the <i><program></i> will be forwarded directly.<br><br>


title: DESCRIPTION
content:
<b>proxychains</b> is a UNIX program that allows any application to transparently use a SOCKS (version 4 or 5) or HTTP proxy. It intercepts standard C library calls for network connections (like <i>connect</i>, <i>sendto</i>, <i>recvfrom</i>) and redirects them through a specified proxy server or a chain of multiple proxy servers. This enables applications that don't have built-in proxy support to access the internet securely and anonymously, or to bypass network restrictions. It's particularly useful for routing traffic through anonymity networks like Tor. The program works by dynamically preloading a shared library (using <i>LD_PRELOAD</i> on Linux) that overrides the networking functions, making the proxying transparent to the application. It's commonly used to anonymize tools or access geo-restricted content.


title: CAVEATS
content:
<b>DNS Leaks</b>: If not configured properly (e.g., the <i>proxy_dns</i> option is not enabled or working), DNS requests might still leak outside the proxy chain, potentially revealing your real location.<br><b>UDP Traffic</b>: While <i>proxychains</i> primarily handles TCP connections reliably, its support for UDP traffic is limited and can lead to leaks or failed connections.<br><b>Application Compatibility</b>: Some applications with custom or low-level networking implementations might not work correctly or might bypass the proxy.<br><b>Configuration Errors</b>: Incorrect configuration of proxy servers, chain types, or other options in <i>proxychains.conf</i> can lead to connection failures or expose the user's real IP address.


title: CONFIGURATION FILE (`PROXYCHAINS.CONF`)
content:
The core functionality of <i>proxychains</i> is determined by its configuration file, typically located at <i>/etc/proxychains.conf</i> or <i>~/.proxychains/proxychains.conf</i>. This file defines the types of proxies to use (SOCKS4, SOCKS5, HTTP), the proxy server addresses and ports, and the chaining method. Users must carefully edit this file to suit their proxy requirements, including setting <i>proxy_dns</i> to prevent DNS leaks.


title: PROXY CHAINING METHODS
content:
<i>proxychains</i> supports different methods for routing traffic through multiple proxies:<br><i>strict_chain</i>: Uses proxies in the exact order listed in the configuration file.<br><i>random_chain</i>: Selects proxies randomly from the list for each new connection.<br><i>dynamic_chain</i>: Similar to strict, but skips any dead or unresponsive proxies in the chain. This is often the recommended default for flexibility and reliability.


title: SUPPORTED PROXY TYPES
content:
<i>proxychains</i> supports various proxy protocols, including SOCKS4, SOCKS5, and HTTP. SOCKS5 is generally preferred for its better support for UDP (though proxychains' UDP handling is still limited) and IPv6, offering more robust and secure proxying capabilities.


title: HISTORY
content:
The original <i>proxychains</i> project gained popularity for its ability to transparently force network connections through proxies. Over time, it faced limitations and became less actively maintained. This led to the development of <i>proxychains-ng</i> (the 'next generation' version), which is now the widely used and actively maintained successor. <i>proxychains-ng</i> brought improvements in IPv6 support, DNS proxying, and overall stability, addressing many issues present in the original implementation. Most modern Linux distributions provide the <i>proxychains-ng</i> package, often simply named <i>proxychains</i> or <i>proxychains4</i>.


title: SYNOPSIS
content:
ash [<I>options</I>] [<I>arguments</I>]<br>ash -c <I>command_string</I> [<I>command_name</I> [<I>arguments</I>...]]<br>ash -s [<I>arguments</I>...]


title: PARAMETERS
content:
<b>-c <I>command_string</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads commands from the specified <I>command_string</I> and then exits.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads commands from standard input. If this option is omitted, commands are read from the first non-option argument or from standard input if no non-option arguments are present.<br><br><b>-i</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the shell to run in interactive mode, even if input is not from a terminal.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints shell input lines to standard error as they are read. This can be useful for debugging.<br><br><b>-x</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints commands and their arguments to standard error after parameter expansion and before execution. This is commonly used for script debugging.<br><br><b>-n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads commands but does not execute them. This option is useful for checking the syntax of a script without actually running it.<br><br><b>-u</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treats unset variables as an error. If an unset variable is expanded, the shell will print an error message and exit.<br><br><b>-e</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exits immediately if a command exits with a non-zero status. This is often used in scripts to ensure that a failure in one command stops the entire script.<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables filename generation (globbing). This prevents the shell from expanding wildcard characters like `*` or `?` in filenames.<br><br><b>-m</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables job control. This allows the user to manage background and foreground processes (e.g., using `Ctrl+Z`, `bg`, `fg`).<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the shell's version information and exits.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with common options and exits.<br><br>


title: DESCRIPTION
content:
The <b>A</b>lmquist <b>Sh</b>ell, or `ash`, is a compact and fast Unix shell originally developed by Kenneth Almquist. It functions as a faithful, minimalist clone of the Bourne shell (`sh`), emphasizing a small memory footprint and high performance over the extensive features found in shells like `bash` or `zsh`. Due to its efficiency and diminutive size, `ash` is frequently used as the default system shell (`/bin/sh`) in embedded systems, routers, and minimalistic Linux distributions. It adheres closely to the POSIX standard, making it an excellent environment for executing shell scripts designed for maximum portability across various Unix-like operating systems. While it lacks many interactive conveniences of modern shells, its strength lies in the reliable and swift execution of system scripts and its suitability for resource-constrained environments. The Debian Almquist Shell (`dash`) is a widely adopted derivative of `ash`, serving as the default `/bin/sh` on Debian and Ubuntu systems.


title: CAVEATS
content:
`ash` is intentionally minimalistic and therefore lacks many advanced features common in more feature-rich shells like `bash`, such as sophisticated command-line editing, history expansion, programmable completion, and associative arrays. It is generally not recommended as a primary interactive shell for daily desktop use due to these limitations. Its primary design goal is efficiency and strict POSIX compliance for scripting and embedded environments, not extensive user convenience or rich interactive features.


title: POSIX COMPLIANCE
content:
`ash` adheres strictly to the POSIX.1-2001 and POSIX.1-2008 standards for shell commands. This strong adherence makes it an ideal environment for developing and testing portable shell scripts that are intended to run across various Unix-like systems without relying on shell-specific extensions or non-standard behaviors.


title: EMBEDDED SYSTEMS AND MINIMAL ENVIRONMENTS
content:
Due to its minimal memory footprint and fast execution speed, `ash` (and its derivatives like `dash` or the `ash` variant found in BusyBox) is a popular and critical choice for embedded systems, routers, and limited-resource environments. In such scenarios, where every byte of memory and CPU cycle counts, it provides a robust and reliable scripting engine for system initialization, configuration, and various management tasks efficiently.


title: HISTORY
content:
The <b>A</b>lmquist <b>Sh</b>ell (`ash`) was created by Kenneth Almquist in the late 1980s as a high-performance, small-footprint alternative to the existing Bourne shell. It was designed to be freely redistributable under a BSD license, distinguishing it from earlier proprietary shells. Its efficiency and small size led to its adoption as the default `/bin/sh` in FreeBSD. A significant derivative, the Debian Almquist Shell (`dash`), became the default `/bin/sh` in Debian and Ubuntu distributions around 2006, replacing `bash` for improved system boot times and faster execution of system scripts due to its reduced overhead and faster startup.


title: PARAMETERS
content:
<b><b>-a</b>, <b>--animate</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Animate the GIF if it contains multiple frames. This is the default behavior if the GIF is animated.<br><br><b><b>-d</b> <i>&lt;delay&gt;</i>, <b>--delay</b> <i>&lt;delay&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the frame delay in milliseconds (ms) for animation playback. Overrides the GIF's internal delay.<br><br><b><b>-w</b> <i>&lt;width&gt;</i>, <b>--width</b> <i>&lt;width&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the output width in characters. The image will be scaled to fit this width.<br><br><b><b>-h</b> <i>&lt;height&gt;</i>, <b>--height</b> <i>&lt;height&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the output height in characters. The image will be scaled to fit this height.<br><br><b><b>-i</b>, <b>--interlaced</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display interlaced GIFs properly, rendering them gradually as data arrives. (Typically default behavior).<br><br><b><b>-s</b> <i>&lt;speed&gt;</i>, <b>--speed</b> <i>&lt;speed&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the playback speed multiplier. For example, <i>0.5</i> for half speed, <i>2.0</i> for double speed.<br><br><b><b>-t</b>, <b>--time</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show elapsed time and current frame number during animation playback.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b><b>-X</b> <i>&lt;x-offset&gt;</i>, <b>--x-offset</b> <i>&lt;x-offset&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the X-offset (horizontal position) for the display in characters from the left edge.<br><br><b><b>-Y</b> <i>&lt;y-offset&gt;</i>, <b>--y-offset</b> <i>&lt;y-offset&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the Y-offset (vertical position) for the display in characters from the top edge.<br><br><b><b>-f</b> <i>&lt;frame&gt;</i>, <b>--frame</b> <i>&lt;frame&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start animation playback from a specific frame number (0-indexed).<br><br><b><b>-F</b>, <b>--foreground</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run <b>gifview</b> in the foreground; do not fork to the background after starting.<br><br><b><b>--loop</b> <i>&lt;count&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loop the animation <i>&lt;count&gt;</i> times. Use <i>0</i> for indefinite looping.<br><br><b><b>--scale</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Scale the image to fit the current terminal window dimensions.<br><br><b><b>--fit-width</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Scale the image to fit the current terminal width, maintaining aspect ratio.<br><br><b><b>--fit-height</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Scale the image to fit the current terminal height, maintaining aspect ratio.<br><br><b><b>--unscaled</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not scale the image; display it at its original pixel dimensions, potentially clipping.<br><br><b><b>--crop</b> <i>&lt;WxH+X+Y&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Crop the image to the specified width (W), height (H), X-offset (X), and Y-offset (Y).<br><br><b><b>--optimize</b> <i>&lt;level&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optimize the output for better rendering, potentially reducing colors or simplifying character sets. Level <i>0</i> for no optimization.<br><br><b><b>--no-optimize</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable any output optimization, displaying the image as-is.<br><br><b><b>--display</b> <i>&lt;device&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the display device to use (e.g., <i>text</i> or <i>stdout</i> for ASCII output).<br><br><b><b>--background</b> <i>&lt;color&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the background color for the displayed image. Color can be a name or hex value.<br><br><b><b>--char-set</b> <i>&lt;set&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a specific character set for rendering (e.g., <i>ascii</i> for basic characters, <i>unicode</i> for richer rendering).<br><br><b><b>--font-size</b> <i>&lt;size&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjust internal font size calculations, which can affect image scaling and aspect ratio in some terminals.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message with available options and exit.<br><br>


title: DESCRIPTION
content:
<b>gifview</b> is a lightweight command-line utility designed for displaying animated GIF images directly within a terminal emulator. Unlike traditional GUI-based image viewers, <b>gifview</b> renders GIFs using ASCII art or suitable Unicode characters, allowing users to quickly preview animations without leaving the command line. It supports various playback options, including speed control, frame-by-frame navigation, and looping. Ideal for server environments, SSH sessions, or scripting where a graphical display is unavailable or undesirable, <b>gifview</b> provides a simple yet effective way to interact with GIF files. Its ability to play animations directly in a text-based environment makes it a unique and valuable tool for developers, system administrators, and anyone working primarily within the terminal.


title: CAVEATS
content:
Performance can vary significantly based on the terminal emulator's capabilities and the complexity of the GIF. Color accuracy may be limited by terminal color support (e.g., 256 colors vs. true color). Large or high-resolution GIFs might render slowly or consume significant CPU resources. Optimal viewing often requires a terminal with good Unicode support and a monospace font. Rendering quality can be inconsistent across different terminal emulators.


title: INTERACTIVE CONTROLS
content:
When <b>gifview</b> is running in animation mode, the following keys provide interactive control:<br><b>Spacebar</b>: Pause/Resume animation.<br><b>Backspace</b>: Go back to the previous frame.<br><b>Enter</b>: Advance to the next frame.<br><b>q</b>: <b>Q</b>uit the viewer.<br><b>s</b>: Toggle `s`peed display.<br><b>t</b>: Toggle `t`ime display.<br><b>d</b>: Increase `d`elay (slow down).<br><b>D</b>: Decrease `d`elay (speed up).<br><b>h</b>: Show/hide `h`elp (in some versions).<br>These controls allow for dynamic interaction with the GIF during playback, enhancing its utility beyond simple viewing.


title: HISTORY
content:
Part of the <b>giflib</b> development project, <b>gifview</b> has emerged as a utility for command-line users needing to quickly inspect animated GIFs without relying on a graphical environment. Its existence underscores the ongoing demand for rich media capabilities within text-based interfaces, making it particularly useful for remote server administration, scripting, and minimalist computing setups.


title: PARAMETERS
content:
<b><b>-f</b>, <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force decompression even if the file has multiple links or the corresponding uncompressed file already exists. Also suppresses prompts.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all warning and error messages.<br><br><b><b>-S</b> <i>.suf</i>, <b>--suffix</b> <i>.suf</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the specified suffix <i>.suf</i> instead of the default <i>.gz</i> when searching for compressed files. For example, <i>gzcat -S .zip file</i>.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version number of the <i>gzip</i> program and exit.<br><br>


title: DESCRIPTION
content:
<i>gzcat</i> is a Linux command-line utility that decompresses files compressed with the <i>gzip</i> algorithm and writes the uncompressed data to standard output. It is essentially equivalent to running <i>gunzip -c</i> or <i>gzip -dc</i>. Its primary purpose is to allow users to view the contents of a gzipped file without needing to decompress it to disk, or to pipe the decompressed data directly to another command for further processing. <i>gzcat</i> automatically detects and handles files with common <i>gzip</i> extensions like <i>.gz</i>, <i>.taz</i>, and <i>.tgz</i>. If no file name is provided, or if the file name is specified as a single hyphen (<i>-</i>), <i>gzcat</i> reads compressed data from standard input, making it highly versatile for use in pipelines. This command is part of the <i>gzip</i> package and provides a convenient, <i>cat</i>-like interface for compressed files.


title: CAVEATS
content:
<i>gzcat</i> specifically handles files compressed with <i>gzip</i>. It will not work with other compression formats like <i>bzip2</i> (<i>.bz2</i>), <i>xz</i> (<i>.xz</i>), or <i>zip</i> (<i>.zip</i>). For those formats, you would typically use <i>bzcat</i>, <i>xzcat</i>, or <i>unzip -p</i> respectively.<br>Since <i>gzcat</i> writes to standard output, any existing file with the same name as the uncompressed output will not be overwritten unless the output is redirected and explicitly handled (e.g., <i>gzcat file.gz > file</i>).


title: PIPING OUTPUT
content:
One of the most powerful uses of <i>gzcat</i> is its ability to pipe the decompressed data directly to other commands. This avoids the need to create a temporary uncompressed file on disk. For example, to search for specific text within a gzipped log file, you could use: <br><i><b>gzcat</b> access.log.gz | <b>grep</b> 'error'</i>


title: READING FROM STANDARD INPUT
content:
<i>gzcat</i> can read compressed data from standard input if no file argument is given or if '-' is provided as the file name. This is useful when the compressed data comes from another command in a pipeline, such as receiving a gzipped file over a network connection: <br><i><b>curl</b> http://example.com/data.gz | <b>gzcat</b></i>


title: HISTORY
content:
<i>gzcat</i> is part of the <i>gzip</i> project, which was developed by Jean-loup Gailly and Mark Adler in the early 1990s as a free and more efficient replacement for the proprietary <i>compress</i> and <i>pack</i> utilities commonly found on Unix systems. From its inception, the <i>gzip</i> suite included utilities like <i>gunzip</i> (for decompression) and a symbolic link or hard link named <i>gzcat</i> (or <i>zcat</i>) to provide a convenient way to view the contents of gzipped files directly to the standard output, mimicking the behavior of the standard <i>cat</i> command for uncompressed files.


title: PARAMETERS
content:
<b><i>file1</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The first file to be compared. This can be an uncompressed file or a <i>gzip</i>-compressed file (typically ending in <b>.gz</b>).<br><br><b><i>file2</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The second file to be compared. Like <i>file1</i>, it can be uncompressed or <i>gzip</i>-compressed. If this argument is omitted, <i>gzcmp</i> will attempt to compare <i>file1</i> (assuming it ends with <b>.gz</b>) with its uncompressed counterpart (e.g., comparing <b>archive.gz</b> with <b>archive</b>).<br><br><b>[<i>cmp-or-diff-options</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Options and arguments provided here are directly passed through to the underlying <b>cmp</b> or <b>diff</b> command used for the actual content comparison. <i>gzcmp</i> itself does not define unique command-line options.<br><br>


title: DESCRIPTION
content:
<i>gzcmp</i> is a utility designed for the byte-by-byte comparison of two files, where at least one is typically compressed with <i>gzip</i>. It operates by transparently decompressing the files on the fly and piping their uncompressed content to the standard <i>cmp</i> command. This eliminates the need for manual decompression before comparison. If <i>cmp</i> is unavailable or reports an error (e.g., due to different file sizes or specific options not supported by <i>cmp</i> for the given scenario), <i>gzcmp</i> may fall back to using <i>diff -q</i> for a quicker check of differences, though its primary function aligns with <i>cmp</i>'s byte-by-byte equality verification. It is a convenient tool for verifying the integrity or identity of compressed data without intermediate steps, often distributed as part of the <i>gzip</i> package.


title: CAVEATS
content:
<b>Dependency</b>: <i>gzcmp</i> relies on the <b>cmp</b> and potentially <b>diff</b> utilities being available in the system's PATH.<br><b>Performance</b>: Comparing files with <i>gzcmp</i> might be slightly slower than comparing uncompressed files directly due to the overhead of on-the-fly decompression.<br><b>Error Clarity</b>: Error messages and exit statuses primarily originate from the underlying <b>cmp</b> or <b>diff</b> commands, which might require familiarity with those tools for full interpretation.<br><b>No Specific Options</b>: As a wrapper, <i>gzcmp</i> offers no unique options; all provided options are forwarded, which can sometimes be confusing if specific behavior is expected directly from <i>gzcmp</i>.


title: EXIT STATUS
content:
<i>gzcmp</i> typically returns the exit status of the underlying <b>cmp</b> command: <b>0</b> if the files are identical, <b>1</b> if they differ, and <b>2</b> if an error occurred (e.g., a file not found or an unreadable file).


title: UNDERLYING MECHANISM
content:
When comparing <b>.gz</b> files, <i>gzcmp</i> uses pipes (e.g., <b>gzip -cd file1.gz | cmp - file2</b> or <b>gzip -cd file1.gz | gzip -cd file2.gz | cmp - -</b>) to feed the decompressed content directly to <b>cmp</b> or <b>diff</b> without creating intermediate uncompressed files. This makes it efficient in terms of disk space usage.


title: HISTORY
content:
<i>gzcmp</i> is a long-standing utility included as part of the GNU <i>gzip</i> compression software package, which first saw release in the early 1990s. Its primary purpose has always been to provide a convenient, transparent way to compare gzipped files, eliminating the manual steps of decompression. As a wrapper script, its core functionality and interface have remained consistent, reflecting its role as a simple helper utility for the <i>gzip</i> ecosystem.


title: SYNOPSIS
content:
<b>ccrypt</b> [<i>options</i>] [<i>file</i>...]<br><b>ccrypt</b> -e [<i>file</i>...] (encrypts files)<br><b>ccrypt</b> -d [<i>file</i>...] (decrypts files)<br><b>ccrypt</b> -c (operates on standard input/output)


title: PARAMETERS
content:
<b>-e, --encrypt</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Encrypts the specified files. This is the default action if no other action is given.<br><br><b>-d, --decrypt</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decrypts the specified files. Files must have the <i>.cpt</i> extension or be specified explicitly.<br><br><b>-c, --stream</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Encrypts or decrypts standard input to standard output. No files are processed.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overwrites existing output files without prompting for confirmation.<br><br><b>-m, --mismatch</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows decryption even if the checksum embedded in the file does not match (potential data corruption or wrong key).<br><br><b>-o, --output <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output file name. This option is required when using -c or with a single input file.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses most warnings and interactive prompts, useful for scripting.<br><br><b>-s, --symlinks</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Follows symbolic links when processing files. By default, symlinks are ignored.<br><br><b>-u, --unlink</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unlinks (securely deletes) the original file after successful encryption or decryption.<br><br><b>-x, --key <key></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the encryption/decryption key on the command line. <b>Caution:</b> This method is insecure as the key may be visible in process listings.<br><br><b>-y, --key-from-file <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads the encryption/decryption key from the specified file.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br>


title: DESCRIPTION
content:
<b>ccrypt</b> is a command-line utility for encrypting and decrypting files and streams. It utilizes the Rijndael block cipher, which is the algorithm behind the Advanced Encryption Standard (AES), employing 256-bit keys and Counter (CTR) mode for robust cryptographic protection. Designed for simplicity and ease of use, it's ideal for quick encryption tasks directly from the command line or within scripts.<br><br>By default, <b>ccrypt</b> replaces the original file with its encrypted or decrypted version, automatically appending or removing the <i>.cpt</i> file extension. It also fully supports encryption and decryption from standard input and output, enabling its seamless integration into shell pipelines. Key features include secure key derivation from a passphrase, optional secure zeroing of original file data for enhanced privacy, and integrity checking using a checksum. It serves as a reliable and user-friendly tool for safeguarding sensitive data on local file systems or during data streams.


title: CAVEATS
content:
<b>Key Security:</b> A weak or easily guessable passphrase undermines the strongest encryption. Always use strong, unique passphrases.<br><br><b>Command-line Key (-x):</b> Using the <i>-x</i> option to provide the key on the command line is highly insecure as the key is exposed in system process listings (e.g., via <i>ps</i> or history files). Prefer interactive password prompts or key files.<br><br><b>Data Loss:</b> If the encryption key or passphrase is lost, the encrypted data becomes irrecoverable. Always back up your keys/passphrases securely.<br><br><b>Overwrite Behavior:</b> By default, <b>ccrypt</b> replaces the original file. Ensure you have backups or use the <i>-o</i> option if you need to preserve the original file.


title: KEY DERIVATION
content:
<b>ccrypt</b> uses a key derivation function (like PBKDF2) to convert your passphrase into a cryptographic key. This process is intentionally computationally intensive to make brute-force attacks against passphrases significantly harder, even if an attacker obtains the encrypted file.


title: SECURE DELETION
content:
The <i>-u</i> (<i>--unlink</i>) option provides a basic level of secure deletion. After successful encryption or decryption, <b>ccrypt</b> attempts to overwrite the original file's contents multiple times with random data before unlinking it from the file system. This reduces the chances of recovering the original data through forensic techniques.


title: FILE EXTENSION
content:
By convention, <b>ccrypt</b> appends the <i>.cpt</i> extension to encrypted files. When decrypting, it expects this extension and removes it automatically upon successful decryption, making it easy to identify encrypted files and revert to original filenames.


title: HISTORY
content:
<b>ccrypt</b> was developed by Peter Selinger, aiming to provide a modern, simple, and secure file encryption utility as an alternative to older, less secure tools. It leverages the Rijndael algorithm (AES) to offer strong cryptography in a user-friendly command-line interface. Its development focused on ease of integration into shell scripts and everyday usage, providing a straightforward approach to symmetric file encryption.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with all available command-line options and exits.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of <b>pcmanfm</b> and exits.<br><br><b><b>-w</b>, <b>--new-window</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens a new <b>pcmanfm</b> window, even if an instance is already running.<br><br><b><b>-d</b>, <b>--desktop</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts <b>pcmanfm</b> in desktop management mode. In this mode, it handles the desktop background, icons, and context menus. This is typically how it runs as part of an LXDE/LXQt session.<br><br><b><b>-n</b>, <b>--no-desktop</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <b>pcmanfm</b> from managing the desktop. This is useful if another application is responsible for the desktop or if you only want to use <b>pcmanfm</b> as a file browser without its desktop features.<br><br><b><b>-x</b>, <b>--exit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Closes all running <b>pcmanfm</b> instances, including any desktop manager processes.<br><br><b><b>--set-wallpaper=</b><i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the specified image <i>FILE</i> as the desktop wallpaper. Requires <b>pcmanfm</b> to be running in desktop management mode.<br><br><b><b>--set-wallpaper-mode=</b><i>MODE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines how the wallpaper is displayed. Common <i>MODE</i>s include <i>tile</i>, <i>stretch</i>, <i>center</i>, <i>fit</i>, and <i>zoom</i>.<br><br><b><i>PATH...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies one or more directories to open in the <b>pcmanfm</b> window. If no <i>PATH</i> is provided, it typically opens the user's home directory.<br><br>


title: DESCRIPTION
content:
<b>pcmanfm</b> is a highly efficient and lightweight file manager, often used as the default in desktop environments like LXDE and LXQt. It offers a comprehensive set of features for file browsing, copying, moving, deleting, and renaming files and folders. Beyond basic file operations, <b>pcmanfm</b> also functions as a desktop manager, capable of handling desktop icons, wallpapers, and providing a desktop context menu. Its design prioritizes speed and low resource consumption, making it an excellent choice for older hardware or users who prefer a minimal yet functional environment. It supports tabbed browsing, customizable views, and basic network share capabilities.


title: CAVEATS
content:
When running <b>pcmanfm</b> in desktop management mode (<b>-d</b>), it often starts as a background daemon. Be mindful of potential conflicts if another desktop environment or application attempts to manage the desktop simultaneously. Using <b>-x</b> is crucial to properly exit the desktop management process.


title: DESKTOP MANAGEMENT INTEGRATION
content:
One of <b>pcmanfm</b>'s distinguishing features is its integrated desktop management. It can render the desktop background, display icons on the desktop (for files, folders, or mounted drives), and provide a right-click context menu on the desktop itself. This dual functionality as both a file browser and a desktop manager makes it a central component of lightweight desktop environments.


title: PLUGIN AND CUSTOMIZATION SUPPORT
content:
<b>pcmanfm</b> supports a variety of plugins that extend its functionality, such as archive handling, volume management, and image viewing directly within the file manager. Users can also highly customize its appearance, toolbar, and shortcuts through its preferences dialog, adapting it to their workflow and aesthetic preferences.


title: HISTORY
content:
Created by Hong Jen Yee (PCMan) in 2005, <b>pcmanfm</b> was initially developed as a lightweight alternative to existing file managers for Linux. It quickly became a core component of the LXDE (Lightweight X11 Desktop Environment) project due to its focus on speed and minimal resource usage. While originally written in GTK+ 2, it later saw a significant rewrite to GTK+ 3. A separate Qt-based version, <b>PCManFM-Qt</b>, was developed to serve as the default file manager for the LXQt desktop environment.


title: PARAMETERS
content:
<b><I>path_to_ebook</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the specified ebook file immediately in the Calibre viewer upon launching the GUI.<br><br><b><B>--with-library=</B><I>PATH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts Calibre using the library located at the specified <I>PATH</I> instead of the default or last used library.<br><br><b><B>--shutdown-running</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends a signal to a running Calibre instance to shut down gracefully.<br><br><b><B>--editor</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches the Calibre Ebook Editor directly, bypassing the main Calibre GUI.<br><br><b><B>--viewer</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches the Calibre Ebook Viewer directly, useful for quickly opening an ebook without the full GUI.<br><br><b><B>--help</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message detailing all available command-line options and then exits.<br><br><b><B>--version</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the program's version number and exits.<br><br>


title: DESCRIPTION
content:
Calibre is a powerful and open-source ebook management software. It allows users to organize, view, edit, and convert ebooks across various formats. While primarily known for its rich graphical user interface, the <I><B>calibre</B></I> command itself launches this GUI, providing access to its comprehensive features like library management, metadata editing, news fetching, and device synchronization.<br><br>It serves as the central hub for the Calibre ecosystem, which also includes several dedicated command-line tools for specific tasks such as format conversion (<I><B>ebook-convert</B></I>), database management (<I><B>calibredb</B></I>), and content serving (<I><B>calibre-server</B></I>). It supports a vast array of ebook formats and is cross-platform, making it a versatile tool for ebook enthusiasts.


title: CAVEATS
content:
The <I><B>calibre</B></I> command primarily launches the graphical user interface. While it offers some command-line options for initial setup or interaction with a running instance, it is not designed for complex, scriptable ebook manipulations directly. Operations like batch format conversions, deep metadata editing, or hosting an ebook server are handled by dedicated, separate command-line utilities within the Calibre suite (e.g., <I><B>ebook-convert</B></I>, <I><B>calibredb</B></I>, <I><B>calibre-server</B></I>).


title: SEPARATE COMMAND-LINE TOOLS
content:
The Calibre ecosystem includes a robust set of standalone command-line tools for specific tasks. These include <I><B>ebook-convert</B></I> for batch format conversions, <I><B>calibredb</B></I> for managing the Calibre database and library, <I><B>calibre-server</B></I> for serving your ebook collection over the network, and others like <I><B>calibre-editor</B></I> and <I><B>calibre-viewer</B></I> for direct access to the editor and viewer components. Users needing automation or scriptable interactions with their ebook library will typically leverage these dedicated tools rather than the main <I><B>calibre</B></I> command.


title: HISTORY
content:
Calibre was initially released in 2006 as <I>libprs500</I> by Kovid Goyal, created to convert obscure ebook formats for the Sony PRS-500 ebook reader. It quickly evolved beyond a simple converter into a comprehensive ebook management system, gaining its current name <I>calibre</I> in 2008. Its development has been community-driven, with continuous updates adding new features, device support, and format compatibility, establishing it as a leading open-source solution for ebook enthusiasts worldwide.


title: PARAMETERS
content:
<b><i>file...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths to presentation files (e.g., .odp, .ppt) to be opened by Calligra Stage upon launch. If no file is specified, the application starts with an empty document or template selection.<br><br><b>--fullscreen</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches Calligra Stage in fullscreen mode. This is particularly useful for immediately starting a presentation without window decorations or desktop elements.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a short help message detailing common command-line options for the application.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of Calligra Stage.<br><br><b>--author</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays information about the authors of the Calligra Stage application.<br><br><b>--license</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the license under which Calligra Stage is distributed (typically LGPL/GPL).<br><br>


title: DESCRIPTION
content:
<i>calligrapresenter</i> is the executable name for <b>Calligra Stage</b>, the presentation component of the Calligra Office Suite. It is an open-source application designed for creating, editing, and presenting professional-quality slideshows. As part of the KDE ecosystem, it offers a user-friendly graphical interface for designing presentations with various elements, including text, images, shapes, charts, and multimedia. <br><br>Users can apply diverse transitions and animations to slides, manage master slides for consistent branding, and export presentations to various formats, including PDF and OpenDocument Presentation (ODP). While its primary mode of operation is interactive through its GUI, the command-line interface allows for opening specific presentation files or launching the application with certain display configurations, making it a flexible tool for both design and delivery.


title: CAVEATS
content:
<i>calligrapresenter</i> is primarily a graphical application, meaning most advanced features and presentation controls are accessible only through its GUI. Command-line options are mainly for launching, opening files, or basic display settings. Its availability and performance are dependent on the Calligra Suite installation and underlying KDE/Qt libraries. While it supports common formats, compatibility with very complex or proprietary presentation features from other suites (like Microsoft PowerPoint) might vary.


title: SUPPORTED FILE FORMATS
content:
Calligra Stage primarily uses the OpenDocument Presentation (ODP) format as its native file type. It also provides filters for opening and saving files in other popular formats, including Microsoft PowerPoint's PPT and PPTX, though full fidelity may vary with complex documents.


title: INTEGRATION WITH KDE
content:
As a native KDE application, <i>calligrapresenter</i> integrates seamlessly with the KDE Plasma Desktop environment, adhering to KDE's visual guidelines and leveraging its underlying technologies for features like file dialogs, printing, and clipboard management.


title: HISTORY
content:
<i>calligrapresenter</i> is the modern executable name for what was formerly known as <b>KPresenter</b>, the presentation application of the KOffice suite. With the significant rewrite and restructuring of KOffice, it was rebranded as <b>Calligra Stage</b> as part of the Calligra Suite, first released in 2012. This transition aimed to modernize the codebase and improve integration with newer KDE technologies. It continues to be developed as a Free and Open Source Software (FOSS) project, offering a native KDE alternative for presentation creation.


title: TLDR
content:
<b>Display temperature of a specific drive</b>`hddtemp [type]:[/dev/sdX]`<br><b>Display temperature of a SATA drive assigned to sda</b>`hddtemp SATA:/dev/sda`<br><b>Log temperatures to syslog every n seconds</b>`hddtemp [[-S|--syslog]] [nseconds] [type]:[/dev/sdX]`<br><b>Print only numeric value of temperature without unit</b>`hddtemp [[-n|--numeric]] [type]:[/dev/sdX]`<br><b>Define the unit used to denote temperature</b>`hddtemp [[-u|--unit]] [C|F] [type]:[/dev/sdX]`<br><b>Wake ATA drive before attempting to read temperature</b>`hddtemp [[-w|--wake-up]] [type]:[/dev/sdX]`<br><b>Enter debug mode to show S.M.A.R.T. fields and their values</b>`hddtemp [[-D|--debug]] [type]:[/dev/sdX]`<br><b>Suppress compatibility check for drive types</b>`hddtemp [[-q|--quiet]] [type]:[/dev/sdX]`


title: SYNOPSIS
content:
As a graphical user interface application, <i>Pirut</i> was primarily launched by simply invoking its name. It offered very limited or no functional command-line options for direct package manipulation.<br><br><b>pirut</b> <i>[generic_options]</i><br><br><i>generic_options:</i> Common options like <b>--help</b> or <b>--version</b>.


title: PARAMETERS
content:
<b><i>No specific package management parameters.</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Pirut</i> was primarily a graphical application and did not offer command-line parameters for performing package management tasks directly. Its command-line invocation was typically limited to launching the GUI.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays a brief help message regarding generic command usage.</i><br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Shows the version information of the Pirut application.</i><br><br>


title: DESCRIPTION
content:
<i>Pirut</i> was a graphical front-end application designed for Red Hat Enterprise Linux (RHEL) and Fedora distributions. Its primary purpose was to simplify package management by providing an intuitive user interface over the command-line <b>yum</b> (Yellowdog Updater, Modified) utility. Users could easily search for, install, update, and remove software packages without needing to memorize <b>yum</b> commands or package names. It offered a visual representation of available software, categories, and installed packages, making it accessible for users less familiar with the Linux terminal. <i>Pirut</i> aimed to enhance the user experience for system administration tasks related to software installation and maintenance.<br><br>While widely used in earlier versions of RHEL and Fedora, it has since been superseded by more modern and robust package management front-ends like <b>yumex</b> and, more recently, <b>dnfdragora</b> and GNOME Software Center, which provide similar or enhanced functionalities on systems that now primarily use <b>dnf</b>.


title: CAVEATS
content:
<i>Pirut</i> is an <b>outdated and deprecated</b> graphical package manager. It is no longer actively developed or maintained and has been replaced by more modern tools like <b>yumex</b>, <b>dnfdragora</b>, and system-integrated software centers (e.g., GNOME Software) in contemporary Red Hat-based distributions (Fedora, RHEL, CentOS Stream). Attempting to use <i>pirut</i> on recent systems will likely fail as the executable may not exist, or its dependencies might be missing. Users should utilize <b>dnf</b> or <b>yum</b> (on older systems) from the command line, or their respective graphical front-ends, for package management.


title: PURPOSE
content:
<i>Pirut</i> provided a user-friendly graphical interface for managing RPM packages, including searching, installing, updating, and removing software. It was designed to make package management accessible to users who preferred a visual approach over the command line.


title: REPLACEMENT
content:
While <i>Pirut</i> offered basic functionalities, it lacked advanced features and modern UI/UX elements. It was gradually phased out and replaced by more robust and actively maintained graphical tools such as <b>yumex</b> (for <b>yum</b>) and later <b>dnfdragora</b> and other distribution-specific software centers that leverage <b>dnf</b>.


title: HISTORY
content:
<i>Pirut</i> emerged as an early attempt by Red Hat and the Fedora project to provide a more user-friendly interface for package management, abstracting the complexities of the <b>yum</b> command-line utility. It was prominently featured in Fedora Core releases and early versions of Red Hat Enterprise Linux. Its development coincided with a period when graphical desktop environments were becoming more sophisticated, and there was a growing need for intuitive system administration tools.<br><br>As Linux distributions evolved, so did their package management needs. <i>Pirut</i> eventually became stagnant in development and was superseded by new generations of graphical tools that offered better integration with modern desktop environments and kept pace with changes in the underlying <b>yum</b> and later <b>dnf</b> technologies. Its legacy lies in paving the way for more refined graphical package managers.


title: PARAMETERS
content:
<b>--generate-privkey</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a new private key.<br><br><b>--generate-self-signed</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a self-signed X.509 certificate.<br><br><b>--generate-request</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a certificate signing request (CSR).<br><br><b>--sign-request</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Signs a certificate request with a CA key and certificate.<br><br><b>--verify-chain</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verifies a certificate chain against a trusted CA.<br><br><b>--generate-crl</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a Certificate Revocation List (CRL).<br><br><b>--crl-info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays information about a CRL.<br><br><b>--pkcs12-encrypt</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Encrypts a private key and certificate into a PKCS#12 file.<br><br><b>--pkcs12-decrypt</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decrypts a PKCS#12 file, extracting keys and certificates.<br><br><b>--info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays information about a certificate, key, or CSR.<br><br><b>--bits <I>BITS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the key size in bits for generated keys (e.g., 2048).<br><br><b>--sec-param <I>LEVEL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the security level for cryptographic operations.<br><br><b>--hash <I>ALGORITHM</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the hash algorithm to be used (e.g., SHA256).<br><br><b>--load-privkey <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads a private key from the specified file.<br><br><b>--load-request <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads a certificate request from the specified file.<br><br><b>--load-certificate <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads a certificate from the specified file.<br><br><b>--load-ca-privkey <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads the CA private key for signing.<br><br><b>--load-ca-certificate <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads the CA certificate for signing or verification.<br><br><b>--outfile <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output file for generated content.<br><br><b>--infile <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input file for processing.<br><br><b>--days <I>DAYS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the validity period for certificates in days.<br><br><b>--key-usage <I>USAGE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the purpose(s) for which the public key may be used.<br><br><b>--ext-usage <I>USAGE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines extended purposes for which the public key may be used.<br><br><b>--template <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a template file for certificate or request generation.<br><br><b>--password <I>STRING</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a password for encrypted files.<br><br><b>--passphrase <I>STRING</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Alias for <I>--password</I>.<br><br><b>--p12-name <I>STRING</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the friendly name for PKCS#12 entries.<br><br><b>--debug <I>LEVEL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the debug level for verbose output.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output during execution.<br><br><b>--batch</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates in non-interactive mode, suppressing prompts.<br><br><b>--force-overwrite</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overwrites existing output files without prompting.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <b>certtool</b> version and exits.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br>


title: DESCRIPTION
content:
<b>certtool</b> is a command-line utility provided by the GnuTLS (GNU Transport Layer Security) library. It serves as a comprehensive tool for managing various cryptographic elements essential for secure communication. Its primary functions include generating X.509 certificates, creating private keys (RSA, DSA, ECC), signing certificate requests (CSRs), verifying certificate chains, and managing Certificate Revocation Lists (CRLs).<br><br><b>certtool</b> supports a wide range of cryptographic algorithms and parameters, making it versatile for establishing Public Key Infrastructure (PKI) components. It is commonly used by administrators and developers to set up SSL/TLS servers, secure client applications, and manage digital identities. The tool allows for detailed specification of certificate fields, extensions, and key usages, providing granular control over the cryptographic properties of generated assets.


title: CAVEATS
content:
Users should exercise caution when handling private keys and certificates, as improper usage or exposure can compromise security. <b>certtool</b> is part of the GnuTLS ecosystem, meaning its internal mechanisms and default behaviors might differ from other cryptographic toolkits like OpenSSL. Always verify the generated output and ensure proper file permissions.


title: CERTIFICATE TEMPLATES
content:
<b>certtool</b> supports the use of template files (specified with <I>--template</I>) to define certificate fields, extensions, and key usages. This feature allows for automated and consistent generation of certificates and certificate signing requests (CSRs), reducing manual input and potential errors.


title: PKCS#12 SUPPORT
content:
The command provides comprehensive functionality for handling PKCS#12 (PFX) files. This includes encrypting private keys and certificates into a single, password-protected file (<I>--pkcs12-encrypt</I>) and decrypting such files to extract their contents (<I>--pkcs12-decrypt</I>), which is crucial for secure key and certificate distribution.


title: SECURITY PARAMETER CONTROL
content:
Users can specify a security level using the <I>--sec-param</I> option. This influences the selection of cryptographic parameters like key sizes and hash algorithms, ensuring that generated keys and certificates meet desired security standards or policy requirements.


title: HISTORY
content:
<b>certtool</b> is an integral part of the GnuTLS project, which was initiated to provide a free software implementation of the SSL/TLS protocols. Development began in the early 2000s, aiming to offer an alternative to OpenSSL, especially for projects preferring LGPL-licensed libraries. <b>certtool</b> evolved alongside the GnuTLS library, incorporating new cryptographic algorithms, protocol versions (TLS 1.2, 1.3), and key types (ECC) as they became standardized. Its design prioritizes consistency with the GnuTLS API, making it a natural choice for developers working within that ecosystem.


title: TLDR
content:
<b>Generate a private key and save it to a file</b>`certtool [[-p|--generate-privkey]] --outfile [path/to/private.key]`<br><b>Generate a self-signed certificate using a private key and a template file</b>`certtool [[-s|--generate-self-signed]] --load-privkey [path/to/private.key] --template [path/to/info.template] --outfile [path/to/certificate.crt]`<br><b>Generate a certificate signing request (CSR)</b>`certtool [[-q|--generate-request]] --load-privkey [path/to/private.key] --template [path/to/info.template] --outfile [path/to/request.csr]`<br><b>Generate a certificate authority (CA) certificate</b>`certtool [[-s|--generate-self-signed]] --load-privkey [path/to/ca.key] --template [path/to/ca.template] --outfile [path/to/ca.crt]`<br><b>Verify a certificate against a CA certificate</b>`certtool --verify --infile [path/to/certificate.crt] --load-ca-certificate [path/to/ca.crt]`


title: TLDR
content:
<b>Start the Stratis service (must be active before managing pools or volumes)</b>`sudo systemctl start stratisd`<br><b>Create a storage pool from one or more devices</b>`sudo stratis pool create [pool_name] [/dev/sdX] [/dev/sdY]`<br><b>Create a filesystem (volume) in a pool</b>`sudo stratis filesystem create [pool_name] [volume_name]`<br><b>List all Stratis filesystems</b>`sudo stratis filesystem list`<br><b>Format and mount a Stratis volume manually</b>`sudo mkfs.xfs /dev/stratis/[pool_name]/[volume_name] && sudo mount /dev/stratis/[pool_name]/[volume_name] [/mnt/target]`<br><b>Add a volume to /etc/fstab for mounting at boot</b>`echo /dev/stratis/[pool_name]/[volume_name] [/mnt/target] xfs defaults,x-systemd.requires=stratisd.service 0 0 | sudo tee [[-a|--append]] /etc/fstab`<br><b>Extend an existing pool by adding a new device</b>`sudo stratis pool add-data [pool_name] [/dev/sdZ]`<br><b>Delete a volume</b>`sudo stratis filesystem destroy [pool_name] [volume_name]`


title: SYNOPSIS
content:
<b>apt install</b> [<i>options</i>] <i>package</i>[<i>...</i>]<br>Example: <i>apt install firefox nano</i>


title: PARAMETERS
content:
<b><i>package</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more package names to install.<br><br><b><b>-y</b>, <b>--yes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assume 'yes' to all prompts and run non-interactively.<br><br><b><b>--no-install-recommends</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not install recommended packages.<br><br><b><b>--no-install-suggests</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not install suggested packages.<br><br><b><b>--dry-run</b>, <b>-s</b>, <b>--simulate</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulate an operation without making any actual changes.<br><br><b><b>--reinstall</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reinstall packages that are already installed.<br><br><b><b>--allow-unauthenticated</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignore warnings about unauthenticated packages.<br><br><b><b>--allow-downgrades</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow installing older versions of packages.<br><br><b><b>--fix-broken</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempt to correct a system with broken dependencies. Often used as <i>apt --fix-broken install</i>.<br><br>


title: DESCRIPTION
content:
The <b>apt install</b> command is part of the Advanced Package Tool (APT), a powerful command-line utility for managing software packages on Debian-based Linux distributions like Ubuntu. It is primarily used to install new software packages, including their dependencies, from the configured repositories. When <b>apt install</b> is executed, it first updates its internal cache of available packages (if an <b>apt update</b> was recently performed), then resolves all necessary dependencies for the requested package(s), downloads them, and finally installs them onto the system. It handles complex dependency chains automatically, ensuring that all required libraries and programs are present for the installed software to function correctly. This command provides a user-friendly interface with progress bars and clear output, making package management straightforward for both new and experienced users.


title: CAVEATS
content:
Requires <b>root</b> privileges to execute successfully; typically run with <b>sudo</b>.<br>Installing packages from untrusted sources or with <b>--allow-unauthenticated</b> can compromise system security.<br>Removing essential system packages can render your system unusable. Use with caution.<br>Requires an active internet connection to download packages from remote repositories.


title: <I>UPDATING PACKAGE LISTS</I>
content:
Before installing new packages, it's good practice to update your local package list cache using <b>apt update</b>. This command fetches the latest information about available packages from all configured repositories, ensuring you can install the most recent versions.


title: <I>PACKAGE SOURCES</I>
content:
APT retrieves packages from repositories defined in the <b>/etc/apt/sources.list</b> file and files within <b>/etc/apt/sources.list.d/</b>. These files specify the URLs of package archives and the distribution components (e.g., main, universe) to use.


title: HISTORY
content:
The <b>apt</b> command was introduced as a more user-friendly and feature-rich front-end to <b>apt-get</b> and <b>apt-cache</b>. While <b>apt-get</b> remains important for scripting, <b>apt</b> provides a more interactive experience for everyday use, including progress bars, better-formatted output, and consolidated functionality. Its development aimed to simplify common tasks and improve the overall user experience of package management on Debian-based systems, building upon the robust foundation laid by <b>apt-get</b> since the late 1990s.


title: TLDR
content:
<b>Install a package, or update it to the latest version</b>`sudo apt install [package]`<br><b>Display verbose package version information during installation or update</b>`sudo apt install [[-V|--verbose-versions]] [package]`


title: PARAMETERS
content:
<b>expression</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The literal string or substring to be found within the filenames.<br><br><b>replacement</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The literal string or substring that will replace the <b>expression</b>.<br><br><b>file...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths to files that will be processed. Wildcards (e.g., *.txt) are commonly used here to specify multiple files.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about each renaming operation, showing the old and new filenames.<br><br><b>-s, --symlinks</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <b>rename</b> from dereferencing symbolic links. If a symlink is encountered, the symlink itself will be renamed, not its target.<br><br><b>-n, --no-act</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a "dry run" by printing what actions would be taken without actually renaming any files. This is highly recommended for testing complex renaming operations.<br><br><b>-o, --old-file-names</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows filenames beginning with a hyphen (-) to be specified without being interpreted as options. This is useful when dealing with unusual filenames.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <b>rename</b> utility and exits.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with usage information and exits.<br><br>


title: DESCRIPTION
content:
The <b>rename</b> command, often provided as part of the <b>util-linux</b> package, is used for batch renaming of multiple files by replacing a specified string (<b>expression</b>) with another string (<b>replacement</b>) within their filenames. Unlike the <b>mv</b> command, which renames one file at a time or moves files, <b>rename</b> is designed for altering parts of filenames across a group of files. For instance, you can use it to change all occurrences of "old_" to "new_" in file names like "old_report.txt" to "new_report.txt". It operates by iterating through the list of provided files and, for each file, replaces the first occurrence of <b>expression</b> in its name with <b>replacement</b>. It's crucial to differentiate this <b>rename</b> from the Perl-based <b>rename</b> (often found on Debian/Ubuntu systems), which offers more powerful regular expression capabilities. The <b>util-linux</b> version performs a simple literal string replacement, not a regex match. Always use the <b>-n</b> (dry-run) option first to preview changes before committing to them.


title: CAVEATS
content:
<b>Literal String Replacement:</b> This version of <b>rename</b> performs a literal string replacement. It does <b>not</b> support regular expressions like the Perl-based <b>rename</b> utility. If you need regex capabilities, ensure you are using the correct <b>rename</b> version (often <i>prename</i> or <i>rename</i> from <i>perl-utils</i>).<br><b>Overwrite Risk:</b> <b>rename</b> can silently overwrite existing files if a new filename generated by the replacement already exists. Use the <b>-n</b> (dry-run) option and carefully review output to avoid unintended data loss.<br><b>First Occurrence Only:</b> By default, <b>rename</b> replaces only the <i>first</i> occurrence of the <b>expression</b> within each filename. If <b>expression</b> appears multiple times and you wish to replace all, this command is not suitable for that.<br><b>Directory Handling:</b> This command is primarily for renaming files. While you can specify paths containing directories (e.g., <i>dir/oldfile</i>), it will not rename the directories themselves; it only modifies the filenames within them.<br><b>Wildcard Expansion:</b> The shell expands wildcards (e.g., *, ?) <i>before</i> <b>rename</b> sees them. Ensure your shell's wildcard expansion includes only the files you intend to rename.


title: EXAMPLE USAGE
content:
To rename all files ending with <I>.txt</I> to end with <I>.bak</I> in the current directory, and see what would happen without actually doing it:<br><pre><code>rename -n .txt .bak *.txt</code></pre>To actually perform the above renaming operation:<br><pre><code>rename .txt .bak *.txt</code></pre>To replace "photo" with "image" in files like "my_photo_01.jpg" and "old_photo.png":<br><pre><code>rename photo image my_photo_01.jpg old_photo.png</code></pre>


title: HISTORY
content:
The <b>rename</b> command has a long history within the Linux ecosystem, particularly as part of the <b>util-linux</b> project, a collection of essential system utilities. Historically, there have been two predominant implementations of <b>rename</b> on Linux systems: the simpler, literal string replacement version (from <b>util-linux</b>) and a more powerful, regular-expression-based version (often written in Perl and distributed as <i>perl-rename</i> or <i>prename</i>). The <b>util-linux</b> version, which is the focus here, evolved to provide basic batch renaming capabilities by finding and replacing a specific substring within filenames. Its development aimed to offer a lightweight utility for common renaming tasks without the overhead or complexity of regular expressions, distinguishing it from its Perl counterpart which caters to more advanced pattern-matching requirements. Distributions like Red Hat Enterprise Linux and CentOS typically provide the <b>util-linux rename</b> as the default, while Debian and Ubuntu often default to the Perl version, leading to occasional confusion for users.


title: TLDR
content:
<b>Rename files using simple substitutions (substitute foo with bar wherever found)</b>`rename [foo] [bar] [*]`<br><b>Dry-run - display which renames would occur without performing them</b>`rename [[-vn|--verbose --no-act]] [foo] [bar] [*]`<br><b>Do not overwrite existing files</b>`rename [[-o|--no-overwrite]] [foo] [bar] [*]`<br><b>Change file extensions</b>`rename [.ext] [.bak] [*.ext]`<br><b>Prepend "foo" to all filenames in the current directory</b>`rename '' '[foo]' [*]`<br><b>Rename a group of increasingly numbered files zero-padding the numbers up to 3 digits</b>`rename [foo] [foo00] [foo?] && rename [foo] [foo0] [foo??]`


title: PARAMETERS
content:
<b><<i>vmid</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The unique ID of the virtual machine to configure.<br><br><b>--autodeploy <<i>boolean</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable or disable automatic deployment of cloud-init configuration (default is 1 for enabled).<br><br><b>--cipassword <<i>password</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the password for the specified Cloud-Init user (<i>ciuser</i>).<br><br><b>--ciuser <<i>username</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the username for the Cloud-Init configuration (e.g., 'root', 'ubuntu').<br><br><b>--force-ip-config <<i>boolean</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces Cloud-Init to configure the IP address, even if it's already configured by DHCP.<br><br><b>--hostname <<i>hostname</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the hostname for the VM.<br><br><b>--ip <<i>ipaddress/cidr</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the IP address and CIDR for the VM's network interface (e.g., '192.168.1.10/24').<br><br><b>--gw <<i>ipaddress</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the default gateway IP address for the VM.<br><br><b>--nameserver <<i>ipaddress</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the DNS nameserver IP address for the VM.<br><br><b>--searchdomain <<i>domain</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the DNS search domain for the VM.<br><br><b>--sshkeys <<i>path-to-public-key</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to an SSH public key file to be added to the <i>ciuser</i>'s authorized_keys.<br><br><b>--tags <<i>tag1,tag2,...</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated list of tags to associate with the VM (used for grouping/identification).<br><br><b>--user-data <<i>path-to-yaml-file</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a YAML file containing custom user-data scripts or configurations for Cloud-Init.<br><br><b>--network <<i>json/yaml-string</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Directly provides network configuration in JSON or YAML format, overriding other network options.<br><br><b>--template <<i>boolean</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Marks the VM as a Cloud-Init template, applying default Cloud-Init settings and potentially simplifying future deployments.<br><br><b>--ide<<i>N</i>> <<i>storage:size</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attaches a Cloud-Init disk as an IDE device (e.g., '--ide0 local-lvm:4M'). <<i>N</i>> is the controller index.<br><br><b>--scsi<<i>N</i>> <<i>storage:size</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attaches a Cloud-Init disk as a SCSI device (e.g., '--scsi0 local-lvm:4M'). <<i>N</i>> is the controller index.<br><br><b>--virtio<<i>N</i>> <<i>storage:size</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attaches a Cloud-Init disk as a VirtIO device (e.g., '--virtio0 local-lvm:4M'). <<i>N</i>> is the controller index.<br><br>


title: DESCRIPTION
content:
The <b>qm-cloudinit</b> command in Proxmox VE is a powerful utility designed to automate the initial configuration of virtual machines (VMs) using Cloud-Init. Cloud-Init is the industry standard for cross-platform cloud instance initialization, commonly used to set up cloud instances on first boot. <br><br>When applied to a Proxmox VM, <b>qm-cloudinit</b> injects configuration data (such as hostname, IP address, DNS settings, user accounts, SSH keys, and custom scripts) into a virtual disk image that the Cloud-Init enabled guest OS can read and apply during its boot process. This streamlines the deployment of new VMs from templates, enabling Infrastructure as Code (IaC) principles. <br><br>It allows for rapid, consistent, and reproducible VM deployments without manual intervention, making it invaluable for environments that require quick scaling or frequent provisioning of new instances. The command ensures that VMs come online with the desired network, user, and other pre-defined settings.


title: CAVEATS
content:
For <b>qm-cloudinit</b> to function correctly, the guest VM must be running a Cloud-Init enabled operating system (e.g., most cloud images of Ubuntu, Debian, CentOS). The VM should ideally be shut down when applying Cloud-Init configurations to ensure changes are written to the disk correctly. While some settings might apply on a running VM with <i>qemu-guest-agent</i>, it's generally safer and more reliable to power off the VM. The Cloud-Init disk (typically a small ISO or raw disk image) must be properly attached to the VM, usually on an IDE, SCSI, or VirtIO controller, often as the first disk.


title: HOW CLOUD-INIT WORKS IN PROXMOX
content:
When you use <b>qm-cloudinit</b>, Proxmox typically generates a small virtual CD-ROM or disk image containing the Cloud-Init configuration (metadata and user-data). This disk is then attached to the VM. The Cloud-Init daemon running within the guest OS detects this disk on boot, reads the configuration, and applies the specified settings. This method allows for a 'fire and forget' approach to VM provisioning, where the VM configures itself upon its first startup.


title: CREATING CLOUD-INIT TEMPLATES
content:
A common best practice in Proxmox is to create a 'Cloud-Init template'. This involves importing a clean cloud image (e.g., from Ubuntu or Debian), installing the <i>qemu-guest-agent</i> within it, and then configuring the VM as a template using <b>qm-cloudinit --template 1</b>. Future VMs can then be cloned from this template, and <b>qm-cloudinit</b> can be used on the cloned VMs to inject unique network settings, hostnames, and user data, making them ready for use instantly.


title: HISTORY
content:
Cloud-Init originated with Ubuntu for use on Amazon EC2 in 2009, becoming a de facto standard for initial instance configuration across various cloud platforms. Proxmox VE, a popular open-source virtualization platform, integrated Cloud-Init support to provide a robust solution for VM templating and automated deployment. The <b>qm-cloudinit</b> command was developed as part of Proxmox's toolset to expose and manage these Cloud-Init capabilities directly from the hypervisor, allowing Proxmox users to leverage the power of Cloud-Init for their local VM infrastructure, mirroring the automation capabilities found in public clouds.


title: TLDR
content:
<b>Configure cloudinit settings for a specific user and set password for the user</b>`qm [[clou|cloudinit]] [vm_id] -user=[user] -password=[password]`<br><b>Configure cloudinit settings for a specific user and set password for the user with a specific SSH key</b>`qm [[clou|cloudinit]] [vm_id] -user=[user] -password=[password] -sshkey=[ssh_key]`<br><b>Set the hostname for a specific virtual machine</b>`qm [[clou|cloudinit]] [vm_id] -hostname=[hostname]`<br><b>Configure the network interface settings for a specific virtual machine</b>`qm [[clou|cloudinit]] [vm_id] -ipconfig [ipconfig]`<br><b>Configure a shell script to execute before cloudinit is run on a virtual machine</b>`qm [[clou|cloudinit]] [vm_id] -pre [script]`


title: SYNOPSIS
content:
<b>bsub</b> [<i>options</i>] <i>command</i> [<i>arguments</i>]<br><b>bsub</b> [<i>options</i>] <b>-J</b> <i>job_name</i> <b>-o</b> <i>output_file</i> <b>-e</b> <i>error_file</i> <i>command</i><br><b>bsub</b> [<i>options</i>] <b>-Is</b> <i>command</i> [<i>arguments</i>]


title: PARAMETERS
content:
<b>-q <queue_name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the queue for job submission.<br><br><b>-P <project_name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns the job to a specific project.<br><br><b>-J <job_name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a unique name for the job.<br><br><b>-o <output_file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Redirects standard output to the specified file.<br><br><b>-e <error_file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Redirects standard error to the specified file.<br><br><b>-W <minutes></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the wall clock time limit for the job in minutes.<br><br><b>-n <num_processors></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Requests a specific number of processors.<br><br><b>-R "<resource_requirements>"</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines job resource requirements (e.g., <i>select[os_linux] span[hosts=1] rusage[mem=100]</i>).<br><br><b>-i <input_file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Redirects standard input from the specified file.<br><br><b>-C <checkpoint_dir></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables job checkpointing to the specified directory.<br><br><b>-K</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Keeps the job running after submission, typically for interactive use.<br><br><b>-Is</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Submits an interactive job with a pseudo-terminal (shell access).<br><br><b>-Ip</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Submits an interactive job with pre-execution commands.<br><br><b>-L <login_shell></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the login shell for the job execution environment.<br><br><b>-cwd</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the job in the current working directory.<br><br><b>-host <hostname></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Requests execution on a specific host.<br><br><b>-m <host_group></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Requests execution on hosts from a specified host group.<br><br><b>-u <email_address></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends job status notifications to the specified email.<br><br><b>-b <begin_time>[,<end_time>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines a job run window (e.g., <i>09:00:22:00</i>).<br><br><b>-c <CPU_limit></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the CPU time limit for the job in minutes.<br><br><b>-M <memory_limit></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the memory limit for the job in MB.<br><br><b>-N</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables email notification upon job completion or termination.<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows the job to be rerun automatically if it terminates abnormally.<br><br><b>-s <script_file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Submits a job from a script file.<br><br><b>-f <local_file> '<remote_file_spec>'</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies file staging for job input/output.<br><br>


title: DESCRIPTION
content:
<b>bsub</b> is a fundamental command within the IBM Spectrum LSF (Load Sharing Facility) workload management system. It is used to submit computation jobs, scripts, or commands to the LSF cluster for execution. Unlike directly running commands on a local machine, <b>bsub</b> offloads the execution to a managed cluster, allowing LSF to efficiently allocate resources, schedule jobs, and manage their lifecycle from submission to completion.<br><br>Users employ <b>bsub</b> to specify various job attributes such as the execution queue, resource requirements (e.g., number of CPUs, memory, specific hosts), job name, output/error file redirection, and time limits. LSF then places the job into a queue, and once resources become available according to defined policies, the job is dispatched to an appropriate execution host. This provides benefits like improved resource utilization, fault tolerance (jobs can be re-run or rescheduled), and centralized monitoring, making <b>bsub</b> indispensable for high-performance computing (HPC), grid computing, and large-scale enterprise batch processing environments.


title: CAVEATS
content:
The <b>bsub</b> command is part of the IBM Spectrum LSF suite and is not a standard component of core Linux distributions. Its availability and specific functionality depend entirely on a configured LSF environment. Options and behavior may vary slightly across different LSF versions. Jobs submitted via <b>bsub</b> are subject to cluster policies, resource availability, and potential licensing constraints. Proper environment setup (e.g., LSF client libraries, PATH configuration) is required for <b>bsub</b> to function correctly.


title: JOB STATES AND LIFECYCLE
content:
LSF jobs submitted via <b>bsub</b> transition through various states: <br><i>PEND</i> (Pending): Waiting for resources.<br><i>RUN</i> (Running): Currently executing.<br><i>PSUSP</i> (Preempted Suspend): Suspended by LSF for higher priority jobs.<br><i>USUSP</i> (User Suspend): Suspended by user.<br><i>DONE</i> (Done): Completed successfully.<br><i>EXIT</i> (Exited): Terminated with non-zero exit code or by LSF.<br>Monitoring these states with commands like <b>bjobs</b> is crucial for job management.


title: INTERACTIVE VS. BATCH JOBS
content:
<b>bsub</b> supports both traditional batch processing and interactive job submission. Batch jobs run in the background, typically redirecting output to files. Interactive jobs, often submitted with options like <b>-Is</b> or <b>-Ip</b>, allow users to interact with the running application directly, similar to a regular shell session, once the job starts on a compute node. This is useful for debugging, developing, or running applications that require user input.


title: HISTORY
content:
LSF (Load Sharing Facility) was originally developed by Platform Computing Corporation in the early 1990s. It quickly became a leading workload management system for distributed computing and High-Performance Computing (HPC) environments. IBM acquired Platform Computing in 2012, integrating LSF into its Spectrum Computing portfolio as IBM Spectrum LSF. The <b>bsub</b> command has been a central component since LSF's inception, evolving alongside the product to support increasingly complex workloads, diverse resource types, and large-scale clusters.


title: TLDR
content:
<b>Submit a script file as a job</b>`bsub [path/to/script.sh]`<br><b>Submit a job to a specific queue</b>`bsub -q [queue_name] make all`<br><b>Submit a job with a name and redirect output and error</b>`bsub -J [job_name] --output [path/to/output.log] --error [path/to/error.log] [path/to/script.sh]`<br><b>Request 8 CPU cores and 16GB memory for a command</b>`bsub -n 8 -M 16G cargo build --release`<br><b>Run an interactive shell in the current session</b>`bsub -I bash`<br><b>Submit a job with a runtime limit of 45 minutes</b>`bsub -W 45 [path/to/script.sh]`


title: SYNOPSIS
content:
<b>qwen</b> [<i>OPTIONS</i>] <i>&lt;PROMPT&gt;</i><br><i>or</i><br><b>qwen</b> [<i>OPTIONS</i>] <b>--file</b> <i>&lt;FILE_PATH&gt;</i>


title: PARAMETERS
content:
<b><b>--model</b> <i>&lt;NAME&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the particular Qwen model to use (e.g., <i>qwen-turbo</i>, <i>qwen-plus</i>, <i>qwen-long</i>).<br><br><b><b>--api-key</b> <i>&lt;KEY&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the API authentication key for accessing Qwen services. Can often be set via an environment variable.<br><br><b><b>--temperature</b> <i>&lt;VALUE&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls the randomness of the output. A floating-point value between 0.0 (deterministic) and 1.0 (very random).<br><br><b><b>--max-tokens</b> <i>&lt;N&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum number of tokens (words/sub-words) the model should generate in its response.<br><br><b><b>--stream</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables streaming mode, displaying the model's response incrementally as it is generated.<br><br><b><b>--file</b> <i>&lt;PATH&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads the input prompt from the specified file instead of directly from the command line argument.<br><br><b><b>--output</b> <i>&lt;FORMAT&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the desired output format (e.g., <i>text</i>, <i>json</i>). Useful for scripting and integration.<br><br><b><b>--system</b> <i>&lt;MESSAGE&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides an initial system message to guide the model's overall behavior or persona for the conversation.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with command usage and options.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of the <b>qwen</b> CLI tool.<br><br>


title: DESCRIPTION
content:
The <b>qwen</b> command, as described here, is a hypothetical command-line interface (CLI) designed to interact with Alibaba Cloud's Qwen family of large language models. It is important to note that this is not a standard, pre-installed Linux utility. Such a tool would provide a streamlined way for users to send prompts to Qwen models, receive generated responses, and manage various interaction parameters directly from the terminal. Its primary purpose would be to facilitate rapid prototyping, integrate AI capabilities into shell scripts, and enable developers and researchers to leverage Qwen's power without extensive programming. Users could specify different Qwen model versions, adjust parameters like generation temperature or maximum output tokens, and manage authentication credentials. This conceptual command aims to simplify access to advanced AI functionalities for command-line centric workflows.


title: CAVEATS
content:
It is crucial to understand that <b>qwen</b> is not a standard, pre-installed Linux command. This analysis describes a hypothetical utility for interacting with the Qwen LLM.<br>Usage would typically require an active internet connection and a valid API key from Alibaba Cloud, incurring costs based on usage.<br>Performance can vary significantly based on network latency, model load, and the complexity of the prompt.<br>As a large language model, Qwen, like others, can sometimes produce inaccurate, biased, or nonsensical outputs (hallucinations).


title: AUTHENTICATION & API USAGE
content:
Interaction with the Qwen LLMs via a hypothetical <b>qwen</b> command would typically rely on API keys for authentication. These keys, obtained from Alibaba Cloud, grant access to the Qwen services. For security and convenience, it is highly recommended to store the API key as an environment variable (e.g., <i>QWEN_API_KEY</i>) rather than passing it directly on the command line, especially in scripts. Usage of the Qwen API is subject to Alibaba Cloud's pricing policies, which are usually based on token consumption (input and output tokens).


title: EXAMPLE USAGE
content:
<b>Basic Prompt:</b><br><i>qwen "Explain quantum computing in simple terms."</i><br><br><b>Specify Model and Temperature:</b><br><i>qwen --model qwen-plus --temperature 0.7 "Write a short poem about a cat."</i><br><br><b>Read from File and Stream Output:</b><br><i>qwen --file my_prompt.txt --stream</i><br><br><b>Get JSON Output for Scripting:</b><br><i>qwen --model qwen-turbo --output json "List 3 benefits of cloud computing." | jq .</i>


title: HISTORY
content:
As a hypothetical command, <b>qwen</b> has no direct historical development as a standard Linux utility. Its conceptualization arises from the increasing demand for accessible command-line interfaces to interact with powerful large language models. The underlying Qwen models themselves were developed by Alibaba Cloud, with significant investment and continuous iterations since their initial public announcements. These models have rapidly evolved, offering diverse capabilities from general-purpose conversation to specialized tasks. A CLI tool like <b>qwen</b> would represent a natural progression in making these advanced AI functionalities more directly consumable and scriptable for developers and researchers within a Linux environment.


title: TLDR
content:
<b>Start a REPL session to chat interactively</b>`qwen`<br><b>Send the output of another command to Qwen and exit immediately</b>`[echo "Summarize the history of Rome"] | qwen [[-p|--prompt]]`<br><b>Override the default model (default: qwen3-coder-max)</b>`qwen [[-m|--model]] [model_name]`<br><b>Run inside a sandbox container</b>`qwen [[-s|--sandbox]]`<br><b>Execute a prompt then stay in interactive mode</b>`qwen [[-i|--prompt-interactive]] "[Give me an example of recursion in Python]"`<br><b>Include all files in context</b>`qwen [[-a|--all-files]]`<br><b>Show memory usage in status bar</b>`qwen --show-memory-usage`


title: SYNOPSIS
content:
<b>nvidia-smi mig</b> [<I>command</I>] [<I>options</I>]<br><br><b>nvidia-smi mig -lgi</b> [-i <I>GPU_ID</I>]<br><b>nvidia-smi mig -lci</b> [-i <I>GPU_ID</I>]<br><b>nvidia-smi mig -lcc</b> [-i <I>GPU_ID</I>]<br><b>nvidia-smi mig -lgi-profiles</b> [-i <I>GPU_ID</I>]<br><b>nvidia-smi mig -lci-profiles</b> [-i <I>GPU_ID</I>]<br><b>nvidia-smi mig -cgi</b> <I>GI_PROFILE_ID</I> [-i <I>GPU_ID</I>] [--count <I>N</I>] [--default-device-file <I>FILE</I>]<br><b>nvidia-smi mig -dgi</b> <I>GI_ID</I> [-i <I>GPU_ID</I>] [--force] [--no-confirm]<br><b>nvidia-smi mig -cci</b> <I>CI_PROFILE_ID</I> [--gpuidx <I>GPU_IDX</I> | --parentgi <I>GI_ID</I>] [--count <I>N</I>]<br><b>nvidia-smi mig -dci</b> <I>CI_ID</I> [--gpuidx <I>GPU_IDX</I> | --parentgi <I>GI_ID</I>] [--force] [--no-confirm]<br><b>nvidia-smi mig -mig-mode</b> <I>MODE</I> [-i <I>GPU_ID</I>] [--no-confirm]


title: PARAMETERS
content:
<b>-lgi</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all GPU Instances (GIs) on the system or specified GPU.<br><br><b>-lci</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all Compute Instances (CIs) on the system or specified GPU.<br><br><b>-lcc</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all MIG compute configurations on the system or specified GPU.<br><br><b>-lgi-profiles</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists supported GPU Instance profiles for a GPU.<br><br><b>-lci-profiles</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists supported Compute Instance profiles for a GPU or a parent GPU Instance.<br><br><b>-cgi <I>PROFILE_ID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a GPU Instance using the specified profile ID. Use `-lgi-profiles` to find available IDs.<br><br><b>-dgi <I>GI_ID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes the specified GPU Instance. Use `-lgi` to find existing GI IDs.<br><br><b>-cci <I>PROFILE_ID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a Compute Instance using the specified profile ID. Use `-lci-profiles` to find available IDs.<br><br><b>-dci <I>CI_ID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes the specified Compute Instance. Use `-lci` to find existing CI IDs.<br><br><b>-mig-mode <I>MODE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the MIG mode for a GPU. <I>MODE</I> can be 'ENABLED' or 'DISABLED'. Requires a GPU reset.<br><br><b>-i <I>GPU_ID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target GPU by its 0-indexed device ID (e.g., 0, 1).<br><br><b>--gpuidx <I>GPU_IDX</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target GPU by its index, primarily for CI operations.<br><br><b>--parentgi <I>GI_ID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the parent GPU Instance for Compute Instance operations.<br><br><b>--count <I>N</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of instances to create (for creation commands).<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the operation, overriding certain checks (use with caution as it can lead to data loss).<br><br><b>--no-confirm</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips the confirmation prompt for destructive operations, allowing unattended execution.<br><br>


title: DESCRIPTION
content:
The `<b>nvidia-smi mig</b>` command is a powerful subcommand of `<b>nvidia-smi</b>` used to manage NVIDIA's Multi-Instance GPU (MIG) feature. MIG allows a single Ampere or newer GPU to be partitioned into up to seven independent GPU Instances (GIs) and Compute Instances (CIs). Each GI has its own dedicated memory, cache, and compute cores, providing fault isolation and guaranteed quality of service (QoS) for various workloads.<br><br>This command facilitates the creation, deletion, and listing of these MIG objects, enabling users to optimize GPU utilization by running diverse workloads concurrently with strong isolation. It's crucial for cloud providers and AI/ML researchers who need to partition high-end GPUs for multiple users or applications.


title: CAVEATS
content:
The MIG feature is only available on NVIDIA GPUs based on the Ampere architecture (e.g., A100) or newer. Before using MIG, the GPU's MIG mode must be enabled, which often requires a system reboot. Operations like enabling/disabling MIG mode or deleting all instances typically require a GPU reset, which can disrupt running workloads. All `<b>nvidia-smi mig</b>` commands require root privileges to execute successfully.


title: NOTE ON COMMAND NAME
content:
The command discussed is specifically `<b>nvidia-smi mig</b>`, which is a subcommand of the primary `<b>nvidia-smi</b>` utility. While some references might conceptually use `nvidia-smi-mig`, the literal executable command is invoked by passing `mig` as an argument to `nvidia-smi`.


title: GPU INSTANCE (GI) AND COMPUTE INSTANCE (CI) PROFILES
content:
MIG utilizes predefined profiles that dictate the memory, compute, and video decode/encode capabilities allocated to each instance. GPU Instance profiles define the partitioning of the physical GPU, while Compute Instance profiles define the compute resources within a created GPU Instance. Users select these profiles based on their workload requirements and the available GPU resources.


title: DEVICE FILES
content:
When GPU Instances are created, the system typically presents them as separate, independent CUDA-capable devices, each with its own device file (e.g., <I>/dev/nvidia-gi<I>N</I>c<I>M</I>). This allows applications to target specific MIG instances as if they were distinct physical GPUs, simplifying workload deployment.


title: HISTORY
content:
Multi-Instance GPU (MIG) technology was introduced by NVIDIA with its Ampere architecture, first showcased with the A100 GPU in 2020. The `<b>nvidia-smi mig</b>` subcommand was subsequently added to the `<b>nvidia-smi</b>` utility to provide a programmatic interface for managing these new GPU partitioning capabilities, evolving with new GPU generations.


title: TLDR
content:
<b>Create a compute instance from device 0</b>`nvidia-smi mig [[-cgi|--create-gpu-instance]] [0] [[-C|--default-compute-instance]]`<br><b>List GPU instances</b>`nvidia-smi mig [[-lgi|--list-gpu-instances]]`<br><b>Display help</b>`nvidia-smi mig [[-h|--help]]`


title: TLDR
content:
<b>Start local/production server with hot reloading</b>`trunk serve --port [port] --release --proxy-backend [URL]`<br><b>Build for production at root or subdirectory</b>`trunk build --release --dist [path/to/distribution] --public-url /[path/to/app_subdirectory]`<br><b>List all available tools in the repo and if they are enabled</b>`trunk tools list`<br><b>Enable/disable a tool at a specific version</b>`trunk tools [enable|disable] [tool]@[version]`<br><b>Print an action's execution history</b>`trunk actions history [action]`


title: PARAMETERS
content:
<b>-d, --daemon</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs <b>scim</b> in daemon mode, allowing it to provide input method services to applications. This is its most common operational mode and is typically how it's used within a desktop environment.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message outlining the available command-line options for <b>scim</b>.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of the <b>scim</b> platform, including its release number.<br><br><b>-x <protocol>, --xim-protocol=<protocol></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the XIM protocol to use (e.g., 'xim', 'xim-sync'). This option is less commonly used by end-users directly, as the default is usually sufficient.<br><br>


title: DESCRIPTION
content:
The <b>scim</b> command refers to the Smart Common Input Method platform, a framework designed to provide a unified input method interface for various languages, especially those with complex character sets like Chinese, Japanese, and Korean. It acts as a bridge between applications and different input method engines, allowing users to type non-ASCII characters using their keyboard.<br><br><b>scim</b> primarily runs as a daemon in the background, intercepting keyboard input and converting it based on the selected input method engine (e.g., Pinyin for Chinese, Anthy for Japanese). It interacts with applications primarily through the X Input Method (XIM) protocol, making it a crucial component for internationalization on X Window System-based desktop environments. While once a predominant solution for inputting complex scripts, its role has largely been taken over by more modern input method frameworks.


title: CAVEATS
content:
<b>scim</b> is largely considered deprecated in modern Linux distributions. It has been superseded by newer, more actively developed input method frameworks such as <b>IBus</b> (Intelligent Input Bus) and <b>Fcitx</b> (Flexible Input Method Framework). Users on contemporary systems are unlikely to find <b>scim</b> pre-installed or supported by default, and should instead look towards <b>IBus</b> or <b>Fcitx</b> for their multilingual input needs, especially concerning Wayland support.


title: ENVIRONMENT VARIABLES
content:
The behavior of <b>scim</b> and how applications interact with input methods is often influenced by environment variables, most notably <I>XMODIFIERS</I>.<br><br>For <b>scim</b> to function correctly, <I>XMODIFIERS</I> should typically be set to <i>@im=SCIM</i> or <i>@im=SCIM.</i> (with a trailing dot) to instruct X applications to use SCIM as their input method server. This setting is usually managed by desktop environment startup scripts or tools like <I>im-config</I> rather than directly by the user.


title: HISTORY
content:
SCIM (Smart Common Input Method) was developed in the early 2000s as a powerful and flexible input method platform for Linux and other Unix-like systems, aiming to unify various language input methods under a single framework. It quickly gained widespread adoption, particularly for East Asian language support, becoming a standard component in many distributions due to its modular design which allowed for easy integration of new input engines.<br><br>However, starting in the late 2000s and early 2010s, newer projects like IBus and Fcitx emerged. These frameworks offered improved architectures, better integration with modern desktop environments (like GNOME and KDE), and addressed some of SCIM's limitations (e.g., performance, initial lack of Wayland support). Consequently, SCIM's development became less active, and it was gradually replaced as the default input method in most major Linux distributions, although it can still be manually installed on some systems.


title: SYNOPSIS
content:
<b>dcgmi</b> <i>&lt;subcommand&gt;</i> [<i>&lt;subcommand_options&gt;</i>]<br>Example: <b>dcgmi</b> <i>dmon</i> -e 100,101 -d 500<br>Example: <b>dcgmi</b> <i>health</i> -c all


title: PARAMETERS
content:
<b>discovery</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Discover and list GPUs and their properties.<br><br><b>dmon</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stream device monitoring metrics and statistics.<br><br><b>health</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check the health status of GPUs or the system.<br><br><b>diag</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run diagnostic tests on GPUs to identify issues.<br><br><b>modules</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manage DCGM policy modules and their configurations.<br><br><b>policy</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configure and view GPU performance policies (e.g., power limits).<br><br><b>config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manage GPU persistence mode and compute mode settings.<br><br><b>start</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start the DCGM service (daemon).<br><br><b>stop</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stop the DCGM service (daemon).<br><br><b>status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check the running status of the DCGM service.<br><br><b>group</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create, manage, and list GPU groups for targeted operations.<br><br><b>profile</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Monitor GPU application profiling metrics.<br><br><b>sysinfo</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display system information relevant to DCGM and GPUs.<br><br><b>field</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List available DCGM fields for monitoring and their IDs.<br><br><b>version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the DCGM library and <i>dcgmi</i> utility versions.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help information for the command or a specific subcommand.<br><br>


title: DESCRIPTION
content:
<i>dcgmi</i> is a command-line interface (CLI) tool that interacts with the NVIDIA Data Center GPU Manager (DCGM) service. It provides robust capabilities for monitoring, diagnostics, and management of NVIDIA GPUs in data center and HPC environments. <br><br>Users can leverage <i>dcgmi</i> to retrieve real-time telemetry data (like GPU utilization, memory usage, temperature, power consumption), perform health checks, run diagnostic tests, configure GPU policies, and manage GPU groupings. It is designed for system administrators, cluster managers, and developers who need programmatic access to GPU information and control over large deployments of NVIDIA GPUs, enabling proactive maintenance, performance tuning, and fault detection. <br><br>Unlike <i>nvidia-smi</i> which is typically for a single node's GPUs, <i>dcgmi</i> is built for scale, supporting agent-client architecture for remote monitoring and management across multiple nodes. It's an essential tool for maintaining the health and efficiency of GPU-accelerated clusters.


title: CAVEATS
content:
Requires NVIDIA GPUs and the NVIDIA Data Center GPU Manager (DCGM) software package to be installed and the <i>dcgm</i> service running.<br>Often requires root or <i>sudo</i> privileges to execute commands, especially for configuration changes or health checks.<br>The <i>dcgmi</i> client communicates with the <i>dcgm</i> service; ensure the service is active and accessible.<br>Understanding the various subcommands and their specific options can have a learning curve due to the tool's comprehensive nature.


title: DCGM SERVICE
content:
<i>dcgmi</i> is a client-side utility that communicates with the <i>dcgm</i> background service (daemon). The service must be running for <i>dcgmi</i> commands to function correctly. This client-server architecture allows for remote monitoring and management of GPUs across multiple nodes.


title: PROGRAMMATIC ACCESS
content:
Beyond the CLI, DCGM also offers a C API and Python bindings, allowing developers to integrate GPU monitoring and management capabilities directly into their applications and scripts for automated workflows and custom tooling.


title: HEALTH CHECKS AND DIAGNOSTICS
content:
One of <i>dcgmi</i>'s key strengths is its ability to perform comprehensive health checks and run extensive diagnostic tests (e.g., memory, compute, interconnect tests) to identify potential hardware issues proactively, minimizing downtime in critical GPU-accelerated environments.


title: HISTORY
content:
<i>dcgmi</i> is an integral part of the NVIDIA Data Center GPU Manager (DCGM) suite, which was developed by NVIDIA to address the growing needs of managing large-scale GPU deployments in data centers, high-performance computing (HPC) clusters, and AI/ML infrastructure. It was designed to provide a more robust, scalable, and programmatic interface for GPU management compared to individual node tools. Its development has focused on enabling comprehensive monitoring, diagnostic capabilities, and policy enforcement across a fleet of GPUs, facilitating automated operations and ensuring optimal cluster health and performance.


title: TLDR
content:
<b>Display information on all available GPUs and processes using them</b>`dcgmi discovery [[-l|--list]]`<br><b>List created groups</b>`dcgmi group [[-l|--list]]`<br><b>Display current usage statistics for device 0</b>`dcgmi dmon [[-e|--field-id]][1001,1002,1003,1004,1005]`<br><b>Display help</b>`dcgmi [[-h|--help]]`<br><b>Display help for a subcommand</b>`dcgmi [subcommand] [[-h|--help]]`


title: PARAMETERS
content:
<b><b>-b</b>, <b>--basename</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Match only the base name of pathnames. Do not match directories.<br><br><b><b>-c</b>, <b>--count</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instead of printing filenames, print only the number of matching entries.<br><br><b><b>-d</b> <i>PATH</i>, <b>--database=</b><i>PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a different database to search. Multiple databases can be specified, separated by <b>:</b>. If none is specified, <i>slocate</i> uses the default database (e.g., <i>/var/lib/mlocate/mlocate.db</i>).<br><br><b><b>-e</b>, <b>--existing</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only print entries that existed at the time <i>slocate</i> was run. This performs a file system check on the results from the database, which can slow down the command.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b><b>-i</b>, <b>--ignore-case</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignore case distinctions in patterns.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print error messages about inaccessible files or database issues.<br><br><b><b>-r</b>, <b>--regex</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interpret patterns as extended regular expressions (ERE).<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b><b>-w</b>, <b>--wholename</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Match the whole pathname, not just the base name. This is the default behavior.<br><br>


title: DESCRIPTION
content:
<i>slocate</i> (secure locate) is a command-line utility used to quickly find files on the filesystem by searching a pre-built database. Unlike the original <i>locate</i> command, <i>slocate</i> was designed with security in mind, ensuring that search results only include files that the executing user has permission to see. This prevents information leakage, as users cannot discover the existence of files they are not authorized to access.<br><br>The command does not scan the filesystem in real-time. Instead, it queries a database (typically updated daily by the <i>updatedb</i> command) containing a snapshot of the filesystem's contents. This approach makes <i>slocate</i> exceptionally fast for file searches, as it avoids the overhead of traversing the entire directory tree. However, a trade-off is that recently created or deleted files will not appear in search results until the database has been updated.


title: CAVEATS
content:
The primary limitation of <i>slocate</i> is its reliance on a pre-built database. This means that search results are not real-time; any files created, deleted, or moved since the last <i>updatedb</i> run will not be accurately reflected. Additionally, while <i>slocate</i> enforces user permissions during queries, the <i>updatedb</i> utility (which builds the database) typically runs as root and indexes all files, including those inaccessible to regular users. Modern Linux distributions often use <i>mlocate</i>, which is a more advanced replacement for both the original <i>locate</i> and <i>slocate</i>, incorporating security features and improved performance.


title: DATABASE LOCATION
content:
The <i>slocate</i> command typically queries a database file, most commonly found at <i>/var/lib/mlocate/mlocate.db</i> or <i>/var/lib/locate/locate.db</i>, depending on the system's specific setup.


title: DATABASE UPDATE
content:
The database used by <i>slocate</i> is generated and updated by the <i>updatedb</i> command. This command is usually run automatically at regular intervals (e.g., daily) via a cron job, often as a root user, to ensure the database remains reasonably current. Users typically do not run <i>updatedb</i> manually.


title: HISTORY
content:
The <i>locate</i> utility has a long history in Unix-like systems, providing fast file searches using an indexed database. The original <i>locate</i> program, however, presented a security concern: it would show the existence of files even if the user executing the command did not have permission to view or access them, potentially leaking sensitive information. To address this, <i>slocate</i> (secure locate) was developed, introducing access checks at query time to ensure only permissible files were displayed.<br><br>Over time, the need for a more robust and efficient solution led to the development of <i>mlocate</i> (merging locate), which effectively combined the speed of <i>locate</i> with the security features of <i>slocate</i>, alongside performance improvements for database updates and searches. As a result, <i>mlocate</i> has largely superseded <i>slocate</i> and is the standard <i>locate</i> implementation on most modern Linux distributions, often symlinked as <i>locate</i>.


title: TLDR
content:
<b>Enable quiet mode to suppress error messages</b>`slocate -q`<br><b>Limit the number of results shown</b>`slocate -n [number]`<br><b>Build an slocate database starting at path /</b>`slocate -u`<br><b>Build an slocate database starting at a given directory</b>`slocate -U [path/to/directory]`<br><b>Update an slocate database using the default /etc/updatedb.conf configuration</b>`slocate -c`<br><b>Set the security level of slocate, with 0 being disabled, and 1 being secure</b>`slocate -l [0|1]`<br><b>Specify the database that slocate should search in</b>`slocate [[-d|--database]] [path/to/directory]`<br><b>Search the slocate database using a specific regex string</b>`slocate [[-r|--regexp]] [regex]`


title: SYNOPSIS
content:
manim [<i>OPTIONS</i>] <i>FILE</i> [<i>SCENE_NAMES</i>...]<br><br><i>FILE</i>: The path to the Python script containing Manim scene definitions.<br>[<i>SCENE_NAMES</i>...]: Optional. One or more names of specific Manim scene classes to render from the file. If omitted, all scenes marked for rendering will be processed.


title: PARAMETERS
content:
<b><b>-p</b>, <b>--preview</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Renders the scene and automatically opens the output video file upon completion.<br><br><b><b>-ql</b>, <b>--low_quality</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Renders in low quality (e.g., 480p, 15fps) for quick previews.<br><br><b><b>-qm</b>, <b>--medium_quality</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Renders in medium quality (e.g., 720p, 30fps).<br><br><b><b>-qh</b>, <b>--high_quality</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Renders in high quality (e.g., 1080p, 60fps).<br><br><b><b>-s</b>, <b>--save_last_frame</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves only the last frame of the animation as an image.<br><br><b><b>-o</b>, <b>--open</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the output file(s) after rendering is complete.<br><br><b><b>-r</b> <i>WIDTH</i>x<i>HEIGHT</i>, <b>--resolution</b> <i>WIDTH</i>x<i>HEIGHT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the custom output resolution for the video (e.g., 1920x1080).<br><br><b><b>--transparent</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Renders the animation with a transparent background (requires specific output formats like .webm).<br><br><b><b>--config_file</b> <i>PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file to use for Manim settings.<br><br><b><b>--log_level</b> <i>LEVEL</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls the verbosity of log messages (e.g., <i>DEBUG</i>, <i>INFO</i>, <i>WARNING</i>, <i>ERROR</i>, <i>CRITICAL</i>).<br><br><b><b>--force_output</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overwrites existing output files without prompting for confirmation.<br><br>


title: DESCRIPTION
content:
Manim is a free and open-source Python library used to create high-quality animations for educational videos, primarily focused on mathematical visualizations. It allows users to define scenes and objects programmatically, then renders them into video files. Its programmatic nature provides precise control over object transformations, timing, and aesthetics, making it popular for explaining complex mathematical or scientific concepts visually. It leverages Python for scripting and relies on tools like FFmpeg for video processing and LaTeX for rendering mathematical equations.


title: CAVEATS
content:
Manim requires a Python environment and several external dependencies, including FFmpeg for video processing and a LaTeX distribution for mathematical typesetting, which must be installed separately. The learning curve can be steep for users unfamiliar with Python programming and object-oriented concepts. Rendering complex or long animations can be computationally intensive and time-consuming, requiring significant system resources.


title: TYPICAL USAGE EXAMPLE
content:
To render a scene named <i>MyScene</i> from a file named <i>my_animations.py</i> and preview it in high quality, you would typically run: <br><i>manim -ph my_animations.py MyScene</i>


title: CUSTOMIZATION
content:
Manim's behavior can be extensively customized through configuration files (typically <i>manim.cfg</i>) or command-line arguments, allowing fine-tuning of rendering quality, output directory paths, and default animation settings.


title: HISTORY
content:
Manim was initially developed by <i>Grant Sanderson</i> for his highly acclaimed YouTube channel, <i>3Blue1Brown</i>, to create stunning mathematical visualizations. The original version was a private tool. Later, the <i>Manim Community Edition</i> was forked and open-sourced, transforming it into the widely adopted and actively maintained library it is today, driven by a dedicated community of developers.


title: TLDR
content:
<b>Render a scene from a Python script using the default settings</b>`manim [path/to/file.py] [SceneName]`<br><b>Render with live preview (auto-opens the video file after rendering)</b>`manim [[-pql|--preview --quality low]] [path/to/file.py] [SceneName]`<br><b>Render at high quality (1080p 60fps)</b>`manim [[-pqh|--preview --quality high]] [path/to/file.py] [SceneName]`<br><b>Specify a custom output file name</b>`manim [[-o|--output_file]] [output_file_name] [path/to/file.py] [SceneName]`<br><b>Render using a specific resolution and frame rate</b>`manim [[-r|--resolution]] [1920,1080] [[-f|--fps]] [60] [path/to/file.py] [SceneName]`<br><b>List available scenes in a file without rendering</b>`manim --list_scenes [path/to/file.py]`<br><b>Display help</b>`manim --help`


title: SYNOPSIS
content:
<b>gitea</b> [<i>global options</i>] <i>command</i> [<i>command options</i>] [<i>arguments...</i>]<br>Example: <b>gitea web --config /etc/gitea/app.ini</b>


title: PARAMETERS
content:
<b>web</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the Gitea web server. This is the primary command to run Gitea as a service.<br><br><b>migrate</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs database schema or data migrations. Essential after upgrading Gitea to a new version.<br><br><b>admin</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides various administrative functionalities, such as creating new users, changing passwords, or managing repositories.<br><br><b>doctor</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a health check on the Gitea instance, verifying database, configuration, and other critical components.<br><br><b>keys</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages SSH and GPG keys associated with users and repositories within Gitea.<br><br><b>cert</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages SSL certificates for the Gitea instance, primarily for self-signed certificates.<br><br><b>dump</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a backup dump of the Gitea data, including the database, repositories, and attachments.<br><br><b>restore</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restores a Gitea instance from a previously created dump file.<br><br><b>help [command]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the <b>gitea</b> command or a specific subcommand.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the current Gitea version and exits.<br><br><b>--config &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Global option)</i> Specifies the path to the Gitea configuration file (usually <b>app.ini</b>).<br><br><b>--custom-path &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Global option)</i> Specifies the path to custom files such as templates, options, or static assets.<br><br>


title: DESCRIPTION
content:
<i>Gitea</i> is a community-managed, lightweight, and fast-growing open-source code hosting solution written in Go. The <b>gitea</b> command-line interface provides tools to manage and interact with a <i>Gitea</i> instance. This includes starting the web server, performing database migrations, managing administrative tasks like creating users or repositories, checking system health, and various other utilities. It's designed to be a self-contained binary, making deployment simple and efficient. It supports various databases like SQLite, MySQL, PostgreSQL, and MSSQL, and runs on multiple platforms, offering a robust and easy-to-maintain alternative to larger Git platforms for personal or small to medium-sized team use. Its ease of installation and low resource footprint make it a popular choice for self-hosting.


title: CAVEATS
content:
Requires proper configuration in its <b>app.ini</b> file for full functionality and security, especially regarding database connections and server settings.<br>Running <b>gitea web</b> directly in the foreground is generally not recommended for production environments; it should typically be managed by a service manager like <i>systemd</i>.<br>Correct file system and database permissions are crucial for Gitea's operation, as misconfigurations can lead to data loss or security vulnerabilities.


title: CONFIGURATION
content:
<i>Gitea's</i> behavior is primarily controlled by its <b>app.ini</b> configuration file. This file specifies crucial settings such as database connections, repository root paths, server listen addresses, authentication options, and various feature toggles. Understanding and properly configuring this file is essential for a secure, performant, and functional <i>Gitea</i> instance. The command-line options often allow overriding or specifying the location of this file.


title: DEPLOYMENT CONSIDERATIONS
content:
While <b>gitea web</b> starts the server, for production environments, it is highly recommended to deploy <i>Gitea</i> as a system service (e.g., using <i>systemd</i> for automatic startup and management) and to place it behind a reverse proxy like <i>Nginx</i> or <i>Apache</i>. A reverse proxy handles SSL termination, allows for hosting multiple web services on the same port, and can provide additional security features.


title: EXTENSIBILITY AND API
content:
<i>Gitea</i> is highly extensible, supporting webhooks for integration with CI/CD pipelines and other external services. It also offers comprehensive support for OAuth2 authentication and provides a rich RESTful API, allowing programmatic interaction with its features for automation and custom integrations.


title: HISTORY
content:
<i>Gitea</i> was forked from <i>Gogs</i> (Go Git Service) in late 2016 due to disagreements within the <i>Gogs</i> community regarding its development model and responsiveness. The <i>Gitea</i> project aimed for a more community-driven and transparent development process. Since its inception, <i>Gitea</i> has rapidly gained popularity as a lightweight, self-hostable alternative to larger Git platforms like <i>GitLab</i> and <i>GitHub</i>, focusing on ease of use, low resource consumption, and a robust feature set, making it suitable for personal projects, small teams, and even larger organizations looking for a self-managed Git solution.


title: TLDR
content:
<b>Run the Gitea web server using the default configuration</b>`gitea web`<br><b>Create the necessary database schema and tables</b>`gitea migrate`<br><b>Run administrative subcommands for user management or authentication management</b>`gitea admin [user list]`<br><b>Display help for a specific subcommand</b>`gitea [admin] --help`<br><b>Display help</b>`gitea help`<br><b>Display version</b>`gitea --version`


title: SYNOPSIS
content:
<code>openrgb [<i>OPTIONS</i>]</code><br>When executed without options, <b>openrgb</b> typically launches its graphical user interface. Various options allow for server mode operation, specific profile loading, or debugging.<br><i>Example:</i> <code>openrgb --start-server --no-gui</code>


title: PARAMETERS
content:
<b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays a comprehensive help message</i> showing all available command-line options and their usage.<br><br><b>--version, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Prints the current version information</i> of the <b>OpenRGB</b> application.<br><br><b>--start-server</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Initiates the <b>OpenRGB</b> server</i>, enabling other applications or clients to connect and control devices via the SDK.<br><br><b>--server-port <port></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the TCP port</i> on which the <b>OpenRGB</b> server will listen for incoming connections. Default is usually 6742.<br><br><b>--no-gui</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Runs <b>OpenRGB</b> in a server-only mode</i> without launching the graphical user interface. Useful for headless systems or background services.<br><br><b>--no-detection</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Prevents <b>OpenRGB</b> from automatically detecting devices</i> on startup. Device detection can then be triggered manually or via SDK.<br><br><b>--profile <profile_name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Loads a specific lighting profile</i> named <i>&lt;profile_name&gt;</i> upon application startup.<br><br><b>--verbose, -V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Increases the verbosity of logging output</i>, providing more detailed information for debugging purposes.<br><br><b>--daemon</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Starts <b>OpenRGB</b> as a daemon</i> (background process), typically combining `--start-server` and `--no-gui` behavior.<br><br>


title: DESCRIPTION
content:
<b>OpenRGB</b> is a free and open-source software suite designed to unify control of <b>RGB</b> lighting across various hardware components from different manufacturers. It eliminates the need for multiple, often proprietary, vendor-specific applications by providing a single, cross-platform solution. Users can manage <b>RGB</b> on motherboards, RAM modules, graphics cards, keyboards, mice, and other peripherals. The software achieves this by reverse-engineering proprietary lighting protocols.<br><br>While primarily known for its graphical user interface (GUI), <b>OpenRGB</b> also features a powerful SDK (Software Development Kit) for third-party application integration and can be controlled via a command-line interface (CLI) or run as a server for remote access. It supports custom profiles, various lighting effects, and synchronization across all detected devices, aiming to provide a seamless and cohesive lighting experience for your entire system.


title: CAVEATS
content:
<ul><li><b>Root Privileges:</b> <b>OpenRGB</b> often requires root or `sudo` privileges, or proper `udev` rules, to access and control hardware devices directly. Running it without sufficient permissions may lead to device detection failures or inability to apply settings.</li><li><b>Hardware Compatibility:</b> While aiming for broad support, not all <b>RGB</b> devices are fully compatible. Some devices may have limited functionality or require specific drivers/firmware.</li><li><b>Potential Conflicts:</b> Running <b>OpenRGB</b> alongside vendor-specific <b>RGB</b> software (e.g., ASUS Aura Sync, Corsair iCUE, Razer Synapse) can lead to conflicts, unexpected behavior, or device control issues. It's generally recommended to disable or uninstall proprietary software when using <b>OpenRGB</b>.</li><li><b>Device Damage Risk:</b> Although highly unlikely with proper usage, manipulating hardware at a low level carries inherent risks. Always ensure you are using a stable version and understand the implications of changing settings.</li></ul>


title: <I>SDK AND API INTEGRATION</I>
content:
<b>OpenRGB</b> provides a powerful Software Development Kit (SDK) and a network-based API, allowing third-party applications to interact with and control <b>RGB</b> devices. This enables developers to create custom lighting effects, synchronize lighting with games or media, or integrate <b>RGB</b> control into broader system monitoring tools. This feature is particularly useful for modders, game developers, or anyone looking to automate their lighting setup.


title: <I>UDEV RULES FOR PERMISSIONS</I>
content:
For <b>OpenRGB</b> to access and control hardware devices without requiring constant `sudo` elevation, it's often necessary to set up specific `udev` rules. These rules grant non-root users the necessary permissions to interface with USB and other bus devices that control <b>RGB</b> lighting. This is a crucial step for a smooth user experience on Linux distributions.


title: HISTORY
content:
<b>OpenRGB</b> was initiated by <i>Adam Honse</i> in late 2019 / early 2020. Its primary motivation was to address the fragmentation and proprietary nature of <b>RGB</b> lighting control software in the PC hardware ecosystem. Frustrated by the need for multiple applications to control different components, Honse began reverse-engineering existing protocols.<br><br>The project rapidly gained traction within the open-source community, attracting numerous contributors who have helped expand its hardware compatibility through dedicated reverse-engineering efforts and driver development. This community-driven approach has been central to its evolution into a robust, cross-vendor solution.


title: TLDR
content:
<b>Start the OpenRGB GUI</b>`openrgb`<br><b>List devices supported by OpenRGB</b>`openrgb --noautoconnect [[-l|--list-devices]]`<br><b>Set the mode and color of a device</b>`openrgb [[-m|--mode]] [off|static|breathing|rainbow|flashing|...] [[-c|--color]] [random|red|00AAFF|...]`<br><b>Display help</b>`openrgb [[-h|--help]]`


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message for the main command or a specific subcommand, providing usage details and available options.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the version number of the installed <i>gemini</i> tool.<br><br><b><b>load</b> <I>options</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Options specific to the <i>load</i> subcommand, used for importing VCF data and other annotations into a <i>gemini</i> database. Examples include <i>--anno-dir</i> to specify annotation directories, or <i>--cores</i> for parallel processing during data loading.<br><br><b><b>query</b> <I>options</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Options specific to the <i>query</i> subcommand, used for retrieving and filtering data from an existing <i>gemini</i> database. Key options include <i>-q "SELECT ..."</i> for the SQL query string, <i>--gt-filter</i> for genotype-based filtering, and <i>--column</i> to specify output columns.<br><br><b><b>annotate</b> <I>options</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Options specific to the <i>annotate</i> subcommand, used for adding external annotation sources (e.g., dbSNP, ClinVar, ExAC) to a <i>gemini</i> database. Examples include <i>--columns</i> to specify annotation sources, <i>--a-dbsnp</i> to add dbSNP annotations, or <i>--a-clinvar</i> for ClinVar annotations.<br><br>


title: DESCRIPTION
content:
The `gemini` command-line tool, specifically referring to the <b>G</b><I>Enome</I> <b>M</b><I>INing</I> platform, is a powerful and flexible utility designed for the analysis and interpretation of genomic variation data. It allows researchers to load and store genetic variant information, typically from VCF (Variant Call Format) files, into a highly indexed SQLite database.<br><br>Once loaded, `gemini` enables efficient and complex SQL-like queries against this data, facilitating tasks such as variant filtering based on population frequencies, functional annotations, inheritance patterns, and integration with phenotypic data. It simplifies the process of identifying disease-causing variants and exploring large-scale genomic datasets.


title: CAVEATS
content:
The `gemini` command is <b>not</b> a standard, pre-installed Linux utility. It refers to a specialized bioinformatics software package (GEMINI - GEnome MINIng) that requires explicit installation, typically via Python's package manager (`pip`) or Conda. Its usage is highly specific to genomic data analysis and is not intended for general system administration or common command-line tasks. Users must also manage substantial input data (VCF files, reference genomes, annotation databases) for its effective use.


title: SUBCOMMAND DRIVEN ARCHITECTURE
content:
Similar to popular version control systems like `git` or package managers like `apt`, `gemini` operates primarily through a series of distinct subcommands (e.g., <i>load</i>, <i>query</i>, <i>annotate</i>, <i>stats</i>, <i>comp_hets</i>, <i>autosomal_recessive</i>). Each subcommand performs a specific, specialized function in the variant analysis pipeline, and comes with its own set of dedicated options and arguments.


title: SQLITE DATABASE INTEGRATION
content:
A core design principle and powerful feature of <i>gemini</i> is its reliance on SQLite. All genomic variant data, along with extensive associated annotations, are loaded and stored within a single, portable SQLite database file. This architecture allows for rapid, flexible, and complex SQL-based queries, enabling highly intricate filtering and data extraction that would be challenging or inefficient with traditional flat file formats.


title: HISTORY
content:
The GEMINI (GEnome MINIng) project was initiated by Aaron Quinlan's lab at the University of Utah, with significant development contributions from others in the bioinformatics community. It was conceived to address the growing challenges of efficiently querying, filtering, and prioritizing variants from large-scale next-generation sequencing data. The first stable versions of the software emerged around 2013-2014, providing a novel database-centric approach to variant analysis, contrasting with earlier file-based methods, and quickly gaining traction in the genomics research community.


title: TLDR
content:
<b>Start a REPL session to chat interactively</b>`gemini`<br><b>Send the output of another command to Gemini and exit immediately</b>`[echo "Summarize the history of Rome"] | gemini [[-p|--prompt]]`<br><b>Override the default model (default: gemini-2.5-pro)</b>`gemini [[-m|--model]] [gemini-2.5-flash]`<br><b>Run inside a sandbox container</b>`gemini [[-s|--sandbox]]`<br><b>Execute a prompt then stay in interactive mode</b>`gemini [[-i|--prompt-interactive]] "[Give me an example of recursion in Python]"`<br><b>Include all files in context</b>`gemini [[-a|--all-files]]`<br><b>Show memory usage in status bar</b>`gemini --show-memory-usage`


title: SYNOPSIS
content:
PaperMC is a Java application and is not a native Linux command. It is executed via the Java Virtual Machine.<br><br><b><I>java -Xmx&lt;memory&gt;G -jar paper.jar [server_arguments...]</I></b><br><br>Where:<br><I><b>&lt;memory&gt;</b></I>: The maximum amount of RAM (e.g., 2, 4, 8) in gigabytes to allocate to the server. Use 'M' for megabytes.<br><I><b>paper.jar</b></I>: The actual filename of your downloaded PaperMC JAR file (e.g., <I>paper-1.20.4-500.jar</I>).<br><I><b>[server_arguments...]</b></I>: Optional arguments passed directly to the Minecraft server (e.g., <I>--nogui</I>, <I>--world</I>).


title: PARAMETERS
content:
<b><I><b>-Xmx&lt;size&gt;</b></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum heap size for the JVM. Essential for allocating sufficient RAM to the Minecraft server (e.g., <I>-Xmx4G</I> for 4 Gigabytes).<br><br><b><I><b>-Xms&lt;size&gt;</b></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the initial heap size for the JVM. Often set to the same value as <I>-Xmx</I> for consistent performance (e.g., <I>-Xms4G</I>).<br><br><b><I><b>-jar &lt;filename&gt;</b></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the JAR file to be executed (e.g., <I>paper.jar</I>).<br><br><b><I><b>--nogui</b></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Minecraft server argument) Prevents the server from launching a graphical user interface (GUI) window, which is standard for headless Linux server environments.<br><br><b><I><b>--world &lt;world_name&gt;</b></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Minecraft server argument) Specifies the name of the world folder to load if different from the default "world".<br><br><b><I><b>--port &lt;port_number&gt;</b></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Minecraft server argument) Sets the network port the server will listen on (default is 25565).<br><br><b><I><b>-DIpaper.nogui=true</b></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(JVM property) Can be used to prevent the GUI from launching, similar to <I>--nogui</I>.<br><br>


title: DESCRIPTION
content:
PaperMC is a highly optimized, open-source Minecraft server fork based on Spigot and CraftBukkit. It aims to significantly improve server performance, stability, and provide additional features not available in vanilla Minecraft or its predecessors. While not a standalone Linux command, PaperMC is executed as a Java Archive (JAR) file using the Java Virtual Machine (JVM). Server administrators typically download the <I>paper.jar</I> file and run it using the <I>java -jar</I> command, specifying memory allocation and other JVM arguments. It's widely used for hosting large-scale Minecraft servers due to its efficiency and extensive configuration options, making it a popular choice for enhancing the multiplayer experience.


title: CAVEATS
content:
<I><b>Java Runtime Environment (JRE) Required</b></I>: PaperMC requires a compatible Java JRE or JDK to be installed on the system (typically Java 17 or newer for recent Minecraft versions).<br><I><b>Not a Native Command</b></I>: PaperMC is a Java application, not a standalone Linux executable. It is run using the <I>java</I> command.<br><I><b>Memory Allocation</b></I>: Proper memory allocation using <I>-Xmx</I> is crucial for server performance and stability; insufficient RAM will lead to crashes or lag.<br><I><b>EULA Agreement</b></I>: Upon first execution, Minecraft servers (including PaperMC) require acceptance of the Minecraft End User License Agreement (EULA). This creates an <I>eula.txt</I> file that must be manually changed from <I>eula=false</I> to <I>eula=true</I>.<br><I><b>Resource Intensive</b></I>: Running a Minecraft server, especially with many players or complex plugins, can be resource-intensive, requiring adequate CPU, RAM, and disk I/O.


title: <I>FIRST RUN AND EULA ACCEPTANCE</I>
content:
The first time you attempt to run a PaperMC server, it will generate several configuration files and an <I>eula.txt</I> file. The server will not fully start until you open <I>eula.txt</I> and change the line <I>eula=false</I> to <I>eula=true</I>, signifying your agreement to Minecraft's End User License Agreement.


title: <I>OPTIMAL MEMORY ALLOCATION</I>
content:
It's crucial to allocate sufficient but not excessive memory to your PaperMC server using the <I>-Xmx</I> and <I>-Xms</I> JVM arguments. Allocating too little memory will result in lag and crashes, while allocating too much can lead to inefficient garbage collection and potential performance issues or "swap thrashing" if it exceeds physical RAM. A good starting point for a small server might be <I>-Xmx2G</I> to <I>-Xmx4G</I>.


title: <I>UPDATING PAPERMC</I>
content:
To update your PaperMC server, you typically download the latest <I>paper.jar</I> file from the official PaperMC website and replace the old one. It's recommended to stop the server before replacing the JAR and to back up your server files regularly. Configuration files like <I>server.properties</I> and <I>paper.yml</I> are usually preserved across updates.


title: HISTORY
content:
PaperMC originated as a fork of the Spigot Minecraft server software, which itself was built upon CraftBukkit. The project began with a strong focus on optimizing server performance, specifically addressing issues like tick lag and general server overhead common in large-scale Minecraft deployments. Over time, PaperMC introduced numerous significant architectural changes and new features, establishing itself as a leading server software due to its superior efficiency, stability, and extensive configuration options compared to its predecessors. Its development continues to be community-driven, adapting rapidly to new Minecraft versions and community needs.


title: TLDR
content:
<b>Start a server</b>`papermc start`<br><b>Stop a server</b>`papermc stop`<br><b>Restart a server</b>`papermc restart`<br><b>Backup a world</b>`papermc backup`<br><b>Restore world data from a backup</b>`papermc restore [path/to/file]`<br><b>Display help</b>`papermc`


title: SYNOPSIS
content:
<b>elasticsearch-croneval</b> <i>&lt;cron_expression&gt;</i> [<b>--timezone</b> <i>&lt;timezone_id&gt;</i>] [<b>--count</b> <i>&lt;number&gt;</i>]<br>or<br><b>elasticsearch-croneval</b> <i>&lt;cron_expression&gt;</i> [<b>-t</b> <i>&lt;timezone_id&gt;</i>] [<b>-n</b> <i>&lt;number&gt;</i>]


title: PARAMETERS
content:
<b><i>&lt;cron_expression&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The cron string to be evaluated. This must be the first argument and should follow the Elasticsearch cron expression format.<br><br><b><b>--timezone</b> <i>&lt;timezone_id&gt;</i>, <b>-t</b> <i>&lt;timezone_id&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the timezone for evaluating the cron expression. This should be a valid Java TimeZone ID (e.g., 'America/Los_Angeles', 'Europe/Berlin', 'UTC'). If omitted, the server's default timezone is used.<br><br><b><b>--count</b> <i>&lt;number&gt;</i>, <b>-n</b> <i>&lt;number&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the number of future execution times to display. If omitted, the command typically defaults to showing a small number of upcoming times (e.g., 10).<br><br>


title: DESCRIPTION
content:
The <b>elasticsearch-croneval</b> command is a utility provided with Elasticsearch, primarily used to evaluate and validate cron expressions that are understood by Elasticsearch's Watcher feature and other scheduling components. It allows users to test and debug their cron strings without needing to deploy or activate a Watcher, providing a list of upcoming execution times based on the given expression. This is invaluable for ensuring that scheduled tasks, such as alerting or data transformations, will run precisely when intended. The command helps in confirming the syntax and behavior of cron expressions, especially when dealing with specific timezones or complex schedules. It's a key tool for developers and administrators working with time-based automation within the Elasticsearch ecosystem.


title: CAVEATS
content:
The <b>elasticsearch-croneval</b> command requires a Java Runtime Environment (JRE) to be installed and configured, as it is a Java-based utility. It must be run from the Elasticsearch installation's <code>bin/</code> directory or have the necessary environment variables set to locate its dependencies. The command evaluates expressions based on the current system time, which might differ from the time on remote Elasticsearch nodes if not explicitly aligned or compensated for with the <code>--timezone</code> option.


title: ELASTICSEARCH CRON EXPRESSION FORMAT
content:
Elasticsearch's cron expression format is similar to the standard Unix cron but with some key differences and extensions, particularly for specifying seconds, years, and different kinds of wildcards. It typically consists of 6 or 7 fields:<br><code>seconds minutes hours day_of_month month day_of_week [year]</code><br>Supported special characters include: <code>*</code> (all values), <code>?</code> (no specific value for day of month/week), <code>-</code> (range), <code>,</code> (list), <code>/</code> (increment), <code>L</code> (last), <code>W</code> (weekday nearest day), <code>#</code> (nth day of week). For precise details, refer to the official Elasticsearch Watcher documentation on cron schedules.


title: HISTORY
content:
The <b>elasticsearch-croneval</b> utility was introduced as part of the X-Pack extension for Elasticsearch, specifically to support and debug the cron-based scheduling capabilities of the Watcher feature. Watcher, which allows users to create alerts and automate tasks based on data in Elasticsearch, heavily relies on cron expressions for its scheduling. Over time, as X-Pack features became more integrated into the core Elasticsearch distributions, <b>elasticsearch-croneval</b> transitioned to being a standard utility bundled with Elasticsearch, accessible in the <code>bin/</code> directory for convenient command-line validation of cron schedules.


title: TLDR
content:
<b>Evaluate a cron expression and display the next 10 trigger times (default behavior)</b>`elasticsearch-croneval "[cron_expression]"`<br><b>Evaluate a cron expression and display a specific number of future trigger times</b>`elasticsearch-croneval "[cron_expression]" [[-c|--count]] [integer]`<br><b>Display detailed information (including stack trace) for an invalid cron expression</b>`elasticsearch-croneval "[invalid_cron_expression]" [[-d|--detail]]`<br><b>Display minimal output (silent mode)</b>`elasticsearch-croneval "[cron_expression]" [[-s|--silent]]`<br><b>Display verbose output</b>`elasticsearch-croneval "[cron_expression]" [[-v|--verbose]]`


title: TLDR
content:
<b>Start dnsmasq with default configuration</b>`dnsmasq`<br><b>Run dnsmasq in the foreground (for debugging)</b>`dnsmasq --no-daemon`<br><b>Specify a custom configuration file</b>`dnsmasq --conf-file=[path/to/config.conf]`<br><b>Enable verbose logging</b>`dnsmasq --log-queries --log-facility=-`<br><b>Set a DHCP range and lease time</b>`dnsmasq --dhcp-range=[192.168.0.50,192.168.0.150,12h]`<br><b>Print dnsmasq version</b>`dnsmasq --version`


title: SYNOPSIS
content:
<b>dmypy</b> [<i>GLOBAL_OPTIONS</i>] <i>COMMAND</i> [<i>COMMAND_OPTIONS</i>] [<i>FILES...</i>]<br><br><b>Commands:</b><br>&nbsp;&nbsp;<b>dmypy run</b> [<i>MYPY_OPTIONS</i>] [<i>FILES...</i>]<br>&nbsp;&nbsp;<b>dmypy status</b><br>&nbsp;&nbsp;<b>dmypy stop</b><br>&nbsp;&nbsp;<b>dmypy restart</b><br>&nbsp;&nbsp;<b>dmypy kill</b><br>&nbsp;&nbsp;<b>dmypy recheck</b> [<i>FILES...</i>]<br>&nbsp;&nbsp;<b>dmypy check</b> [<i>FILES...</i>]<br>&nbsp;&nbsp;<b>dmypy configure</b> [<i>MYPY_OPTIONS</i>]


title: PARAMETERS
content:
<b><b>--log-file</b> <i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a file to write daemon logs to. By default, logs go to stderr or a temporary file.<br><br><b><b>--log-level</b> <i>LEVEL</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the log level for the daemon. Common levels include <i>info</i>, <i>debug</i>, <i>warning</i>, <i>error</i>.<br><br><b><b>--unix-socket</b> <i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the path to the Unix socket for inter-process communication. Overrides the default location (usually in /tmp).<br><br><b><b>--tcp-port</b> <i>PORT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a TCP port for communication instead of a Unix socket. Useful for remote access or containerized environments.<br><br><b><b>--pid-file</b> <i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a file to write the daemon's process ID (PID) to. Useful for process management.<br><br><b><b>--skip-fine-grained</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skip fine-grained dependency tracking. This can sometimes improve performance at the cost of less precise invalidation.<br><br><b><b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose logging output from the daemon.<br><br><b><b>--timeout</b> <i>SECONDS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a timeout for client commands (e.g., <I>run</I>, <I>status</I>) to connect to the daemon. Default is 5 seconds.<br><br><b><b>run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts a <I>mypy</I> daemon (if not running) and then performs a type check using the provided <I>MYPY_OPTIONS</I> and <I>FILES</I>. This is the most commonly used command.<br><br><b><b>status</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks and reports the status of the <I>dmypy</I> daemon (running, not running, etc.).<br><br><b><b>stop</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Gracefully stops the running <I>dmypy</I> daemon.<br><br><b><b>restart</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops the daemon if running, then starts it again. Useful for applying configuration changes or clearing state.<br><br><b><b>kill</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forcefully terminates the <I>dmypy</I> daemon process.<br><br><b><b>recheck</b> [<i>FILES...</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs the daemon to re-check specific files or all files if none are specified. This command often implies that the daemon has already loaded the project.<br><br><b><b>check</b> [<i>FILES...</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Similar to <I>run</I>, but typically assumes the daemon is already running and configured. It performs a type check and reports errors.<br><br><b><b>configure</b> [<i>MYPY_OPTIONS</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies new <I>mypy</I> configuration options to the running daemon without restarting it. These options will be used for subsequent <I>run</I> or <I>check</I> commands.<br><br><b><b>--update</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Used with <I>run</I>) Only re-check files that have changed since the last run. This is part of <I>mypy</I>'s incremental checking capabilities.<br><br>


title: DESCRIPTION
content:
<i>dmypy</i> is a client-server daemon for <I>mypy</I>, the static type checker for Python. Its primary purpose is to significantly speed up incremental type checking by keeping a <I>mypy</I> instance and the Python program's type information in memory across multiple runs. Instead of restarting <I>mypy</I> and reloading all source files for every check, <I>dmypy</I> maintains the necessary state, allowing for much quicker re-checks, especially during development cycles where small changes are made frequently. When a <I>dmypy</I> client command is executed, it communicates with the running <I>dmypy</I> daemon (server) to initiate a type-checking run, obtain the status, or control the daemon's lifecycle. This persistent memory state drastically reduces overhead, making type checking a more integrated and less disruptive part of the development workflow. It's particularly beneficial for large codebases where full <I>mypy</I> runs can be time-consuming.<br><br>The daemon can be configured to use either a Unix socket (default) or a TCP port for communication.


title: CAVEATS
content:
While <i>dmypy</i> significantly speeds up type checking for incremental changes, the initial full run can still take time. It also consumes system resources (memory and CPU) as long as the daemon is running. Ensuring the daemon is stopped when not needed, or restarting it periodically for a clean state, can be beneficial. Compatibility issues with specific <I>mypy</I> versions or project configurations might arise, requiring restarts or debugging through log files. File system events are typically used to detect changes, but in some environments (e.g., network mounts), this detection might not be instantaneous or reliable.


title: CONFIGURATION AND PROJECT SETUP
content:
<i>dmypy</i> inherits its configuration from your <I>mypy</I> setup (e.g., <I>pyproject.toml</I>, <I>mypy.ini</I>). When you run <i>dmypy</i>, it typically looks for a <I>.dmypy.json</I> file in the current directory or parent directories to determine its operating parameters like socket paths. It's crucial that the daemon is started in the root directory of your project or configured to correctly locate your project's <I>mypy</I> configuration.


title: DAEMON LIFECYCLE
content:
Managing the <i>dmypy</i> daemon's lifecycle is key to its effective use. You typically start it implicitly with <b>dmypy run</b> for the first time or explicitly with <b>dmypy start</b> (though less common in direct usage). The <b>dmypy stop</b> and <b>dmypy restart</b> commands are essential for resetting its state or applying new global configurations. In CI/CD pipelines or automated environments, ensuring the daemon is properly shut down is important to prevent orphaned processes.


title: HISTORY
content:
<I>dmypy</I> emerged as a solution to address the performance bottlenecks of <I>mypy</I> in large Python codebases. As static type checking became more prevalent in the Python ecosystem, the time taken for full <I>mypy</I> runs became a significant concern for developers' inner loops. Inspired by similar daemonized type checkers in other languages (e.g., TypeScript's `tsc --watch`), <I>dmypy</I> was developed as part of the <I>mypy</I> project itself to provide a persistent process that could maintain the type analysis state in memory. This allows subsequent checks to only re-analyze changed files and their dependencies, drastically reducing execution time. Its development has been driven by the need for more efficient developer workflows, making static analysis a less intrusive and more integrated part of continuous development.


title: TLDR
content:
<b>Type check a file, and start the daemon if it is not running</b>`dmypy check -- [path/to/file.py]`<br><b>Start the daemon</b>`dmypy start`<br><b>Type check a file (requires the daemon to be running)</b>`dmypy run -- [path/to/file.py]`<br><b>Stop the daemon</b>`dmypy stop`


title: SYNOPSIS
content:
<b>immich-cli</b> [<i>global-options</i>] &lt;<i>command</i>&gt; [<i>command-options</i>] [<i>arguments</i>]


title: PARAMETERS
content:
<b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the command or a specific subcommand, detailing available options and usage.<br><br><b><b>--version</b>, <b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the current version of the Immich CLI tool.<br><br><b><b>--host</b> <i>&lt;hostname_or_ip&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the hostname or IP address of the Immich server to connect to. This overrides any configured host.<br><br><b><b>--port</b> <i>&lt;port_number&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the port number of the Immich server. This overrides any configured port.<br><br><b><b>--api-key</b> <i>&lt;key&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides an API key for authentication, bypassing interactive login for script-based operations.<br><br><b><b>login</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Authenticates the CLI with an Immich server, typically by prompting for username and password to obtain session tokens.<br><br><b><b>upload</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uploads photos and videos from local directories to the Immich server. This is one of the most frequently used subcommands and has its own specific options (e.g., <i>--recursive</i>, <i>--album</i>).<br><br><b><b>config</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages the CLI's configuration, such as setting default server connections or clearing cached credentials.<br><br><b><b>asset</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interacts with individual assets (photos/videos) on the server, allowing operations like listing, deleting, or viewing details.<br><br><b><b>user</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages user accounts on the Immich server. This subcommand typically requires administrative privileges on the Immich server.<br><br>


title: DESCRIPTION
content:
Immich is a high-performance, self-hosted backup solution for photos and videos, designed to be an open-source alternative to Google Photos. The <b>immich-cli</b> command-line interface provides a convenient way to interact with an Immich server from a Linux environment.<br><br>It allows users to perform various tasks such as uploading media, managing server configurations, authenticating with the server, and interacting with user accounts and assets. This tool is essential for scripting automated backups, managing large media collections, or integrating Immich into existing workflows. It emphasizes privacy, user control, and robust media management capabilities, making it a popular choice for individuals seeking to self-host their digital memories. The CLI complements the web interface, offering programmatic access to server functionalities without needing direct database or file system access on the server.


title: CAVEATS
content:
The <b>immich-cli</b> tool requires a running Immich server to connect to. Most operations necessitate prior authentication (via <b>login</b> or <b>--api-key</b>).<br>The available subcommands and their specific options are actively developed and may change between versions; always refer to the specific version's help documentation.<br>This CLI is for interacting with the server's API, not for managing the server's underlying services (e.g., Docker containers).


title: INSTALLATION
content:
The <b>immich-cli</b> tool is typically installed via <b>npm</b> (Node Package Manager), <b>yarn</b>, or by downloading pre-compiled binaries for various operating systems from the official Immich GitHub releases page. It is not usually found in standard Linux distribution repositories.


title: AUTHENTICATION FLOW
content:
When using the <b>login</b> subcommand, <b>immich-cli</b> will guide you through entering your server URL and user credentials. Upon successful login, it stores authentication tokens locally, allowing subsequent commands to be executed without re-entering credentials until the tokens expire or are revoked.


title: HISTORY
content:
Immich is a relatively modern open-source project, with its initial public releases gaining significant traction around 2021-2022. The <b>immich-cli</b> tool was developed as a crucial companion to the main Immich server application, providing command-line capabilities for users and developers to automate tasks, script backups, and interact with the server's API without relying solely on the web interface. Its development closely follows the main Immich project's roadmap, adapting to new features and API changes, and it is a testament to Immich's commitment to providing flexible self-hosting solutions.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows version information and exits.<br><br><b>-d <display-name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X11 display name (e.g., :0).<br><br><b>-o <output-file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the path and filename for the output video (default: output.mp4).<br><br><b>-f <framerate></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target framerate for the recording (default: 60).<br><br><b>-r <resolution></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the recording resolution (e.g., 1920x1080).<br><br><b>-x <x-offset></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X-axis offset for the capture area (default: 0).<br><br><b>-y <y-offset></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Y-axis offset for the capture area (default: 0).<br><br><b>-c <codec></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the video codec to use (e.g., h264_nvenc, h264_amf, h264_vaapi for hardware acceleration).<br><br><b>-a <audio-input></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the audio input device (e.g., default, pulse).<br><br><b>-b <bitrate></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the video bitrate (e.g., 8M for 8 megabits/second, 12000K for 12000 kilobits/second).<br><br><b>-m <max-duration></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum recording duration in seconds.<br><br><b>-s <preset></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the encoding preset (e.g., quality, performance).<br><br><b>--cursor</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes the mouse cursor in the recorded video.<br><br><b>--gl</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses the OpenGL backend for screen capture (default).<br><br><b>--vk</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses the Vulkan backend for screen capture.<br><br><b>--list-codecs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available video codecs on the system.<br><br><b>--list-audio-devices</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available audio input devices on the system.<br><br><b>--no-metadata</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables including metadata in the output file.<br><br><b>--loop-input</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loops the audio input if its duration is shorter than the video.<br><br><b>--capture-window <window-id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Captures a specific window by its X11 window ID.<br><br><b>--capture-area <x,y,w,h></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Captures a specific rectangular area defined by x, y coordinates, width (w), and height (h).<br><br><b>--v-sync <mode></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the V-Sync mode (off, on, adaptive) for capture.<br><br>


title: DESCRIPTION
content:
<b>gpu-screen-recorder</b> is a powerful, open-source command-line utility designed for capturing screen activity directly from the GPU. Unlike traditional screen recorders that capture from the display buffer, <b>gpu-screen-recorder</b> leverages modern graphics APIs like OpenGL and Vulkan to capture frames with minimal overhead. This makes it particularly well-suited for recording demanding applications such as video games, ensuring high performance and smooth recordings without significantly impacting system resources.<br><br>It offers extensive customization options, including specifying resolution, framerate, video codecs (like h264_nvenc, h264_amf, h264_vaapi for hardware acceleration), audio input devices, and even specific window or area capture. Its focus on efficiency and direct GPU integration provides a superior recording experience for users requiring high-fidelity captures.


title: CAVEATS
content:
<b>gpu-screen-recorder</b> is primarily designed for X11 environments; its functionality on Wayland might be limited or require specific configurations depending on the compositor. Optimal performance and hardware-accelerated encoding rely heavily on the availability of appropriate GPU drivers (NVIDIA, AMD, Intel) and libraries. Users might need to install specific codec libraries (e.g., FFmpeg with nvenc support) for certain hardware acceleration features. Audio configuration can sometimes be challenging, requiring correct identification of audio input devices.


title: GPU BACKEND SELECTION
content:
Users can explicitly choose between OpenGL (<code>--gl</code>) or Vulkan (<code>--vk</code>) capture backends, allowing optimization based on their system's graphics stack and the application being recorded. This direct GPU integration is key to its low-overhead design.


title: HARDWARE ACCELERATED ENCODING
content:
The command strongly supports hardware-accelerated video encoding through various codecs like h264_nvenc (NVIDIA), h264_amf (AMD), and h264_vaapi (Intel/other VAAPI-enabled hardware). Utilizing these codecs offloads encoding tasks from the CPU to the GPU, significantly improving performance and reducing system load during recording.


title: HISTORY
content:
<b>gpu-screen-recorder</b> was developed by Decembersoft with the explicit goal of providing a low-overhead, high-performance screen recording solution for Linux. It emerged as an alternative to traditional CPU-bound recorders, aiming to leverage modern GPU rendering APIs (OpenGL, Vulkan) to capture screen content directly from the graphics pipeline, making it ideal for recording demanding applications like video games. Its development has focused on efficiency and offering users direct control over capture and encoding parameters.


title: TLDR
content:
<b>Select a source using a desktop portal and record it</b>`gpu-screen-recorder -w portal -o [path/to/video.mp4]`<br><b>Specify a specific video source</b>`gpu-screen-recorder -w [screen|DP-1|HDMI-A1|...] -o [path/to/video.mp4]`<br><b>List video capture sources</b>`gpu-screen-recorder --list-capture-options`<br><b>List audio capture sources</b>`gpu-screen-recorder [--list-audio-devices|--list-application-audio]`<br><b>Record using the replay buffer</b>`gpu-screen-recorder -w [screen] -r [30] -c [mp4] -ro [path/to/directory] -o [whatever]`<br><b>Capture a video from the replay buffer</b>`pkill -SIGUSR1 -f gpu-screen-recorder`<br><b>Run gpu-screen-recorder in the background</b>`systemctl start --user gpu-screen-recorder`


title: TLDR
content:
<b>Check to see if the system has any available updates</b>`updatectl check`<br><b>Update to the latest version</b>`updatectl update`<br><b>Show update targets</b>`updatectl list`<br><b>Show data about a target and its versions</b>`updatectl list [target]`<br><b>Return local data about a target without fetching from the network</b>`updatectl --offline list [target]`<br><b>Apply an update to a target and then reboot the system</b>`updatectl --reboot update [target]`<br><b>Clean up old versions of a specified target</b>`updatectl vacuum [target]`<br><b>Display help</b>`updatectl [[-h|--help]]`


title: SYNOPSIS
content:
<b>sudoedit</b> [<I>-AknPS</I>] [<I>-r role</I>] [<I>-t type</I>] [<I>-C num</I>] [<I>-g group</I>] [<I>-h host</I>] [<I>-u user</I>] <I>file</I> ...


title: PARAMETERS
content:
<b>-A, --askpass</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prompts the user for a password if required.<br><br><b>-C <num>, --close-from=<num></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Closes file descriptors greater than or equal to <I>num</I> before executing the editor.<br><br><b>-g <group>, --group=<group></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Edit the file as if the effective group ID were <I>group</I>. Defaults to <b>root</b>.<br><br><b>-h <host>, --host=<host></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For proxied commands, specifies the host where the command is to be run.<br><br><b>-k, --reset-timestamp</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Invalidates the user's cached credentials. A password will be required for the next <b>sudo</b> command.<br><br><b>-n, --non-interactive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents prompts for user input (e.g., password). If a password is required, <b>sudoedit</b> will exit with an error.<br><br><b>-P, --preserve-groups</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Preserves the user's group vector rather than setting it to the target user's default group.<br><br><b>-r <role>, --role=<role></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a SELinux security context for the command using the specified role.<br><br><b>-S, --stdin</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads the password from standard input.<br><br><b>-t <type>, --type=<type></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a SELinux security context for the command using the specified type.<br><br><b>-u <user>, --user=<user></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Edit the file as if the effective user ID were <I>user</I>. Defaults to <b>root</b>.<br><br><b>file ...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more files to be edited. These files must be absolute paths or relative to the current working directory.<br><br>


title: DESCRIPTION
content:
<b>sudoedit</b> (also aliased as <b>sudo -e</b>) provides a secure way to edit files that require root or another user's privileges. Unlike directly running an editor with <b>sudo</b> (e.g., <b>sudo vi /etc/fstab</b>), which executes the entire editor process with elevated rights, <b>sudoedit</b> operates differently. It makes a temporary copy of the specified file, sets its ownership to the current user, and then invokes the user's preferred editor (determined by <b>SUDO_EDITOR</b>, <b>VISUAL</b>, or <b>EDITOR</b> environment variables) to edit this temporary copy.<br><br>Once the user finishes editing and the editor exits, <b>sudoedit</b> verifies that the temporary file has been modified and, if so, copies it back to the original location with the correct permissions and ownership. This approach enhances security by ensuring that the editor itself does not run with elevated privileges, minimizing the attack surface and potential for privilege escalation through misbehaving plugins or scripts within the editor. It's the recommended method for modifying system configuration files securely.


title: CAVEATS
content:
<b>sudoedit</b> relies on the editor process saving changes to the temporary file before exiting. Editors that use aggressive swap files or don't write changes back immediately might not work as expected.<br>The chosen editor (from <b>SUDO_EDITOR</b>, <b>VISUAL</b>, <b>EDITOR</b>) must be a trusted application. While <b>sudoedit</b> prevents the editor from running as root, a malicious editor could still modify the temporary file in unexpected ways or leak its content.<br>If the system crashes or the editor is killed ungracefully, temporary files might be left behind, though <b>sudoedit</b> attempts to clean them up.<br>The user must have <b>sudo</b> privileges configured for <b>sudoedit</b> in <I>/etc/sudoers</I>.


title: EDITOR SELECTION PRECEDENCE
content:
<b>sudoedit</b> determines which editor to use by checking environment variables in the following order: <b>SUDO_EDITOR</b>, <b>VISUAL</b>, and then <b>EDITOR</b>. If none of these are set, a default editor (often <I>vi</I> or <I>nano</I>) is used, as defined by the system's <b>sudo</b> configuration.


title: INTERNAL WORKFLOW
content:
The core of <b>sudoedit</b>'s security model lies in its temporary file strategy. When invoked, it performs these steps:<br>1. Copies the target file to a secure, temporary location (e.g., <I>/var/tmp/sudoedit.#####</I>).<br>2. Changes the ownership of the temporary copy to the current user.<br>3. Invokes the user's specified editor on this temporary file.<br>4. Waits for the editor to exit.<br>5. If the temporary file was modified, <b>sudoedit</b> then copies it back to the original location, preserving the original file's ownership and permissions, but with the new content. This final step is the only one that requires elevated privileges, and it's performed by the <b>sudoedit</b> binary itself, not the editor.


title: HISTORY
content:
<b>sudoedit</b> was introduced as part of the <b>sudo</b> suite to address the security concerns associated with running a full-featured text editor with root privileges. Historically, users would run <I>sudo vi /path/to/file</I> to edit system configuration. This meant the entire <I>vi</I> process, including any plugins, scripts, or shell escapes, ran with root permissions, increasing the potential attack surface. <b>sudoedit</b> was designed as a safer alternative, fundamentally changing the workflow to minimize the time and scope of elevated privileges, thereby reducing risks. Its inclusion reflects a broader trend in security to implement the principle of least privilege.


title: PARAMETERS
content:
<b><b><tt>-h</tt></b>, <b><tt>--help</tt></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a summary of command-line options and exit.<br><br><b><b><tt>-v</tt></b>, <b><tt>--version</tt></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the <code>distcc</code> version and exit.<br><br><b><b><tt>-j</tt></b> <I>jobs</I>, <b><tt>--jobs</tt></b> <I>jobs</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the maximum number of concurrent jobs to run across all <code>distcc</code> hosts. This can limit local and remote compilation parallelism.<br><br><b><b><tt>--show-hosts</tt></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the current list of hosts that <code>distcc</code> will use for compilation.<br><br><b><b><tt>--drop-hosts</tt></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When using host randomization, this option forces <code>distcc</code> to drop hosts from the list that have failed recently.<br><br><b><b><tt>--scan-hosts</tt></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Scan the current host list to determine their availability and compiler compatibility.<br><br><b><b><tt>--verbose</tt></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose logging, showing more information about <code>distcc</code>'s operations, including host selection and file transfers.<br><br><b><b><tt>--debug</tt></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debug logging, providing even more detailed output for troubleshooting.<br><br><b><b><tt>--profile</tt></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable profiling of <code>distcc</code>'s internal operations for performance analysis.<br><br><b><b><tt>--no-fallback</tt></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable falling back to local compilation if a remote host fails or is unavailable. <code>distcc</code> will report an error instead.<br><br><b><b><tt>--distcc-pump</tt></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable 'pump mode,' which sends preprocessed source and header files to remote hosts, potentially speeding up compilation further by reducing local preprocessing.<br><br><b><b><tt>--no-link</tt></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When acting as a wrapper, ensures that <code>distcc</code> only attempts to compile source files and never to link them remotely.<br><br>


title: DESCRIPTION
content:
<code>distcc</code> is a program designed to speed up compilation of C, C++, and Objective-C code by distributing the compilation workload across multiple machines on a network. It acts as a wrapper around your local C/C++ compiler (like <code>gcc</code> or <code>g++</code>). When a build system invokes a compiler, <code>distcc</code> intercepts the call. If the compilation command doesn't require local preprocessing or complex linking, <code>distcc</code> sends the source file to a <code>distccd</code> daemon running on a remote host. The <code>distccd</code> daemon compiles the file on the remote machine and sends the resulting object file back to the original machine. This parallelization significantly reduces build times for large software projects by utilizing idle CPU cycles across a cluster of machines. It requires the <code>distccd</code> daemon to be running on all participating remote hosts and compatible compiler versions across all machines.


title: CAVEATS
content:
<b>Compiler Compatibility:</b> All participating machines must have compilers of the same version and architecture for consistent results.<br><b>Network Overhead:</b> For very small source files, the overhead of network transfer can outweigh the benefits of distributed compilation.<br><b>Debugging Challenges:</b> Debugging compilation issues can be more complex as the actual compilation happens on a remote machine.<br><b>Security:</b> The <code>distccd</code> daemon, by default, listens on the network and can execute arbitrary code (though typically restricted to compilation commands). It should only be used in trusted environments or with proper firewall rules and access control.<br><b>Preprocessing:</b> By default, <code>distcc</code> performs preprocessing locally before sending the source code, which can still be a bottleneck. "Pump mode" (<code>--distcc-pump</code>) can mitigate this.<br><b>Linking/Archiving:</b> <code>distcc</code> does not distribute linking or archiving operations; these always happen on the local machine.


title: CONFIGURATION VIA ENVIRONMENT VARIABLES
content:
<code>distcc</code> relies heavily on environment variables for configuration. The most critical is <br><b><tt>DISTCC_HOSTS</tt></b>, which specifies a space-separated list of remote hosts (and optional ports or connection types like <code>lzo</code> for compression) that <code>distcc</code> should use. For example: <br><code><br>export DISTCC_HOSTS="localhost remote1.example.com remote2:3632"<br></code><br>Other important variables include <br><b><tt>DISTCC_DIR</tt></b> (directory for cache and logs), <br><b><tt>DISTCC_JOBS</tt></b> (overrides <code>--jobs</code>), and <br><b><tt>DISTCC_VERBOSE</tt></b> (enables verbose output).


title: TYPICAL USAGE PATTERN
content:
To use <code>distcc</code>, you typically prepend its directory to your system's <br><b><tt>PATH</tt></b> environment variable, so that when a build system (like <br><b><tt>make</tt></b>) invokes <br><b><tt>gcc</tt></b> or <br><b><tt>g++</tt></b>, it finds <code>distcc</code> first. <br><code><br>export PATH="/usr/lib/distcc/bin:$PATH"<br></code><br>Alternatively, you can configure your build system to explicitly use <br><b><tt>distcc gcc</tt></b> as the compiler.


title: HISTORY
content:
<code>distcc</code> was originally developed by <I>Martin Pool</I> in the early 2000s, with initial versions appearing around 2002. It was created to address the growing need for faster build times in large software projects, leveraging the idle CPU cycles of other machines on a local network. Its design, acting as a simple wrapper around existing compilers, made it easy to integrate into existing build systems without significant modifications. Over the years, it has become a widely adopted tool in open-source development and various Linux environments for accelerating software compilation.


title: TLDR
content:
<b>Compile a source file using a compiler like gcc</b>`distcc [gcc] -c [path/to/source.c] -o [path/to/output.o]`<br><b>Set remote hosts to distribute compilation</b>`export DISTCC_HOSTS="localhost [ip1 ip2 ...]"`<br><b>Compile a project with make using distcc</b>`make [[-j|--jobs]] [parallel_jobs] CC="distcc [gcc]"`<br><b>Show the list of current distcc hosts</b>`distcc --show-hosts`<br><b>Display help</b>`distcc --help`<br><b>Display version</b>`distcc --version`


title: SYNOPSIS
content:
<b>vagrant snapshot</b> <I>subcommand</I> [<I>machine-name</I>] [<I>args</I>] [<I>options</I>]<br><br>Subcommands:<br>  <b>vagrant snapshot save</b> [<I>machine-name</I>] <I>name</I><br>  <b>vagrant snapshot restore</b> [<I>machine-name</I>] <I>name</I><br>  <b>vagrant snapshot list</b> [<I>machine-name</I>]<br>  <b>vagrant snapshot delete</b> [<I>machine-name</I>] <I>name</I>


title: PARAMETERS
content:
<b><I>subcommand</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the action to perform: <b>save</b>, <b>restore</b>, <b>list</b>, or <b>delete</b>.<br><br><b><I>machine-name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. The name of the specific Vagrant machine within the multi-machine environment to apply the command to. If omitted, the command typically applies to the primary or only machine.<br><br><b><I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Required for <b>save</b>, <b>restore</b>, and <b>delete</b> subcommands. A unique name to identify the snapshot.<br><br><b>--provider <I>PROVIDER</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restricts the operation to a specific virtualization provider (e.g., virtualbox, vmware_fusion). Useful in multi-provider environments.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;For <b>save</b>, overwrites an existing snapshot with the same name. For <b>restore</b>, forces the restoration even if the VM's state is considered 'dirty' or not clean.<br><br><b>--provision</b><br>&nbsp;&nbsp;&nbsp;&nbsp;For <b>restore</b>, runs configured provisioners after restoring the snapshot. This ensures the VM is brought up to date after reverting its state.<br><br><b>--no-provision</b><br>&nbsp;&nbsp;&nbsp;&nbsp;For <b>restore</b>, prevents provisioners from running after the snapshot is restored. Useful for quick reverts without additional configuration steps.<br><br><b>--box <I>BOX_NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For <b>list</b> and <b>delete</b>, specifies that snapshots should be managed for a Vagrant box, not a specific machine. Useful for cleaning up space or managing shared box snapshots.<br><br>


title: DESCRIPTION
content:
The `vagrant snapshot` command provides a powerful way to manage the state of your development virtual machines. It allows users to <I>save</I> the current state of a running or halted VM, <I>restore</I> a VM to a previously saved state, <I>list</I> all existing snapshots for a VM, or <I>delete</I> unneeded snapshots. This functionality is crucial for developers who need to quickly revert to a known good state, experiment with changes without fear of permanent damage, or share specific VM states within a team. Snapshots capture the entire disk and memory state of the VM at a given point, making them invaluable for debugging complex issues or setting up consistent test environments. It leverages the underlying virtualization provider's snapshot capabilities (e.g., VirtualBox, VMware) to perform these operations.


title: CAVEATS
content:
Snapshots can consume significant disk space, as they store the full state of the VM's disk and sometimes memory. Frequent or numerous snapshots can lead to large disk usage.<br><br>Not all virtualization providers offer the same level of snapshot functionality, and some may have limitations or performance implications.<br><br>While useful for development, snapshots are generally not a robust solution for production backups or continuous integration environments; they are best suited for local development workflow management.<br><br>Restoring a snapshot effectively rewinds the VM's state. Any data or changes made after the snapshot was taken will be lost unless backed up externally.


title: SNAPSHOT NAMING BEST PRACTICES
content:
When saving snapshots, it's highly recommended to use descriptive names that indicate the state of the VM, such as 'initial_os_install', 'after_db_setup', or 'pre_feature_x_branch_merge'. This makes it much easier to identify and restore the correct state later on.


title: COMMON USE CASES
content:
Beyond simple rollback, `vagrant snapshot` is invaluable for:<br> - <b>Debugging:</b> Revert to a state just before a bug occurred to reproduce and debug.<br> - <b>Feature Branching:</b> Take a snapshot before switching to a new feature branch, allowing a quick return to the previous environment.<br> - <b>Testing:</b> Test multiple configurations or software versions by restoring to different baseline snapshots.


title: HISTORY
content:
The `vagrant snapshot` functionality was integrated into Vagrant as a core feature to address the common developer need for quick state management and rollback capabilities. Vagrant, created by Mitchell Hashimoto, aims to provide an easy-to-use layer for managing virtual development environments. As virtualization technology advanced and became more accessible, the ability to snapshot a VM became a fundamental requirement for efficient iterative development and debugging workflows. This command leverages the native snapshot features of underlying hypervisors like VirtualBox and VMware, abstracting away their specific commands into a unified Vagrant interface.


title: TLDR
content:
<b>Take a snapshot of the machine (running or stopped)</b>`vagrant snapshot save [snapshot_name]`<br><b>Restore a snapshot and start the machine</b>`vagrant snapshot restore [snapshot_name]`<br><b>Restore a snapshot without starting the machine</b>`vagrant snapshot restore --no-start [snapshot_name]`<br><b>Delete a snapshot</b>`vagrant snapshot delete [snapshot_name]`<br><b>List available snapshots of the machine</b>`vagrant snapshot list`


title: PARAMETERS
content:
<b>-f <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input BDF font file.<br><br><b>-o <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the name of the output C source file.<br><br><b>-m <map_type></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines character mapping (e.g., 'auto', 'unicode', 'iso-8859-1').<br><br><b>-N <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a prefix for generated C function and variable names.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details during conversion.<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures right-to-left drawing mode for glyphs.<br><br><b>-s <start_char></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the starting character code for the conversion range.<br><br><b>-e <end_char></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the ending character code for the conversion range.<br><br><b>-c <count></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of characters to convert, starting from '-s'.<br><br><b>-a <alignment></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines byte alignment for glyph data (e.g., 1, 2, 4).<br><br><b>-b <bits></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies bits per pixel for the font (commonly 1 for monochrome displays).<br><br><b>-M</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Horizontally mirrors the glyphs.<br><br><b>-d <draw_mode></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the drawing mode (e.g., 'u8x8', 'u8g2') for glyphs.<br><br><b>-u</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables UTF-8 support for input character ranges.<br><br><b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the content and properties of the BDF font file without converting.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br>


title: DESCRIPTION
content:
<b>bdfconv</b> is a specialized utility primarily used in embedded systems development to convert BDF (Bitmap Distribution Format) font files into C language data arrays. These arrays can then be directly compiled into firmware, allowing microcontrollers and other resource-constrained devices to display custom fonts without needing a full-fledged font rendering engine.<br><br>It's often associated with popular graphics libraries like <I>U8g2</I> and <I>U8x8</I>, providing a streamlined way to integrate bitmap fonts for small OLEDs, LCDs, and other displays commonly found in IoT devices and hobbyist projects. The conversion process typically involves selecting specific character ranges, defining output format parameters such as bits-per-pixel and byte alignment, and optionally mirroring or adjusting the drawing mode of glyphs. This ensures efficient storage and optimized access of glyph data in the limited memory environments of embedded systems.


title: CAVEATS
content:
<b>bdfconv</b> is typically a command-line tool without a graphical interface. Its primary output is C source code, which requires a C compiler for integration into a project. The utility's specific features and options can vary slightly depending on the version or the library it is packaged with (e.g., different versions within U8g2, or if it's a standalone tool). It primarily handles bitmap fonts; scalable fonts like TrueType or OpenType require different conversion tools.


title: HISTORY
content:
<b>bdfconv</b>'s origins are closely tied to the need for efficient font rendering on resource-constrained embedded systems. While bitmap font conversion tools existed for the X Window System (like <I>bdftopcf</I>), a dedicated tool to convert BDF into directly embeddable C arrays became essential for microcontroller projects. It gained prominence particularly with the rise of dedicated graphics libraries like <I>U8g2</I> and <I>u8x8</I>, which simplify display interaction for hobbyists and professionals working with small OLED/LCD displays on platforms like Arduino. Its development is often driven by the requirements of these specific embedded graphics ecosystems, providing a critical link between design and deployment for custom fonts.


title: PARAMETERS
content:
<b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable fullscreen mode for playback.<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output raw, unformatted frames without <i>libcaca</i> headers (useful for piping).<br><br><b>-x</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable playback and instead dump frames as C-arrays to standard output (developer-oriented).<br><br><b>-d <i><driver></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the display driver to use (e.g., 'ncurses', 'x11', 'sdl', 'raw'). Defaults to auto-detection.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Quiet mode; do not display anything (useful for benchmarking).<br><br><b>-b</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not display the background, drawing only the foreground elements.<br><br><b>-s <i><width>x<height></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the output resolution or character grid size, e.g., '80x25'.<br><br><b>-S <i><factor></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the font scaling factor for the output.<br><br><b>-c <i><charset></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the character set to use for rendering (e.g., 'ascii', 'cp437', 'utf8').<br><br><b>-p <i><plugin></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a particular playback plugin to use for decoding (e.g., 'ffmpeg', 'mplayer').<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, displaying more information during execution.<br><br><b>-V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information for <b>cacaplay</b> and exit.<br><br>


title: DESCRIPTION
content:
<b>cacaplay</b> is a command-line utility from the <i>libcaca</i> library, designed to play various multimedia files, including videos and animated GIFs, directly within your terminal as ASCII art. It leverages external decoding libraries like FFmpeg or MPlayer to interpret media formats, then renders the frames using characters, colors, and block elements supported by the terminal.<br><br>The primary purpose of <b>cacaplay</b> is to demonstrate the capabilities of <i>libcaca</i> in converting graphical content into a text-based representation. While not intended for high-fidelity playback, it offers a unique and nostalgic way to experience multimedia, turning your terminal into a retro display. It can handle a wide range of video and image formats, making it a versatile tool for both entertainment and showcasing the artistic potential of character-based graphics.


title: CAVEATS
content:
The performance and visual quality of <b>cacaplay</b> are highly dependent on the terminal emulator's capabilities, the input media's resolution, and the speed of your system. High-resolution videos or complex animations can lead to slow frame rates. It relies on external libraries (like FFmpeg or MPlayer) for decoding most common video formats; if these are not installed or <i>libcaca</i> was not compiled with their support, functionality may be limited. The output is inherently stylized and low-resolution, not suitable for detailed visual analysis.


title: SUPPORTED FILE FORMATS
content:
<b>cacaplay</b> can play its native <i>.caca</i> animation files directly. For other multimedia formats (e.g., MP4, MKV, AVI, GIF, WebM), it typically relies on underlying video decoding libraries like FFmpeg or MPlayer. This means it can theoretically play any format that these robust libraries support, converting their visual content into ASCII or ANSI art for terminal display.


title: USAGE EXAMPLE
content:
To play a video file named <i>my_video.mp4</i> using <b>cacaplay</b>, you would simply execute:<br><br><code><b>cacaplay</b> my_video.mp4</code><br><br>For a more controlled playback, you might specify the output size and character set:<br><br><code><b>cacaplay</b> -s 120x40 -c utf8 my_video.mp4</code>


title: HISTORY
content:
<b>cacaplay</b> is a core utility of the <i>libcaca</i> library, which was primarily developed by Sam Hocevar starting around 2005. <i>libcaca</i> gained popularity for its whimsical yet technically impressive ability to render graphics, including video, as pure ASCII art in a terminal. It was conceived as an alternative to <i>libaa</i> (AAlib) and aimed to provide better color support and performance. <b>cacaplay</b> emerged as the main application demonstrating <i>libcaca</i>'s video playback capabilities, showcasing the library's versatility in creative text-based graphical representations.


title: PARAMETERS
content:
<b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compress multiple blanks in an index entry to a single blank character.<br><br><b><b>-g</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use German-style ordering for sorting index entries. This affects how certain characters and ligatures are sorted.<br><br><b><b>-i</b> <i>input_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly specify an input file. If this option is used, <i>makeindex</i> will process the given file as an index input, even if its extension is not <b>.idx</b>.<br><br><b><b>-o</b> <i>output_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the name of the output index file. By default, it uses the input base name with an <b>.ind</b> extension.<br><br><b><b>-s</b> <i>style_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the name of the index style file (<b>.ist</b>) to use. This file dictates the formatting and structure of the generated index. If not specified, <i>makeindex</i> looks for <i>input_base_name</i><b>.ist</b>.<br><br><b><b>-t</b> <i>log_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the name of the transcript (log) file. This file records messages, errors, and warnings generated during processing. Defaults to <i>input_base_name</i><b>.ilg</b>.<br><br><b><b>-L</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a <i>long</i> language definition file for sorting, which provides more comprehensive rules for specific languages (e.g., complex rules for German or French characters). This is often used in conjunction with <b>-g</b> for German.<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable quiet mode. Suppresses all progress and informational messages, printing only error messages.<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Discard page number ranges. Instead of showing "1-3", it will list "1, 2, 3" for the index entry.<br><br><b><b>-p</b> <i>num</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the starting page number for page number ranges. For example, if <i>num</i> is '1', '1-3' becomes '1-3'. If '0', '1-3' might be '1, 2, 3'.<br><br><b><b>-P</b> <i>string</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the specified <i>string</i> instead of the page number for entries whose page number has been discarded (e.g., due to <b>-p 0</b> or <b>-r</b>). This is typically used for entries that should not have a page number.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose mode. Prints detailed progress and diagnostic messages during processing.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message with usage information and exit.<br><br>


title: DESCRIPTION
content:
<i>makeindex</i> is a utility program designed to process raw index information generated by LaTeX into a formatted, human-readable index. When a LaTeX document contains <b>\index{}</b> commands, LaTeX writes the index entries to a file with the <b>.idx</b> extension. <i>makeindex</i> then takes this <b>.idx</b> file as input, sorts the entries, resolves page ranges, and applies formatting rules defined in an index style (<b>.ist</b>) file. The result is an output file with the <b>.ind</b> extension, which can then be included back into the LaTeX document using the <b>\printindex</b> command. This process typically requires an additional LaTeX compilation pass to incorporate the newly generated index.<br><br>It is an essential tool for creating professional indexes, lists of figures, lists of tables, and glossaries in complex documents, allowing authors to automatically manage and format cross-references and page numbers for numerous terms.


title: CAVEATS
content:
<i>makeindex</i> is highly dependent on the correct generation of <b>.idx</b> files by LaTeX and the proper configuration of <b>.ist</b> style files. Issues often arise from incorrect indexing commands in LaTeX, malformed <b>.ist</b> files, or character encoding mismatches. While powerful, for highly complex indexing needs, especially with multi-language support or advanced sorting, alternatives like <i>xindy</i> may offer more flexibility.


title: INDEX COMPILATION WORKFLOW
content:
Creating an index with <i>makeindex</i> typically involves a multi-pass compilation:<br>1. Run <b>latex</b> or <b>pdflatex</b> on your <b>.tex</b> document. This generates the raw index file (<b>.idx</b>) based on <b>\index{}</b> commands.<br>2. Run <b>makeindex</b> on the generated <b>.idx</b> file (e.g., <b>makeindex mydocument</b>). This processes the <b>.idx</b> file and creates the formatted index file (<b>.ind</b>).<br>3. Run <b>latex</b> or <b>pdflatex</b> again on your <b>.tex</b> document. This time, LaTeX includes the newly generated <b>.ind</b> file into your document, rendering the index.


title: INDEX STYLE (.IST) FILES
content:
The appearance and structure of the generated index are controlled by an Index Style file, typically with a <b>.ist</b> extension. These plain text files contain directives that define things like:<br><i>* How page numbers are formatted (e.g., bold for main entries).</i><br><i>* The separators used between page numbers or sub-entries.</i><br><i>* Headings for index sections (e.g., 'A', 'B', 'C').</i><br><i>* The layout of group headers and main index entries.</i><br>Customizing these files allows for highly flexible and professional index designs.


title: HISTORY
content:
<i>makeindex</i> was developed by Jonathan Fine as an integral part of the LaTeX typesetting system. It addresses the need for automated index generation, a labor-intensive task in manual document production. Since its inception, it has been a stable and widely used component within the TeX Live and MiKTeX distributions, though more modern alternatives like <i>xindy</i> have emerged to handle challenges posed by Unicode and complex linguistic sorting rules.


title: SYNOPSIS
content:
<b>stratis</b> [GLOBAL_OPTIONS] <SUBCOMMAND> [SUBCOMMAND_OPTIONS] [ARGUMENTS]<br><br>Common <b>SUBCOMMANDS</b> include:<br><b>pool</b>, <b>filesystem</b>, <b>blockdev</b>, <b>report</b>, <b>key</b>, <b>daemon</b>, <b>version</b>, <b>list</b>.


title: PARAMETERS
content:
<b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the <b>stratis</b> version and exit.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce output in JSON format, if applicable. Useful for scripting.<br><br><b>--propagate</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Propagate daemon errors. Primarily for internal use or debugging.<br><br><b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message for the main <b>stratis</b> command or a specific subcommand.<br><br><b>--verbose, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase output verbosity, providing more detailed information.<br><br><b>--quiet, -q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decrease output verbosity, suppressing non-critical messages.<br><br>


title: DESCRIPTION
content:
<b>stratis</b> is an advanced local storage management system for Linux, designed to simplify the complex tasks associated with managing disks and filesystems. It provides a user-friendly interface to create, manage, and monitor storage pools and filesystems.<br><br>Built on top of well-established Linux technologies like LVM2 and XFS, <b>stratis</b> offers features such as <i>thin provisioning</i>, <i>copy-on-write snapshots</i>, and <i>data encryption</i> (via LUKS), all with a focus on ease of use. It abstracts away the intricacies of underlying storage layers, allowing administrators to efficiently provision storage for various applications and services without deep knowledge of low-level device management. <b>stratis</b> aims to be a modern, flexible, and robust solution for local storage.


title: CAVEATS
content:
<b>stratis</b> is specifically designed for <i>local block storage management</i> and is not intended for network-attached storage solutions. It relies on the <b>stratisd</b> daemon running in the background; commands will fail if the daemon is inactive. While it simplifies storage, users should understand that it builds upon LVM and XFS, and complex recovery scenarios might still require lower-level expertise. It typically requires unpartitioned block devices for pool creation.


title: KEY CONCEPTS
content:
<b>stratis</b> manages storage using a few core concepts:<br><b>Pool</b>: The fundamental storage unit, created from one or more block devices, from which filesystems are allocated.<br><b>Filesystem</b>: A thin-provisioned filesystem created within a <b>stratis</b> pool.<br><b>Snapshot</b>: A read-only, point-in-time copy of a <b>stratis</b> filesystem, useful for backups or testing.


title: DAEMON REQUIREMENT
content:
The <b>stratis</b> command-line tool communicates with the <b>stratisd</b> daemon. For <b>stratis</b> commands to function correctly, the <b>stratisd</b> service must be running and accessible. It typically runs as a systemd service.


title: HISTORY
content:
<b>stratis</b> was developed by engineers at Red Hat, aiming to provide a simpler and more consistent user experience for local storage management on Linux systems. Its development began around 2018, with initial releases appearing in Fedora and subsequently Red Hat Enterprise Linux (RHEL). It was conceived as a high-level abstraction over existing mature technologies like Device Mapper, LVM2, and XFS, similar in concept to ZFS or Btrfs but designed to integrate seamlessly with the enterprise Linux ecosystem. Its usage has grown steadily, particularly in server environments where ease of storage provisioning and management is critical.


title: DESCRIPTION
content:
The term "trunk" is not a directly executable Linux command found in standard Linux distributions. Instead, it refers to a conceptual term used across various technical domains:<br><br><i>Version Control Systems (VCS)</i>: Primarily in systems like Apache Subversion (SVN), the 'trunk' represents the main line of development for a software project. It is the primary path where all major development occurs, and new features or bug fixes are typically integrated here, often after being developed on separate 'branches' and then merged back.<br><br><i>Networking</i>: In network infrastructure, a 'trunk port' or 'trunk link' describes an Ethernet connection configured to carry traffic for multiple Virtual Local Area Networks (VLANs) over a single physical cable. This is typically achieved using the IEEE 802.1Q standard, allowing switches and devices to communicate across different VLANs.<br><br><i>Telephony/PBX Systems</i>: In the context of Private Branch Exchange (PBX) systems, a 'trunk' refers to a logical or physical communication line that connects the PBX system to external networks, such as the Public Switched Telephone Network (PSTN) or other PBX systems, enabling calls to be routed in and out of the organization.


title: CAVEATS
content:
Users attempting to find a 'trunk' command will not locate a directly executable utility in typical Linux environments. The term's meaning is highly dependent on the specific technical context (e.g., version control, networking, telephony). Interaction with these 'trunk' concepts is performed using other dedicated commands or configuration tools relevant to that domain, not a universal 'trunk' command.


title: USAGE IN VERSION CONTROL
content:
In version control systems like SVN, the 'trunk' directory (or path) is where the main, most current version of the project's codebase resides. Developers perform routine operations like <B>svn checkout</B> to obtain a copy of the trunk, <B>svn commit</B> to save their changes back to it, and <B>svn update</B> to synchronize their local copy with the latest trunk changes. Branches are often created from the trunk for parallel development, and then merged back to integrate completed work.


title: USAGE IN NETWORKING
content:
Configuring a network 'trunk' involves setting up a switch port or network interface to tag Ethernet frames with VLAN IDs, allowing it to transport traffic for multiple VLANs. This is crucial for connecting switches to each other, or connecting servers that host virtual machines belonging to different VLANs. This configuration is performed using device-specific commands on network hardware or through Linux networking utilities like the <B>ip</B> command (for managing VLAN interfaces) and configuration files (e.g., in /etc/network/interfaces or /etc/sysconfig/network-scripts) rather than a direct 'trunk' command.


title: HISTORY
content:
As 'trunk' is a conceptual term rather than a specific Linux command, it does not possess a distinct development history like traditional command-line utilities. Its conceptual use has evolved within various technical fields over time, particularly gaining prominence in software development with the widespread adoption of version control systems and in networking with the standardization of VLAN technologies.


title: PARAMETERS
content:
<b><i>COMMAND</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the action to perform (e.g., <b><i>status</i></b>, <b><i>apply</i></b>, <b><i>list</i></b>, <b><i>history</i></b>).<br><br><b><b><i>status</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hypothetically, displays the current update status of the system, including pending updates or ongoing operations.<br><br><b><b><i>apply</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hypothetically, initiates the download and installation of available updates.<br><br><b><b><i>list</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hypothetically, lists all available updates or specific types of updates (e.g., security, critical).<br><br><b><b><i>history</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hypothetically, shows a log of past update operations, including success/failure status and timestamps.<br><br><b><b><i>rollback</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hypothetically, attempts to revert the system to a previous update state (requires specific system snapshot/rollback capabilities).<br><br><b><b><i>--check-only</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hypothetically, performs a dry run without actually applying updates.<br><br><b><b><i>--reboot</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hypothetically, triggers a system reboot after applying updates, if necessary.<br><br><b><b><i>--verbose</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hypothetically, increases the verbosity of the output.<br><br><b><b><i>--help</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hypothetically, displays help information for the command or a specific subcommand.<br><br>


title: DESCRIPTION
content:
The command <b><i>updatectl</i></b> is not a standard utility found in common Linux distributions like Debian, Ubuntu, Fedora, or RHEL. Its existence is highly unlikely as a generally available or documented command.<br><br>This analysis is therefore based on the hypothetical functionality suggested by its name: a 'control' utility for system 'updates'. If such a command were to exist, it would likely serve as a high-level interface for managing various aspects of system updates, patching, and software package management. Its purpose might be to centralize and simplify common update operations, offering a unified command-line interface akin to <b><i>systemctl</i></b> for service management, but focused purely on software updates and their lifecycle. This could include checking for available updates, initiating download and installation processes, viewing update history, or even rolling back recent updates, depending on its design.


title: CAVEATS
content:
It is crucial to understand that <b><i>updatectl</i></b> is <b>not a standard or commonly recognized Linux command</b>. This analysis is purely hypothetical, based on the naming convention of similar '<i>ctl</i>' commands (like <b><i>systemctl</i></b>, <b><i>ipctl</i></b>, etc.). If you encountered this command, it is likely part of a highly specialized, custom-built system, an embedded appliance's firmware, or a specific, non-mainstream Linux distribution's toolset. It does not have a general man page or widespread usage.


title: HISTORY
content:
Given that <b><i>updatectl</i></b> is not a standard Linux command, there is no public or generally documented history of its development or widespread usage. If such a command exists, its 'history' would be confined to the specific project or vendor that developed it. It might have originated as an internal tool to streamline update processes for a particular product line or custom operating system, possibly to provide a simplified interface over more complex underlying package management systems (like APT, DNF, or Zypper).


title: SEE ALSO
content:
apt(8) - Debian/Ubuntu package manager, dnf(8) - Fedora/RHEL/CentOS package manager, yum(8) - Older RHEL/CentOS package manager, zypper(8) - openSUSE package manager, pacman(8) - Arch Linux package manager, systemctl(1) - systemd system and service manager (for managing update services), unattended-upgrades(8) - Debian/Ubuntu automated update utility


title: PARAMETERS
content:
<b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run in foreground; do not daemonize.<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dry run; do not execute any actions.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose logging.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print version information and exit.<br><br><b><b>-c</b> <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternate configuration file path. Default is <I>/etc/zfs/zed.d/zed.rc</I>.<br><br><b><b>-l</b> <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternate log file path. Default is <I>/var/log/zed.log</I>.<br><br><b><b>-p</b> <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternate PID file path. Default is <I>/var/run/zed.pid</I>.<br><br><b><b>-d</b> <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternate directory for event handling scripts. Default is <I>/etc/zfs/zed.d</I>.<br><br><b><b>-e</b> <I>secs</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the event timeout in seconds. Default is 300 seconds.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br>


title: DESCRIPTION
content:
<b>zed</b> is the ZFS Event Daemon, an essential component for managing and monitoring ZFS file systems. It runs in the background, continuously listening for events generated by the ZFS kernel module. These events can include changes in pool status, disk errors, hot spares being activated, or scrub operations completing.<br><br>When an event occurs, <b>zed</b> evaluates it against a set of configured rules and can execute predefined scripts located in a specific directory (typically <I>/etc/zfs/zed.d</I>). This allows for automated responses to ZFS-related incidents, such as sending email alerts, replacing failed disks, or performing remedial actions.<br><br><b>zed</b> greatly enhances the reliability and maintainability of ZFS storage systems by providing proactive detection and automated handling of critical events, reducing the need for manual intervention and improving overall data integrity. It's a crucial part of an OpenZFS deployment for robust monitoring.


title: CAVEATS
content:
<ul><li><b>zed</b> requires a properly configured ZFS environment to function effectively.</li><li>The effectiveness of <b>zed</b> heavily depends on the quality and robustness of the event handling scripts located in its configured script directory.</li><li>Care must be taken when configuring automated actions, as incorrect scripts could lead to unintended system behavior or data loss.</li><li>It operates on the events generated by the ZFS kernel module; if the module is not loaded or ZFS is not in use, <b>zed</b> will not have events to process.</li></ul>


title: CONFIGURATION
content:
The primary configuration for <b>zed</b> involves placing executable scripts (typically shell scripts) within the <I>/etc/zfs/zed.d</I> directory. These scripts are triggered based on the ZFS event names. For instance, a script named <I>ZFS_POOL_IO_FAIL.sh</I> might be executed when an I/O error occurs on a ZFS pool.


title: EVENT HANDLING
content:
<b>zed</b> passes several environment variables to the executed scripts, providing context about the event, such as <I>ZEVENT_POOL</I>, <I>ZEVENT_VDEV</I>, <I>ZEVENT_EID</I>, and <I>ZEVENT_TYPE</I>. Scripts use these variables to identify the specific nature of the event and take appropriate action.


title: INTEGRATION WITH SYSTEMD
content:
On modern Linux distributions, <b>zed</b> is typically managed by systemd, with units like <I>zed.service</I> ensuring it starts automatically at boot and can be managed via <I>systemctl start zed</I> or <I>systemctl status zed</I>.


title: HISTORY
content:
The <b>zed</b> daemon is an integral part of the OpenZFS project, which emerged from the original ZFS filesystem developed by Sun Microsystems. When Oracle acquired Sun and halted open-sourcing ZFS, the community initiated OpenZFS to continue its development and port it to various operating systems, including Linux. <b>zed</b> was developed as part of this effort to provide a robust, event-driven monitoring solution for ZFS pools, addressing the need for automated responses to array and storage health events that are common in enterprise storage. Its design reflects the self-healing and data integrity focus of ZFS, providing a mechanism for administrators to be proactively informed and to automate remediation actions, thereby strengthening the resilience and reliability of ZFS deployments across different platforms.


title: SYNOPSIS
content:
<i>openocd</i> [ <i>options</i> ] [ <i>arguments</i> ]<br><br><b>Common Usage:</b><br><i>openocd</i> <b>-f</b> <i>interface.cfg</i> <b>-f</b> <i>target.cfg</i>


title: PARAMETERS
content:
<b><b>-f</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the specified <i>file</i> as an OpenOCD configuration script. Used to load interface and target definitions.<br><br><b><b>-s</b> <i>dir</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds <i>dir</i> to the list of directories where OpenOCD searches for configuration scripts.<br><br><b><b>-c</b> <i>command</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the specified <i>command</i> directly, overriding any commands in config files or for interactive use.<br><br><b><b>-l</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Redirects all OpenOCD output messages (logs) to the specified <i>file</i> instead of standard output.<br><br><b><b>-d</b> [<i>level</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the debug message verbosity <i>level</i> (0-3), with 3 being the most verbose. Default is 1.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message with available command-line options and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the OpenOCD version information and exits.<br><br>


title: DESCRIPTION
content:
OpenOCD (Open On-Chip Debugger) is essential <i>open-source software</i> providing powerful debugging and in-system programming capabilities for embedded systems. It bridges the gap between your development machine's debugger (like <i>GDB</i>) and the embedded target hardware, typically via a <i>JTAG</i> or <i>SWD</i> debug adapter.<br><br>It supports an extensive range of microcontrollers (including <i>ARM</i>, <i>RISC-V</i>, <i>MIPS</i>) and various debug probes, enabling critical development tasks such as flashing firmware, setting breakpoints, stepping through code, inspecting memory, and reading CPU registers. OpenOCD is a fundamental tool for embedded developers, crucial for prototyping, debugging, and production programming workflows.


title: CAVEATS
content:
<b>Configuration Dependency:</b> OpenOCD's functionality heavily relies on correctly written and selected configuration files (.cfg) that match your specific debug probe and target hardware.<br><br><b>Initial Setup Complexity:</b> Can be challenging for newcomers, often requiring precise hardware connections and understanding of JTAG/SWD protocols.<br><br><b>Hardware Reliability:</b> Issues frequently stem from poor electrical connections, incorrect wiring, or insufficient power to the target device.


title: GDB SERVER FUNCTIONALITY
content:
OpenOCD primarily operates as a <i>GDB server</i>, enabling standard <i>GDB</i> clients to connect via TCP/IP (default port 3333). This seamless integration facilitates debugging from command-line <i>GDB</i> or integrated development environments (IDEs).


title: CONFIGURATION FILE STRUCTURE
content:
OpenOCD's behavior is defined by <i>.cfg</i> files. These files are typically split into <b>interface</b> configurations (describing the debug probe, e.g., <i>ftdi.cfg</i>) and <b>target</b> configurations (describing the microcontroller or board, e.g., <i>stm32f4.cfg</i>). Users often combine these or create custom ones.


title: TELNET/TCL CONTROL
content:
Beyond <i>GDB</i>, OpenOCD offers a Telnet server (default port 4444) and a TCL server (default port 6666) for direct command execution, scripting, and advanced control of the debugging session. This allows for automated testing or complex flashing sequences.


title: HISTORY
content:
OpenOCD was initiated by Dominic Rath in 2005, primarily to support ARM processor debugging. Its open-source nature and early support for cost-effective <i>FT2232</i>-based debug adapters quickly propelled its adoption within the embedded development community. Over time, contributions from a global community expanded its support to a vast array of microcontrollers (<i>ARM</i>, <i>RISC-V</i>, <i>MIPS</i>), diverse debug interfaces (<i>JTAG</i>, <i>SWD</i>, <i>OCDLink</i>, etc.), and various development boards, establishing it as a <i>de-facto</i> standard for open-source embedded debugging.


title: SEE ALSO
content:
<i>gdb(1)</i>: The GNU Debugger, commonly used as a client connecting to OpenOCD's GDB server., <i>make(1)</i>: A build automation tool often used in conjunction with embedded projects compiled for debugging., <i>arm-none-eabi-gdb</i>: A specific cross-GDB variant for ARM bare-metal targets, frequently used with OpenOCD.


title: SYNOPSIS
content:
<b>vcftools</b> <i>--vcf <input.vcf></i> [<i>OPTIONS</i>]<br><b>vcftools</b> <i>--gzvcf <input.vcf.gz></i> [<i>OPTIONS</i>]<br><b>vcftools</b> [<i>GENERAL_OPTIONS</i>]


title: PARAMETERS
content:
<b><i>--vcf <file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input VCF file. Mandatory for most operations.<br><br><b><i>--gzvcf <file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input gzipped VCF file (.vcf.gz).<br><br><b><i>--out <prefix></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the prefix for all output files generated by <i>vcftools</i>.<br><br><b><i>--recode</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs <i>vcftools</i> to output a new VCF file after applying filters or modifications.<br><br><b><i>--recode-INFO-all</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <i>--recode</i> to ensure all INFO fields from the original VCF are retained in the output.<br><br><b><i>--keep <file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retains only the individuals whose IDs are listed in the specified file (one ID per line).<br><br><b><i>--remove <file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes individuals whose IDs are listed in the specified file.<br><br><b><i>--snps <file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes only SNPs whose IDs are listed in the specified file.<br><br><b><i>--exclude-snps <file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes SNPs whose IDs are listed in the specified file.<br><br><b><i>--positions <file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes only sites (chromosome and position) listed in the specified file.<br><br><b><i>--regions <file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes only sites within genomic regions specified in the file (e.g., BED format).<br><br><b><i>--chr <chromosome></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Processes only variants on the specified chromosome.<br><br><b><i>--from-bp <pos></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the start base pair position for a genomic region filter.<br><br><b><i>--to-bp <pos></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the end base pair position for a genomic region filter.<br><br><b><i>--min-alleles <int></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes only sites with a minimum number of alleles.<br><br><b><i>--max-alleles <int></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes only sites with a maximum number of alleles.<br><br><b><i>--remove-indels</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes insertion/deletion variants, retaining only SNPs.<br><br><b><i>--min-maf <float></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters sites with a minor allele frequency (MAF) below the specified threshold (0.0-0.5).<br><br><b><i>--max-maf <float></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters sites with a minor allele frequency (MAF) above the specified threshold (0.0-0.5).<br><br><b><i>--max-missing <float></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters sites with a proportion of missing genotypes above the specified threshold (e.g., 0.5 for 50% missing data).<br><br><b><i>--min-meanDP <float></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters sites with a mean depth of coverage across individuals below the specified threshold.<br><br><b><i>--hardy</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Calculates and outputs Hardy-Weinberg equilibrium (HWE) statistics for each site.<br><br><b><i>--freq</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Calculates and outputs allele frequencies for each site.<br><br><b><i>--site-pi</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Calculates and outputs nucleotide diversity (Pi) per site.<br><br><b><i>--window-pi <size></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Calculates and outputs nucleotide diversity (Pi) in non-overlapping windows of specified size (in base pairs).<br><br><b><i>--fst <file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Calculates and outputs Fst between populations specified in the input file (e.g., with population assignments for individuals).<br><br><b><i>--diff-site <file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compares two VCF files and reports differences at shared sites.<br><br><b><i>--012</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs a genotype matrix where genotypes are represented as 0 (homozygous reference), 1 (heterozygous), or 2 (homozygous alternate), with -1 for missing data.<br><br><b><i>--force-index</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the creation of a VCF index file (.vcf.idx or .vcf.gz.tbi) if one doesn't exist, which can speed up region-based queries.<br><br><b><i>--remove-filtered-all</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes all sites that have anything in the FILTER column (i.e., are marked as failed by previous steps).<br><br>


title: DESCRIPTION
content:
<i>vcftools</i> is a powerful and versatile suite of command-line utilities designed for working with Variant Call Format (VCF) files, the standard for storing genomic sequence variations. It provides a wide array of functionalities for manipulating, analyzing, filtering, and summarizing VCF data. Users can perform tasks such as calculating genetic diversity statistics (e.g., allele frequencies, nucleotide diversity, Fst), filtering variants based on quality scores, allele frequencies, or missing data thresholds, extracting specific genomic regions or individuals, comparing VCF files, and converting between different formats. Its modular design allows users to chain commands for complex bioinformatics workflows, making it an indispensable tool for population genetics, medical genomics, and genetic association studies.


title: CAVEATS
content:
While powerful, <i>vcftools</i> can be memory-intensive for extremely large VCF files, especially when performing certain global statistics. Its performance may vary significantly depending on the specific analyses and filters applied. Some advanced statistical calculations (e.g., Fst, population-specific analyses) require additional input files defining population assignments or sample groups. Users should ensure their VCF files adhere strictly to the VCF specification for reliable processing.


title: COMMON WORKFLOWS
content:
<i>vcftools</i> is frequently used for quality control (e.g., removing low-quality variants or individuals, filtering by missing data or allele frequency), extracting subsets of data (e.g., specific chromosomes or regions), and calculating various population genetic statistics like allele frequencies, nucleotide diversity (Pi), and measures of population differentiation (Fst).


title: OUTPUT FILE NAMING
content:
When using the <i>--out</i> option, <i>vcftools</i> appends specific suffixes to the output files based on the operation performed. For instance, allele frequency output will be <i>&lt;prefix&gt;.frq</i>, Hardy-Weinberg equilibrium output will be <i>&lt;prefix&gt;.hwe</i>, and a recoded VCF will be <i>&lt;prefix&gt;.recode.vcf</i>. Users should be aware of these conventions for locating their results.


title: HISTORY
content:
Developed as part of the 1000 Genomes Project, <i>vcftools</i> quickly became a widely adopted standard for initial processing and quality control of VCF files. Its development addressed the growing need for a flexible command-line toolkit to handle the rapidly increasing volume of genomic variation data. It remains actively maintained and widely used in population genetics and clinical genomics due to its comprehensive feature set and ease of integration into bioinformatics pipelines.


title: PARAMETERS
content:
<b><i>&lt;vmid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The unique ID (e.g., 100, 101) of the virtual machine to interact with.<br><br><b>ping</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks if the QEMU Guest Agent is running and responsive inside the VM.<br><br><b>info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieves general information about the QEMU Guest Agent and its capabilities.<br><br><b>ip-addresses</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the IP addresses configured on the guest OS, including IPv4 and IPv6.<br><br><b>network-get-interfaces</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides detailed information about all network interfaces found in the guest, including MAC addresses, IP addresses, and status.<br><br><b>exec <i>&lt;command&gt;</i> [<i>&lt;args&gt;</i>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes an arbitrary command inside the guest VM. The command's output (stdout/stderr) and exit code are returned. Requires the command to be available in the guest's PATH or provided with a full path.<br><br><b>fsfreeze-freeze</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Requests the guest agent to freeze the guest's filesystems. This is crucial for creating consistent backups (snapshots) of the VM.<br><br><b>fsfreeze-thaw</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Requests the guest agent to thaw previously frozen filesystems, resuming normal I/O operations.<br><br><b>set-user-password <i>&lt;username&gt; &lt;password&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets or changes the password for a specified user account within the guest OS. This command should be used with caution.<br><br><b>shutdown</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Requests a graceful shutdown of the guest operating system. The VM will power off after the OS shuts down.<br><br><b>reboot</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Requests a graceful reboot of the guest operating system.<br><br><b>file-read <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads the content of a specified file from the guest filesystem and returns it. Path must be absolute.<br><br><b>file-write <i>&lt;path&gt; &lt;content&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the provided content to a specified file on the guest filesystem. Path must be absolute.<br><br><b>get-fsinfo</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieves information about the filesystems mounted within the guest, including mount points and total/used space.<br><br><b>get-osinfo</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieves general operating system information from the guest, such as OS name, version, and architecture.<br><br>


title: DESCRIPTION
content:
The term 'qm-guest' refers to the set of functionalities within Proxmox VE for interacting with the QEMU Guest Agent (<i>qemu-ga</i>) running inside a virtual machine.<br><br>While 'qm-guest' is not a standalone command, its capabilities are primarily accessed via the <b>qm guest</b> sub-command of the main <b>qm</b> (Proxmox Virtual Machine) utility. This interface allows administrators to perform various operations on the guest OS without direct network access, such as retrieving network configurations, querying OS information, executing commands, or managing filesystem freezes for backups. It is an essential tool for advanced VM management, automation, and backup consistency within a Proxmox environment, requiring <i>qemu-ga</i> to be installed and running in the guest.


title: CAVEATS
content:
<b>Prerequisites:</b> The QEMU Guest Agent (<i>qemu-ga</i>) must be installed and running inside the guest VM. Additionally, the 'QEMU Guest Agent' device must be enabled in the VM's hardware settings within Proxmox VE.<br><br><b>Security:</b> The <b>exec</b> and <b>set-user-password</b> commands grant significant control over the guest OS and should be used responsibly. Ensure that access to the Proxmox host and <b>qm guest</b> command is restricted.<br><br><b>Compatibility:</b> Filesystem freezing (<b>fsfreeze-freeze</b>/<b>thaw</b>) relies on guest OS support and typically works with common Linux filesystems (e.g., ext4, XFS) and Windows NTFS. Not all guest commands are supported on every operating system or <i>qemu-ga</i> version.


title: INSTALLATION AND CONFIGURATION (GUEST OS)
content:
For Linux guests, install the <i>qemu-guest-agent</i> package using your distribution's package manager (e.g., <code>apt install qemu-guest-agent</code> on Debian/Ubuntu, <code>yum install qemu-guest-agent</code> on RHEL/CentOS). For Windows guests, the agent can be installed via the VirtIO drivers ISO. After installation, ensure the service is running.<br><br>In Proxmox VE, ensure the 'QEMU Guest Agent' device is added to the VM's hardware configuration (VM Options -> QEMU Guest Agent -> Check 'Enabled').


title: COMMON USE CASES
content:
<ul><li><b>Automated IP Address Retrieval:</b> Easily get a VM's IP without logging in.</li><li><b>Consistent Backups:</b> Use <b>fsfreeze-freeze</b>/<b>thaw</b> with <b>vzdump</b> to ensure data integrity during backups.</li><li><b>Guest OS Management:</b> Gracefully shut down or reboot VMs, or execute maintenance scripts remotely.</li><li><b>Automation:</b> Script various guest operations for deployment or monitoring purposes.</li></ul>


title: HISTORY
content:
The QEMU Guest Agent (<i>qemu-ga</i>) was developed to improve interaction between the QEMU hypervisor and the guest operating system, bridging the gap for tasks like graceful shutdowns, network information retrieval, and filesystem freezing. Proxmox VE integrated this functionality deeply into its <b>qm</b> command-line utility, providing the <b>qm guest</b> sub-command suite. This integration evolved over Proxmox versions, adding more specific guest agent commands to enhance management capabilities and automation, especially for consistent backups.


title: TLDR
content:
<b>Print the status of a specific PID</b>`qm [[g|guest]] [[exec-s|exec-status]] [vm_id] [pid]`<br><b>Set a password for a specific user in a virtual machine interactively</b>`qm [[g|guest]] [[p|passwd]] [vm_id] [username]`<br><b>Execute a specific QEMU Guest Agent command</b>`qm [[g|guest]] [[c|cmd]] [virtual_machine_id] [fsfreeze-freeze|fsfreeze-status|fsfreeze-thaw|fstrim|get-fsinfo|...]`<br><b>Execute a specific command via a guest agent</b>`qm [[g|guest]] exec [vm_id] [command] [argument1 argument2 ...]`


title: PARAMETERS
content:
<b><i>N/A</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;This is not a standard Linux command, so no general parameters are defined.<br><br>


title: DESCRIPTION
content:
The command <i>snap.esa</i> is not recognized as a standard Linux command or a common subcommand of the <i>snap</i> package manager. <br><br>The <i>snap</i> command itself refers to <b>Snapcraft</b>, a universal packaging system developed by Canonical for Linux. It allows software developers to package their applications with all dependencies into a single 'snap' package that can be deployed across various Linux distributions. However, <i>.esa</i> is not a known subcommand, option, or a standard related utility within the Linux ecosystem when combined with <i>snap</i>.<br><br>It is highly probable that <i>snap.esa</i> refers to a custom script, an internal tool specific to an organization (e.g., the European Space Agency, if 'ESA' is an acronym relevant to the context), or a very specialized application that is not part of general Linux distributions' core utilities.


title: CAVEATS
content:
As <i>snap.esa</i> is not a standard Linux command, its behavior, existence, and any potential side effects are undefined in a general Linux environment. Users encountering this command should investigate its origin within their specific system, as it likely represents a custom script, an application-specific utility, or an alias rather than a system-wide standard tool. Attempting to run it without understanding its purpose could lead to unexpected results or errors.


title: NOTE ON NAMING
content:
The 'snap' component of <i>snap.esa</i> generally refers to the <b>Snapcraft</b> package manager. The '.esa' suffix is highly unusual for standard Linux commands and is not indicative of a common command-line utility. It might suggest a file extension, an acronym (e.g., European Space Agency, a common acronym for ESA), or a specific project identifier, implying a non-standard or custom-built tool.


title: HISTORY
content:
There is no public history or development record for a standard Linux command named <i>snap.esa</i> because it is not a part of the standard Linux utility set. The 'snap' package manager, however, was first released in 2014 by Canonical and has since evolved significantly as a cross-distribution packaging format.


title: PARAMETERS
content:
<b><i>&lt;vmid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The numeric ID of the virtual machine to interact with.<br><br><b><i>&lt;command&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The specific guest agent command to execute. This can be one of many operations supported by the QEMU Guest Agent. Common commands include <b>ping</b>, <b>network-get-interfaces</b>, <b>get-fsinfo</b>, <b>fstrim</b>, <b>fsfreeze-freeze</b>, <b>fsfreeze-thaw</b>, <b>exec</b>, and <b>set-password</b>.<br><br><b><i>ping</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks connectivity to the QEMU Guest Agent within the VM. Useful for verifying the agent's status.<br><br><b><i>network-get-interfaces</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieves detailed information about the network interfaces configured within the guest OS, including IP addresses.<br><br><b><i>get-fsinfo</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Obtains information about the filesystems mounted inside the guest VM.<br><br><b><i>fstrim</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends an <I>fstrim</I> command to the guest, useful for SSDs and thin-provisioned storage to reclaim unused blocks.<br><br><b><i>fsfreeze-freeze</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Freezes the filesystems inside the guest, preparing them for a consistent snapshot. This is crucial for application-consistent backups.<br><br><b><i>fsfreeze-thaw</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Thaws previously frozen filesystems inside the guest, resuming normal I/O operations.<br><br><b><i>exec --command &lt;cmd&gt; [--input &lt;data&gt;] [--timeout &lt;sec&gt;]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a specified command within the guest OS. Output, error streams, and exit codes can be retrieved. Requires careful use due to security implications.<br><br><b><i>set-password --user &lt;username&gt; --password &lt;pass&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Changes the password for a specified user account within the guest OS. Highly useful for password management and automation.<br><br>


title: DESCRIPTION
content:
The <b>qm-agent</b> command, part of the Proxmox VE command-line interface, facilitates communication between the Proxmox host and the QEMU Guest Agent daemon running inside a virtual machine. This powerful tool allows administrators to perform various operations within the guest OS without direct network access or SSH, provided the QEMU Guest Agent is installed and actively running within the VM. It is essential for advanced VM management, enabling features such as querying guest IP addresses, gracefully freezing/thawing filesystems for consistent backups, executing commands inside the guest, and managing user passwords. Its capabilities significantly enhance automation and reliability for virtualized environments, especially in scenarios requiring precise interaction with the guest's internal state.


title: CAVEATS
content:
For <b>qm-agent</b> commands to function, the QEMU Guest Agent must be <I>installed</I> and <I>running</I> inside the virtual machine, and the 'Qemu Agent' option must be <I>enabled</I> in the VM's configuration on the Proxmox host. Without the agent, host-guest communication via this command is not possible. Not all guest OSes fully support all agent commands, and some commands (like <b>exec</b>) require appropriate permissions and security considerations within the guest.


title: QEMU GUEST AGENT INSTALLATION
content:
To enable <b>qm-agent</b> functionality, install the QEMU Guest Agent inside your VM:<br><br><i>For Debian/Ubuntu/Proxmox LXC:</i> sudo apt update && sudo apt install qemu-guest-agent<br><i>For RHEL/CentOS/Fedora:</i> sudo dnf install qemu-guest-agent or sudo yum install qemu-guest-agent<br><i>For Windows:</i> Download the MSI installer from the <I>virtio-win</I> ISO (typically mounted as a CD-ROM in Windows VMs) and run qemu-ga-x86_64.msi. Ensure the service starts automatically.


title: PROXMOX VM CONFIGURATION
content:
After installing the agent in the guest, ensure it's enabled in the VM's Proxmox configuration. This can be done via the web UI (VM -> Options -> Qemu Agent) or via CLI:<br>qm set &lt;vmid&gt; --agent 1<br>A reboot of the VM is often recommended after these changes for the agent to fully initialize and communicate with the host.


title: HISTORY
content:
The QEMU Guest Agent and its integration via tools like <b>qm-agent</b> are integral parts of the Proxmox Virtual Environment's evolution. As Proxmox VE grew in features and stability, the need for robust host-guest communication became paramount for advanced functionalities like live migration, consistent backups, and enhanced monitoring. The <b>qm-agent</b> utility emerged as a CLI-driven method to leverage these capabilities, continuously refined with new agent features and improved reliability across various guest operating systems.


title: SYNOPSIS
content:
<b>snap</b> [<I>OPTIONS</I>] <I>COMMAND</I> [<I>ARGS...</I>]<br><br>Common Commands:<br><b>snap install</b> <I>snap_name</I> [<I>options</I>]<br><b>snap remove</b> <I>snap_name</I> [<I>options</I>]<br><b>snap refresh</b> <I>snap_name</I> [<I>options</I>]<br><b>snap list</b><br><b>snap find</b> [<I>search_term</I>]<br><b>snap info</b> <I>snap_name</I><br><b>snap run</b> <I>snap_name</I>.<I>app_name</I>


title: PARAMETERS
content:
<b><b>install</b> <I>snap_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a snap from the Snap Store or a local file.<br><br><b><b>remove</b> <I>snap_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes an installed snap from the system.<br><br><b><b>refresh</b> <I>snap_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates an installed snap to its latest available revision.<br><br><b><b>list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all currently installed snaps along with their versions and health status.<br><br><b><b>find</b> [<I>search_term</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for snaps in the Snap Store. If no term is provided, lists popular snaps.<br><br><b><b>info</b> <I>snap_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about a specific snap, including its publisher, interfaces, and channels.<br><br><b><b>run</b> <I>snap_name</I>.<I>app_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a specific application or command provided by an installed snap.<br><br><b><b>connect</b> <I>plug</I> <I>slot</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects a snap interface 'plug' to a 'slot', allowing the snap to access specific system resources.<br><br><b><b>disconnect</b> <I>plug</I> <I>slot</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disconnects a snap interface, revoking access to specific system resources.<br><br><b><b>revert</b> <I>snap_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reverts a snap to its previously installed revision, useful for troubleshooting updates.<br><br><b><b>set</b> <I>snap_name</I> <I>key</I>=<I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets configuration options for a specific snap.<br><br><b><b>get</b> <I>snap_name</I> <I>key</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieves the value of a configuration option for a snap.<br><br><b>--<I>classic</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>install</b> to allow installation of snaps that require 'classic' confinement (less strict security).<br><br><b>--<I>devmode</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>install</b> to allow installation of snaps in 'development mode' (no confinement, for debugging).<br><br><b>--<I>channel</I> <I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the release channel (e.g., <I>stable</I>, <I>candidate</I>, <I>beta</I>, <I>edge</I>) from which to install or refresh a snap.<br><br><b>--<I>revision</I> <I>number</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a particular revision number to install or revert to.<br><br><b>--<I>no-wait</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs the operation in the background and returns immediately without waiting for completion.<br><br>


title: DESCRIPTION
content:
The <b>snap</b> command is the primary interface for interacting with the Snap packaging system on Linux. Snaps are <I>self-contained software packages</I> that bundle an application and all its dependencies, ensuring it runs reliably across various Linux distributions. The <b>snap</b> command allows users to <I>install, update, remove, and manage</I> snaps, as well as interact with the <I>Snap Store</I>. It handles package isolation, automatic updates, and rollback capabilities, making software deployment simpler and safer. Snaps are confined using technologies like <I>AppArmor</I> and <I>seccomp</I>, enhancing system security by limiting application access to system resources. This modern packaging format aims to provide a universal solution for distributing Linux applications, similar to app stores on mobile platforms. It integrates deeply with <I>systemd</I> for service management and uses a transaction-based system for updates, ensuring system stability.


title: CAVEATS
content:
While offering significant advantages, <b>snap</b> also has some considerations:<br><b><I>Confinement Limitations</I></b>: Snaps run in isolated environments, which can sometimes restrict access to certain system resources, traditional file paths, or interact with other non-snap applications directly without explicit interface connections.<br><b><I>Disk Space Usage</I></b>: Due to their self-contained nature and the retention of older revisions for rollback, snaps can consume more disk space compared to traditionally packaged applications.<br><b><I>Automatic Updates</I></b>: Snaps update automatically in the background by default. While convenient, this can occasionally occur at inconvenient times or introduce unexpected changes. Users have limited control over the exact timing of these updates.


title: <I>CONFINEMENT AND INTERFACES</I>
content:
Snaps are designed to be isolated from the rest of the system for security. This isolation is achieved through <I>confinement</I> (e.g., using <I>AppArmor</I> and <I>seccomp</I>). Communication with the system and other snaps happens via well-defined <I>interfaces</I>. Users might need to manually connect or disconnect interfaces for certain functionalities using <b>snap connect</b> or <b>snap disconnect</b>.


title: <I>CHANNELS AND REVISIONS</I>
content:
Snaps are distributed via different <I>channels</I> (<b>stable</b>, <b>candidate</b>, <b>beta</b>, <b>edge</b>) which represent varying levels of stability. Users can choose a channel when installing or refreshing a snap using the <b>--channel</b> option. Additionally, the <b>snap</b> system keeps track of <I>revisions</I> for each snap, allowing users to revert to a previous working version if an update causes issues using <b>snap revert</b>.


title: HISTORY
content:
The <b>snap</b> packaging system was developed by <I>Canonical</I>, the company behind Ubuntu Linux. It was initially introduced in <I>2014</I> as a universal package format for <I>Ubuntu Touch</I> and later expanded to desktop Linux, gaining significant adoption from around <I>2016-2017</I>. The primary motivation was to address the challenges of software distribution fragmentation across different Linux distributions and to provide a more secure, isolated, and automatically updating application delivery mechanism, akin to mobile app stores. Over time, it has become a core component of Ubuntu and is supported on many other Linux distributions, with a growing number of applications available in the <I>Snap Store</I>.


title: SEE ALSO
content:
<b>apt</b>(8), <b>dnf</b>(8), <b>yum</b>(8), <b>flatpak</b>(1), <b>dpkg</b>(8), <b>rpm</b>(8), <b>snapd</b>(8)


title: TLDR
content:
<b>Search for a package</b>`snap find [query]`<br><b>Install a package</b>`snap install [package]`<br><b>Update a package</b>`snap refresh [package]`<br><b>Update a package to another channel (track, risk, or branch)</b>`snap refresh [package] --channel=[channel]`<br><b>Update all packages</b>`snap refresh`<br><b>Display basic information about installed snap software</b>`snap list`<br><b>Uninstall a package</b>`snap remove [package]`<br><b>Check for recent snap changes in the system</b>`snap changes`


title: PARAMETERS
content:
<b><i>&lt;vmid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The unique ID (Virtual Machine ID) for the new container. Must be an integer and not currently in use by another VM or container.<br><br><b><i>&lt;template&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path or ID of the LXC template file (e.g., <i>local:vztmpl/debian-11-standard_11.0-1_amd64.tar.gz</i>). Templates can be downloaded using <b>pveam</b>.<br><br><b>--arch <i>&lt;architecture&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Container architecture (e.g., <i>amd64, arm64</i>). Defaults to host architecture.<br><br><b>--cores <i>&lt;integer&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of CPU cores allocated to the container.<br><br><b>--cpuunits <i>&lt;integer&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;CPU weight for fairness scheduling (higher value means more CPU time, default is 1024).<br><br><b>--memory <i>&lt;integer&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;RAM in MB allocated to the container.<br><br><b>--swap <i>&lt;integer&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Swap space in MB allocated to the container.<br><br><b>--rootfs <i>&lt;volume&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disk volume for the container's root filesystem (e.g., <i>local-lvm:4G</i> or <i>local-zfs:pool/subvol,size=8G</i>). Specifies storage and size.<br><br><b>--storage <i>&lt;storage_id&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The storage where the rootfs will be created if not explicitly specified in <i>--rootfs</i>. For example, <i>local-lvm</i>.<br><br><b>--hostname <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hostname for the container.<br><br><b>--net<i>&lt;n&gt;</i> <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Network device configuration. Multiple devices can be specified (e.g., <i>--net0 name=eth0,bridge=vmbr0,ip=dhcp</i>).<br>Use <i>ip</i> for static IP, <i>ip=dhcp</i> for DHCP.<br><br><b>--password <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Password for the root user inside the container.<br><br><b>--unprivileged <i>&lt;0|1&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create an unprivileged container (<i>1</i> for yes, <i>0</i> for no). Defaults to <i>0</i> (privileged).<br><br><b>--ostype <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operating system type (e.g., <i>debian, ubuntu, centos</i>). Automatically detected from template if not specified.<br><br><b>--onboot <i>&lt;0|1&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start the container automatically on host boot (<i>1</i> for yes, <i>0</i> for no).<br><br><b>--start <i>&lt;0|1&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start the container immediately after creation (<i>1</i> for yes, <i>0</i> for no). Defaults to <i>0</i>.<br><br><b>--description <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A descriptive note for the container.<br><br><b>--ip<i>&lt;n&gt;</i> <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;IP address(es) for network device <i>n</i>. Can be <i>dhcp</i> or <i>&lt;IP&gt;/&lt;CIDR&gt;</i> (e.g., <i>192.168.1.10/24</i>). Requires <i>--net&lt;n&gt;</i> to be defined.<br><br><b>--gw <i>&lt;IP&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Default gateway IP address. Typically used with static IP configurations.<br><br><b>--nameserver <i>&lt;IP&gt;[,&lt;IP&gt;...]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Comma-separated list of DNS server IP addresses.<br><br><b>--searchdomain <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;DNS search domain.<br><br><b>--ssh-public-keys <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file containing SSH public keys to add to the root user's <i>authorized_keys</i> inside the container for remote access.<br><br><b>--tags <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Comma-separated list of tags for the container, used for organization and filtering.<br><br>


title: DESCRIPTION
content:
The <b>pct create</b> command is a fundamental utility within the Proxmox Virtual Environment (PVE) for deploying Linux Containers (LXC). It enables users to quickly provision new lightweight virtualized environments based on pre-downloaded OS templates. Unlike full virtualization (like KVM), LXC containers share the host kernel, resulting in lower overhead and faster startup times, making them ideal for microservices, application hosting, and testing environments.<br><br>This command allows for extensive customization during container creation, including defining the container's unique ID (VMID), selecting the operating system template, allocating CPU cores and memory, configuring network interfaces (IP addresses, gateways, DNS), setting up storage for the root filesystem, and specifying various other operational parameters like hostname, startup behavior, and security features. By leveraging templates, <b>pct create</b> simplifies the deployment process, allowing for consistent and repeatable container setups across a Proxmox cluster.


title: CAVEATS
content:
Creating LXC containers requires sufficient system resources (CPU, RAM, storage) on the Proxmox host. VMIDs must be unique across all VMs and containers on the cluster. Network configurations need to be carefully planned to avoid IP conflicts. Unprivileged containers offer enhanced security by preventing root in the container from gaining root on the host, but they may have limitations with certain advanced features or mounting specific types of filesystems without additional configuration.


title: LXC TEMPLATES
content:
Before creating a container, you typically need an LXC template. These templates are pre-built root filesystems for various operating systems (e.g., Debian, Ubuntu, CentOS) and are usually downloaded from Proxmox's template repositories using the <b>pveam download</b> command (e.g., <i>pveam download local debian-11-standard_11.0-1_amd64.tar.gz</i>). The <i>&lt;template&gt;</i> argument in <b>pct create</b> refers to the path of this downloaded template on a storage identified by Proxmox.


title: PRIVILEGED VS. UNPRIVILEGED CONTAINERS
content:
By default, <b>pct create</b> generates a 'privileged' container (<i>--unprivileged 0</i>). In a privileged container, the root user inside the container is also root on the host, which poses a security risk. 'Unprivileged' containers (<i>--unprivileged 1</i>) map the container's root user to an unprivileged user on the host, significantly enhancing security. While unprivileged containers are recommended for production, they might require specific configurations for certain operations (e.g., mounting NFS shares, running Docker) due to stricter permission management.


title: RESOURCE ALLOCATION
content:
<b>pct create</b> allows precise allocation of resources like CPU cores, memory, and disk space. It's crucial to set these limits appropriately to prevent a single container from monopolizing host resources and affecting other VMs/containers. Proxmox uses cgroups to enforce these limits. For disk, <b>--rootfs</b> allows specifying the storage pool and size, while <b>--storage</b> can be used to just pick a storage pool for the default size, enabling flexible storage management.


title: HISTORY
content:
The <b>pct</b> command is an integral part of Proxmox Virtual Environment, which has been under active development since its initial release in 2007. Proxmox VE introduced LXC container support as a lightweight virtualization alternative to KVM virtual machines, leveraging Linux container technology for efficient resource utilization. The <b>pct</b> command-line tool was developed to provide a comprehensive and user-friendly interface for managing these LXC containers, mirroring the functionality available through the Proxmox web GUI. Its evolution has focused on integrating new LXC features, improving resource management, and enhancing security aspects like unprivileged containers.


title: TLDR
content:
<b>Create a container from a template with 4GB size, give it 512MiB of memory and unlimited access to CPU</b>`pct [[cr|create]] [100] [local:vztmpl/distro-name.tar.zst] --rootfs [local-lvm]:4`<br><b>Create a container from a template and give it a specific memory limit in megabytes</b>`pct [[cr|create]] [100] [local:vztmpl/distro-name.tar.zst] --rootfs [local-lvm]:[4] --memory [8192]`<br><b>Create a container from a template and give it a hostname and a password</b>`pct [[cr|create]] [100] [local:vztmpl/distro-name.tar.zst] --rootfs [local-lvm]:[4] --hostname [hostname] --password [password]`<br><b>Create a container from a template and give it network access</b>`pct [[cr|create]] [100] [local:vztmpl/distro-name.tar.zst] --rootfs [local-lvm]:[4] --net0 name=[eth0],bridge=[vmbr0],ip=[dhcp|manual|10.0.0.1/24] --features nesting=1`<br><b>Start a container immediately after creation</b>`pct [[cr|create]] [100] [local:vztmpl/distro-name.tar.zst] --rootfs [local-lvm]:[4] --start`


title: SYNOPSIS
content:
<b>pct clone</b> <i>&lt;vmid&gt; &lt;newid&gt;</i> [<i>OPTIONS</i>]<br><i>&lt;vmid&gt;</i>: The ID of the source LXC container.<br><i>&lt;newid&gt;</i>: The desired ID for the new cloned LXC container.


title: PARAMETERS
content:
<b>--full</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a full, independent copy of the container's disk, consuming more space and time but ensuring no dependency on the source.<br><br><b>--snapshot <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a linked clone from a specific snapshot of the source container, if snapshots are available.<br><br><b>--storage <id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target storage for the new container's disk. If omitted, the source container's storage is used.<br><br><b>--format <fmt></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the disk image format (e.g., <code>raw</code>, <code>qcow2</code>) for the new container's disk.<br><br><b>--target-node <node></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the Proxmox node where the cloned container will be created. Necessary for cross-node cloning.<br><br><b>--description <text></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a descriptive text for the new container, visible in the Proxmox UI.<br><br><b>--hostname <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the hostname for the newly created container. If not specified, the old hostname might be kept or derived.<br><br><b>--size <size></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjusts the disk size of the new container's root filesystem. Accepts units like 'G' for Gigabytes.<br><br><b>--bwlimit <rate></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the bandwidth used for disk operations during cloning in KB/s. Useful for large clones over busy networks.<br><br><b>--ignore-lock</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Proceeds with cloning even if the source container is locked. Use with caution as it may lead to inconsistent clones.<br><br>


title: DESCRIPTION
content:
The <b>pct-clone</b> command is a core utility within the Proxmox Virtual Environment (PVE) suite, designed to efficiently duplicate existing Linux Containers (LXC). This command is indispensable for administrators needing to quickly provision new containers based on a pre-configured template, or to create a snapshot-like backup for testing purposes.<br><br>It offers two primary cloning methods: <i>linked clones</i> and <i>full clones</i>. Linked clones, the default behavior when supported by the storage backend (e.g., ZFS, LVM-Thin, Ceph), are extremely fast and space-efficient as they only store the differences from the original container's disk image. However, they remain dependent on the source container's integrity. Full clones, specified with the <code>--full</code> option, create a completely independent copy of the container's disk, making it self-contained and easily movable, though it consumes more disk space and takes longer to create. This flexibility makes <b>pct-clone</b> a powerful tool for rapid deployment and environment management in Proxmox.


title: CAVEATS
content:
When using <i>linked clones</i>, the new container remains dependent on the original source container and its disk image. Deleting the source or specific snapshots can render the linked clone unusable. <i>Full clones</i>, while independent, consume significantly more disk space and take longer to create. Always ensure sufficient disk space on the target storage before initiating a clone operation. Cloning a running container without using a snapshot might result in an inconsistent state in the cloned instance.


title: <I>CLONE TYPES EXPLAINED</I>
content:
<i><b>Linked Clones</b></i>: These are the default for snapshot-capable storage. They are extremely fast and space-efficient as they only store changes relative to the original. Ideal for quick test environments, but dependent on the source.<br><br><i><b>Full Clones</b></i>: Created using the <code>--full</code> option, these are completely independent copies of the container's disk. They consume more space and time but offer full autonomy and are easily migratable without source dependencies.


title: HISTORY
content:
The <b>pct-clone</b> command is an integral part of the Proxmox Virtual Environment (PVE) project, which has been under continuous development since its inception. As PVE evolved to support Linux Containers (LXC) natively, tools like <b>pct-clone</b> were developed to provide robust and flexible management capabilities, becoming a cornerstone for efficient container deployment and replication within the Proxmox ecosystem.


title: TLDR
content:
<b>Clone a container</b>`pct clone [template_id] [copy_id]`<br><b>Clone a container with a custom name</b>`pct [[cl|clone]] [template_id] [copy_id] --hostname [host_name]`


title: PARAMETERS
content:
<b><b>list</b> [<I>--vmid &lt;VMID&gt;</I>] [<I>--storage &lt;STORAGE&gt;</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all virtual machine disks. Optionally filters by <I>VMID</I> to show disks for a specific VM, or by <I>STORAGE</I> to show disks located on a particular storage.<br><br><b><b>resize</b> <I>&lt;VMID&gt; &lt;DISK&gt; &lt;SIZE&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resizes a virtual machine disk. <I>&lt;VMID&gt;</I> specifies the VM, <I>&lt;DISK&gt;</I> identifies the disk (e.g., <b>scsi0</b>, <b>sata0</b>), and <I>&lt;SIZE&gt;</I> is the new size (e.g., <b>100G</b>, <b>+10G</b> for growth). Note that online resize depends on the disk type and guest OS support.<br><br><b><b>move</b> <I>&lt;VMID&gt; &lt;DISK&gt; &lt;TARGET_STORAGE&gt;</I> [<I>--delete</I>] [<I>--format &lt;FORMAT&gt;</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Moves a virtual machine disk to a different storage. <I>&lt;VMID&gt;</I> is the VM, <I>&lt;DISK&gt;</I> is the disk to move, and <I>&lt;TARGET_STORAGE&gt;</I> is the name of the destination storage. Use <I>--delete</I> to remove the source disk after a successful move. <I>--format</I> allows specifying the target image format (e.g., <b>qcow2</b>, <b>raw</b>).<br><br><b><b>image-id</b> <I>&lt;VMID&gt; &lt;DISK&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieves the full image ID for a specified VM disk.<br><br><b><b>image-properties</b> <I>&lt;IMAGEID&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed properties and configuration for a given disk image using its full <I>IMAGEID</I>.<br><br>


title: DESCRIPTION
content:
The <b>qm disk</b> command is a specialized subcommand of the Proxmox VE <b>qm</b> utility, providing comprehensive tools for managing virtual machine disk images. It centralizes and simplifies various disk-related operations that are crucial for efficient VM administration.<br><br>Administrators utilize <b>qm disk</b> to perform tasks such as:<br><ul><li>Listing all attached VM disks across different storage types.</li><li>Resizing virtual disk volumes, allowing for dynamic adjustment of storage capacity.</li><li>Moving disk images between diverse storage backends (e.g., local, LVM, ZFS, NFS, iSCSI, Ceph), facilitating storage optimization and migration strategies.</li><li>Inspecting detailed properties of disk images.</li></ul><br>This command is indispensable for maintaining the health, performance, and flexibility of virtualized environments within Proxmox VE, automating complex storage interactions.


title: CAVEATS
content:
<ul><li><b>Context Specific:</b> This command is part of Proxmox VE and is not available on standard Linux distributions without Proxmox installed.</li><li><b>Data Loss Risk:</b> Operations like <b>resize</b> or <b>move</b> can lead to data loss if not used carefully, especially when combined with options like <I>--delete</I>. Always ensure backups before critical operations.</li><li><b>VM State:</b> For certain operations, the VM may need to be shut down to prevent data corruption or ensure consistency.</li><li><b>Permissions:</b> Requires appropriate Proxmox VE user permissions to execute disk management tasks.</li></ul>


title: DISK IDENTIFICATION
content:
Virtual disks are typically identified by a combination of their controller type and index, such as <b>scsi0</b>, <b>virtio0</b>, <b>sata0</b>, or <b>ide0</b>. For standalone disk images not currently attached to a VM, or for operations requiring direct image reference, the full image ID (e.g., <I>local-lvm:vm-100-disk-0</I>) is used.


title: SUPPORTED STORAGE TYPES
content:
<b>qm disk</b> can interact with disks residing on various Proxmox storage types, including: <I>Local Directory</I>, <I>LVM</I>, <I>LVM-Thin</I>, <I>ZFS</I>, <I>NFS</I>, <I>iSCSI</I>, and <I>Ceph RBD</I>. The behavior and capabilities of disk operations might vary slightly depending on the underlying storage technology.


title: HISTORY
content:
The <b>qm disk</b> subcommand emerged as an evolution within the Proxmox VE project, aiming to consolidate and streamline complex virtual disk management tasks. Initially, many disk operations were performed indirectly through <b>qm set</b> or by directly manipulating files on underlying storage. The introduction of the dedicated <b>disk</b> subcommand provided a more intuitive, robust, and unified interface for administrators, significantly enhancing usability and simplifying the lifecycle management of VM storage within the Proxmox ecosystem. This development reflects Proxmox's commitment to providing comprehensive and user-friendly virtualization management tools.


title: TLDR
content:
<b>Add n gigabytes to a virtual disk</b>`qm [[di|disk]] [[resi|resize]] [vm_id] [disk_name] +[n]G`<br><b>Move a virtual disk</b>`qm [[di|disk]] [[m|move]] [vm_id] [destination] [index]`<br><b>Delete the previous copy of the virtual disk</b>`qm [[di|disk]] [[m|move]] --delete [vm_id] [destination] [index]`<br><b>Import a VMDK/qcow2/raw disk image using a specific storage name</b>`qm [[di|disk]] [[i|import]] [vm_id] [path/to/disk] [storage_name] --format [qcow2|raw|vmdk]`


title: SYNOPSIS
content:
<b>bindfs</b> [<i>OPTIONS</i>] <i>ORIGINAL_DIR</i> <i>MOUNT_POINT</i><br><b>bindfs</b> <i>--help</i><br><b>bindfs</b> <i>--version</i>


title: PARAMETERS
content:
<b>--uid &lt;uid&gt;, -u &lt;uid&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the owner UID for all files and directories visible through the mount point.<br><br><b>--gid &lt;gid&gt;, -g &lt;gid&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the owner GID for all files and directories visible through the mount point.<br><br><b>--perms &lt;permissions&gt;, -p &lt;permissions&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the permissions for all files and directories. Can be octal (e.g., 755) or symbolic (e.g., u=rwX,go=rX).<br><br><b>--create-for-user &lt;user&gt;, -m &lt;user&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the user (by name or UID) who will own newly created files and directories.<br><br><b>--create-for-group &lt;group&gt;, -M &lt;group&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the group (by name or GID) which will own newly created files and directories.<br><br><b>--create-perms &lt;permissions&gt;, -P &lt;permissions&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the permissions for newly created files and directories (octal or symbolic).<br><br><b>--user-map &lt;from_uid&gt;/&lt;to_uid&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Maps a specific UID from the original directory to a different UID at the mount point. Can be specified multiple times.<br><br><b>--group-map &lt;from_gid&gt;/&lt;to_gid&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Maps a specific GID from the original directory to a different GID at the mount point. Can be specified multiple times.<br><br><b>--force-user &lt;user&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces all files and directories to be owned by the specified user (name or UID), overriding any other user rules.<br><br><b>--force-group &lt;group&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces all files and directories to be owned by the specified group (name or GID), overriding any other group rules.<br><br><b>--mirror-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Makes the bindfs mount read-only and ensures that the visible owner, group, and permissions exactly mirror the underlying files.<br><br><b>--allow-recursion</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows mounting a bindfs over another bindfs mount point, enabling layered transformations.<br><br><b>-o &lt;options&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes comma-separated FUSE-specific options directly to the FUSE kernel module (e.g., <i>allow_other</i>, <i>default_permissions</i>, <i>ro</i>).<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs bindfs in the foreground; it will not daemonize.<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug output, showing detailed FUSE operations.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays usage information and exits.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br>


title: DESCRIPTION
content:
<b>bindfs</b> is a powerful FUSE (Filesystem in Userspace) program that allows you to create a virtual view of an existing directory. Unlike a standard <b>mount --bind</b> operation, <b>bindfs</b> can dynamically alter the permissions, ownership, and other file attributes of the content <i>as seen through the mount point</i>, without modifying the original files or directories. This makes it invaluable for scenarios where you need to present different access rights or ownerships for a set of files to different users or applications. For instance, a web server might require read-only access to specific files, while the original files need write access by an administrator. <b>bindfs</b> acts as an on-the-fly translator, intercepting filesystem operations and applying configured rules. It's commonly used in shared development environments, web hosting, or to bridge permission discrepancies between host systems and containerized applications. It provides flexibility and enhanced security by allowing fine-grained control over how a directory's contents appear to users accessing it via the <b>bindfs</b> mount.


title: CAVEATS
content:
<b>Performance Overhead</b>: Being a FUSE filesystem, <b>bindfs</b> introduces a slight performance overhead compared to direct filesystem access or native <b>mount --bind</b> operations, as every file operation is intercepted and processed in userspace.<br><b>Virtual, Not Actual Changes</b>: The permission and ownership changes applied by <b>bindfs</b> are only virtual; the original files and directories on the underlying filesystem remain untouched. This distinction can sometimes lead to confusion if users access the original path directly.<br><b>ACLs</b>: <b>bindfs</b> primarily works with traditional Unix permissions. While it attempts to translate ACLs to an extent, it might not provide full ACL functionality or perfect mapping for complex scenarios.<br><b>Requires FUSE Module</b>: The FUSE kernel module must be loaded on the system for <b>bindfs</b> to function correctly.


title: COMMON USE CASES
content:
<ul><li><i>Web servers</i>: Providing restricted read-only access to web roots while developers maintain write access to original files.</li><li><i>Shared development environments</i>: Allowing multiple users with different UIDs/GIDs to collaborate on the same codebase, where <b>bindfs</b> normalizes permissions.</li><li><i>Containerization</i>: Bridging permission mismatches between host volumes and container expectations (e.g., a container user 'nginx' with UID 101 needs access to host files owned by 'root' or a different UID).</li><li><i>Security hardening</i>: Presenting a directory with more restrictive permissions to a specific application or service.</li></ul>


title: HOW IT WORKS
content:
<b>bindfs</b> operates as a FUSE filesystem. When you mount a directory with <b>bindfs</b>, it acts as an intermediary. Any attempt to access files or directories through the <b>bindfs</b> mount point is intercepted by the <b>bindfs</b> process. This process then consults its internal rules (configured via command-line options) and presents a modified view of the underlying files' attributes (permissions, ownership, etc.) to the requesting application or user. The actual files on the original filesystem remain unchanged. When a write operation occurs, <b>bindfs</b> translates it back to the original filesystem, respecting its rules for new file creation or attribute modification if configured.


title: HISTORY
content:
<b>bindfs</b> was created by Martin F. Krafft and first released around 2008. It emerged to address a significant limitation of the standard <b>mount --bind</b> command, which allows binding a directory to another location but does not provide any means to modify the attributes (like permissions or ownership) of the files visible through the new mount point. <b>bindfs</b> filled this gap by leveraging the FUSE framework, enabling user-space manipulation of filesystem attributes. Its development provided a flexible solution for scenarios requiring permission translation on the fly, quickly becoming a go-to tool for specific system administration and development environment needs.


title: TLDR
content:
<b>Mount a directory with same permissions</b>`sudo bindfs [path/to/directory] [path/to/mount_point]`<br><b>Map filesystem objects owned by user1 to be owned by user2 (also applies in reverse to newly created files)</b>`sudo bindfs --map=[user1]/[user2] [path/to/directory] [path/to/mount_point]`<br><b>Unmount a directory</b>`sudo umount [path/to/mount_point]`


title: PARAMETERS
content:
<b><i>&lt;vmid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The ID of the virtual machine (an integer ranging from 1 to 999999999) to which the console connection should be established.<br><br><b><b>--console</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to the serial console of the virtual machine. This is often the default behavior if not specified, provided the VM has a serial port configured.<br><br><b><b>--type</b> <i>&lt;console|vga&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly specifies the type of console to connect to.<br><i>console</i>: Connects to the serial console, suitable for text-based interactions.<br><i>vga</i>: Connects to the graphical (VGA) console, requiring a graphical setup (like SPICE or VNC) for the VM and a compatible viewer.<br><br><b><b>--vga</b> <i>&lt;integer&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When connecting to a graphical console (using <b>--type vga</b>), this option specifies the VGA console ID. This is particularly useful for virtual machines configured with multiple virtual displays.<br><br>


title: DESCRIPTION
content:
<i>qm-terminal</i> is a Proxmox VE command-line utility that allows users to connect directly to the console of a running virtual machine (VM). It provides a convenient way to interact with the guest operating system without needing a graphical interface or SSH access to the guest itself. This command is particularly useful for debugging, initial setup, or when network access to the guest is unavailable. It effectively acts as a serial or display console depending on the type and configuration of the virtual machine.


title: CAVEATS
content:
This command requires an active Proxmox VE installation and appropriate user permissions on the host system. The target virtual machine must be in a running state to establish a console connection. For graphical console access (via <b>--type vga</b>), the VM must have a graphical interface configured (e.g., SPICE or VNC) and a client capable of rendering it. Serial console access might also require specific configuration within the guest operating system for full functionality.


title: INTERACTIVE SESSION
content:
<i>qm-terminal</i> provides a direct, interactive text-based console session to the virtual machine. This is analogous to connecting a serial cable to a physical server's serial port, allowing low-level interaction with the guest operating system, even before network services are fully initialized.


title: DEBUGGING TOOL
content:
It is an indispensable tool for debugging critical issues such as boot failures, network configuration problems, or when the guest operating system is unresponsive and traditional network-based access methods (like SSH) are not available.


title: HISTORY
content:
The <b>qm</b> command family, including <b>qm-terminal</b>, is an integral part of Proxmox VE, an open-source virtualization management solution that first emerged around 2007. As Proxmox VE is built upon QEMU and KVM for virtual machine management, <b>qm-terminal</b> evolved to provide direct console access capabilities, adapting to the underlying virtualization technologies. It has been a core tool for managing and troubleshooting virtual machines directly from the Proxmox host since early versions of the platform.


title: TLDR
content:
<b>Create a new initramfs (use all for all installed kernel versions)</b>`sudo update-initramfs -c -k [kernel_version]`<br><b>Update an existing initramfs</b>`sudo update-initramfs -u`<br><b>Remove an existing initramfs (be careful when using all for kernel_version)</b>`sudo update-initramfs -d -k [kernel_version]`


title: SYNOPSIS
content:
<b>efivar</b> [<i>OPTIONS</i>] [<i>COMMAND</i>] [<i>VARIABLE_NAME</i>] [<i>VALUE</i>]<br><b>efivar --list</b><br><b>efivar --print</b> <i>VARIABLE_NAME</i><br><b>efivar --write</b> <i>VARIABLE_NAME</i> [<i>VALUE</i>]<br><b>efivar --append</b> <i>VARIABLE_NAME</i> [<i>VALUE</i>]<br><b>efivar --delete</b> <i>VARIABLE_NAME</i>


title: PARAMETERS
content:
<b>--list, -l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available UEFI variables found in NVRAM.<br><br><b>--print, -p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the value and attributes of a specified UEFI variable.<br><br><b>--write, -w</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes a new value to a UEFI variable. Requires a variable name and data (from command line or <i>--from-file</i>).<br><br><b>--append, -a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Appends data to an existing UEFI variable. Requires a variable name and data (from command line or <i>--from-file</i>).<br><br><b>--delete, -d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes a specified UEFI variable from NVRAM. Use with extreme caution.<br><br><b>--from-file, -f <FILE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads the variable data from the specified file. Used with <i>--write</i> or <i>--append</i>.<br><br><b>--guid, -g <GUID></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the GUID (Globally Unique Identifier) of the variable. Required for variables not in the default namespace or when ambiguity exists.<br><br><b>--attributes, -t <ATTRIBUTES></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the attributes (e.g., 'NV', 'BS', 'RT', 'AT') for a variable during write or append operations. Attributes are typically comma-separated.<br><br><b>--verbose, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more details about the operation.<br><br><b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br>


title: DESCRIPTION
content:
<i>efivar</i> is a command-line utility for interacting with <b>UEFI (Unified Extensible Firmware Interface)</b> variables. These variables are stored in the system's <b>NVRAM (Non-Volatile RAM)</b> and are crucial for the firmware, bootloaders, and operating systems to store configuration data and state.<br>Common uses include managing boot entries (though <i>efibootmgr</i> is often preferred for that), secure boot settings, and system-specific configurations. <b>It allows users to list, read, write, and delete UEFI variables, providing a powerful interface for low-level system configuration.</b><br>The command often requires root privileges as it interacts directly with system firmware. Misuse of <i>efivar</i> can render a system unbootable, so caution is advised. It provides more granular control over individual variables compared to higher-level tools.


title: CAVEATS
content:
<b>Root Privileges:</b> <i>efivar</i> almost always requires root privileges (e.g., using <i>sudo</i>) to access and modify UEFI variables.<br><b>System Stability:</b> Incorrectly modifying or deleting UEFI variables can render your system unbootable or lead to unpredictable behavior. Exercise extreme caution.<br><b>Firmware Specificity:</b> The meaning and function of UEFI variables can vary significantly between different UEFI firmware implementations and motherboard manufacturers.<br><b>Write Protection:</b> Some UEFI variables may be protected by the firmware or require specific Secure Boot states to be modified.


title: ACCESS MECHANISM
content:
Under Linux, UEFI variables are primarily exposed through the <i>efivarfs</i> pseudo-filesystem, typically mounted at <i>/sys/firmware/efi/efivars</i>. Each variable appears as a file with its name and a GUID. While direct file operations are possible, <i>efivar</i> offers a more robust and safer command-line interface for complex manipulations, such as handling binary data, specific GUIDs, and setting attributes.


title: VARIABLE FORMAT
content:
UEFI variables are identified by a <b>Globally Unique Identifier (GUID)</b> and a name (e.g., '<i>8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOrder</i>'). Their content is often binary data, and interpreting it accurately usually requires knowledge of the <i>UEFI Specification</i> or specific firmware documentation.


title: COMMON USE CASES
content:
Common applications for <i>efivar</i> include:<br>Debugging UEFI boot issues by inspecting or modifying boot order variables.<br>Manually configuring advanced firmware options not exposed in the visual BIOS/UEFI setup.<br>Managing <b>Secure Boot</b> related variables (e.g., PK, KEK, DB, DBX) for advanced security configurations.<br>Automating firmware configuration tasks in data centers or large deployments.


title: HISTORY
content:
<i>efivar</i> is part of the broader Linux <b>UEFI support infrastructure</b>. Its development is closely tied to the `efivarfs` pseudo-filesystem, which exposes UEFI variables as files in `/sys/firmware/efi/efivars`. The command-line tool provides a more direct and programmatic interface, complementing the file-system approach, especially for complex operations like setting attributes or handling binary data. It emerged as UEFI replaced traditional BIOS, enabling Linux to fully interact with and manage modern firmware settings.


title: TLDR
content:
<b>List all UEFI variables</b>`efivar [[-l|--list]]`<br><b>Print the contents of a variable</b>`efivar [[-n|--name]] [146b234d-4052-4e07-b326-11220f8e1fe8-lBoot0000] [[-p|--print]]`


title: SYNOPSIS
content:
<b>parted</b> <i>[options]</i> <i>[device]</i><br>To enter interactive mode, simply run:<br><b>sudo parted /dev/sda</b>


title: PARAMETERS
content:
<b><i>device</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The disk device to operate on (e.g., <i>/dev/sda</i>, <i>/dev/nvme0n1</i>). Specifying a device will select it for interactive operations.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for <b>parted</b> and exits without entering interactive mode.<br><br><b><b>-s</b>, <b>--script</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes commands non-interactively from a script or pipeline. (<i>Note: This option prevents interactive mode.</i>)<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <b>parted</b> version information and exits.<br><br><b><b>-a</b>, <b>--align</b> <i>type</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set alignment type for partitions (e.g., <i>optimal</i>, <i>cylinder</i>, <i>none</i>). Affects how partitions are created or resized for performance or compatibility.<br><br><b><b>-l</b>, <b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available disk devices and their partition tables without entering interactive mode.<br><br><b><b>-m</b>, <b>--machine</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays information in a machine-readable format, suitable for scripting.<br><br><b><b>-e</b>, <b>--error-symbolic</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report errors symbolically rather than numerically.<br><br>


title: DESCRIPTION
content:
<i>parted.interactive</i> conceptually refers to the GNU Parted utility when it is run in its interactive mode, which is its default behavior if no specific commands are provided on the command line. <b>parted</b> is a powerful and versatile command-line tool used for creating, deleting, resizing, moving, copying, and checking disk partitions. It supports various partition table formats, including MS-DOS, GPT, Mac, and others.<br><br>In interactive mode, users are presented with a prompt where they can type commands such as <b>mklabel</b>, <b>mkpart</b>, <b>rm</b>, <b>resize</b>, <b>print</b>, and <b>select</b>, to manage disk partitions step-by-step. This interactive approach provides immediate feedback and allows for cautious, guided manipulation of disk layouts, significantly reducing the risk of accidental data loss compared to non-interactive, script-driven operations. Due to its direct interaction with disk structures, <b>parted</b> requires superuser (root) privileges.


title: CAVEATS
content:
<b>Data Loss Risk</b>: Incorrect use of <b>parted</b> can lead to permanent data loss. Always back up critical data before making changes to partition tables.<br><b>Root Privileges</b>: <b>parted</b> requires superuser privileges (root) to operate on disk devices.<br><b>Device Selection</b>: Always ensure you are operating on the correct disk device to avoid accidentally modifying the wrong drive.<br><b>In-Use Partitions</b>: It is generally unsafe to modify partitions that are currently in use or mounted. Unmount filesystems before modifying their partitions.<br><b>File System Awareness</b>: <b>parted</b> itself does not directly manipulate file systems (like <i>ext4</i> or <i>NTFS</i>) within partitions; it only manages the partitions themselves. Tools like <b>mkfs</b> and <b>fsck</b> are needed for file system operations.


title: INTERACTIVE COMMANDS
content:
Once in interactive mode, <b>parted</b> offers a range of commands to manage partitions:<br><b>help</b>: Display help for commands.<br><b>mklabel</b> <i>label-type</i>: Create a new disk label (e.g., <i>gpt</i>, <i>msdos</i>).<br><b>mkpart</b> <i>part-type name fs-type start end</i>: Make a partition.<br><b>rm</b> <i>number</i>: Delete partition <i>number</i>.<br><b>resize</b> <i>number start end</i>: Resize partition <i>number</i>.<br><b>print</b>: Display the partition table.<br><b>select</b> <i>device</i>: Select a different device to work on.<br><b>unit</b> <i>unit-type</i>: Set the default unit for sizes (e.g., <i>GiB</i>, <i>s</i> for sectors).<br><b>quit</b>: Exit <b>parted</b>.


title: UNITS AND SIZES
content:
<b>parted</b> often defaults to MiB or GiB for displaying sizes but allows users to specify units (e.g., <i>500MB</i>, <i>10GB</i>, <i>100s</i> for sectors) when creating or resizing partitions. The <b>unit</b> command within the interactive session can change the default display unit.


title: HISTORY
content:
GNU Parted was developed by Andrew Clausen and released in 1998 as part of the GNU project. It was designed to be a more modern and flexible alternative to existing tools like <b>fdisk</b>, supporting a wider range of partition table types (including GPT) and providing functionality for resizing and moving partitions, which <b>fdisk</b> typically lacks. Its interactive mode has been a core feature since its inception, providing a guided way to manage disk layouts. Over the years, it has become a standard utility in most Linux distributions.


title: SYNOPSIS
content:
<b>pct template</b> <I>download</I> &lt;storage&gt; &lt;template-name&gt; [<I>options</I>]<br><b>pct template</b> <I>update</I> &lt;storage&gt; &lt;template-name&gt; [<I>options</I>]<br><b>pct template</b> <I>list</I> [&lt;storage&gt;] [<I>options</I>]<br><b>pct template</b> <I>delete</I> &lt;storage&gt; &lt;template-name&gt; [<I>options</I>]


title: PARAMETERS
content:
<b>download <storage> <template-name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Downloads a specified container template to the designated storage. If the template already exists, use <b>--force</b> to overwrite.<br><br><b>update <storage> <template-name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates an existing container template to its latest version from the repository.<br><br><b>list [<storage>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available container templates on a specific storage or across all storages if none is specified.<br><br><b>delete <storage> <template-name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes a specified container template from the storage.<br><br><b>--force <boolean></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the operation, e.g., overwrite an existing template during download, or proceed with update/deletion without prompting.<br><br><b>--url <string></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative URL when downloading a template, overriding the default repository source.<br><br><b>--output-format <json|pretty></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the output format for the 'list' command. Can be 'json' for machine-readable or 'pretty' for human-readable output.<br><br><b>--output-config <boolean></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the 'list' command to include detailed template configuration information in the output.<br><br>


title: DESCRIPTION
content:
<b>pct-template</b> is a subcommand of the <I>pct</I> (Proxmox Container Toolkit) utility, specifically designed for managing LXC (Linux Container) operating system templates within a Proxmox Virtual Environment (PVE) cluster.<br>It provides functionalities to download new container templates from official or custom repositories, update existing ones to their latest versions, list available templates stored on various PVE storage backends, and delete obsolete templates.<br>These templates serve as base images for creating new LXC containers, significantly streamlining the deployment process by providing pre-configured minimal operating systems without needing to install from scratch.<br>By utilizing <I>pct-template</I>, administrators can ensure consistent and up-to-date container deployments across their PVE infrastructure.


title: CAVEATS
content:
<b>pct-template</b> is exclusively available on Proxmox Virtual Environment (PVE) installations. It is not a standard Linux command and requires a functional PVE setup.<br>Internet connectivity is required for downloading and updating templates from external repositories. Template availability depends on the configured Proxmox repositories and any custom URLs provided.<br>Ensure sufficient storage space on the chosen backend before downloading large templates.


title: TEMPLATE STORAGE LOCATIONS
content:
Proxmox VE stores container templates on various storage types configured within the system, such as local storage, NFS, or ZFS. Templates are typically found in a dedicated 'template' subdirectory on the chosen storage. The <I>pct template list</I> command helps identify where templates are stored.


title: AUTOMATING DEPLOYMENTS
content:
Using <I>pct template</I> in scripts allows for automated and consistent deployment of new LXC containers. By pre-downloading or updating templates, administrators can ensure that new containers are always based on the desired and latest images, reducing manual intervention and potential inconsistencies.


title: HISTORY
content:
The <I>pct-template</I> functionality emerged as part of the <I>Proxmox Container Toolkit</I> (pct), which was developed to simplify the management of LXC containers within the Proxmox Virtual Environment. As LXC container support matured in Proxmox VE, the need for an efficient way to manage container base images became apparent, leading to the integration of template management capabilities. Its development is tied directly to the evolution of Proxmox VE itself, aiming to provide an all-in-one platform for virtualization and containerization.


title: PARAMETERS
content:
<b><i>&lt;vmid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The unique integer ID of the Proxmox LXC container to resize.<br><br><b><i>&lt;disk&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The identifier of the disk to resize. Commonly <i>rootfs</i> for the primary disk, or <i>mp0</i>, <i>mp1</i>, etc., for additional mount points configured in the container's configuration.<br><br><b><i>&lt;size&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The target size for the disk. This can be an absolute size (e.g., <i>8G</i> for 8 Gigabytes, <i>512M</i> for 512 Megabytes) or a relative change (e.g., <i>+2G</i> to add 2 Gigabytes, <i>-1G</i> to reduce by 1 Gigabyte). The unit (G for Gigabytes, M for Megabytes) is required.<br><br>


title: DESCRIPTION
content:
The <b>pct resize</b> command is part of the Proxmox Container Toolkit (PCT) and is used to modify the allocated disk space for Linux Container (LXC) virtual machines within a Proxmox Virtual Environment (PVE) host.<br><br>It allows administrators to expand or shrink the size of a container's virtual disk, such as its primary filesystem (<i>rootfs</i>) or additional mount points (<i>mpX</i>). When resizing the <i>rootfs</i>, <b>pct resize</b> typically handles the underlying filesystem expansion (for <i>ext4</i> and <i>xfs</i>) automatically, making it a convenient tool for dynamic resource management of unprivileged containers.


title: CAVEATS
content:
<b>Proxmox VE Requirement:</b> This command is specific to Proxmox Virtual Environment and is not a standard Linux utility found on non-Proxmox systems.<br><br><b>Container State:</b> While <i>rootfs</i> resize often works with the container running, it is generally safer to stop the container before performing resize operations, especially for shrinking or for other mount points.<br><br><b>Filesystem Consistency:</b> For <i>rootfs</i>, <b>pct resize</b> attempts to grow/shrink the filesystem automatically for common types (<i>ext4</i>, <i>xfs</i>). For other mount points (<i>mpX</i>), only the underlying block device is resized; you must manually resize the filesystem inside the container using tools like <b>resize2fs</b> or <b>xfs_growfs</b>.<br><br><b>Shrinking Risks:</b> Shrinking a disk carries a higher risk of data loss. It typically requires shrinking the filesystem <i>inside</i> the container first, and then shrinking the underlying block device via <b>pct resize</b>. Always back up critical data before shrinking operations.


title: HISTORY
content:
<b>pct resize</b> is an integral part of the Proxmox Container Toolkit (PCT), developed by Proxmox Server Solutions GmbH. It was introduced as part of the <b>pct</b> command-line utility to simplify the management of LXC containers within Proxmox VE, evolving with the platform to provide robust disk management capabilities for container storage.


title: TLDR
content:
<b>Resize the container size to 20GB</b>`pct [[resi|resize]] [100] rootfs 20G`<br><b>Add 10GB to the container storage</b>`pct [[resi|resize]] [100] rootfs +10G`


title: PARAMETERS
content:
<b><i>&lt;vmid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The unique ID (integer) of the container to modify. This is a mandatory argument.<br><br><b><b>--hostname</b> <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the hostname inside the container.<br><br><b><b>--memory</b> <i>&lt;integer&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the container's RAM limit in MB. A value of 0 means no limit.<br><br><b><b>--swap</b> <i>&lt;integer&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the container's swap space limit in MB.<br><br><b><b>--cores</b> <i>&lt;integer&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of CPU cores allocated to the container.<br><br><b><b>--cpulimit</b> <i>&lt;integer&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the CPU usage limit in percent (e.g., 50 for 50%). Values greater than 100 are possible for multi-core CPUs.<br><br><b><b>--cpuunits</b> <i>&lt;integer&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets CPU weight for scheduler (defaults to 1024). Higher values give more CPU time.<br><br><b><b>--net</b><i>&lt;id&gt;</i> <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures a network device. <i>&lt;id&gt;</i> is the device index (e.g., net0, net1). The <i>&lt;string&gt;</i> specifies properties like <i>name</i>, <i>bridge</i>, <i>ip</i>, <i>gw</i>, <i>macaddr</i>, <i>rate</i>, etc.<br><br><b><b>--rootfs</b> <i>&lt;volume&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the root filesystem of the container, e.g., <i>local-lvm:10</i> or <i>local-zfs:subvol-100-disk-0</i>. Can also modify size with <i>size=&lt;size&gt;</i>.<br><br><b><b>--unprivileged</b> <i>&lt;0|1&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the container to unprivileged (1) or privileged (0) mode. Unprivileged containers offer better security isolation.<br><br><b><b>--onboot</b> <i>&lt;0|1&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines if the container should start automatically when the Proxmox host boots (1 for yes, 0 for no).<br><br><b><b>--autostart</b> <i>&lt;0|1&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Similar to <b>--onboot</b>, but specifically for containers managed by the HA manager in a cluster. Enables/disables automatic start.<br><br><b><b>--features</b> <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables specific kernel features inside the container, e.g., <i>nesting=1</i> (for nested virtualization), <i>keyctl=1</i>, <i>fuse=1</i>, etc. Multiple features can be comma-separated.<br><br><b><b>--hookscript</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a script that will be executed during various container lifecycle events (start, stop, etc.).<br><br><b><b>--nameserver</b> <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the DNS nameserver for the container.<br><br><b><b>--searchdomain</b> <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the DNS search domain for the container.<br><br>


title: DESCRIPTION
content:
The <b>pct set</b> command is a subcommand of the <b>pct</b> utility, used within Proxmox Virtual Environment (PVE) to modify various configuration parameters and resource limits for a specific Linux Container (LXC). It allows administrators to fine-tune aspects like CPU, memory, network interfaces, storage, boot behavior, and security features for existing containers. Changes made with <b>pct set</b> are typically persistent and stored in the container's configuration file, located in <i>/etc/pve/lxc/&lt;vmid&gt;.conf</i>. Many configuration changes, especially those related to resource limits or hardware definitions, require the container to be restarted to take full effect. This command is essential for managing the lifecycle and performance of LXC containers on a Proxmox host.


title: CAVEATS
content:
The <b>pct set</b> command directly modifies the container's configuration file. Incorrect parameters or values can lead to a non-functional container. Always ensure correct syntax and valid values.<br>Most resource-related changes (CPU, memory, networking) require the container to be restarted for the new settings to take effect.<br>The command must be run with root privileges on the Proxmox host.


title: CONFIGURATION FILE LOCATION
content:
Every LXC container's configuration is stored in a file named <i>&lt;vmid&gt;.conf</i> within <i>/etc/pve/lxc/</i>. For example, container 101's configuration would be at <i>/etc/pve/lxc/101.conf</i>. The <b>pct set</b> command directly modifies this file.


title: APPLYING CHANGES
content:
While <b>pct set</b> immediately updates the configuration file, many parameters (especially those affecting resource allocation or hardware) only take effect after the container is stopped and then started again. For example, changing <b>--memory</b> or <b>--cores</b> requires a restart.


title: HISTORY
content:
The <b>pct</b> command-line utility is an integral part of Proxmox Virtual Environment (PVE), a Debian-based virtualization management solution. Proxmox initially supported OpenVZ for containers but transitioned to LXC (Linux Containers) with PVE 3.0, released in 2013. The <b>pct</b> command suite was developed to provide a unified and robust interface for managing LXC containers, mirroring the functionality previously offered for OpenVZ, and integrating seamlessly with PVE's web interface and clustering capabilities. The <b>pct set</b> subcommand emerged as the primary tool for modifying the configuration of these LXC containers.


title: TLDR
content:
<b>Set container to start automatically on boot</b>`pct set [100] --onboot`<br><b>Set a container to have a static IP</b>`pct set [100] --net0 name=eth0,bridge=vmbr0,ip=[10.0.0.100/24],gw=[10.0.0.1]`<br><b>Set container memory and CPU limit</b>`pct set [100] --memory [8192] --cpulimit [4]`<br><b>Mount a host file location in a guest</b>`pct set [100] --mp[0] /[path/to/host_directory],mp=/[path/to/guest_mount_point]`<br><b>Set container tags</b>`pct set [100] --tags [tag1,tag2,...]`<br><b>Remove an option</b>`pct set [100] --delete [net0,mp0,mp1,...]`


title: TLDR
content:
<b>Dump boot entries from a file</b>`efibootdump [[-f|--file]] [/sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c]`


title: SYNOPSIS
content:
<b>partclone.&lt;fstype&gt;</b> [<i>options</i>] <i>&lt;source&gt;</i> [<i>destination</i>]<br><br><b>Examples:</b><br><i>To backup:</i> <b>partclone.ext4 -s /dev/sda1 -o sda1.img</b><br><i>To restore:</i> <b>partclone.ext4 -r -s sda1.img -o /dev/sda1</b><br><i>Common &lt;fstype&gt; include:</i> <b>ext2</b>, <b>ext3</b>, <b>ext4</b>, <b>ntfs</b>, <b>fat32</b>, <b>xfs</b>, <b>btrfs</b>, <b>reiserfs</b>, <b>hfs+</b>, etc.


title: PARAMETERS
content:
<b><b>-s</b>, <b>--source &lt;source&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the source partition or image file for the operation.<br><br><b><b>-o</b>, <b>--output &lt;destination&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the destination partition or image file for the operation.<br><br><b><b>-r</b>, <b>--restore</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activate restore mode (default is backup/clone mode).<br><br><b><b>-c</b>, <b>--clone</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activate clone (backup) mode (backup partition to image file).<br><br><b><b>-b</b>, <b>--batch</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run in batch mode, suppressing all interactive prompts.<br><br><b><b>-z</b>, <b>--compression &lt;level&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set compression level (0-9, 0 for no compression, 9 for best compression; 'auto' can be used).<br><br><b><b>-L</b>, <b>--logfile &lt;file&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write all messages and progress to the specified log file.<br><br><b><b>-C</b>, <b>--checksum</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable data verification with checksums for integrity checking.<br><br><b><b>-d</b>, <b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display debug messages, useful for troubleshooting.<br><br><b><b>-F</b>, <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the operation, overriding some safety checks.<br><br><b><b>-N</b>, <b>--nocheck</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not check the image header when restoring.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run in quiet mode, suppressing most output messages.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information of <i>partclone</i>.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the help message and available options.<br><br>


title: DESCRIPTION
content:
<i>partclone</i> is a powerful and versatile command-line utility designed for backing up and restoring disk partitions. Unlike <i>dd</i>, which performs a bit-by-bit copy of an entire partition (including empty space), <i>partclone</i> intelligently copies only the allocated blocks, significantly reducing image size and backup time. <br><br>It supports a wide range of file systems, including <b>ext2/3/4</b>, <b>btrfs</b>, <b>xfs</b>, <b>ntfs</b>, <b>hfs+</b>, <b>reiserfs</b>, and more. <i>partclone</i> can create image files of partitions and restore them to the same or different partitions. It offers features like compression, checksum verification, and the ability to clone to/from standard input/output, making it flexible for scripting and integration with other tools like <i>gzip</i> or <i>pv</i>. It's a core component widely used by <i>Clonezilla</i> for its disk imaging capabilities.


title: CAVEATS
content:
<ul><li>For reliable backup and restore, the target partition must typically be <b>unmounted</b>. Operating on a mounted partition can lead to data inconsistency.</li><li>Restoring an image to a smaller partition than the original source partition may require manual resizing of the filesystem beforehand, or careful handling with other tools.</li><li>You must use the correct <b>partclone.&lt;fstype&gt;</b> executable corresponding to the filesystem type of the partition. Using the wrong one can lead to data corruption or errors.</li><li><i>partclone</i> operates on partitions, not entire disks. It does not handle Master Boot Records (MBRs) or partition tables directly. These must be managed separately (e.g., with <i>dd</i>, <i>fdisk</i>, or <i>parted</i>).</li></ul>


title: COMMON USAGE PATTERNS
content:
<ul><li><b>Backup a partition to an image:</b><br><b>partclone.ext4 -s /dev/sda1 -o /mnt/backup/sda1.img</b></li><li><b>Backup a partition with compression (piping to gzip):</b><br><b>partclone.ntfs -s /dev/sda2 | gzip -c > /mnt/backup/sda2.img.gz</b></li><li><b>Restore an image to a partition:</b><br><b>partclone.ext4 -r -s /mnt/backup/sda1.img -o /dev/sda1</b></li><li><b>Restore a compressed image (piping from gunzip):</b><br><b>gunzip -c /mnt/backup/sda2.img.gz | partclone.ntfs -r -o /dev/sda2</b></li></ul>


title: FILESYSTEM-SPECIFIC EXECUTABLES
content:
<i>partclone</i> is not a single universal executable. Instead, it comes as a family of binaries, each tailored for a specific filesystem type (e.g., <b>partclone.ext4</b>, <b>partclone.ntfs</b>, <b>partclone.btrfs</b>, etc.). You must use the variant that matches the filesystem of the partition you intend to clone or restore. This design allows <i>partclone</i> to optimize its operations based on the underlying filesystem structure, leading to greater efficiency and reliability.


title: HISTORY
content:
<i>partclone</i> was primarily developed by Steven Shiau and others, serving as the underlying engine for the renowned open-source disk cloning software <i>Clonezilla</i>. Its development commenced in the early 2000s, driven by the need for a more efficient and filesystem-aware alternative to <i>dd</i> for disk imaging. It was designed to provide a robust and versatile solution for cloning and restoring partitions across various Linux distributions and other operating systems, greatly enhancing the capabilities of live system rescue and backup environments.


title: TLDR
content:
<b>Copy a partition into an image</b>`sudo partclone.[ext4|btrfs|fat32|xfs|...] [[-c|--clone]] [[-s|--source]] [/dev/sdXY] [[-o|--output]] [path/to/backup.img]`<br><b>Restore a partition from an image</b>`sudo partclone.[ext4|btrfs|fat32|xfs|...] [[-c|--clone]] [[-s|--source]] [path/to/backup.img] [[-o|--output]] [/dev/sdXY]`<br><b>Display help</b>`partclone.[ext4|btrfs|fat32|xfs|...] [[-h|--help]]`


title: DESCRIPTION
content:
<i>qm-disk-rescan</i> is a specialized utility command primarily used within the <b>Proxmox Virtual Environment (Proxmox VE)</b> to detect and update information about available storage devices.<br><br>Its main purpose is to trigger a rescan of the underlying storage infrastructure, allowing Proxmox to discover newly added disks, partitions, or changes to existing block devices without requiring a full system reboot.<br><br>This command is particularly useful when physically adding new hard drives, SSDs, or SAN LUNs to a Proxmox node, or when performing changes at the hardware level that affect disk visibility.<br><br>Upon execution, it attempts to identify new block devices and updates Proxmox's internal storage view, which is then reflected in the web interface and command-line tools. It helps ensure that Proxmox VE's storage subsystem is aware of the current physical disk layout, enabling these devices to be used for virtual machine storage, LVM volume groups, ZFS pools, or other storage types supported by Proxmox.


title: CAVEATS
content:
<b>.</b> This command is specific to the <i>Proxmox Virtual Environment</i> and is not a general-purpose Linux utility found on all distributions.<br><b>.</b> It typically requires root privileges (or `sudo`) to execute successfully, as it interacts directly with system hardware and storage layers.<br><b>.</b> While it triggers a rescan, it may not resolve all underlying issues if there are problems with device drivers, kernel modules, or hardware connectivity.<br><b>.</b> It primarily helps Proxmox update its internal view; sometimes additional steps (e.g., `pvcreate`, `vgcreate`, `zpool create`) are needed to prepare the newly detected devices for use.


title: USAGE CONTEXT
content:
<i>qm-disk-rescan</i> is designed to be used within a <b>Proxmox VE</b> server environment. While it can be executed from the command line, its functionality is also integrated into the Proxmox web interface (e.g., when adding storage or creating new LVM/ZFS pools), where it often runs automatically in the background to update the storage view for the administrator.


title: HISTORY
content:
The <i>qm-disk-rescan</i> utility has been an integral part of the Proxmox VE distribution since its earlier versions. It was developed to address the common operational need for system administrators to hot-add or modify storage without requiring disruptive reboots. Its development reflects Proxmox VE's focus on ease of management and robust virtualization infrastructure.


title: TLDR
content:
<b>Rescan all storages and update disk sizes and unused disk images</b>`qm [[di|disk]] [[resc|rescan]]`<br><b>Perform a dry-run of a rescan and do not write any changes to configurations</b>`qm [[di|disk]] [[resc|rescan]] --dryrun`<br><b>Specify a virtual machine by its ID</b>`qm [[di|disk]] [[resc|rescan]] --vmid [100]`


title: SYNOPSIS
content:
<b>pvesm</b> &lt;<i>command</i>&gt; [&lt;<i>id</i>&gt;] [<i>OPTIONS</i>]<br>or<br><b>pvesm add</b> &lt;<i>type</i>&gt; &lt;<i>id</i>&gt; [<i>OPTIONS</i>]


title: PARAMETERS
content:
<b><b>add</b> &lt;<i>type</i>&gt; &lt;<i>id</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a new storage backend of a specified type with a unique ID.<br><br><b><b>delete</b> &lt;<i>id</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes an existing storage backend identified by its ID.<br><br><b><b>set</b> &lt;<i>id</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Modifies properties and options of an existing storage backend.<br><br><b><b>list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a summary list of all configured storage backends.<br><br><b><b>scan</b> &lt;<i>type</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Scans for available storage resources of a specific type (e.g., LVM, iSCSI targets, ZFS pools).<br><br><b><b>status</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the current status and usage information for all configured storages.<br><br><b><b>showconfig</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the raw, detailed configuration of all storage backends, often used for debugging or backup.<br><br>


title: DESCRIPTION
content:
<i>pvesm</i> is a powerful command-line interface tool within <b>Proxmox Virtual Environment (PVE)</b> designed for comprehensive storage backend management. It enables administrators to seamlessly add, modify, remove, and query various storage types, including local directories, <b>NFS</b> shares, <b>iSCSI</b> targets, <b>LVM</b> (Logical Volume Manager) volumes, <b>ZFS</b> pools, <b>Ceph</b> (RBD and FS), and <b>GlusterFS</b>. This utility is fundamental for defining where virtual machine disk images, container root file systems, backups, and ISO templates are stored. By interacting with the <b>PVE</b> storage subsystem, which leverages <b>pmxcfs</b> for cluster-wide consistency, <i>pvesm</i> facilitates flexible, scalable, and resilient storage solutions for virtualized and containerized workloads across a <b>Proxmox</b> cluster.


title: CAVEATS
content:
Requires <b>root</b> privileges or <b>sudo</b> for execution.<br>Improper use can lead to data loss or render virtual machines/containers inaccessible.<br>All changes made via <i>pvesm</i> are immediately effective and, in a cluster setup, are synchronized across all nodes via <b>pmxcfs</b>.<br>Some operations (e.g., modifying storage backing a running VM) might require stopping or migrating affected virtual machines/containers.


title: COMMON STORAGE TYPES
content:
<i>pvesm</i> supports a wide array of storage types, enabling flexible integration within <b>Proxmox VE</b> deployments. Common types include:<br><b>dir</b>: Local directory storage.<br><b>nfs</b>: Network File System shares.<br><b>lvm</b>: Logical Volume Management volumes.<br><b>lvmthin</b>: LVM thin-provisioned volumes.<br><b>zfspool</b>: ZFS file system pools.<br><b>iscsi</b>: iSCSI targets.<br><b>rbd</b>: Ceph RADOS Block Device.<br><b>cephfs</b>: Ceph File System.<br><b>glusterfs</b>: GlusterFS distributed file system.


title: CONFIGURATION FILE
content:
The configurations managed by <i>pvesm</i> are persistently stored in the cluster's main storage configuration file, typically located at <b>/etc/pve/storage.cfg</b>. This file is part of the <b>pmxcfs</b> and is automatically synchronized across all nodes in a <b>Proxmox</b> cluster.


title: HISTORY
content:
<i>pvesm</i> has been a foundational utility in <b>Proxmox VE</b> since its early iterations, evolving alongside the platform's expanding storage capabilities. It was developed to provide a unified command-line interface for managing diverse storage technologies, crucial for <b>PVE</b>'s goal of offering a comprehensive virtualization solution. Its design ensures cluster-aware configuration management, integrating tightly with <b>pmxcfs</b> to maintain consistency across <b>Proxmox</b> nodes. The command continues to be actively maintained and enhanced to support new storage backends and features as the <b>Proxmox</b> ecosystem grows.


title: TLDR
content:
<b>Get status for all datastores</b>`pvesm [[st|status]]`<br><b>List storage contents</b>`pvesm [[l|list]] [storage_name]`<br><b>Add a directory storage</b>`pvesm add [[d|dir]] [storage_name] --path [path/to/directory]`<br><b>Set a storage to contain specific content</b>`pvesm set [storage_name] --content [iso,images,backup,vztmpl,...]`<br><b>Delete a file from storage</b>`pvesm free [local:iso/archlinux-2025.08.01-x86_64.iso]`<br><b>Remove a storage</b>`pvesm [[r|remove]] [storage_name]`


title: SYNOPSIS
content:
<i>qm-set</i> <b><i>message-ID</i></b> [<b><i>flag</i></b>] [<b><i>attribute</i></b> <b><i>value</i></b>]<br>This represents a generalized syntax, as <i>qm-set</i> often acts as a prefix for more specific commands (e.g., <i>qm-set-dt</i>) or takes various types of flags/attributes. The simplest common form involves setting a status flag for a given message ID.


title: PARAMETERS
content:
<b><b><i>message-ID</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The unique identifier of the message within the <i>qmail</i> queue. This ID is typically a hexadecimal string representing the message's inode number or a path to the message file.<br><br><b><b><i>flag</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional single-character flag to set the message's status. Common flags include:<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>d</b> or <b>D</b>: Mark message as delivered or to be deleted.<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>f</b> or <b>F</b>: Mark message as failed.<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>p</b> or <b>P</b>: Mark message as pending for re-delivery.<br><br><b><b><i>attribute</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Less common for <i>qm-set</i> itself, more for <i>qm-set-*</i> variants) Specifies a particular message attribute to modify, such as delivery time or recipient status.<br><br><b><b><i>value</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The new value for the specified <b><i>attribute</i></b>.<br><br>


title: DESCRIPTION
content:
<i>qm-set</i> is a specialized utility within the <i>qmail</i> Mail Transfer Agent (MTA) ecosystem. It is designed for administrators to directly manipulate the state and attributes of messages residing in the <i>qmail</i> message queue. Unlike general-purpose Linux commands, <i>qm-set</i> is highly specific to <i>qmail</i> installations and is not universally present. Its primary function is to allow fine-grained control over individual messages, enabling actions such as marking messages for re-delivery, setting their delivery status (e.g., pending, failed, delivered), or modifying certain message-specific parameters. This command is invaluable for troubleshooting, queue management, and recovering from specific mail delivery issues. Due to its direct interaction with critical queue files, <i>qm-set</i> often requires elevated privileges, typically root, or specific file permissions related to the <i>qmail-queue</i> daemon. Its exact functionality and available options can vary slightly depending on the <i>qmail</i> version, applied patches, or specific third-party tools that might incorporate or wrap its underlying capabilities.


title: CAVEATS
content:
Part of the <i>qmail</i> MTA suite; not a standard or universal Linux command. Its presence and exact behavior depend on the <i>qmail</i> installation and specific patches.<br>Requires root privileges or specific permissions to the <i>qmail</i> queue directories for most operations.<br>Direct manipulation of the <i>qmail</i> queue can lead to data corruption or mail delivery issues if not performed with caution and understanding of the <i>qmail</i> queue structure.


title: QUEUE STRUCTURE INTERACTION
content:
<i>qm-set</i> operates by directly modifying flags and data within <i>qmail</i>'s distinct on-disk queue structure, which consists of multiple directories (e.g., <i>todo</i>, <i>local</i>, <i>remote</i>, <i>intd</i>). It typically targets specific message files identified by their unique IDs to alter their state or attributes, making it a low-level, powerful tool for advanced queue management.


title: COMMON USE CASES
content:
Common uses include:<br>&nbsp;&nbsp;&nbsp;&nbsp;- Forcing re-delivery of stuck messages.<br>&nbsp;&nbsp;&nbsp;&nbsp;- Marking specific messages as failed to prevent further delivery attempts.<br>&nbsp;&nbsp;&nbsp;&nbsp;- Deleting malicious or unwanted messages directly from the queue.<br>&nbsp;&nbsp;&nbsp;&nbsp;- Adjusting the next delivery attempt time for a message (often via <i>qm-set-dt</i>).


title: HISTORY
content:
The <i>qmail</i> MTA was originally developed by Daniel J. Bernstein (DJB) and released in 1995. The concept of <i>qm-set</i> as a utility to manipulate <i>qmail</i>'s unique queue structure emerged from the need for administrative control over mail messages. While a specific <i>qm-set</i> command might not have been part of the original core <i>qmail</i> distribution in its current form, various patches and third-party tools developed around <i>qmail</i>'s extensible architecture introduced utilities with similar functionality or naming conventions (e.g., <i>qm-set-dt</i> for delivery time). These tools collectively address the need to manage message states, re-queue items, or force specific actions within the <i>qmail</i> system, reflecting its ongoing development and adaptation by the community.


title: TLDR
content:
<b>Set a name for a VM in the GUI</b>`qm set [100] --name [vm_name]`<br><b>Set a VM to autostart on boot</b>`qm set [100] --autostart [0|1]`<br><b>Set the allotted core count of a VM</b>`qm set [100] --cores [4]`<br><b>Set the allotted amount of memory</b>`qm set [100] --memory [8192]`<br><b>Give a VM a network device and bridge it to the host network</b>`qm set [100] --net[0] [virtio|e1000|rtl8139|vmxnet3],bridge=vmbr[0]`<br><b>Delete a device</b>`qm set [100] --delete [device_name0,device_name1,...]`<br><b>Passthrough a GPU device to the guest</b>`qm set [100] --hostpci[0] [0000:00:02],x-vga=1 --bios ovmf`


title: SYNOPSIS
content:
<b>pveum</b> <I>command</I> [<i>options...</i>]<br><br>Examples:<br><b>pveum</b> user list<br><b>pveum</b> group add <I>mygroup</I><br><b>pveum</b> acl add /vms/101 -user <I>user@realm</I> -role <I>VMViewer</I>


title: PARAMETERS
content:
<b><b>user</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages user accounts within Proxmox VE, including adding, modifying, deleting, and listing users and their properties (e.g., email, expiration).<br><br><b><b>group</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages user groups in Proxmox VE, allowing administrators to create, modify, or delete groups and assign users to them for simplified permission management.<br><br><b><b>realm</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures authentication realms, which define how users authenticate to Proxmox VE. Supported realms include PVE's internal database, PAM (for local system users), and external sources like LDAP or Active Directory.<br><br><b><b>acl</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages Access Control List (ACL) entries, which define specific permissions for users or groups on particular Proxmox VE objects (e.g., virtual machines, storage, nodes).<br><br><b><b>role</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages roles, which are collections of privileges that can be assigned to users or groups. Proxmox VE provides default roles, and <i>pveum</i> allows for defining custom roles with specific sets of permissions.<br><br>


title: DESCRIPTION
content:
<i>pveum</i> is a powerful command-line utility essential for administering user accounts, groups, roles, and access permissions within a <b>Proxmox Virtual Environment (PVE)</b> cluster. It provides the necessary tools for system administrators to control who can access and manage virtual machines, containers, storage, and other PVE resources. Through <i>pveum</i>, users can be created, modified, or deleted; assigned to groups; and linked to various authentication realms like <b>PAM</b>, <b>LDAP</b>, or Proxmox's internal database. The utility is fundamental for configuring <b>Access Control Lists (ACLs)</b> and defining custom roles, enabling granular control over user privileges. This ensures a secure and well-managed multi-user or multi-tenant virtualization environment, allowing for precise control over resource access and administrative actions. It serves as a vital tool for scripting and automating user management tasks.


title: CAVEATS
content:
<i>pveum</i> is specific to <b>Proxmox Virtual Environment</b> and is not a standard Linux command on general-purpose distributions. It requires administrative privileges on a Proxmox VE host. Incorrect usage can lead to unintended access changes or security vulnerabilities within the PVE cluster.


title: ACCESS CONTROL MODEL
content:
Proxmox VE utilizes a sophisticated <b>Role-Based Access Control (RBAC)</b> system combined with <b>Access Control Lists (ACLs)</b>. Users are assigned roles, which define broad sets of privileges. <i>ACLs</i> then specify which roles or users have access to particular objects (e.g., VMs, storage, nodes) within the PVE hierarchy. <i>pveum</i> is the primary command-line tool for configuring this granular access control system.


title: AUTHENTICATION REALMS
content:
Through <i>pveum realm</i>, administrators can configure various methods for user authentication. These include the <b>PVE internal user database</b>, <b>PAM</b> (for integration with local system users), and external directories such as <b>LDAP</b> or <b>Microsoft Active Directory</b>. This flexibility allows Proxmox VE to integrate seamlessly into existing IT infrastructures and leverage centralized user management systems.


title: HISTORY
content:
<i>pveum</i> is an integral component of <b>Proxmox Virtual Environment</b>, an open-source server virtualization management solution first released in 2007. Its development has closely paralleled the evolution of Proxmox VE, driven by the increasing need for robust, centralized user and permission management in clustered virtualization environments. It provides a powerful command-line alternative to the web GUI for user and access management, facilitating scripting and automation of administrative tasks.


title: TLDR
content:
<b>List users</b>`pveum [[u|user]] [[l|list]]`<br><b>Add a user</b>`pveum [[u|user]] [[a|add]] [username]@pve`<br><b>Delete a user</b>`pveum [[u|user]] [[d|delete]] [username]@pve`


title: SYNOPSIS
content:
<b>pvesh</b> help [<i>&lt;path&gt;</i>]<br><b>pvesh</b> [<i>&lt;METHOD&gt;</i>] [<i>&lt;path&gt;</i>] [<i>&lt;options&gt;</i>]<br><br><i>&lt;METHOD&gt;</i>: One of <b>get</b>, <b>put</b>, <b>post</b>, <b>delete</b>. These map directly to HTTP API methods.<br><i>&lt;path&gt;</i>: The API resource path (e.g., <b>/nodes/{node}/qemu</b>, <b>/cluster/status</b>).<br><i>&lt;options&gt;</i>: Parameters specific to the API method and path, often key-value pairs (e.g., <b>-vmid 100</b>, <b>-name myvm</b>). Global options like <b>--output-format</b> can also be used.


title: PARAMETERS
content:
<b>--nobanner</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the Proxmox VE Shell header and footer, useful for scripting.<br><br><b>-o, --output-format <i>&lt;format&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format (e.g., <b>json</b>, <b>json-pretty</b>, <b>text</b>, <b>yaml</b>, <b>proxmox-ve-shell</b>).<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about the operation.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses non-error output.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a dry run, showing what would happen without making actual changes.<br><br><b>--rpc-error-continuation</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows scripts to continue execution even if an RPC error occurs.<br><br><b>--pretty-json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;An alias for <b>--output-format json-pretty</b>.<br><br>


title: DESCRIPTION
content:
<b>pvesh</b> is the <b>Proxmox VE Shell</b>, a powerful command-line interface (CLI) for managing Proxmox Virtual Environment (PVE) installations. It acts as a direct client to the Proxmox VE API, allowing administrators to interact with all aspects of a PVE cluster, including virtual machines (VMs), containers (LXC), storage, networking, and cluster resources. Unlike specific tools like <b>qm</b> or <b>pct</b> that focus on a single resource type, <b>pvesh</b> provides a unified interface to the entire API, enabling comprehensive management tasks, automation, and scripting. It supports various HTTP methods (GET, PUT, POST, DELETE) for interacting with API paths and can be used both interactively and non-interactively for scripting purposes. It also offers the unique ability to execute arbitrary Perl code within the Proxmox environment.


title: CAVEATS
content:
Requires a running Proxmox VE installation for full functionality.<br>API calls require appropriate user permissions and authentication, which <b>pvesh</b> inherits from the current user's session or relies on configured API tokens.<br>Direct interaction with the API is powerful and can lead to unintended consequences if not used carefully, especially with <b>put</b>, <b>post</b>, or <b>delete</b> methods.


title: INTERACTIVE MODE
content:
When executed without arguments (e.g., just <b>pvesh</b>), it launches an interactive shell environment, similar to a regular Linux shell, but tailored for Proxmox VE commands. This mode provides tab-completion for API paths and parameters, making exploration and management easier.


title: API METHOD MAPPING
content:
<b>pvesh</b> translates its command syntax (e.g., <b>pvesh get /cluster/status</b>) directly into HTTP requests to the Proxmox VE REST API. <b>get</b> maps to HTTP GET, <b>post</b> to HTTP POST, <b>put</b> to HTTP PUT, and <b>delete</b> to HTTP DELETE. This direct mapping makes it an ideal tool for understanding and interacting with the underlying API structure.


title: PERL INTEGRATION
content:
Beyond API calls, <b>pvesh</b> allows users to execute arbitrary Perl code. This feature provides advanced scripting capabilities, enabling complex logic and data manipulation directly within the Proxmox environment, leveraging Perl's rich ecosystem and Proxmox's internal libraries.


title: HISTORY
content:
<b>pvesh</b> has been a fundamental component of Proxmox VE since its inception, evolving alongside the Proxmox VE API. It was designed to provide a consistent and programmatic interface to the underlying API, enabling both interactive system administration and advanced scripting for automation. Its development has focused on reflecting the growing capabilities of the PVE platform, making it the primary command-line tool for managing the entire Proxmox ecosystem.


title: TLDR
content:
<b>List available nodes</b>`pvesh [[g|get]] /nodes`<br><b>Display detailed information about containers or virtual machines</b>`pvesh [[g|get]] /nodes/[node_name]/[lxc|qemu]`<br><b>Discover API paths</b>`pvesh [[l|ls]] [/]`<br><b>Display API path usage instructions</b>`pvesh [[u|usage]] [/pools]`


title: PARAMETERS
content:
<b><i>&lt;vmid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The ID of the Proxmox container (VMID) where the command will be executed.<br><br><b><i>&lt;command&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The command to be run inside the container. This must be a command available within the container's environment.<br><br><b><i>&lt;args&gt;</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional arguments that are passed to the <i>&lt;command&gt;</i> being executed.<br><br><b>--description <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A descriptive string for the executed task, which will be visible in the Proxmox task log.<br><br><b>--no-pty</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables pseudo-TTY allocation for the command. This is recommended for non-interactive scripts or commands.<br><br><b>--pty</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces pseudo-TTY allocation for the command. This is useful for interactive commands like shells or text editors where terminal features are expected.<br><br><b>--user <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the username under which the command should be executed inside the container. By default, commands run as 'root'.<br><br><b>--shell <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the shell to use when the <b>--user</b> option is specified. If not set, it defaults to <i>/bin/sh</i>.<br><br><b>--timeout <i>&lt;integer&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a timeout in seconds for the command execution. If the command runs longer than this duration, it will be terminated.<br><br><b>--output-format <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format for the command's result, e.g., 'json'.<br><br><b>--ignore-lock</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignores any existing locks on the container. Use with caution as it can lead to inconsistent states if multiple operations are concurrent.<br><br><b>--no-logs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents logging of the command's output in the Proxmox task log. The command's exit status will still be logged.<br><br>


title: DESCRIPTION
content:
The <b>pct exec</b> command is a utility provided by the Proxmox Container Toolkit (PCT) for Proxmox Virtual Environment. It allows users to execute commands directly inside a running Linux Container (LXC) managed by Proxmox. Similar in concept to <i>docker exec</i> or <i>lxc-attach</i>, <b>pct exec</b> provides a powerful way to interact with the container's environment, troubleshoot issues, or perform administrative tasks without needing to SSH into the container itself. By default, commands are executed as the <i>root</i> user within the container, but it also supports specifying an alternative user and shell, making it flexible for various use cases, from interactive debugging to automated scripting.


title: CAVEATS
content:
<b>pct exec</b> is specific to Proxmox Virtual Environment and requires a running LXC container. Commands are executed directly within the container's kernel namespace, granting them full access to the container's resources and file system. Running commands as <i>root</i> inside the container by default carries significant security implications; always ensure commands and their sources are trusted. Network connectivity and overall host system performance can influence command execution within the container.


title: INTERACTIVE VS. NON-INTERACTIVE USE
content:
When <b>pct exec</b> is used without explicit <b>--pty</b> or <b>--no-pty</b>, it attempts to detect if the command is interactive (e.g., a shell or editor) and allocates a pseudo-TTY accordingly. For scripts or automated tasks, it's best practice to explicitly use <b>--no-pty</b> to avoid issues with terminal control sequences. For commands that require interactive input or display, <b>--pty</b> ensures proper terminal behavior.


title: EXIT STATUS
content:
The exit status of the <b>pct exec</b> command directly reflects the exit status of the command executed inside the container. A return code of zero typically indicates successful execution, while any non-zero value signifies an error or a specific condition reported by the executed command.


title: HISTORY
content:
<b>pct exec</b> is an integral part of the Proxmox Container Toolkit (PCT), which was developed to provide robust management capabilities for Linux Containers (LXC) within the Proxmox Virtual Environment (PVE). As PVE evolved into a comprehensive virtualization platform, <b>pct exec</b> was introduced and refined to offer system administrators a direct and efficient way to interact with and troubleshoot running containers, complementing other container management functionalities.


title: TLDR
content:
<b>Launch a command in a container</b>`pct [[ex|exec]] [100] [command]`<br><b>Open a Bash shell in a container</b>`pct [[ex|exec]] [100] bash`<br><b>Pass arguments to the command</b>`pct [[ex|exec]] [100] -- [command] [arguments]`


title: PARAMETERS
content:
<b><i>&lt;vmid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The unique numeric ID of the virtual machine from which to unlink the disk.<br><br><b><i>&lt;diskid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The identifier of the disk to be unlinked (e.g., 'ide0', 'scsi1', 'sata0'). This corresponds to the drive slot within the VM configuration.<br><br><b><i>--delete &lt;boolean&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;If set to '1' (true), the underlying disk image file will also be deleted from the storage along with unlinking it from the VM. Default is '0' (false).<br><br><b><i>--force &lt;boolean&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;If set to '1' (true), attempts to force the unlinking operation even if potential issues are detected. Use with caution as it might lead to data inconsistencies. Default is '0' (false).<br><br><b><i>--skiplock &lt;boolean&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;If set to '1' (true), the command will proceed without acquiring a lock on the VM. This can be dangerous and lead to corruption if other operations are running concurrently. Default is '0' (false).<br><br>


title: DESCRIPTION
content:
The <b>qm-unlink</b> command, part of the Proxmox Virtual Environment (PVE) <i>qm</i> utility, is used to detach a virtual disk from a specific virtual machine's configuration. This operation removes the disk's entry from the VM's hardware settings, making it no longer accessible to the VM. It's important to note that, by default, <b>qm-unlink</b> only unlinks the disk configuration; it does <i>not</i> delete the underlying disk image file from the storage. This allows for flexible management of disk resources, such as moving a disk to another VM, re-using it later, or performing manual cleanup. To also delete the disk file, the <i>--delete</i> option must be explicitly used. This command is crucial for managing storage attached to virtual machines in a Proxmox environment, enabling administrators to reconfigure VM storage without permanent data loss unless intended.


title: CAVEATS
content:
<b><br>1. Disk File Persistence:</b> By default, <b>qm-unlink</b> only removes the disk from the VM's configuration and does <i>not</i> delete the actual disk image file. Use the <i>--delete</i> option with extreme caution, as it will permanently remove the data.<br><br><b>2. VM State:</b> Ensure the virtual machine is powered off before unlinking critical disks to prevent data corruption. While some hot-plugged disks might allow unlinking while the VM is running, it's generally safer to power off.<br><br><b>3. Advanced Options:</b> The <i>--force</i> and <i>--skiplock</i> options should be used only by experienced administrators who understand the potential risks, as they can lead to data loss or inconsistencies if misused.


title: UNLINKING VS. DELETING
content:
It's crucial to understand the distinction between unlinking and deleting a disk. Unlinking (the default behavior of <b>qm-unlink</b>) removes the disk from the VM's configuration file (e.g., <i>/etc/pve/qemu-server/&lt;vmid&gt;.conf</i>). The actual disk image file (e.g., <i>.qcow2</i>, <i>.raw</i>) remains on the storage. Deleting, enabled by the <i>--delete</i> option, removes both the configuration entry and the disk image file itself. This two-step approach allows for greater control over storage resources and prevents accidental data loss.


title: HISTORY
content:
The <b>qm-unlink</b> command is an integral part of the <i>qm</i> utility, which is the primary command-line interface for managing virtual machines within the Proxmox Virtual Environment (PVE). Proxmox VE, first released in 2007, built its virtualization capabilities on QEMU/KVM. As such, the <i>qm</i> tool and its subcommands, including <b>qm-unlink</b>, have evolved alongside PVE to provide robust disk management features necessary for enterprise-grade virtualization. Its function has remained consistent: to provide a straightforward way to manage the lifecycle of virtual disks attached to VMs.


title: SYNOPSIS
content:
<b>pveam</b> <I>command</I> [options]<br><br>Examples:<br><b>pveam</b> <I>update</I><br><b>pveam</b> <I>list</I><br><b>pveam</b> <I>download</I> <I>local</I> <I>debian-11-standard_11.0-1_amd64.tar.gz</I><br><b>pveam</b> <I>delete</I> <I>local</I> <I>ubuntu-22.04-standard_22.04-1_amd64.tar.gz</I>


title: PARAMETERS
content:
<b>download <storage> <template-id|URL></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Downloads a container template or ISO image to the specified storage. <br> <i>storage</i>: The ID of the storage where the file will be saved. <br> <i>template-id|URL</i>: The ID of the template from the Proxmox template catalog (e.g., 'ubuntu-20.04-standard') or a direct URL to the template/ISO file.<br><br><b>list [options]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists existing container templates and ISO images stored on the Proxmox VE server. <br> Common options include: <br> <i>-p, --pve-only</i>: Show only official Proxmox VE templates. <br> <i>-template, --template-only</i>: Show only container templates. <br> <i>-iso, --iso-only</i>: Show only ISO images.<br><br><b>delete <storage> <filename></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes a specific container template or ISO image from the designated storage. <br> <i>storage</i>: The ID of the storage from which to delete. <br> <i>filename</i>: The full name of the file to delete (e.g., 'ubuntu-20.04-standard_20.04-1_amd64.tar.gz').<br><br><b>update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates the local index of available container templates from the official Proxmox VE repositories. This command fetches the latest list of templates and their download URLs.<br><br>


title: DESCRIPTION
content:
<code>pveam</code> is the <b>Proxmox Virtual Environment Appliance Manager</b>, a powerful command-line utility for managing container templates and ISO images within a Proxmox VE cluster. It streamlines the deployment process by allowing users to easily download official Proxmox templates for <i>LXC containers</i> and ISO files for <i>virtual machines</i> directly from configured repositories or custom URLs.<br><br>With <code>pveam</code>, administrators can quickly list, download, and delete these essential files, ensuring that up-to-date resources are readily available for creating new virtual machines and containers. It's an indispensable tool for efficient resource provisioning and management in a Proxmox VE environment.


title: CAVEATS
content:
Running <code>pveam</code> typically requires <b>root privileges</b> or <code>sudo</code> due to its system-wide management of templates and ISOs. <br> For <code>download</code> and <code>update</code> commands, an active internet connection is essential to access Proxmox VE repositories. <br> Ensure the target storage is correctly configured and has sufficient free space before attempting downloads.


title: TYPICAL WORKFLOW
content:
A common workflow involves first running <b>pveam update</b> to refresh the template catalog. Next, <b>pveam list</b> can be used to view available templates and their IDs. Finally, <b>pveam download <storage> <template-id></b> fetches the desired template. Once downloaded, these templates can be used to create new containers via <b>pct create</b> or VMs via <b>qm create</b>.


title: FILE TYPES
content:
<i>Container templates</i> are typically distributed as compressed archives (e.g., <code>*.tar.gz</code>), designed for use with LXC containers. <i>ISO images</i> are standard optical disc images (<code>*.iso</code>) used for installing operating systems on KVM virtual machines.


title: HISTORY
content:
The <code>pveam</code> command is an integral part of the <b>Proxmox Virtual Environment</b>, a comprehensive open-source virtualization platform developed by Proxmox Server Solutions GmbH. It was introduced as a core utility to simplify and standardize the management of container templates and ISO images, reflecting Proxmox VE's focus on ease of use and rapid deployment for both <i>KVM virtual machines</i> and <i>LXC containers</i> since its early versions.


title: TLDR
content:
<b>Update container template database</b>`pveam [[u|update]]`<br><b>List available templates</b>`pveam [[a|available]]`<br><b>Download a template</b>`pveam [[d|download]] [local] [template_name]`<br><b>List downloaded templates</b>`pveam [[l|list]] [local]`<br><b>List available templates in a specific section</b>`pveam [[a|available]] --section [system|turnkeylinux|mail]`<br><b>Remove a template</b>`pveam [[r|remove]] [local]:[vztmpl]/[template_name]`


title: SYNOPSIS
content:
<b>pct status</b> <i>&lt;vmid&gt;</i><br>(<i>&lt;vmid&gt;</i> is the numeric ID of the LXC container)


title: DESCRIPTION
content:
<b>pct status</b> is a command-line utility used within Proxmox Virtual Environment (PVE) to ascertain the operational status of a specific Linux Container (LXC). Unlike virtual machines (KVM), LXC containers share the host kernel, and <b>pct status</b> provides a quick and precise snapshot of whether a container is running, stopped, or experiencing issues. It is part of the <i>proxmox-tools</i> suite and is essential for administrators to monitor and manage the state of their containerized workloads. The command requires a Container ID (VMID) as an argument and returns a simple string indicating the container's current state, such as "running", "stopped", or "unknown". This information is crucial for scripting, automation, and general system monitoring, allowing users to verify if a container is in the expected state before performing further actions like starting, stopping, or migrating it.


title: CAVEATS
content:
<b>Proxmox VE Specific:</b> This command is exclusive to Proxmox Virtual Environment installations and will not be found on standard Linux distributions without PVE.<br><b>LXC Only:</b> It operates solely on Linux Containers (LXC) and cannot be used for KVM virtual machines; use <i>qm status</i> for KVM VMs.<br><b>Permissions:</b> Requires root privileges or appropriate sudo permissions to execute.<br><b>VMID Required:</b> Always requires a valid Container ID (VMID) as an argument. It cannot be used to list the status of all containers (use <i>pct list</i> for that).


title: OUTPUT VALUES
content:
The command typically returns one of the following simple strings:<br><i>running</i>: The container is active and operational.<br><i>stopped</i>: The container is currently shut down.<br><i>unknown</i>: The status could not be determined, often indicating an issue with the container or Proxmox services.<br><i>suspended</i>: The container state has been frozen to disk or memory (less common for LXC than for KVM).


title: USAGE EXAMPLE
content:
To check the status of an LXC container with VMID <i>101</i>:<br><pre># pct status 101</pre><br>Expected output:<br><pre>running</pre><br>or<br><pre>stopped</pre>


title: HISTORY
content:
The <i>pct</i> command suite was developed as an integral part of Proxmox Virtual Environment to provide robust command-line management for LXC containers. As Proxmox VE evolved to support both KVM and LXC technologies, a dedicated set of tools for container management became necessary. <i>pct status</i> emerged as a fundamental utility, alongside other <i>pct</i> sub-commands, to offer granular control and immediate feedback on container states, reflecting the growing adoption of containerization in virtualization platforms.


title: TLDR
content:
<b>Display if the container is running</b>`pct status [100]`<br><b>Display detailed container information</b>`pct status [100] --verbose`


title: SYNOPSIS
content:
<I>Not a standard system command; typically an alias or script wrapper.</I><br><br>Common usage resembles:<br><b>astroterm</b> [<I>IPython_options</I>]<br><br>The actual command it executes might be <b>ipython</b> or <b>python</b> with specific environment variables or initialization scripts.


title: PARAMETERS
content:
<b>[<I>IPython_options</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Options provided after <b>astroterm</b> are typically passed directly to the underlying <I>IPython</I> or Python interpreter it launches. For instance, options like <I>--matplotlib</I> or <I>--pylab</I> could be passed to <I>IPython</I> for immediate plotting support within the interactive session.<br><br>


title: DESCRIPTION
content:
<b>astroterm</b> is generally not a standard, universally available Linux command but rather a common alias or shell script found in environments configured for astronomical data analysis, particularly those utilizing the <I>Astropy</I> Python library. Its primary purpose is to launch an interactive Python (often <I>IPython</I>) shell with pre-loaded modules and configurations essential for astronomical computations, such as <I>Astropy</I>, <I>NumPy</I>, and <I>Matplotlib</I>.<br><br>This provides a convenient and ready-to-use environment for researchers and students to perform calculations, visualize data, and prototype code related to astronomy and astrophysics without the need for manual imports or extensive setup. It aims to simplify access to powerful scientific computing tools in an astronomical context.


title: CAVEATS
content:
<ul><li><b>Non-Standard Command:</b> <b>astroterm</b> is not a universally available command on all Linux systems. Its presence depends entirely on the installation of specific astronomical software packages (e.g., <I>Astropy</I> or dedicated astronomy environments) and whether a corresponding alias or script has been set up by the user or system administrator.</li><li><b>Implementation Varies:</b> The exact behavior and underlying implementation of <b>astroterm</b> can differ significantly. It might be a simple shell alias, a small Python script, or part of a larger package's entry points.</li><li><b>Dependencies:</b> Requires Python, <I>IPython</I> (for enhanced interactive features), and typically <I>Astropy</I> and other core scientific libraries (<I>NumPy</I>, <I>SciPy</I>, <I>Matplotlib</I>) to be installed and properly configured in the environment.</li></ul>


title: INTEGRATION WITH ASTROPY
content:
<b>astroterm</b> is most closely associated with the <I>Astropy</I> project, a community-developed Python library for astronomy. When <b>astroterm</b> is used, it often ensures that <I>Astropy</I> is readily available and potentially pre-imports common <I>Astropy</I> sub-modules (e.g., <I>astropy.units</I>, <I>astropy.constants</I>) for immediate use, making it an ideal entry point for Astropy-centric work.


title: INTERACTIVE ENVIRONMENT
content:
It provides an interactive prompt where users can type Python code, execute commands, and get immediate feedback. This makes it ideal for data exploration, quick calculations, script development, and educational exercises within an astronomical context, leveraging the full power of Python's scientific stack.


title: HISTORY
content:
The concept of a specialized 'astroterm' emerged with the growing use of Python and its rich ecosystem of scientific libraries, particularly <I>Astropy</I>, as primary tools for astronomical research and education. While not a formally developed 'command' in the traditional sense, the practice of creating an <b>astroterm</b> alias or script became common among users and distributors of astronomical software. This provided a quick-start, pre-configured interactive environment, streamlining the workflow for astronomers by reducing initial setup time and ensuring access to essential tools. It reflects a community-driven effort to enhance usability rather than a distinct software project with a formal development history.


title: TLDR
content:
<b>Display real-time positions of stars and planets based on your current location</b>`astroterm`<br><b>Display constellations, use colour, and render the simulation at the given frame rate</b>`astroterm [[-C|--constellations]] [[-c|--color]] [[-f|--fps]] [60]`<br><b>Use unicode characters instead of the basic ASCII characters, and only render stars brighter than the given magnitude</b>`astroterm [[-u|--unicode]] [[-t|--threshold]] [2.0]`<br><b>Use a given latitude, longitude and datetime</b>`astroterm [[-a|--latitude]] [90.0] [[-o|--longitude]] [-180.0] [[-d|--datetime]] [2025-08-04T12:00:00]`<br><b>Use the longitude and latitude of a given city, and set the speed of the simulation to a given factor</b>`astroterm [[-i|--city]] [Singapore] [[-s|--speed]] [1000.0]`


title: SYNOPSIS
content:
<b>elasticsearch-users</b> <i>&lt;subcommand&gt;</i> [<i>options</i>] [<i>arguments</i>]<br><br><i>Common subcommands include:</i><br><b>elasticsearch-users add</b> <i>&lt;username&gt;</i> <b>-p</b> <i>&lt;password&gt;</i> <b>-r</b> <i>&lt;role1&gt;</i> [<b>-r</b> <i>&lt;role2&gt;</i>...]<br><b>elasticsearch-users passwd</b> <i>&lt;username&gt;</i> <b>-p</b> <i>&lt;new_password&gt;</i><br><b>elasticsearch-users delete</b> <i>&lt;username&gt;</i><br><b>elasticsearch-users list</b><br><b>elasticsearch-users roles</b> <i>&lt;username&gt;</i>


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the command or a specific subcommand.<br><br><b><b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed execution information.<br><br><b><b>--silent</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses all output messages, useful for scripting.<br><br><b><b>-p</b>, <b>--password</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <i>add</i> and <i>passwd</i> subcommands to specify or set the user's password. Omitting this flag will prompt for secure password entry.<br><br><b><b>-r</b>, <b>--roles</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the <i>add</i> subcommand to assign one or more roles to the new user. Can be specified multiple times for multiple roles.<br><br><b><b>--system</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(add subcommand only)</i> Marks the new user as a system user, primarily for internal Elasticsearch processes.<br><br><b><b>--description</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(add subcommand only)</i> Provides a descriptive text for the new user.<br><br>


title: DESCRIPTION
content:
The <b>elasticsearch-users</b> command-line utility provides administrative functions for managing users within Elasticsearch's native and file security realms. It enables operations such as creating, deleting, and modifying users, changing passwords, and assigning roles directly from the terminal. This tool is particularly valuable for automating user management tasks or for scenarios where direct API interaction or Kibana's UI is not feasible. It interacts with Elasticsearch's security layer to ensure controlled access to cluster resources. While effective for its purpose, it's important to note its deprecation status in newer Elasticsearch versions, advocating for migration towards direct Security APIs or Kibana for more modern and integrated user management workflows. This utility is typically located in the Elasticsearch installation's <i>bin</i> directory and operates against a running Elasticsearch instance.


title: CAVEATS
content:
<b>Deprecation:</b> The <b>elasticsearch-users</b> command is deprecated in recent Elasticsearch versions (e.g., 7.x+) in favor of direct Elasticsearch Security APIs, Kibana's security management UI, or the newer <b>elasticsearch-api-util</b> CLI tool. Users are strongly encouraged to transition to these modern alternatives.<br><b>Realm Specificity:</b> This utility primarily manages users within the <i>native</i> or <i>file</i> realms. It does not support user management for external realms like LDAP, Active Directory, or SAML.<br><b>Security:</b> Providing passwords directly on the command line using <b>-p</b> can expose them in process listings (e.g., <i>ps -ef</i>). For enhanced security, omit the password flag to be prompted for a secure input.<br><b>Permissions:</b> Proper file system permissions on the Elasticsearch installation directory and appropriate cluster privileges are required to execute this command successfully.


title: KEY SUBCOMMANDS
content:
The <b>elasticsearch-users</b> command functions through a set of specific subcommands, each performing a distinct user management operation:<br><b>add</b> <i>&lt;username&gt;</i>: Creates a new user, requiring a password (<b>-p</b>) and assigned roles (<b>-r</b>).<br><b>delete</b> <i>&lt;username&gt;</i>: Removes an existing user from the realm.<br><b>passwd</b> <i>&lt;username&gt;</i>: Changes the password for an existing user, requiring the new password (<b>-p</b>).<br><b>list</b>: Displays a list of all users configured in the realm.<br><b>roles</b> <i>&lt;username&gt;</i>: Shows the roles currently assigned to a specified user.


title: HISTORY
content:
The <b>elasticsearch-users</b> command emerged as a key utility for command-line user management alongside the development and integration of X-Pack security features into Elasticsearch. It provided a direct and scriptable way to manage native and file realm users, filling a crucial need before more comprehensive API and UI tools matured. Its evolution reflects Elasticsearch's journey towards robust security, transitioning from specific CLI tools to a more API-first and integrated management approach, culminating in its deprecation as the Security APIs and Kibana's capabilities expanded.


title: TLDR
content:
<b>Add a new user interactively (prompts for password)</b>`elasticsearch-users useradd [username]`<br><b>Add a new user and specify roles</b>`elasticsearch-users useradd [username] -r [role1,role2]`<br><b>Change the password for an existing user</b>`elasticsearch-users passwd [username]`<br><b>Delete a user</b>`elasticsearch-users userdel [username]`<br><b>List all users in the native realm</b>`elasticsearch-users list`


title: SYNOPSIS
content:
<b><I>elasticsearch-saml-metadata</I></b> --url <I>es_cluster_url</I> --saml-realm <I>realm_name</I> [--output <I>file</I>] [<I>options</I>]


title: PARAMETERS
content:
<b>--url <I>es_cluster_url</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the URL of the Elasticsearch cluster (e.g., <I>https://localhost:9200</I>). This URL is used to derive the Entity ID and Assertion Consumer Service (ACS) URL within the generated SAML metadata. It must be an accessible endpoint of your Elasticsearch instance.<br><br><b>--saml-realm <I>realm_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Mandatory. Defines the name of the SAML authentication realm configured in your <I>elasticsearch.yml</I> file for which the metadata should be generated. The specified realm must already exist and be active.<br><br><b>--output <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the output file where the SAML metadata XML will be written. If this option is omitted, the metadata will be printed to standard output (stdout).<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the command to overwrite the output file if it already exists, without prompting for confirmation.<br><br><b>--insecure</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows the command to connect to an Elasticsearch cluster even if its SSL/TLS certificate is untrusted (e.g., self-signed or expired). Use with caution in production environments.<br><br><b>--ca-cert <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to a CA certificate bundle (<I>.pem</I> file) used to verify the SSL/TLS certificate of the Elasticsearch cluster. This is essential for secure connections when your Elasticsearch instance uses a trusted certificate.<br><br><b>--config <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a path to a configuration file that provides command-line options. Options specified directly on the command line will override those in the file.<br><br><b>--username <I>username</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the username for authenticating with the Elasticsearch cluster, if basic authentication is required for accessing the security endpoint.<br><br><b>--password <I>password</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the password for the specified username when authenticating with the Elasticsearch cluster.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message detailing the command's usage and available options.<br><br>


title: DESCRIPTION
content:
The <b><I>elasticsearch-saml-metadata</I></b> command is a crucial utility provided by Elasticsearch for setting up SAML (Security Assertion Markup Language) authentication. It generates the Service Provider (SP) metadata XML file for a specific SAML realm configured in your Elasticsearch cluster. This metadata file contains essential information about the Elasticsearch SP, such as its entity ID, Assertion Consumer Service (ACS) URL, and signing certificate, which is then provided to your Identity Provider (IdP). The IdP uses this information to configure its side of the SAML integration, allowing it to correctly send authenticated assertions back to Elasticsearch. This command simplifies the complex process of creating the necessary XML metadata, ensuring interoperability between Elasticsearch and a wide range of SAML 2.0 compliant Identity Providers.


title: CAVEATS
content:
This command requires network connectivity to the Elasticsearch cluster.<br>The specified <I>--url</I> must be the exact URL that your Identity Provider (IdP) will use to reach Elasticsearch's Assertion Consumer Service.<br>The <I>--saml-realm</I> must be pre-configured in your <I>elasticsearch.yml</I> file before running this command.<br>Running this command may require appropriate privileges if the security endpoint is protected by basic authentication (e.g., a user with <I>manage_security</I> or <I>monitor</I> cluster privileges).


title: HISTORY
content:
The <b><I>elasticsearch-saml-metadata</I></b> command was introduced as part of the X-Pack security features in Elasticsearch, enabling robust enterprise-grade authentication through SAML 2.0. Its development paralleled the increasing demand for seamless integration with corporate Identity Providers, simplifying the often complex process of SAML configuration by automating the generation of the Service Provider metadata XML, which is critical for establishing trust between Elasticsearch and an IdP.


title: SEE ALSO
content:
elasticsearch-certutil(1), elasticsearch-users(1), elasticsearch-setup-passwords(1), bin/elasticsearch(1)


title: TLDR
content:
<b>Generate SAML metadata for a specific realm and print it to stdout</b>`elasticsearch-saml-metadata --realm [realm_name]`<br><b>Generate SAML metadata and write it to a specific file</b>`elasticsearch-saml-metadata --realm [realm_name] --out [path/to/file.xml]`<br><b>Display help</b>`elasticsearch-saml-metadata [[-h|--help]]`


title: SYNOPSIS
content:
<b>elasticsearch-node</b> <i>&lt;command&gt;</i> [<i>&lt;options&gt;</i>]<br><br><u>Common Usage Examples:</u><br><b>elasticsearch-node</b> <i>list</i><br><b>elasticsearch-node</b> <i>stats</i><br><b>elasticsearch-node</b> <i>repurpose</i> <i>--master</i> <i>my_node_name</i><br><b>elasticsearch-node</b> <i>unsafe-bootstrap</i>


title: PARAMETERS
content:
<b>list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all nodes currently registered with the Elasticsearch cluster, displaying their name, ID, roles, and other relevant information.<br><br><b>stats</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieves and displays various detailed statistics about the Elasticsearch node, including JVM metrics, OS information, process details, and thread pool metrics.<br><br><b>repurpose <i>&lt;node_name&gt;</i> <i>--master</i>|<i>--data</i>|<i>--ingest</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Changes the role of a specified node within the cluster. For instance, it can be used to make a data node eligible to become a master node. Requires the node name and appropriate role options.<br><br><b>unsafe-bootstrap</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used to bootstrap a single-node Elasticsearch cluster from a non-bootstrapped state. This command should be used with extreme caution and only in specific disaster recovery scenarios when all master-eligible nodes are lost.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays general help information for the <i>elasticsearch-node</i> command or specific help for a given subcommand.<br><br>


title: DESCRIPTION
content:
<i>elasticsearch-node</i> is a command-line utility provided with Elasticsearch, designed for administrators to manage specific aspects of an individual node's participation within an Elasticsearch cluster. Unlike the primary <i>elasticsearch</i> command which starts and runs an instance, <i>elasticsearch-node</i> focuses on node-level administrative tasks related to cluster topology and state. It enables operations such as listing all active nodes in the cluster, retrieving detailed statistics for a node, and performing advanced actions like changing a node's role (e.g., from a data node to a master-eligible node) or bootstrapping a single-node cluster under specific recovery scenarios. This tool helps in diagnosing cluster health, reconfiguring node roles, and ensuring proper cluster membership.


title: CAVEATS
content:
<b>Key Considerations:</b><br><i>elasticsearch-node</i> operations (e.g., list, stats) typically require a running Elasticsearch instance or connectivity to a cluster.<br>The <i>unsafe-bootstrap</i> command is powerful and potentially destructive; use it only when absolutely necessary and understand its implications on cluster state.<br>The user executing the command must have appropriate file system permissions to access Elasticsearch's configuration and data directories.<br>The command is usually found in the <i>ELASTICSEARCH_HOME/bin/</i> directory and might require navigating there or adding it to your system's <i>PATH</i>.<br>For secured clusters, proper authentication (e.g., API keys, username/password) or security configuration might be required.


title: EXECUTION CONTEXT
content:
The <i>elasticsearch-node</i> command typically needs to be executed from the Elasticsearch installation directory's <i>bin</i> subdirectory. Alternatively, ensure that this directory is included in your system's <i>PATH</i> environment variable for direct access.


title: SECURITY CONSIDERATIONS
content:
In a secure Elasticsearch cluster, interactions with <i>elasticsearch-node</i> may require proper authentication. This could involve providing API keys, usernames and passwords, or ensuring the security configuration allows the command to connect to the cluster successfully, especially when managing remote or production environments.


title: HISTORY
content:
Elasticsearch, initially released in 2010, has continuously evolved its command-line toolset alongside its core functionality. As the platform grew in complexity and enterprise adoption, specialized utility scripts like <i>elasticsearch-node</i> were introduced. These tools abstract away lower-level API interactions, simplifying common administrative tasks related to node-level cluster membership, configuration, and diagnostics. The dedicated focus of <i>elasticsearch-node</i> on node roles and cluster state management reflects the increasing importance of robust cluster resilience and topological control in modern Elasticsearch deployments.


title: SEE ALSO
content:
elasticsearch(1), elasticsearch-plugins(1), elasticsearch-setup-passwords(1), curl(1), systemctl(1) / service(8)


title: TLDR
content:
<b>Display information about the current node</b>`elasticsearch-node info`<br><b>Prepare the node for a full cluster restart (e.g., after upgrading)</b>`elasticsearch-node unsafe-bootstrap`<br><b>Repurpose a node for a different role (e.g., from master to data node)</b>`elasticsearch-node repurpose`<br><b>List the roles assigned to the node</b>`elasticsearch-node roles`<br><b>Show the installed JVM version, Elasticsearch home path, and other diagnostic information</b>`elasticsearch-node diagnostics`<br><b>Display help</b>`elasticsearch-node [[-h|--help]]`


title: SYNOPSIS
content:
<b>b2</b> [<i>GLOBAL_OPTIONS</i>] <i>&lt;COMMAND&gt;</i> [<i>COMMAND_OPTIONS</i>] [<i>ARGUMENTS</i>]<br><i>Examples:</i><br><b>b2</b> authorize <i>&lt;accountId&gt;</i> <i>&lt;applicationKey&gt;</i><br><b>b2</b> ls --long <i>b2://my-bucket</i><br><b>b2</b> upload_file <i>--no-progress my-bucket local_file.txt remote_path/file.txt</i>


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message for the <b>b2</b> command or a specific subcommand.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the installed version number of the <b>b2</b> command-line tool.<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug logging, useful for troubleshooting issues.<br><br><b><b>--account-id</b> <i>&lt;ID&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Backblaze B2 account ID, overriding any ID stored in the configuration file.<br><br><b><b>--application-key</b> <i>&lt;KEY&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Backblaze B2 application key, overriding any key stored in the configuration file.<br><br><b><b>--skip-by-hash</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;During uploads, if a file with the same name and SHA1 hash already exists at the destination, the upload is skipped.<br><br><b><b>--no-progress</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the display of the progress bar during file uploads or downloads.<br><br>


title: DESCRIPTION
content:
The <b>b2</b> command-line tool is a versatile utility for interacting with <i>Backblaze B2 Cloud Storage</i>. It allows users to perform various operations on their B2 buckets and files directly from the command line, providing a powerful interface for automating cloud storage tasks. Key functionalities include listing buckets and files, uploading and downloading data, managing file versions, and handling bucket lifecycle rules. It serves as a programmatic interface ideal for scripts and integration into larger workflows, ensuring secure and efficient data transfers. Being Python-based, it is commonly installed via <i>pip</i> and requires an active Backblaze B2 account for full functionality.


title: CAVEATS
content:
The <b>b2</b> command is not a standard Linux utility and must be installed separately (e.g., using <i>pip</i>).<br>Requires an active Backblaze B2 account and proper authorization before most operations can be performed.<br>Internet connectivity is essential for interacting with the B2 cloud storage service.<br>Security: Always protect your account ID and application keys. Avoid hardcoding them directly in scripts where possible; use environment variables or secure configuration methods.


title: AUTHENTICATION AND CONFIGURATION
content:
Before using most <b>b2</b> commands, you must authenticate. This is typically done via <b>b2 authorize &lt;accountId&gt; &lt;applicationKey&gt;</b>. This command stores your credentials securely in a configuration file (usually <i>~/.b2_account_info</i>), allowing subsequent commands to operate without re-entering credentials. You can create multiple application keys in the Backblaze B2 web interface with different permissions.


title: SUBCOMMANDS STRUCTURE
content:
The <b>b2</b> tool employs a subcommand structure. After the main <b>b2</b> command, you specify the operation you want to perform (e.g., <b>ls</b>, <b>upload_file</b>, <b>delete_file</b>, <b>sync</b>). Each subcommand has its own specific options and arguments. For example, to see options for listing files, you would run <b>b2 ls --help</b>.


title: HISTORY
content:
The <b>b2</b> command-line tool was developed as a crucial interface for <i>Backblaze B2 Cloud Storage</i>, which launched in 2015. Its inception provided users with a robust programmatic method to manage their cloud data, complementing the web-based interface. Written in Python, its development has closely tracked the evolution of the B2 API, continuously adding features for efficient data management, synchronization, and automation, making it an indispensable tool for developers and system administrators utilizing Backblaze B2.


title: PARAMETERS
content:
<b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show all occurrences of the <i>name</i>. For instance, if an alias exists and an executable with the same name also exists in the <b>PATH</b>, both will be reported.<br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;If the <i>name</i> refers to a shell function, display its definition rather than just indicating that it's a function. This is particularly useful for inspecting complex functions.<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a search only using the command search path (<b>PATH</b>). This option bypasses checking for aliases, functions, or built-in commands, making it behave similarly to the <b>which</b> command.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce a more verbose report for each <i>name</i>, providing more details about its type and location. This often adds extra descriptive text to the output.<br><br>


title: DESCRIPTION
content:
The <b>whence</b> command is a shell built-in utility, primarily found in <i>KornShell (ksh)</i> and <i>Z Shell (zsh)</i>. Unlike external commands like <b>which</b>, <b>whence</b> provides a comprehensive lookup of how a command name will be interpreted by the shell. This includes identifying if the name refers to an alias, a shell function, a built-in command, or an external executable found in the <b>PATH</b> environment variable.<br><br>Its primary purpose is to help users and script writers understand the exact nature and location of a command, which is crucial for debugging shell scripts or understanding command precedence. For example, if you define an alias for 'ls', <b>whence ls</b> will tell you it's an alias, whereas <b>which ls</b> might only show the external executable.


title: CAVEATS
content:
The <b>whence</b> command is a shell built-in and not an external executable. It is most commonly available in <i>KornShell (ksh)</i> and <i>Z Shell (zsh)</i>. Users of <i>Bash (Bourne-Again SHell)</i> should use the <b>type</b> built-in command, which offers similar functionality. The exact behavior and available options for <b>whence</b> can vary slightly between different shell versions and implementations.


title: COMMAND PRECEDENCE
content:
Shells resolve command names in a specific order: aliases first, then shell functions, then built-in commands, and finally external commands found in the <b>PATH</b>. <b>whence</b> helps illustrate this precedence by showing the *first* match the shell would use, and with <b>-a</b>, all potential matches.


title: DEBUGGING SHELL SCRIPTS
content:
When debugging shell scripts, it's common to use <b>whence</b> to ensure that the script is executing the intended version of a command, especially when dealing with environments that have many custom aliases or functions.


title: HISTORY
content:
The <b>whence</b> command originated in <i>KornShell (ksh)</i> as a powerful built-in for introspecting how commands are resolved by the shell. Its utility in distinguishing between aliases, functions, and external commands led to its adoption and similar implementations in other advanced shells like <i>Z Shell (zsh)</i>, providing a more robust alternative to the simpler <b>which</b> utility.


title: TLDR
content:
<b>Interpret command, with expansion if defined as an alias (similar to the command -v builtin)</b>`whence "[command]"`<br><b>Display type of command, with location if defined as a function, or binary (equivalent to the type and command -V builtins)</b>`whence -v "[command]"`<br><b>Same as above, except display content of shell functions instead of location (equivalent to which builtin)</b>`whence -c "[command]"`<br><b>Same as above, but show all occurrences on command path (equivalent to the where builtin)</b>`whence -ca "[command]"`<br><b>Search only the PATH for command, ignoring builtins, aliases or shell functions (equivalent to the where command)</b>`whence -p "[command]"`


title: TLDR
content:
<b>Quit Kodi</b>`kodi-send [[-a|--action]] Quit`<br><b>Reboot the system</b>`kodi-send [[-a|--action]] Reboot`<br><b>Send an action to a remote host</b>`kodi-send --host [192.168.0.1] --port [9777] [[-a|--action]] [Quit]`


title: PARAMETERS
content:
<b><i>command</i>: <b>ca</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a new self-signed Certificate Authority (CA) certificate and its private key. This CA can then be used to sign other certificates for your cluster.<br><br><b><i>command</i>: <b>cert</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a new certificate and its private key. This certificate can be self-signed or signed by an existing CA generated by <b>certutil ca</b> or an external CA. It's versatile for node, HTTP, or general-purpose certificates.<br><br><b><i>command</i>: <b>csr</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a Certificate Signing Request (CSR) and a private key. The CSR can then be submitted to an external Certificate Authority for signing to obtain a trusted certificate.<br><br><b><i>command</i>: <b>http</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A specialized subcommand to generate certificates specifically for the HTTP layer, typically used for securing communication between clients (like Kibana or web browsers) and the Elasticsearch REST API. Internally, it uses the <b>cert</b> command with appropriate defaults.<br><br><b><i>command</i>: <b>node</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A specialized subcommand to generate certificates for secure inter-node communication within the Elasticsearch cluster. Internally, it uses the <b>cert</b> command with appropriate defaults.<br><br><b><b>--ca-cert</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the Certificate Authority (CA) certificate file to be used for signing the new certificate.<br><br><b><b>--ca-key</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the Certificate Authority (CA) private key file corresponding to the CA certificate, used for signing.<br><br><b><b>--days</b> <i>&lt;N&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the validity period for the generated certificate in days. Certificates will expire after this duration.<br><br><b><b>--dns</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a DNS name as a Subject Alternative Name (SAN) to the certificate. This option can be specified multiple times for multiple DNS names. Essential for host verification.<br><br><b><b>--ip</b> <i>&lt;address&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds an IP address as a Subject Alternative Name (SAN) to the certificate. This option can be specified multiple times for multiple IP addresses. Essential for host verification.<br><br><b><b>--out</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the full path and filename for the output file where the generated certificate and private key (typically in PKCS#12 or PEM format) will be saved.<br><br><b><b>--pass</b> <i>&lt;password&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns a password to encrypt the private key within the output file. This is crucial for securing the private key.<br><br><b><b>--pem</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the generated certificate and private key in PEM format (.crt and .key files), rather than the default PKCS#12 format (.p12).<br><br><b><b>--multiple</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Triggers an interactive mode that allows generating multiple certificates in a single run, prompting for details for each.<br><br><b><b>--silent</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the command in non-interactive mode, suppressing all prompts and using default or specified values.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the <b>elasticsearch-certutil</b> command or a specific subcommand.<br><br><b><b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables more detailed output during the certificate generation process, useful for debugging.<br><br>


title: DESCRIPTION
content:
The <b>elasticsearch-certutil</b> command is a crucial utility provided by Elasticsearch for managing Transport Layer Security (TLS) certificates and keys. It simplifies the process of securing communication within an Elasticsearch cluster, covering both inter-node communication and HTTP client connections (e.g., Kibana, applications). It can generate self-signed Certificate Authorities (CAs), create node certificates, HTTP certificates, and Certificate Signing Requests (CSRs) for use with external CAs. This tool is essential for enabling encrypted communication and identity verification, ensuring the integrity and confidentiality of data flowing through the cluster.


title: CAVEATS
content:
<b><I>Key Security:</I></b> The private keys generated by <b>elasticsearch-certutil</b> are highly sensitive. They must be protected with strong passwords and strict file system permissions. Losing or compromising these keys can severely undermine your cluster's security.<br><br><b><I>Certificate Expiration:</I></b> Certificates have a defined validity period (set with <b>--days</b>). Ensure you have a plan for regenerating and replacing certificates before they expire to avoid service interruptions.<br><br><b><I>Subject Alternative Names (SANs):</I></b> It's critical to include all hostnames (DNS names) and IP addresses that clients will use to connect to your Elasticsearch nodes in the certificate's SANs using <b>--dns</b> and <b>--ip</b>. Failure to do so will result in certificate validation errors.<br><br><b><I>Cluster Restart:</I></b> After replacing certificates on an Elasticsearch node, the node (and often the entire cluster, in a rolling fashion) must be restarted for the new certificates to take effect.


title: PRODUCTION BEST PRACTICES
content:
For production deployments, consider generating your CA and node/HTTP certificates using a robust external CA or following a strict internal CA policy. The generated private keys should be stored securely, ideally in a hardware security module (HSM) or a secure vault. Automate certificate rotation processes to minimize manual intervention and ensure continuous security.<br><br>When deploying, ensure that the generated certificate and key files have appropriate read-only permissions for the Elasticsearch user and are not world-readable. Misconfigured permissions are a common security vulnerability.


title: PKCS#12 VS. PEM FORMAT
content:
By default, <b>elasticsearch-certutil</b> outputs certificates and keys in PKCS#12 format (a single <b>.p12</b> file containing both). This is often convenient for distribution. However, the <b>--pem</b> flag can be used to output separate <b>.crt</b> (certificate) and <b>.key</b> (private key) files in PEM format, which might be preferred by some applications or for easier inspection.


title: HISTORY
content:
The <b>elasticsearch-certutil</b> command was introduced as part of Elasticsearch's X-Pack security features (later bundled into the free Basic license). Its development was driven by the increasing need for robust, built-in TLS/SSL capabilities to secure data in transit within and around Elasticsearch clusters. It provides a convenient, Elasticsearch-specific abstraction over general-purpose cryptographic tools, simplifying certificate management for administrators.


title: TLDR
content:
<b>Generate a new Certificate Authority (CA) with default options</b>`elasticsearch-certutil ca`<br><b>Generate a new certificate using the built-in CA</b>`elasticsearch-certutil cert`<br><b>Generate certificates non-interactively and output PEM files</b>`elasticsearch-certutil cert [[-s|--silent]] --pem`<br><b>Generate HTTP certificates with the built-in CA</b>`elasticsearch-certutil http`<br><b>Generate transport certificates non-interactively</b>`elasticsearch-certutil transport [[-s|--silent]]`<br><b>Generate a certificate signing request (CSR)</b>`elasticsearch-certutil csr`<br><b>Generate encrypted keystore passwords</b>`elasticsearch-certutil password`<br><b>Generate a keystore password with a specified value</b>`elasticsearch-certutil password --pass [password]`


title: SYNOPSIS
content:
<i>elasticsearch-create-enrollment-token</i> [ <i>-s</i> <I>service-name</I> ]<br><i>elasticsearch-create-enrollment-token</i> [ <i>--service</i> <I>service-name</I> ]


title: PARAMETERS
content:
<b><i>-s</i> <I>service-name</I>, <i>--service</i> <I>service-name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the type of service that will use the enrollment token. Common values include <b>kibana</b> (which is the default if no service is specified) for Kibana instances, or <b>node</b> for Elasticsearch nodes. The token's purpose and the information it encapsulates vary based on the service type. For most initial setups, <b>kibana</b> is the intended service.<br><br>


title: DESCRIPTION
content:
The <i>elasticsearch-create-enrollment-token</i> command is a vital utility for securely integrating Elastic Stack components like Kibana with an Elasticsearch cluster. When Elasticsearch security features are enabled (e.g., in a default distribution), new Kibana instances cannot connect directly without proper authentication. This command generates a short-lived, single-use enrollment token that Kibana can use during its setup process to securely join the cluster. The token simplifies initial configuration by providing a temporary credential for Kibana to register itself, retrieve necessary cluster certificates, and establish secure communication. After successful enrollment, Kibana manages its own authentication with Elasticsearch, typically using service accounts. This command is executed on an existing Elasticsearch node by a user with sufficient privileges, such as the <i>elastic</i> superuser or a user with <i>manage_security</i> cluster privilege.


title: CAVEATS
content:
<b>Security Context</b>: The command must be run on an Elasticsearch node, typically by a user with <i>manage_security</i> cluster privilege or the <i>elastic</i> superuser. Running it with insufficient privileges will result in an error.<br><b>Token Expiration and Single Use</b>: Enrollment tokens are short-lived (default is 30 minutes) and can only be used once. After a token is used or expires, it becomes invalid.<br><b>Sensitive Output</b>: The generated token is sensitive information. It should be handled with extreme care and never exposed in insecure logs or shared publicly.<br><b>No Command-Line History</b>: Avoid pasting the token directly into scripts or saving it in command history files without proper security considerations.<br><b>Elastic Stack Version Compatibility</b>: Ensure the Elasticsearch version matches or is compatible with the Kibana version. Enrollment tokens are designed for specific security models that may vary slightly between major versions.


title: DEFAULT EXPIRATION
content:
The generated enrollment token has a default expiration of 30 minutes. This short lifespan is a security measure to limit the window of exposure, ensuring the token cannot be used indefinitely if compromised.


