# CommandSection

title: DESCRIPTION
content:
<i>OpenSSH-server</i> is the server component of the <i>OpenSSH</i> suite of tools, providing secure encrypted communication over untrusted networks. It enables remote login, command execution, and secure file transfers (via SCP and SFTP). The core executable is <b>sshd</b>, which runs as a background daemon, listening for incoming connections, typically on port 22. It authenticates connecting clients using various methods, including password, public key, and GSSAPI authentication, ensuring that only authorized users can access the system. <i>OpenSSH-server</i> replaces insecure protocols like Telnet, rlogin, and FTP, offering robust security features like strong encryption (e.g., AES, ChaCha20-Poly1305), data integrity checks, and protection against various network attacks. It is an indispensable tool for system administrators and developers to manage servers, deploy applications, and securely transfer data across the internet.<br><br>The server's behavior is highly configurable through the <b>sshd_config</b> file, allowing administrators to define listening ports, authentication methods, authorized users, and various security policies, making it a cornerstone for secure remote administration on Linux and Unix-like operating systems.


title: CAVEATS
content:
Opening port 22 (or any other port for SSH) to the internet poses security risks. It is crucial to:<br><i>1. Secure authentication:</i> Prefer public key authentication over password authentication. If using passwords, ensure they are strong.<br><i>2. Limit access:</i> Use firewall rules to restrict access to known IP addresses or networks.<br><i>3. Disable root login:</i> Prevent direct root login.<br><i>4. Use Fail2Ban:</i> Implement tools like <i>Fail2Ban</i> to mitigate brute-force attacks.<br><i>5. Keep software updated:</i> Regularly update <i>OpenSSH-server</i> to patch known vulnerabilities.<br><i>6. Review logs:</i> Monitor SSH logs for suspicious activity. Misconfiguration can lead to severe security vulnerabilities or lock you out of your system.


title: CONFIGURATION FILE
content:
The primary configuration for <i>OpenSSH-server</i> is located at <b>/etc/ssh/sshd_config</b>. This plain-text file controls almost every aspect of the server's behavior, including listening address and port, authentication methods (e.g., <i>PasswordAuthentication</i>, <i>PubkeyAuthentication</i>), logging levels, allowed users/groups (<i>AllowUsers</i>, <i>AllowGroups</i>), and security parameters. After modifying this file, the <b>sshd</b> service must be restarted (or reloaded) for changes to take effect.


title: SERVICE MANAGEMENT
content:
On most modern Linux distributions (those using <i>systemd</i>), <i>OpenSSH-server</i> (the <b>sshd</b> service) is managed using the <b>systemctl</b> command. Common commands include:<br><b>sudo systemctl start sshd</b>: Starts the SSH daemon.<br><b>sudo systemctl stop sshd</b>: Stops the SSH daemon.<br><b>sudo systemctl restart sshd</b>: Restarts the SSH daemon (applies configuration changes).<br><b>sudo systemctl reload sshd</b>: Reloads the SSH configuration without dropping active connections.<br><b>sudo systemctl status sshd</b>: Checks the current status of the SSH daemon.<br><b>sudo systemctl enable sshd</b>: Enables the SSH daemon to start on boot.


title: AUTHENTICATION METHODS
content:
<i>OpenSSH-server</i> supports several authentication methods:<br><i>1. Password Authentication:</i> Users provide their system password. Less secure against brute-force attacks.<br><i>2. Public Key Authentication:</i> The most recommended method. Users generate a key pair (public and private). The public key is placed on the server (in <b>~/.ssh/authorized_keys</b>), and the private key is kept by the client. This method is more secure and convenient.<br><i>3. Keyboard-Interactive Authentication:</i> A more flexible form of password authentication, often used for multi-factor authentication (e.g., prompting for an OTP).<br><i>4. GSSAPI Authentication:</i> Used in environments with Kerberos or other GSSAPI mechanisms.


title: HISTORY
content:
<i>SSH (Secure Shell)</i> was originally designed in 1995 by Tatu Ylönen to replace older, insecure protocols like <i>Telnet</i>, <i>rsh</i>, and <i>rlogin</i>. The initial commercial version was widely adopted. In 1999, frustrated by the licensing terms of the commercial version, developers from the <i>OpenBSD project</i> created <i>OpenSSH</i>, a free and open-source implementation. <i>OpenSSH-server</i>, the daemon component of this suite, quickly became the de-facto standard for secure remote access on Unix-like operating systems due to its robust security, active development, and open-source nature. It has been continually refined, adding features like stronger encryption algorithms, improved authentication methods, and better performance, making it an essential component of modern networked systems.


title: SEE ALSO
content:
ssh(1), scp(1), sftp(1), ssh-keygen(1), ssh-copy-id(1), sshd_config(5), ssh_config(5), systemctl(1), firewalld(8), ufw(8), passwd(1)


title: PARAMETERS
content:
<b><b>-out</b> <I>filename</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output file for the generated private key. If not specified, the key is written to standard output.<br><br><b><b>-algorithm</b> <I>alg</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the algorithm for the key generation. Common algorithms include <i>RSA</i>, <i>EC</i>, <i>ED25519</i>, <i>X25519</i>, <i>DSA</i>. This option is mandatory.<br><br><b><b>-pkeyopt</b> <I>opt</I>:<I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides algorithm-specific key generation options. For example, for RSA keys, <i>rsa_keygen_bits:2048</i> sets the key length. For EC keys, <i>ec_paramgen_curve:prime256v1</i> specifies the elliptic curve.<br><br><b><b>-passout</b> <I>arg</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the source of the passphrase for encrypting the private key. Can be <i>stdin</i>, <i>pass:<passphrase></i>, <i>env:<var></i>, etc.<br><br><b><b>-aes128</b> | <b>-aes192</b> | <b>-aes256</b> | <b>-camellia128</b> | ...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Encrypts the output private key with the specified symmetric encryption algorithm. A passphrase must be provided via <i>-passout</i> or interactively.<br><br><b><b>-cipher</b> <I>alg</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A generic way to specify the symmetric encryption algorithm for the private key, similar to <i>-aes256</i> etc.<br><br><b><b>-rand</b> <I>files</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies one or more files containing random data to seed the PRNG (Pseudo-Random Number Generator).<br><br><b><b>-text</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the public and private components of the key in a human-readable text format in addition to the encoded output.<br><br><b><b>-noout</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the output of the encoded private key to the specified file or standard output. Useful when only <i>-text</i> or other side effects are desired.<br><br><b><b>-verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints extra information about the key generation process, such as algorithm parameters and progress.<br><br>


title: DESCRIPTION
content:
The <b>openssl genpkey</b> command is a versatile utility used to generate a private key for various cryptographic algorithms, such as RSA, EC (Elliptic Curve), ED25519, and X25519. It was introduced to provide a unified interface for key generation, superseding older, algorithm-specific commands like <i>genrsa</i>, <i>gendsa</i>, and <i>genec</i>. <br><br>The generated private key is typically output in PEM (Privacy-Enhanced Mail) format, which is a Base64-encoded representation of the DER (Distinguished Encoding Rules) encoded key. Users can specify the key algorithm and provide algorithm-specific parameters like key length for RSA or curve name for EC keys. For enhanced security, the private key can be encrypted with a passphrase using various symmetric encryption algorithms (e.g., AES256) when written to disk, preventing unauthorized access.


title: CAVEATS
content:
When generating keys, especially for production environments, ensure that your system has sufficient entropy (randomness) to produce cryptographically strong keys. Lack of entropy can lead to predictable keys and security vulnerabilities. <br><br>Always protect your generated private keys with strong passphrases and appropriate file system permissions (e.g., <i>chmod 600</i>) to prevent unauthorized access. <br><br>The <b>-pkeyopt</b> parameters are highly algorithm-dependent; referring to the <i>openssl man page</i> for specific algorithm requirements is crucial.


title: KEY ALGORITHM PARAMETERS
content:
The <b>-pkeyopt</b> option is critical for configuring algorithm-specific properties. For example: <br><br><ul><li>For <b>RSA</b> keys: Use <i>rsa_keygen_bits:<I>length</I></i> (e.g., <i>2048</i>, <i>4096</i>) to specify the key modulus size.</li><li>For <b>EC</b> keys: Use <i>ec_paramgen_curve:<I>name</I></i> (e.g., <i>prime256v1</i>, <i>secp384r1</i>, <i>secp521r1</i>) to specify the elliptic curve.</li><li>For <b>ED25519</b> and <b>X25519</b> keys: These algorithms typically do not require additional parameters as their properties are fixed by the algorithm definition.</li></ul>


title: PASSPHRASE HANDLING
content:
When encrypting a private key with a passphrase, <b>openssl genpkey</b> will prompt interactively if <i>-passout</i> is not used. Using <i>-passout</i> is recommended for scripting, but care must be taken not to expose passphrases in plain text in scripts or command history. For example, <i>-passout stdin</i> reads the passphrase from standard input, making it suitable for piping or secure interactive entry.


title: HISTORY
content:
The <b>openssl genpkey</b> command was introduced in OpenSSL 0.9.8. Its primary motivation was to provide a unified, generic interface for private key generation, which could support new cryptographic algorithms without requiring a new, dedicated command for each. Prior to <b>genpkey</b>, users had to rely on separate commands like <i>openssl genrsa</i> for RSA keys, <i>openssl gendsa</i> for DSA keys, and <i>openssl genec</i> for EC keys. This unification streamlined key management and made OpenSSL more flexible for future cryptographic developments.


title: SEE ALSO
content:
openssl req(1), openssl rsa(1), openssl ec(1), openssl pkcs8(1), openssl genrsa(1), openssl gendsa(1), openssl genec(1)


title: PARAMETERS
content:
<b>-help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the usage message for the specific subcommand (<I>req</I> or <I>resp</I>).<br><br><b>-in <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input file. For <I>req</I>, this is the data to be time-stamped; for <I>resp</I>, it's the timestamp request or response to be processed.<br><br><b>-out <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output file where the generated request or response will be written.<br><br><b>-text</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the content of the Time Stamp Request or Response in a human-readable text format.<br><br><b>-rand <file(s)></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies one or more files to seed the pseudo-random number generator (PRNG) for cryptographic operations.<br><br><b>-writerand <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the PRNG state to the specified file, allowing it to be reloaded later for continued randomness.<br><br><b>-engine <id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a cryptographic engine to be used for hardware acceleration or alternative cryptographic implementations.<br><br><b>-config <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file to use instead of the default OpenSSL configuration.<br><br><b>-section <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a section within the configuration file from which to read additional options and settings.<br><br><b>-no_nonce</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the generation of a nonce (a unique, random number) in the time stamp request, which is typically included to prevent replay attacks.<br><br><b>-md <alg> (for <I>req</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the message digest algorithm to be used for hashing the input data (e.g., <I>sha256</I>, <I>sha512</I>).<br><br><b>-mda <alg> (for <I>resp</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the message digest algorithm to be used for response generation or verification.<br><br><b>-policy <oid></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the OID (Object Identifier) of the Time Stamp Policy to be requested or verified within the timestamp.<br><br><b>-queryfile <file> (for <I>req</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses an existing Time Stamp Request (TSR) file as input for re-processing or modification, instead of creating a new one from data.<br><br><b>-data <file> (for <I>req</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the data file whose hash will be time-stamped. This is an alternative to using <I>-in</I> for raw data.<br><br><b>-digest <string> (for <I>req</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the hex string of the message digest directly to be time-stamped, bypassing the need to calculate it from a file.<br><br><b>-cert (for <I>req</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Requests the Time Stamping Authority to include its signing certificate in the Time Stamp Response.<br><br><b>-tsp_section <name> (for <I>req</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a section in the configuration file containing options specific to the Time Stamp Protocol request.<br><br><b>-query (for <I>resp</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs the command to treat the input as a Time Stamp Request and generate a Time Stamp Response, acting as a TSA.<br><br><b>-reply (for <I>resp</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs the command to treat the input as a Time Stamp Response and display its contents in text form.<br><br><b>-CA <file> (for <I>resp</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the CA certificate file to be used for verifying signatures within the time stamp response.<br><br><b>-CApath <dir> (for <I>resp</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a directory containing CA certificates to be used for signature verification during response processing.<br><br><b>-verify_sign (for <I>resp</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verifies the cryptographic signature of the time stamp response to ensure its authenticity and integrity.<br><br><b>-verify_cert <file> (for <I>resp</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the certificate against which the TSA's signature on the response should be verified.<br><br><b>-verify_data <file> (for <I>resp</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the original data file against which the time stamp's embedded digest should be verified.<br><br><b>-verify_digest <string> (for <I>resp</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the hex string of the original message digest for verification against the one in the timestamp.<br><br><b>-verify_policy <oid> (for <I>resp</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verifies that the time stamp response matches the specified policy OID.<br><br><b>-verify_tsa (for <I>resp</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verifies the certificate chain of the Time Stamping Authority (TSA) up to a trusted root.<br><br><b>-token_in (for <I>resp</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Indicates that the input file is a Time Stamp Token (a specific ASN.1 structure within the response).<br><br><b>-token_out (for <I>resp</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies that the output should be a Time Stamp Token.<br><br><b>-signer <file> (for <I>resp -query</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the certificate of the entity signing the time stamp response when operating as a TSA.<br><br><b>-inkey <file> (for <I>resp -query</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the private key corresponding to the signer certificate for generating the response signature.<br><br><b>-passin <arg> (for <I>resp -query</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the password for the private key used for signing the response.<br><br><b>-chain (for <I>resp -query</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes the signer's certificate chain in the time stamp response.<br><br><b>-untrusted <file> (for <I>resp -query</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a file containing untrusted certificates to be included in the response for verification purposes.<br><br><b>-tsa_policy <oid> (for <I>resp -query</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the policy OID for the TSA when generating a time stamp response.<br><br><b>-tsa_signer <file> (for <I>resp -query</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Alias for <I>-signer</I> when explicitly referring to the TSA's certificate.<br><br><b>-tsa_inkey <file> (for <I>resp -query</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Alias for <I>-inkey</I> when explicitly referring to the TSA's private key.<br><br><b>-tsa_chain (for <I>resp -query</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Alias for <I>-chain</I> when explicitly referring to the TSA's certificate chain.<br><br><b>-tsa_untrusted <file> (for <I>resp -query</I>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Alias for <I>-untrusted</I> for TSA-specific untrusted certificates.<br><br>


title: DESCRIPTION
content:
The <I>openssl ts</I> command is a powerful subcommand of the OpenSSL cryptographic toolkit, specifically designed for operations related to the Time Stamping Protocol (TSP) as defined in RFC 3161 and RFC 5816. It enables users to create Time Stamp Requests (TSRs) for various data types and to process, verify, or generate Time Stamp Responses (TSRs) from a Time Stamping Authority (TSA). This functionality is vital for providing cryptographic proof that data existed at a specific point in time, thereby ensuring non-repudiation and data integrity for legal and archival purposes. The command supports diverse cryptographic algorithms for hashing and signing, integrates with OpenSSL's configuration file for advanced settings, and can include nonces to prevent replay attacks. It serves as a fundamental tool for digital preservation, long-term document validation, and authenticating electronically signed records.


title: CAVEATS
content:
The <I>openssl ts</I> command functions as a client for creating time stamp requests and for processing/verifying responses, and it can also generate responses from requests when acting as a basic TSA. However, it does not implement the full network communication protocol for a Time Stamping Authority (TSA) server. To interact with a remote TSA, external tools (like <I>curl</I>) are typically used to send the generated request over HTTP/HTTPS and receive the response. Correct setup of trusted CA certificates and the TSA's signing certificate/private key is paramount for reliable time stamping and verification processes. Furthermore, the quality of OpenSSL's random number generator (PRNG) is crucial for the security of nonces and other cryptographic elements; ensure it is properly seeded, especially in production environments.


title: <B>WORKING WITH A TIME STAMPING AUTHORITY (TSA)</B>
content:
While <I>openssl ts</I> is adept at generating Time Stamp Requests (TSRs) and parsing Time Stamp Responses (TSRs), it does not act as a full network-enabled TSA server. To obtain a cryptographically valid timestamp, the TSR generated using <I>openssl ts req</I> must typically be sent to a trusted remote TSA server (often via HTTP POST to a designated URL). The signed response received back from the TSA is then processed and verified using <I>openssl ts resp</I>.


title: <B>CONFIGURATION FILE USAGE</B>
content:
Many advanced options, particularly when <I>openssl ts resp</I> is used in <I>-query</I> mode (i.e., acting as a TSA to generate responses), can be configured within the OpenSSL configuration file. This allows for setting default time stamp policies, specifying certificate paths for signers and CAs, and defining other operational parameters, which simplifies command-line invocation for recurring or complex time-stamping tasks.


title: HISTORY
content:
The Time Stamping Protocol (TSP) functionality has been an integral part of the OpenSSL project for many years, evolving in parallel with the TSP standard itself. TSP is formally defined in RFC 3161 (Time-Stamp Protocol), which succeeded earlier specifications, and was further updated by RFC 5816 to incorporate policy and security requirements. The <I>openssl ts</I> command provides a robust command-line interface for interacting with these PKI standards, enabling developers and administrators to seamlessly integrate time-stamping into their digital workflows and applications. Its development has consistently focused on delivering strong cryptographic operations for time-stamping, adhering to Public Key Infrastructure (PKI) best practices, and ensuring broad interoperability with various Time Stamping Authorities (TSAs) worldwide.


title: SEE ALSO
content:
<I>openssl</I>(1), <I>openssl-req</I>(1), <I>openssl-x509</I>(1), <I>openssl-verify</I>(1), <I>openssl-s_server</I>(1), <I>curl</I>(1)


title: PARAMETERS
content:
<b><b>-in</b> <I>filename</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input certificate file. If not provided, input is read from standard input.<br><br><b><b>-out</b> <I>filename</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output certificate file. If not provided, output is written to standard output.<br><br><b><b>-inform</b> <I>DER</I>|<I>PEM</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input format. <b>DER</b> for binary Distinguished Encoding Rules, <b>PEM</b> for base64 encoded with headers/footers. Defaults to <b>PEM</b>.<br><br><b><b>-outform</b> <I>DER</I>|<I>PEM</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format. <b>DER</b> for binary, <b>PEM</b> for base64 encoded. Defaults to <b>PEM</b>.<br><br><b><b>-text</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the certificate in human-readable text format, including all details.<br><br><b><b>-noout</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents printing of the encoded version of the certificate to the output. Useful when only extracting specific information.<br><br><b><b>-subject</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the subject (owner) Distinguished Name (DN) of the certificate.<br><br><b><b>-issuer</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the issuer (signer) Distinguished Name (DN) of the certificate.<br><br><b><b>-dates</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the certificate's validity period (notBefore and notAfter dates).<br><br><b><b>-startdate</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the 'notBefore' validity date of the certificate.<br><br><b><b>-enddate</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the 'notAfter' validity date of the certificate.<br><br><b><b>-serial</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the certificate's serial number.<br><br><b><b>-hash</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the subject hash (used for symlinking certificates in hash directories).<br><br><b><b>-fingerprint</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the SHA1 fingerprint of the certificate.<br><br><b><b>-pubkey</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extracts and prints the public key from the certificate.<br><br><b><b>-modulus</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the modulus of the public key.<br><br><b><b>-req</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Indicates that the input is a Certificate Signing Request (CSR) instead of a certificate, typically used with signing options.<br><br><b><b>-signkey</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Self-signs the certificate or CSR using the private key in <I>file</I>. Creates a self-signed certificate.<br><br><b><b>-CA</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Signs a certificate request (CSR) with the CA certificate in <I>file</I>.<br><br><b><b>-CAkey</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the private key of the CA certificate (used with <b>-CA</b>).<br><br><b><b>-CAserial</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the file to use for CA serial numbers (used with <b>-CA</b>). If it does not exist, it will be created.<br><br><b><b>-days</b> <I>n</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of days for which a newly generated or signed certificate will be valid. Default is 30 days.<br><br><b><b>-set_serial</b> <I>n</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the serial number of the certificate being signed to <I>n</I>. If not specified, a random serial number is generated (with <b>-CA</b>) or incremented (with <b>-CAserial</b>).<br><br><b><b>-x509toreq</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Converts a certificate into a certificate request (CSR).<br><br><b><b>-extfile</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an OpenSSL configuration file containing certificate extensions to be added during signing.<br><br><b><b>-extensions</b> <I>section</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the section in the <b>-extfile</b> to read extensions from. Defaults to 'v3_ca' or 'v3_req' if not specified.<br><br><b><b>-clrext</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clears any extensions from the certificate, typically when converting or self-signing.<br><br><b><b>-trustout</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs a trusted certificate. This adds trust flags to the certificate.<br><br><b><b>-checkend</b> <I>seconds</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks if the certificate expires within the next <I>seconds</I>. Returns non-zero exit code if it does or is already expired.<br><br>


title: DESCRIPTION
content:
The `openssl-x509` command is a powerful utility within the OpenSSL toolkit designed specifically for handling X.509 certificates. X.509 is a standard defining the format of public key certificates, which are fundamental to Public Key Infrastructure (PKI) used in secure communications like TLS/SSL, VPNs, and code signing. <br><br>This command allows users to perform a wide range of operations on certificates, including: displaying certificate contents in human-readable format, converting between different encoding formats (PEM and DER), extracting specific information (like subject, issuer, serial number, validity dates, public key), creating self-signed certificates, signing certificate requests (CSRs) with a Certificate Authority (CA), and performing basic certificate verification. It is an essential tool for system administrators, developers, and security professionals working with digital certificates and secure communication protocols.


title: CAVEATS
content:
Handling private keys and CA operations requires extreme care due to significant security implications. Mismanagement can lead to compromised systems or untrusted certificates. Always secure private keys and ensure proper permissions.<br><br>The behavior and available options of `openssl-x509` can vary slightly between different OpenSSL library versions. Consult the specific version's man page for precise details.


title: COMMON USE CASES
content:
<ul><li>Inspecting a website's certificate: `openssl s_client -connect example.com:443 -showcerts < /dev/null | openssl x509 -text -noout`</li><li>Converting certificate formats: `openssl x509 -in cert.der -inform DER -out cert.pem -outform PEM`</li><li>Generating a self-signed certificate for testing: `openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365` (Note: `openssl req` is often used for this combined process)</li><li>Extracting a public key: `openssl x509 -in cert.pem -pubkey -noout > publickey.pem`</li></ul>


title: CERTIFICATE TRUST FLAGS
content:
OpenSSL certificates can have associated 'trust' or 'reject' flags, indicating whether they should be trusted for specific purposes (e.g., SSL client, SSL server). The `openssl x509` command allows viewing (`-purpose`, `-trustout`) and manipulating (`-addtrust`, `-addreject`) these flags, which are crucial for defining trust policies in applications that use OpenSSL's certificate validation functions.


title: HISTORY
content:
The `openssl-x509` command is an integral part of the OpenSSL project, which began in 1998 as a successor to the SSLeay library. It has evolved significantly over the years, mirroring the advancements and evolving security requirements of the X.509 standard and Public Key Infrastructure. Its development has consistently focused on providing a comprehensive and flexible toolset for managing digital certificates, which are critical components of secure communication protocols like TLS/SSL. Its continuous maintenance and updates ensure compatibility with new cryptographic algorithms and adherence to industry best practices.


title: SEE ALSO
content:
openssl(1ssl), openssl-req(1ssl), openssl-genrsa(1ssl), openssl-gendsa(1ssl), openssl-ecparam(1ssl), openssl-rsa(1ssl), openssl-pkcs12(1ssl), openssl-crl(1ssl), openssl-verify(1ssl)


title: SYNOPSIS
content:
<b>openssl</b> [<i>global_options</i>] <i>command</i> [<i>command_options</i>]<br><b>openssl</b> <i>list-standard-commands</i><br><b>openssl</b> <i>list-cipher-commands</i><br><b>openssl</b> <i>list-message-digest-commands</i><br><b>openssl</b> <i>list-public-key-commands</i><br><b>openssl</b> <i>list-options</i>


title: PARAMETERS
content:
<b><i>global_options</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Options that apply to the <b>openssl</b> command itself, before a specific subcommand is given. Examples include <b>-help</b> (displays general usage), <b>-config &lt;file&gt;</b> (specifies a configuration file), <b>-rand &lt;file&gt;</b> (seeds the PRNG), and <b>-engine &lt;id&gt;</b> (loads a cryptographic engine). For OpenSSL 3.0+, also includes <b>-provider &lt;name&gt;</b> and <b>-propquery &lt;query&gt;</b> for provider management.<br><br><b><i>command</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The specific subcommand to execute. <b>openssl</b> acts as a dispatcher for these commands. Each subcommand has its own specific set of options and arguments. Examples include: <b>req</b>, <b>x509</b>, <b>enc</b>, <b>dgst</b>, <b>genrsa</b>, <b>s_client</b>, and <b>version</b>.<br><br><b><i>command_options</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Options specific to the chosen <i>command</i>. These options vary widely depending on the subcommand. For instance, the <b>req</b> command uses options like <b>-new</b>, <b>-newkey</b>, <b>-keyout</b>, and <b>-out</b>, while the <b>enc</b> command uses options like <b>-aes256</b>, <b>-in</b>, and <b>-out</b>.<br><br><b><b>req</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates and processes Certificate Signing Requests (CSRs).<br><br><b><b>x509</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays, signs, and manages X.509 certificates.<br><br><b><b>enc</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Encrypts and decrypts data using various symmetric ciphers.<br><br><b><b>dgst</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Computes message digests (hashes) of files.<br><br><b><b>genrsa</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates RSA private keys.<br><br><b><b>s_client</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Implements a generic SSL/TLS client for testing purposes.<br><br><b><b>version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the OpenSSL version and build information.<br><br>


title: DESCRIPTION
content:
The <b>openssl</b> command is a powerful and versatile command-line utility that provides access to the cryptographic functions of the OpenSSL library. It serves as a dispatcher for numerous sub-commands, each designed for specific cryptographic tasks.<br><br>It can be used for a wide array of operations including the generation and management of cryptographic keys (RSA, DSA, EC), creation and manipulation of X.509 certificates, Certificate Signing Requests (CSRs), and Certificate Revocation Lists (CRLs). Users can encrypt and decrypt data with various ciphers, compute message digests (hashes), handle PKCS#12 (PFX) files, and perform SSL/TLS client and server testing.<br><br>Essentially, <b>openssl</b> acts as a central hub for cryptographic operations, making it an indispensable tool for system administrators, developers, and security professionals working with secure communication protocols and digital certificates.


title: CAVEATS
content:
Using <b>openssl</b> for sensitive operations directly on the command line (e.g., providing passphrases as arguments) is insecure, as these might be visible in process lists. Always use prompts or secure methods like configuration files for sensitive data.<br><br>The command is powerful but requires a solid understanding of cryptographic concepts. Misuse or incorrect configuration can lead to insecure deployments.


title: COMMAND CATEGORIES
content:
The <b>openssl</b> command organizes its numerous subcommands into categories such as standard commands (e.g., <b>version</b>, <b>help</b>), cipher commands (e.g., <b>enc</b>), message digest commands (e.g., <b>dgst</b>), public key commands (e.g., <b>genrsa</b>), and utility commands (e.g., <b>s_client</b>). You can list these categories using commands like <b>openssl list-standard-commands</b> or <b>openssl list-cipher-commands</b>.


title: CONFIGURATION FILES
content:
OpenSSL commands often leverage configuration files (e.g., <b>openssl.cnf</b>) to define default values, extensions for certificates, and other parameters. The path to a custom configuration file can be specified using the <b>-config</b> global option.


title: HISTORY
content:
The OpenSSL project and its command-line tool <b>openssl</b> trace their origins back to SSLeay, an SSL/TLS library developed by Eric Young and Tim Hudson. OpenSSL was founded in 1998, building upon SSLeay. The <b>openssl</b> command has continuously evolved, expanding its functionality to support new cryptographic algorithms, standards, and features. A significant architectural change occurred with OpenSSL 3.0, which introduced the 'provider' concept, modularizing cryptographic implementations and affecting how certain functions are invoked or configured.


title: SEE ALSO
content:
<b>ssl(8)</b>, <b>config(5)</b>, <b>x509(1)</b>, <b>req(1)</b>, <b>pkcs12(1)</b>, <b>s_client(1)</b>, <b>s_server(1)</b>, <b>openssl-req(1)</b>, <b>openssl-x509(1)</b>, <b>openssl-dgst(1)</b>, <b>openssl-enc(1)</b>


title: SYNOPSIS
content:
<I>openstack help</I> <br><I>openstack help</I> <B>[command]</B> <br><I>openstack</I> <B>[command]</B> <I>--help</I>


title: PARAMETERS
content:
<b><I>command</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the particular OpenStack CLI command for which help is requested. This can be a service name (e.g., <I>server</I>) or a full command path (e.g., <I>server create</I>).<br><br><b><I>--help</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A standard option available for any <I>openstack</I> command. When appended, it displays a detailed usage message, including options and arguments specific to that command, and then exits.<br><br>


title: DESCRIPTION
content:
The term <I>openstack-help</I> typically refers to the mechanism for accessing documentation and usage information within the official OpenStack Command Line Interface (CLI). While <I>openstack-help</I> is not a standalone binary or command in most standard OpenStackClient installations, it conceptualizes the essential functionality provided by the <I>openstack help</I> subcommand or the <I>--help</I> option. <br><br>The <I>openstack help</I> subcommand provides a top-level list of available services and commands, or detailed assistance for a specific subcommand. For instance, <I>openstack help server</I> will display information about the <I>server</I> commands. Additionally, the <I>--help</I> option can be appended to any <I>openstack</I> command to show its specific usage, options, and arguments. For example, <I>openstack server create --help</I> reveals all parameters for creating a new server instance. This system is crucial for users to discover capabilities and understand command syntax without needing to consult external documentation.


title: CAVEATS
content:
`openstack-help` is not a standard executable binary delivered with the OpenStackClient. It generally refers to the help functionality provided by the <I>openstack</I> client itself, predominantly through the <I>openstack help</I> subcommand and the <I>--help</I> flag. Some distributions or custom environments might include a shell script named `openstack-help` as a wrapper or alias, but its underlying function relies on the core <I>openstack</I> client's help system.


title: GLOBAL OPTIONS
content:
While not directly parameters of the help function, <I>openstack</I> commands, including <I>openstack help</I>, can be prefixed with various global options that affect how the client connects and interacts with OpenStack. Common global options include <I>--os-cloud</I>, <I>--debug</I>, <I>--verbose</I>, <I>--json</I>, etc. These options typically precede the command and its arguments.


title: CONTEXTUAL HELP VS. GENERAL HELP
content:
It's important to distinguish between <I>openstack help [command]</I> and <I>openstack [command] --help</I>. The former provides a general overview or lists subcommands for a given command/service. The latter, <I>--help</I>, offers very specific, detailed information about the direct usage, arguments, and options for the command it's appended to. For example, <I>openstack help server create</I> might show less detail than <I>openstack server create --help</I>.


title: HISTORY
content:
The integrated help system has been a fundamental part of the OpenStack Command Line Interface (CLI) since its inception. Early versions of the CLI (often separate clients like `nova client`, `glance client`, etc., before the unified <I>openstack</I> client) also provided <I>--help</I> options. With the advent of the unified <I>openstack</I> client, the <I>help</I> subcommand was introduced to consolidate and standardize access to documentation across all services, making it a central and easily discoverable feature for users interacting with OpenStack from the command line. Its continuous development focuses on providing up-to-date and comprehensive usage information as the OpenStack services evolve.


title: SYNOPSIS
content:
<b>openstack image</b> <I>subcommand</I> [<i>options</i>] [<i>arguments</i>]<br><br>Common subcommands:<br><i>&nbsp;&nbsp;list</i>: Lists all available images.<br><i>&nbsp;&nbsp;show</i> <I>&lt;image&gt;</I>: Displays detailed information about a specific image.<br><i>&nbsp;&nbsp;create</i> <I>&lt;name&gt;</I> [<i>--file &lt;file&gt;</i>] [<i>--disk-format &lt;format&gt;</i>]: Creates a new image.<br><i>&nbsp;&nbsp;delete</i> <I>&lt;image&gt;</I>: Deletes one or more images.<br><i>&nbsp;&nbsp;set</i> <I>&lt;image&gt;</I> [<i>--property &lt;key=value&gt;</i>]: Modifies properties of an existing image.<br><i>&nbsp;&nbsp;save</i> <I>&lt;image&gt;</I> [<i>--file &lt;file&gt;</i>]: Saves an image to a local file.


title: PARAMETERS
content:
<b>--file <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the local file path for image data to be uploaded or saved.<br><br><b>--disk-format <format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the disk image format (e.g., qcow2, raw, iso, vhd, vmdk) for image creation.<br><br><b>--container-format <format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the container format (e.g., bare, ovf) for image creation.<br><br><b>--public</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Makes the image publicly accessible to all tenants.<br><br><b>--private</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Makes the image private, accessible only to the owner tenant (default).<br><br><b>--protected</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Protects the image from accidental deletion.<br><br><b>--min-disk <GB></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the minimum disk size in GB required to boot the image.<br><br><b>--min-ram <MB></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the minimum RAM in MB required to boot the image.<br><br><b>--property <key=value></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds or updates custom metadata properties for the image. Can be used multiple times.<br><br><b>--tag <tag></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a tag to the image for easier categorization and filtering. Can be used multiple times.<br><br><b>--limit <num></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restricts the number of images returned in a list operation.<br><br><b>--status <status></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters images by their current status (e.g., active, queued, killed) during list operations.<br><br><b>--long</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays additional information for list operations (e.g., properties).<br><br>


title: DESCRIPTION
content:
The <b>openstack image</b> command is a crucial component of the <I>OpenStack command-line client</I> (CLI), designed for interacting with the <I>OpenStack Glance Image Service</I>. It allows users to perform comprehensive management operations on virtual machine images, including creating, listing, showing details, updating, deleting, and sharing images. Images are fundamental to OpenStack, serving as templates for launching virtual machines. This command facilitates the entire lifecycle of images within an OpenStack cloud, enabling administrators and users to prepare, store, and distribute operating system and application environments for cloud instances.


title: CAVEATS
content:
The <b>openstack image</b> command requires the <I>OpenStack CLI client</I> to be installed and properly configured with access to an OpenStack cloud. Authentication details (like OS_AUTH_URL, OS_USERNAME, etc.) must be set up via environment variables or a clouds.yaml file.<br><br>The behavior and available options might vary slightly depending on the specific version of OpenStack Glance and the OpenStack CLI client being used. It's crucial to refer to the official OpenStack documentation for the exact version you are working with.


title: IMAGE LIFECYCLE
content:
Images typically go through several states: <I>queued</I> (uploading), <I>saving</I> (processing), <I>active</I> (ready for use), <I>deactivated</I> (temporarily unavailable), and <I>killed</I> (failed during creation/upload). Understanding these states is vital for troubleshooting image issues and monitoring image availability.


title: IMAGE FORMATS
content:
OpenStack supports various disk image formats, with <I>QCOW2</I> being the most common due to its features like snapshotting and smaller file sizes. Other formats include <I>RAW</I> (raw disk image), <I>ISO</I> (CD/DVD images), <I>VHD</I> (Hyper-V), and <I>VMDK</I> (VMware). Choosing the correct format is important for compatibility and performance with different hypervisors.


title: HISTORY
content:
The <I>OpenStack</I> project, including its <I>Glance Image Service</I>, was initiated in 2010. As OpenStack matured, the original service-specific clients (like `glanceclient`) were consolidated into a single, unified <I>OpenStack CLI client</I> to provide a more consistent and user-friendly experience across all OpenStack services. The <b>openstack image</b> command emerged as part of this consolidation, replacing older, separate commands for image management. This evolution aimed to simplify cloud administration and operations by offering a unified interface for interacting with the entire OpenStack ecosystem.


title: SYNOPSIS
content:
<b>openstack [global-options] volume &lt;subcommand&gt; [subcommand-options] [arguments]</b><br><br><b>Common Subcommands:</b><br>&nbsp;&nbsp;<b>create</b> &lt;size&gt; &lt;name&gt; [options]<br>&nbsp;&nbsp;<b>list</b> [options]<br>&nbsp;&nbsp;<b>show</b> &lt;volume-id-or-name&gt;<br>&nbsp;&nbsp;<b>delete</b> &lt;volume-id-or-name&gt; [<volume-id-or-name>...]


title: PARAMETERS
content:
<b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debug output for the OpenStack client.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing more details for the command execution.<br><br><b>--os-cloud &lt;cloud-name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the specified cloud configuration from clouds.yaml.<br><br><b>--os-region-name &lt;region-name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the OpenStack region to operate in.<br><br><b>--os-project-id &lt;id&gt; | --os-project-name &lt;name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Authenticate to a specific project by ID or name.<br><br><b>--os-user-id &lt;id&gt; | --os-user-name &lt;name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Authenticate with a specific user by ID or name.<br><br><b>--format &lt;format&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify output format (e.g., 'json', 'yaml', 'table', 'value').<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help message and exit. Can be used with subcommands (e.g., 'openstack volume create --help').<br><br>


title: DESCRIPTION
content:
The command <i>openstack volume</i> is part of the unified OpenStack command-line client, used for managing block storage volumes (provided by the Cinder service) within an OpenStack cloud. While the request specifically mentions 'openstack-volume', this is typically a legacy wrapper or a misconception. The standard and widely used command for interacting with OpenStack's Cinder service is <b><i>openstack volume</i></b> followed by a specific subcommand.<br><br>This utility allows cloud administrators and users to perform a wide array of operations on block storage, including creating, deleting, listing, showing details, attaching, and detaching volumes from compute instances. It also supports operations like creating volume snapshots, managing volume types, and extending existing volumes. It provides a programmatic interface to Cinder's REST API, enabling scripting and automation of storage resource management.


title: CAVEATS
content:
The command 'openstack-volume' is typically a legacy reference. Modern OpenStack client installations use <b>'openstack volume'</b> as a subcommand within the unified <i>openstack</i> CLI tool.<br><br>Requires the OpenStack client to be installed and properly configured with authentication credentials (e.g., via environment variables or a clouds.yaml file).<br><br>Operations on volumes can be asynchronous; commands may return before the volume fully reaches its desired state (e.g., 'creating', 'available'). Check volume status with <i>openstack volume show</i>.


title: COMMON VOLUME OPERATIONS
content:
Beyond basic creation and deletion, <i>openstack volume</i> supports advanced operations:<br>&nbsp;&nbsp;<b>Attachment/Detachment:</b> Linking volumes to/from compute instances.<br>&nbsp;&nbsp;<b>Snapshotting:</b> Creating point-in-time backups of volumes.<br>&nbsp;&nbsp;<b>Cloning:</b> Creating new volumes from existing ones or snapshots.<br>&nbsp;&nbsp;<b>Extending:</b> Increasing the size of an existing volume.<br>&nbsp;&nbsp;<b>Type Management:</b> Associating volumes with specific performance or storage backend characteristics.


title: CINDER SERVICE
content:
Cinder is OpenStack's block storage service, providing persistent block storage devices to guest virtual machines. It abstracts various backend storage technologies (like LVM, Ceph, NetApp, EMC) and presents them as a unified API. The <i>openstack volume</i> command interacts directly with the Cinder API to manage these storage resources.


title: HISTORY
content:
Prior to the unified OpenStack client, volume management was primarily handled by the dedicated <i>cinderclient</i> and its <i>cinder</i> command. As OpenStack matured, the community moved towards a single, comprehensive command-line interface, leading to the development of the <i>python-openstackclient</i> and the <b><i>openstack</i></b> command. The <b><i>openstack volume</i></b> subcommand absorbed the functionality previously provided by the <i>cinder</i> CLI, providing a more consistent user experience across OpenStack services. This transition aimed to simplify client installations and usage by consolidating various service-specific clients into one.


title: PARAMETERS
content:
<b>-D, --datadir <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the data directory, where graphics, sound, and other resources are located.<br><br><b>-C, --config <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses an alternative configuration file instead of the default 'openttd.cfg'.<br><br><b>-M, --music <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the music directory for in-game music.<br><br><b>-L, --language <lang></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the game's display language (e.g., 'en', 'de', 'fr').<br><br><b>-p, --port <port></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the UDP port for multiplayer games, overriding the default.<br><br><b>-s, --server</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the game as a dedicated server without a graphical interface, ideal for hosting multiplayer games.<br><br><b>-S, --spectator</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the game in spectator mode, allowing observation of a multiplayer game without participating.<br><br><b>-g, --load <savegame></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads a specific savegame file upon launching the game.<br><br><b>-n, --newgame</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts a new game immediately upon launch, skipping the main menu.<br><br><b>-x, --exit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exits the game immediately after loading a savegame or starting a new game (useful for testing or benchmarking).<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the game's version information and exits.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a summary of command-line options and exits.<br><br><b>--debug <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the debug level (0-4) for various debug output.<br><br><b>--save <savegame></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves the current game to the specified file. Typically used with '--exit'.<br><br><b>--network</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts a network game. Implies '--host' if no '--connect' is specified.<br><br><b>--connect <IP></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to a specific IP address for a multiplayer game.<br><br><b>--fullscreen</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the game in fullscreen display mode.<br><br><b>--resolution <WxH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the game window resolution (e.g., '1024x768').<br><br><b>--gl-driver <driver></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects a specific OpenGL driver (e.g., 'mesa', 'swrast').<br><br><b>--renderer <type></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the rendering backend (e.g., 'software', 'opengl').<br><br><b>--skip-grf-checks</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips integrity checks for GRF files, potentially speeding up loading.<br><br><b>--game-type <type></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the game type for a new game (e.g., 'citybuilder', 'classic').<br><br><b>--host <IP></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hosts a multiplayer game, listening on the specified IP address.<br><br><b>--no-crash-report</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables sending crash reports if the game crashes.<br><br><b>--cmd <cmd></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a console command after loading the game.<br><br><b>--profile-render</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables rendering profiling for performance analysis.<br><br><b>--reset-config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resets all game settings to their default values.<br><br><b>--set-setting <name>=<value></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a specific game setting, overriding values from the configuration file.<br><br><b>--disable-patches</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables all game patches, reverting to original game behavior.<br><br><b>--set-patch <name>=<value></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a specific game patch value (e.g., 'trains=true').<br><br><b>--userdir <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the user directory for saves, screenshots, and custom content.<br><br><b>--server-password <pass></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the server password when hosting a multiplayer game.<br><br>


title: DESCRIPTION
content:
OpenTTD is an open-source business simulation game where players earn money by transporting passengers and cargo by road, rail, water, and air. It is a recreation and expansion of the 1995 video game <b>Transport Tycoon Deluxe</b> by Chris Sawyer.<br><br>OpenTTD adds numerous new features, including larger maps, multiplayer mode for up to 255 players, customisation options via NewGRF (New Graphics Resources Files), and enhanced pathfinding algorithms. The game focuses on building and managing an efficient transport network across diverse landscapes and industries, aiming to become the ultimate transport mogul.


title: CAVEATS
content:
OpenTTD requires external base graphics, sound, and music files to run optimally. While the game can download these from content servers, users may need to manually provide them if offline or restricted. Performance can degrade significantly on very large maps with a high number of vehicles and industries. Multiplayer stability is dependent on network conditions and server specifications.


title: NEWGRF SYSTEM
content:
OpenTTD extensively uses <I>NewGRF</I> files, which are custom graphics, sound, and data packages. These files allow players to add new vehicles, industries, buildings, terrain features, and modify gameplay mechanics, significantly extending the game's longevity and customizability.<br><br>Many NewGRFs are available for download through the game's built-in content downloader.


title: MULTIPLAYER
content:
The game features robust multiplayer support for up to 255 players. Players can join public servers, host their own, or play over a local network. Multiplayer modes support both cooperative play, where players work together on a single company, and competitive play with multiple companies vying for economic dominance.


title: CROSS-PLATFORM COMPATIBILITY
content:
OpenTTD is renowned for its wide cross-platform compatibility. It is available on a vast range of operating systems, including Linux, Windows, macOS, Android, and various BSD variants. This ensures broad accessibility and a large player base across different computing environments.


title: HISTORY
content:
OpenTTD began in 2004 as an effort by Ludvig Stigsson to reverse-engineer and extend the functionality of Chris Sawyer's <b>Transport Tycoon Deluxe</b>. Initially written in C, it aimed to add features like larger maps and multiplayer. Over the years, a large community of developers and players contributed, leading to significant enhancements in graphics, sound, AI, and modding capabilities via NewGRF. Its development has been continuous, making it one of the most successful open-source game remakes, boasting cross-platform compatibility and extensive customisation.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a general help message and exit. When used with a subcommand, it displays help for that specific subcommand.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output version information for the <b>openvpn3</b> client.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase output verbosity. Can be specified multiple times for more detailed output.<br><br><b><b>-d</b>, <b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debug output, providing extensive details useful for troubleshooting.<br><br><b><b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Format output in JSON, which is useful for scripting and programmatic parsing.<br><br><b><b>--service-path</b> <i><path></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the D-Bus service path for communication with the <i>openvpn3-service-netcfg</i> daemon, if it deviates from the default.<br><br>


title: DESCRIPTION
content:
<b>openvpn3</b> is a modern command-line client for managing OpenVPN connections on Linux. Unlike the traditional <i>openvpn</i> client, <b>openvpn3</b> is designed with a modular architecture that heavily leverages D-Bus for communication with a background service, <i>openvpn3-service-netcfg</i>. This design allows for better integration with modern Linux desktop environments and network managers, improved security through privilege separation, and a more structured approach to configuration and session management.<br><br>Users can import <i>.ovpn</i> configuration files, list and manage stored configurations, establish and terminate VPN sessions, and monitor connection status and logs. It supports various authentication methods and facilitates a streamlined workflow for OpenVPN connectivity.


title: CAVEATS
content:
<b>openvpn3</b> relies on the <i>openvpn3-service-netcfg</i> D-Bus service to be running and accessible. Without this service, the client cannot establish or manage VPN connections. It is not a direct drop-in replacement for the traditional <i>openvpn</i> client due to its different architectural approach and D-Bus dependency.


title: ARCHITECTURE OVERVIEW
content:
The <b>openvpn3</b> command-line tool primarily acts as a client to the <i>openvpn3-service-netcfg</i> D-Bus daemon. All actual network configuration and tunnel management are handled by this background service, allowing <b>openvpn3</b> to operate with minimal privileges. This separation enhances security and facilitates integration with other system components like NetworkManager.


title: SUBCOMMANDS
content:
Most functionality of <b>openvpn3</b> is exposed through its subcommands. Key subcommands include:<br><b>config</b>: For importing, listing, and managing OpenVPN configurations.<br><b>session</b>: For starting, stopping, listing, and managing active VPN sessions.<br><b>connection</b>: For interacting with underlying network connections managed by sessions.<br><b>show</b>: For displaying various pieces of information, such as capabilities, D-Bus paths, or configuration details.<br><b>show-log</b>: For viewing logs from active VPN sessions.


title: HISTORY
content:
<b>openvpn3</b> was developed by OpenVPN Inc. as a modern, modular, and D-Bus-integrated client for Linux. It emerged to provide a more streamlined and secure way to manage OpenVPN connections, addressing challenges related to desktop environment integration and privilege management that were present with the older <i>openvpn</i> client. Its development marks a significant architectural evolution for OpenVPN clients on Linux, moving towards a service-oriented model.


title: SEE ALSO
content:
openvpn(8), nmcli(1), ip(8), dbus-send(1), openvpn3-session(1), openvpn3-config(1), openvpn3-connection(1), openvpn3-service-netcfg(8)


title: SYNOPSIS
content:
<b>openvt</b> [<i>options</i>] [<i>command</i> [<i>arguments...</i>]]<br><b>openvt</b> {<i>-h</i>|<i>--help</i>|<i>-V</i>|<i>--version</i>}


title: PARAMETERS
content:
<b><i>-c &lt;console&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the virtual terminal (VT) number to use. By default, <b>openvt</b> finds the first available unused VT.<br><br><b><i>-f</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not fork. The parent process will wait for the command to complete. If this option is used, <i>-s</i> is ignored.<br><br><b><i>-l</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Makes the executed command a login shell by prepending a '-' to its name.<br><br><b><i>-s</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Switches to the newly opened VT when the command starts. The caller's VT is restored after the command terminates. Ignored if <i>-f</i> is set.<br><br><b><i>-u</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Finds a VT owned by the current user. This option can only be used by a regular user (not root) and prioritizes VTs owned by the calling user.<br><br><b><i>-v</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more information about <b>openvt</b>'s operations.<br><br><b><i>--</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Marks the end of options. All subsequent arguments are interpreted as the command and its arguments.<br><br><b><i>command [arguments...]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The command to execute on the new virtual terminal. If omitted, <i>/bin/login</i> is run by default.<br><br><b><i>-h, --help</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information and exits.<br><br><b><i>-V, --version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br>


title: DESCRIPTION
content:
<b>openvt</b> is a utility that finds an unused virtual console (VT) and executes a specified command on it. If no command is provided, it defaults to running <i>/bin/login</i>. This command is particularly useful for tasks requiring a separate, isolated terminal session, such as launching graphical environments, system recovery, or running daemons in the background without affecting the current console.<br>When <b>openvt</b> launches the command, it detaches itself from the controlling terminal and forks the process into a new session, directing all standard input/output to the new VT. Users can choose to immediately switch to the new VT using the <i>-s</i> option, or prevent forking with the <i>-f</i> option. It also allows non-root users to find VTs they own, promoting secure multi-user environments on consoles. <b>openvt</b> is a key component of the <i>util-linux</i> package, providing essential console management capabilities on Linux systems.


title: CAVEATS
content:
Requires appropriate permissions, typically root, to open and manage virtual terminals unless the <i>-u</i> option is used for a user-owned VT. The command depends on the Linux kernel's virtual terminal subsystem. If the current terminal is not in console mode (e.g., an X terminal), <b>openvt</b> will exit with an error. The new VT is not activated by default; use <i>-s</i> to switch to it immediately.


title: DEFAULT COMMAND
content:
If no <i>command</i> is specified, <b>openvt</b> defaults to executing <i>/bin/login</i> on the new virtual terminal.


title: VT SELECTION
content:
By default, <b>openvt</b> finds the first available unused virtual terminal. The <i>-c</i> option allows specifying a particular unused VT, while <i>-u</i> can be used by non-root users to find VTs they own.


title: HISTORY
content:
The <b>openvt</b> command is part of the <i>util-linux</i> project, a collection of essential utilities for the Linux operating system. Its functionality for managing virtual terminals has been a core component of Linux console management from its early days, providing a robust way to isolate and run processes on dedicated console sessions.


title: PARAMETERS
content:
<b><I>URL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a URL to open upon launch. If omitted, Opera starts with its default homepage or last session.<br><br><b>--new-window</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the specified <I>URL</I> or the default page in a new browser window.<br><br><b>--new-tab</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the specified <I>URL</I> in a new tab within an existing Opera window, or in a new window if none are open.<br><br><b>--incognito<br>--private</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches Opera in a private browsing window (similar to Incognito mode in Chrome). All browsing data for that session will be cleared upon closing.<br><br><b>--profile-directory=<I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the profile directory to use. For example, 'Default' or 'Profile 1'. This is useful for managing multiple user profiles.<br><br><b>--user-data-dir=<I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the base directory for user data, which includes profiles, cache, and other browser data. Useful for portable installations or specific testing environments.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the current version of the Opera browser to the console.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a list of available command-line options and their descriptions.<br><br><b>--remote-debugging-port=<I>port</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables remote debugging via the specified port. This is primarily used by web developers for inspecting web content or browser internals.<br><br><b>--disable-gpu</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables GPU hardware acceleration. Useful for troubleshooting rendering issues or on systems with problematic graphics drivers.<br><br>


title: DESCRIPTION
content:
The <b>opera</b> command provides a command-line interface for launching and interacting with the Opera web browser. While most users typically launch Opera via its graphical icon, the command line offers advanced control for specific use cases, such as opening particular URLs, managing browser profiles, or enabling debugging features. It is especially useful for scripting, automation, or troubleshooting browser behavior.<br><br>The command allows users to specify an initial URL to open, choose whether to open it in a new window or tab, or even in a private browsing session. Given that Opera is built on the Chromium engine, many of its command-line arguments are inherited from Chromium, providing a rich set of options for fine-tuning browser behavior, although not all Chromium options are directly applicable or documented for Opera.


title: CAVEATS
content:
Many of Opera's command-line options are inherited from its underlying Chromium engine. Consequently, the specific options available and their behavior can vary slightly between Opera versions, as well as between different Chromium releases. Some advanced Chromium flags might not be officially supported or may have unexpected effects in Opera. It's always advisable to consult the specific Opera documentation or use <b>--help</b> for the installed version.


title: CHROMIUM-BASED OPTIONS
content:
Due to Opera's reliance on the Chromium engine, a vast number of command-line flags available for Chromium and Google Chrome can also be used with <b>opera</b>. These include options for proxy settings, security features, experimental flags, and more. Users interested in deeper control might explore Chromium documentation for additional potential flags, but should do so with caution.


title: PROFILE MANAGEMENT
content:
The <b>--profile-directory</b> and <b>--user-data-dir</b> options are critical for advanced users and developers. They allow launching Opera with a specific user profile or storing all browser data in a custom location, which is invaluable for testing, maintaining separate environments (e.g., work vs. personal), or creating portable installations of the browser.


title: HISTORY
content:
Opera has a long history, dating back to 1995. Originally developed by Opera Software ASA, it used its own proprietary rendering engine, Presto, until 2013. In 2013, Opera transitioned to the Chromium engine, which is maintained by Google. This shift significantly changed the browser's architecture, including its command-line interface. Consequently, many of the command-line options available for <b>opera</b> today are largely identical to those found in Chromium-based browsers like Google Chrome, reflecting the shared codebase and functionalities.


title: PARAMETERS
content:
<b><i>URL</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. Specifies a URL to open upon launching the browser. For example: <i>opera-stable https://www.opera.com</i><br><br><b><b>--new-window</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the opening of a new browser window, even if an existing Opera instance is running.<br><br><b><b>--incognito</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens a new window in incognito mode, which prevents browsing history, cookies, and site data from being saved.<br><br><b><b>--profile-directory=<i>&lt;name&gt;</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the user profile directory to use. For example: <i>Default</i> or <i>Profile 1</i>.<br><br><b><b>--user-data-dir=<i>&lt;path&gt;</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the directory that contains user data. Useful for portable installations or specific profile management.<br><br><b><b>--app=<i>&lt;url&gt;</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the specified URL in an application-like window without browser UI elements (e.g., address bar, tabs).<br><br><b><b>--no-sandbox</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the sandbox security feature. <b>Use with extreme caution</b> as it significantly reduces security.<br><br><b><b>--disable-gpu</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables GPU hardware acceleration. Useful for troubleshooting rendering issues or on systems with problematic graphics drivers.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the installed version of Opera Stable to the console and exits.<br><br>


title: DESCRIPTION
content:
The <b>opera-stable</b> command launches the stable version of the Opera web browser on Linux systems. Opera is a powerful, cross-platform web browser developed by Opera Software, renowned for its unique features and focus on user privacy and browsing efficiency. Built on the Chromium engine (which uses the Blink rendering engine), it ensures broad compatibility with web standards and extensions, similar to Google Chrome.<br><br>Originally, Opera utilized its own proprietary Presto rendering engine, pioneering many features like tabbed browsing, pop-up blocking, and integrated email clients. In 2013, Opera transitioned to a Chromium-based architecture to streamline development and improve compatibility. This shift allowed it to maintain its distinct identity through innovative features such as a built-in VPN, ad blocker, battery saver, and customizable workspaces, offering a compelling alternative to other mainstream browsers.


title: CAVEATS
content:
Opera, while built on the open-source Chromium project, is a proprietary browser. This means its source code is not fully open for review and modification by the community, unlike browsers like Firefox or the Chromium project itself. Updates are typically managed through the system's package manager (e.g., APT on Debian/Ubuntu, DNF/YUM on Fedora/RHEL) once Opera's repository is added during installation.


title: INSTALLATION AND UPDATES
content:
On Linux, Opera Stable is typically installed by downloading a <i>.deb</i> or <i>.rpm</i> package from the official Opera website. This process usually adds an official Opera repository to your system's package manager configuration, allowing for seamless updates through standard system update commands (e.g., <i>sudo apt update &amp;&amp; sudo apt upgrade</i> or <i>sudo dnf update</i>).


title: USER PROFILES
content:
Opera, like other Chromium-based browsers, supports multiple user profiles. This allows different users to have separate browsing data (bookmarks, history, extensions, settings, etc.) without interfering with each other. Profiles can be managed from within Opera's settings or explicitly launched using the <b>--profile-directory</b> and <b>--user-data-dir</b> command-line options.


title: HISTORY
content:
Opera was first released in 1995 by Opera Software ASA. For nearly two decades, it distinguished itself by using its own layout engine, Presto, and introducing numerous innovations that later became industry standards, such as tabbed browsing, pop-up blocking, and integrated search. Facing challenges in web compatibility and resource allocation, Opera made the significant decision in 2013 to switch to the WebKit engine, and subsequently to Blink (Chromium's fork of WebKit). This transition, while controversial among some long-time users, allowed Opera to maintain modern web standards compatibility and focus its development efforts on unique user-facing features, solidifying its position as an alternative browser focused on productivity and privacy.


title: SYNOPSIS
content:
<I>ophcrack-cli</I> [<I>OPTIONS</I>]<br>The primary command-line interface for Ophcrack. While a GUI version is common, <I>ophcrack-cli</I> provides programmatic control for hash cracking.


title: PARAMETERS
content:
<b><b>-t</b>, <I>--tables</I> <I>directory</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the directory where the rainbow tables are located. These tables are essential for cracking.<br><br><b><b>-d</b>, <I>--database</I> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input file containing LM or NTLM hashes to be cracked, often a Windows SAM file or a hash dump.<br><br><b><b>-l</b>, <I>--log</I> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Logs the program's output and progress to the specified file instead of the console.<br><br><b><b>-p</b>, <I>--passwords</I> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs successfully cracked passwords to the specified file.<br><br><b><b>-c</b>, <I>--config</I> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses an alternative configuration file for Ophcrack settings.<br><br><b><b>-h</b>, <I>--help</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with command-line options and usage information.<br><br><b><b>-v</b>, <I>--version</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the Ophcrack CLI tool.<br><br>


title: DESCRIPTION
content:
Ophcrack is a free, open-source tool designed to crack Windows LM and NTLM password hashes using rainbow tables. Unlike brute-force or dictionary attacks that try every possible password, Ophcrack leverages precomputed tables of hash values. This allows for extremely fast recovery of passwords, often within minutes, if the password's hash is present in the loaded rainbow tables.<br><br>It's particularly effective against older Windows operating systems (like XP, 2000, Vista, 7) that primarily use LM and NTLM hashes. The tool can extract hashes directly from a Windows SAM file or process hashes dumped by other utilities. While highly efficient for its target hash types, its effectiveness is limited by the size and scope of the rainbow tables and struggles with modern, salted hashes or very long, complex passwords that are not precomputed.


title: CAVEATS
content:
Ophcrack's primary method relies on <I>rainbow tables</I>, which are large precomputed datasets. <br><b>Limitations include:</b><br>It requires substantial disk space for rainbow tables.<br>It is less effective against modern, salted password hashes (e.g., NTLMv2, bcrypt, scrypt, Argon2) as rainbow tables are designed for unsalted or weakly salted hashes.<br>It cannot crack passwords whose hashes are not present within the loaded rainbow tables.<br><I>Ethical considerations:</I> Ophcrack should only be used on systems for which you have explicit permission to access or audit. Unauthorized use is illegal and unethical.


title: GUI VS. CLI
content:
While this documentation focuses on the <I>ophcrack-cli</I> command-line interface, Ophcrack is also widely known for its intuitive graphical user interface (GUI). The GUI version simplifies the process, making it accessible to users who prefer a visual interaction for loading tables, hashes, and viewing results.


title: RAINBOW TABLES EXPLAINED
content:
Rainbow tables are precomputed tables used in cryptography for reversing cryptographic hash functions, usually for cracking password hashes. They are an optimization over a simple hash chain that allows for a trade-off between time and memory, significantly speeding up the cracking process by reducing the need for brute-force computations at runtime.


title: HISTORY
content:
Ophcrack was initially released around 2004-2006 by the Ophcrack project team. It quickly gained prominence as a highly effective and user-friendly tool for cracking Windows LM and NTLM hashes, particularly for older Windows versions (XP, 2000, Vista, 7). Its innovation lay in popularizing and implementing the concept of <I>rainbow tables</I> for password recovery. While the underlying hash types it targets (LM/NTLM) are becoming less prevalent for new systems due to stronger modern hashing algorithms and password policies, Ophcrack remains a valuable tool for auditing legacy systems or in specific forensic scenarios.


title: PARAMETERS
content:
<b><b>-d &lt;directory&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the directory where Ophcrack should look for rainbow tables. This option is crucial for the command to function.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with available options and exits.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the rainbow tables found in the specified table directory (via <b>-d</b>).<br><br><b><b>-n &lt;number&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of CPU cores or threads to utilize for the cracking process, optimizing performance.<br><br><b><b>-o &lt;file&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Redirects the cracked passwords and their corresponding hashes to the specified output file.<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the successfully cracked passwords and their hashes to the standard output (console).<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables quiet mode, suppressing most informational output during the cracking process.<br><br><b><b>-s &lt;file&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target file containing hashes to crack. This can be a Windows SAM file, a SYSTEM file, or a plain text file containing hashes (e.g., <i>LM:NTLM</i> format).<br><br><b><b>-t &lt;tables&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies which subset of rainbow tables to use for cracking (e.g., <i>"all"</i>, <i>"LM"</i>, <i>"NTLM"</i>, or specific table names).<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information about the cracking process.<br><br>


title: DESCRIPTION
content:
The <b>ophcrack-cli</b> command is the command-line interface version of Ophcrack, a free and open-source tool designed to crack Windows user passwords. It operates primarily by utilizing pre-computed rainbow tables, which are large datasets that allow for very fast lookup of plaintext passwords from their corresponding hashes. Ophcrack is specifically effective against LM (LAN Manager) and NTLM (NT LAN Manager) hashes, commonly used in older and some current Windows environments.<br><br>Users typically provide <b>ophcrack-cli</b> with a directory containing these rainbow tables and a target file, which can be a Windows SAM (Security Account Manager) file, a SYSTEM file, or a plain text file containing extracted hashes. The command then attempts to reverse the hashes into their original passwords using the table data. It is widely used for security auditing, recovering lost Windows passwords, and demonstrating the vulnerabilities of specific hashing algorithms. Its efficiency heavily relies on the availability and completeness of the rainbow tables.


title: CAVEATS
content:
Using <b>ophcrack-cli</b> effectively requires significant storage for rainbow tables (often hundreds of gigabytes). The effectiveness of cracking depends directly on the size and type of available tables and the complexity of the passwords. For modern, complex passwords or newer hashing algorithms, Ophcrack may be less effective than more contemporary tools like <i>hashcat</i> or <i>John the Ripper</i>. Always ensure you have explicit legal authorization to crack passwords, as unauthorized use is illegal and unethical.


title: RAINBOW TABLES EXPLAINED
content:
Rainbow tables are pre-computed tables used in cryptography to reverse cryptographic hash functions, usually for cracking password hashes. Instead of calculating hash values for every possible password (a brute-force attack), Ophcrack looks up the hash in a rainbow table, which contains pre-calculated chains of hashes and their corresponding plaintext values. This method significantly speeds up the cracking process compared to on-the-fly brute-forcing for known hash types like LM and NTLM.


title: SUPPORTED HASH TYPES
content:
<b>ophcrack-cli</b> primarily targets LAN Manager (LM) and NT LAN Manager (NTLM) hashes. LM hashes are particularly weak due to their design (case-insensitivity, 7-character limit, broken into two halves), making them very fast to crack. NTLM hashes are more robust than LM but are still vulnerable to rainbow table attacks, especially with large, comprehensive tables. It does not support newer, stronger hashing algorithms or salted hashes often used in modern systems.


title: PREREQUISITES FOR USAGE
content:
To use <b>ophcrack-cli</b>, you must first download or generate appropriate rainbow tables. These tables are typically very large (tens to hundreds of gigabytes) and must match the hash type you intend to crack (e.g., LM or NTLM tables). Without these tables, the command cannot perform its cracking function. The target hashes must also be extracted from the system (e.g., from SAM/SYSTEM files or a registry hive) before they can be fed into <b>ophcrack-cli</b>.


title: HISTORY
content:
Ophcrack was developed by Objectif Sécurité and first released around 2007, quickly gaining prominence for its innovative use of rainbow tables for Windows password cracking. It was often distributed as a LiveCD/LiveUSB, allowing users to boot directly into an environment capable of cracking passwords from a target system's disk. The <b>ophcrack-cli</b> version provides the core cracking engine without the graphical user interface, making it suitable for scripting and command-line environments. While still functional, its role has somewhat diminished over time with the adoption of stronger password hashing mechanisms and the emergence of more versatile and GPU-accelerated cracking tools.


title: PARAMETERS
content:
<b><i>command</i>: update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates the list of available packages from configured repositories.<br><br><b><i>command</i>: upgrade [<i>pkg</i>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Upgrades all installed packages or specified packages to their newest versions.<br><br><b><i>command</i>: install <i>pkg</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs one or more specified packages, along with their dependencies.<br><br><b><i>command</i>: remove <i>pkg</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes one or more specified packages. Use with <i>--autoremove</i> to remove unneeded dependencies.<br><br><b><i>command</i>: list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all packages available in the configured repositories.<br><br><b><i>command</i>: list-installed</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all currently installed packages on the system.<br><br><b><i>command</i>: search <i>pattern</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for packages whose names or descriptions match the given pattern.<br><br><b><i>command</i>: info <i>pkg</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about one or more specified packages.<br><br><b><i>command</i>: files <i>pkg</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all files owned and installed by a specific package.<br><br><b><i>command</i>: status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the status of installed packages, indicating if they are installed, removed, or partially configured.<br><br><b><i>command</i>: download <i>pkg</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Downloads the specified packages to the current directory without installing them.<br><br><b><i>command</i>: configure <i>pkg</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Re-configures one or more specified packages, typically running their post-install scripts.<br><br><b>-V <i>level</i>, --verbosity <i>level</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the verbosity level for output (0-9). Higher numbers provide more detailed information.<br><br><b>-f <i>conf_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file to use instead of the default <i>/etc/opkg.conf</i>.<br><br><b>-t <i>directory</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses the specified directory for temporary files during operations.<br><br><b>-o <i>directory</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the offline root directory for installations, useful for building system images.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about the operation.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables quiet output, suppressing informational messages.<br><br><b>--no-install-recommends</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the installation of recommended packages during an install operation.<br><br><b>--no-install-suggests</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the installation of suggested packages during an install operation.<br><br><b>--nodeps</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignores package dependencies. Use with caution, as it can lead to broken packages.<br><br><b>--force-depends</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces installation/removal even if dependencies are not met or conflicts exist.<br><br><b>--force-overwrite</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces overwriting of existing files when installing a package, potentially resolving file conflicts.<br><br><b>--force-postinstall</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the execution of post-installation scripts, even if errors occur or conditions are not met.<br><br><b>--force-removal-of-dependent-packages</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces removal of packages that depend on the package being removed, potentially breaking the system.<br><br><b>--force-maintainer</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <i>opkg</i> into maintainer mode, which can alter its behavior for package developers.<br><br><b>--recursive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recursively install or remove packages, including their nested dependencies (where applicable).<br><br><b>--cache <i>directory</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative cache directory for downloaded package files.<br><br><b>--offline-root <i>directory</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs packages into the specified offline root directory for pre-populating system images.<br><br><b>--add-arch <i>arch</i> <i>priority</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a supported architecture and its priority for dependency resolution.<br><br><b>--arch <i>arch</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the architecture for which to manage packages, overriding the system's detected architecture.<br><br>


title: DESCRIPTION
content:
<i>opkg</i> is a lightweight package manager primarily designed for embedded Linux systems, such as OpenWrt routers, IoT devices, and other resource-constrained environments. It is a fork of the <i>ipkg</i> package manager and handles <i>.ipk</i> package files.<br><br><i>opkg</i> simplifies the process of installing, upgrading, and removing software packages on these systems, managing dependencies, and interacting with package repositories. It provides a command-line interface for common package management operations like updating package lists, installing new software, upgrading existing packages, removing unwanted ones, and querying information about installed or available packages. Due to its minimal resource footprint, <i>opkg</i> is a crucial tool for maintaining and extending the functionality of many embedded Linux distributions where full-featured package managers like APT or DNF would be too heavy.


title: CAVEATS
content:
<i>opkg</i> is specifically designed for embedded systems and may not be found or suitable for general-purpose Linux distributions like Debian, Ubuntu, Fedora, or Arch Linux, which use their own, more robust package management systems. Its dependency resolution and package format (<i>.ipk</i>) are simpler than those of larger package managers, making it less suitable for complex server or desktop environments.


title: CONFIGURATION
content:
<i>opkg</i> reads its configuration from <i>/etc/opkg.conf</i> and potentially additional files in <i>/etc/opkg.d/</i>. These files define package repositories (<i>src/gz</i> lines), architecture settings, and other operational parameters. Users can specify custom configuration files using the <i>-f</i> option.


title: PACKAGE SOURCES
content:
Packages are fetched from repositories defined in the configuration. These are typically HTTP/HTTPS URLs pointing to directories containing <i>.ipk</i> files and package index files (like <i>Packages.gz</i>). The <i>opkg update</i> command downloads these index files to build a local cache of available packages, allowing <i>opkg</i> to know which packages are available for installation.


title: HISTORY
content:
<i>opkg</i> originated as a fork of the <i>ipkg</i> package manager. <i>ipkg</i> itself was created for use on embedded Linux devices, particularly during the early days of devices like the Linksys NSLU2 and eventually adopted by projects like OpenWrt. As <i>ipkg</i> development became stagnant, <i>opkg</i> emerged to address its limitations and continue active development, specifically tailored to the needs of the OpenWrt project and other embedded Linux distributions. It gained popularity for its efficiency and small footprint, making it ideal for devices with limited storage and processing power.


title: PARAMETERS
content:
<b><b>-b</b> <i><BFDNAME></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the target Binary File Descriptor (BFD) architecture (e.g., <i>i386</i>, <i>arm</i>, <i>mips</i>). This determines the instruction set to decode.<br><br><b><b>-m</b> <i><MACHINE></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the machine variant for the chosen architecture (e.g., <i>i386:intel</i> for Intel syntax, <i>arm:v7</i>). This fine-tunes the disassembly process.<br><br><b><b>-s</b> <i><START_ADDRESS></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start disassembling from the specified address. Useful when the input represents a larger memory region and you only want to decode from a certain offset.<br><br><b><b>-l</b> <i><LENGTH></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disassemble only the specified number of bytes from the start address (or beginning of input if <b>-s</b> is not used).<br><br><b><b>-w</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display wider output, potentially including more detailed instruction bytes or additional information in the disassembly listing.<br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include instruction address prefix in the output, showing the byte offset of each instruction.<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat input as raw bytes. This is often the default behavior, but explicitly ensures no file header parsing is attempted.<br><br><b><b>-P</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print instruction prolog. This option is specific to certain architectures (e.g., PowerPC) and affects how instructions are displayed.<br><br><b><b>-I</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print instruction prolog. The inverse of <b>-P</b>.<br><br><b><b>-D</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debugging output, providing verbose information about the internal operations of the command. Primarily for development or troubleshooting.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a brief usage message and exit.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information for <b><I>opldecode</I></b> and exit.<br><br>


title: DESCRIPTION
content:
<b><I>opldecode</I></b> is a specialized command-line utility used to disassemble raw binary machine code into human-readable assembly language instructions. It reads input typically from standard input or a specified file, interpreting the bytes as executable opcodes for a chosen processor architecture. Unlike more comprehensive tools like <b><I>objdump</I></b>, <b><I>opldecode</I></b> focuses on raw byte streams and does not parse entire executable formats (e.g., ELF, PE). This makes it particularly useful for analyzing isolated machine code snippets, shellcode, or firmware, where the input is not a structured object file. It is part of the GNU Binutils project and serves as a fundamental example of how the underlying <b><I>libopcodes</I></b> library can be utilized for disassembly.


title: CAVEATS
content:
<b><I>opldecode</I></b> is a relatively simple tool compared to <b><I>objdump</I></b>. It lacks advanced features like symbol resolution, relocation entry parsing, or comprehensive understanding of object file formats. It requires explicit specification of the target architecture (via <b><I>-b</I></b> and often <b><I>-m</I></b>) and does not automatically detect it. Its primary use case is for raw byte streams, not compiled executables, and it may not be installed by default on all Linux distributions as a standalone command, sometimes being an internal Binutils test utility.


title: PIPING RAW BYTES
content:
<b><I>opldecode</I></b> is often used by piping raw binary data directly to its standard input. For example, to disassemble the <i>NOP</i> (0x90) and <i>RET</i> (0xC3) instructions on x86-64:<br><code>echo -ne "\x90\x90\xc3" | opldecode -b i386 -m i386:intel</code><br>This allows for quick analysis of small, arbitrary code sequences without needing to save them to a file.


title: UNDERLYING LIBRARY
content:
The core disassembly logic utilized by <b><I>opldecode</I></b> (and also by <b><I>objdump</I></b>) is provided by the <b><I>libopcodes</I></b> library, a fundamental component of GNU Binutils. This library abstracts away the complexities of different instruction sets, allowing tools to perform disassembly consistently across various processor architectures.


title: HISTORY
content:
<b><I>opldecode</I></b> is part of the GNU Binutils collection, which has been under continuous development since the late 1980s. It likely originated as a practical demonstration or test utility for the <b><I>libopcodes</I></b> library, which is the core engine for disassembling machine instructions across various architectures within Binutils. Its usage has remained niche, primarily for specialized tasks involving raw machine code snippets, as <b><I>objdump</I></b> fulfills most general-purpose disassembly needs.


title: SYNOPSIS
content:
<b><I>opt</I></b> [<i>options</i>] [<i>input_bitcode_file</i>]<br><br>The <b><I>opt</I></b> command processes LLVM bitcode, applying various optimization passes. If no input file is specified, it reads from standard input. If no output file is specified with <b><I>-o</I></b>, it writes to standard output.


title: PARAMETERS
content:
<b><b><I>-help</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show available options and optimization passes.<br><br><b><b><I>-version</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the LLVM version information.<br><br><b><b><I>-S</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Emit LLVM assembly (<b><I>.ll</I></b>) instead of bitcode (<b><I>.bc</I></b>).<br><br><b><b><I>-o</I></b> <i><I>filename</I></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output file. Defaults to standard output if omitted.<br><br><b><b><I>-mem2reg</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Promote <b><I>alloca</I></b> instructions (memory allocations) to registers.<br><br><b><b><I>-instcombine</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform peephole optimizations and combine redundant or inefficient instructions.<br><br><b><b><I>-gvn</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Eliminate redundant expressions using Global Value Numbering.<br><br><b><b><I>-simplifycfg</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simplify the control flow graph of the program.<br><br><b><b><I>-O</I></b><i><I>[0-3saz]</I></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Apply standard sets of optimizations (0: none, 1-3: increasing aggressiveness, s/z: size optimization).<br><br>


title: DESCRIPTION
content:
The <b><I>opt</I></b> command is a crucial tool within the LLVM (Low Level Virtual Machine) toolchain, primarily used for applying various optimization passes to LLVM bitcode files. It reads a bitcode module (typically generated by <b><I>clang</I></b> or <b><I>llvm-as</I></b>) and applies a sequence of transformations to improve its performance, reduce its size, or both. <b><I>opt</I></b> is highly modular, allowing developers to apply individual optimization passes or predefined groups of passes (like those enabled by <b><I>-O1</I></b>, <b><I>-O2</I></b>, etc.). This modularity is a core strength of LLVM, enabling extensive experimentation with different optimization strategies. It plays a vital role in the compilation process, transforming intermediate representations before final code generation by tools like <b><I>llc</I></b>. The output can be optimized bitcode, LLVM assembly, or a human-readable representation of the applied optimizations.


title: CAVEATS
content:
The <b><I>opt</I></b> command is part of the LLVM project and requires LLVM to be installed on your system. It is not a standalone general-purpose Linux utility. The order in which optimization passes are applied can significantly affect the final optimized code, and selecting the optimal set of passes often requires deep understanding of compiler optimizations. It can be complex to use effectively without prior knowledge of LLVM and compiler internals.


title: OPTIMIZATION LEVELS
content:
The <b><I>-O</I></b><i><I>[0-3saz]</I></i> options provide convenient shortcuts to apply predefined sets of optimization passes.<br><br><b><I>-O0</I></b>: Disable most optimizations, useful for debugging.<br><b><I>-O1</I></b>: Enable a basic set of optimizations.<br><b><I>-O2</I></b>: Enable more aggressive optimizations than <b><I>-O1</I></b>, aiming for good overall performance. This is often a good default for release builds.<br><b><I>-O3</I></b>: Enable the most aggressive optimizations, which may increase compile time and sometimes code size, but aims for maximum performance.<br><b><I>-Os</I></b>: Optimize for code size, similar to <b><I>-O2</I></b> but prioritizing size reduction.<br><b><I>-Oz</I></b>: Even more aggressively optimize for code size than <b><I>-Os</I></b>.


title: OPTIMIZATION PASSES
content:
<b><I>opt</I></b> applies individual transformations known as 'passes.' Each pass performs a specific optimization, such as dead code elimination, loop unrolling, or constant propagation. The power of <b><I>opt</I></b> lies in its ability to combine these passes in various orders and sequences. Users can explicitly list individual passes on the command line (e.g., <b><I>-mem2reg -instcombine</I></b>) or use optimization level flags (e.g., <b><I>-O2</I></b>) which implicitly run a curated list of passes.


title: HISTORY
content:
The <b><I>opt</I></b> command has been a core component of the LLVM project since its inception. LLVM was originally developed by Chris Lattner at the University of Illinois at Urbana-Champaign in 2003. A fundamental design goal of LLVM was modularity and extensibility, which <b><I>opt</I></b> embodies by allowing individual optimization passes to be applied independently. This design has enabled rapid development and experimentation with new optimization techniques, making LLVM a popular choice for research and industrial applications. Over the years, <b><I>opt</I></b> has evolved with the LLVM project, gaining more passes and sophisticated optimization strategies.


title: SYNOPSIS
content:
<b>optimus-manager</b> [<i>OPTIONS</i>]<br><b>optimus-manager</b> <i>--switch</i> {<i>integrated</i>|<i>nvidia</i>|<i>hybrid</i>}<br><b>optimus-manager</b> <i>--status</i><br><b>optimus-manager</b> <i>--set-startup-mode</i> {<i>integrated</i>|<i>nvidia</i>|<i>hybrid</i>|<i>nvidia_once</i>}<br><b>optimus-manager</b> <i>--reset</i><br><b>optimus-manager</b> <i>--daemon</i> {<i>start</i>|<i>stop</i>|<i>status</i>|<i>restart</i>}<br><b>optimus-manager</b> <i>--help</i>


title: PARAMETERS
content:
<b><i>--switch</i> {<i>integrated</i>|<i>nvidia</i>|<i>hybrid</i>}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Changes the active GPU mode. Requires a logout/reboot to apply the new mode.<br><br><b><i>--status</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current GPU mode, configured startup settings, and daemon status.<br><br><b><i>--print-mode</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints only the currently active GPU mode to standard output.<br><br><b><i>--set-startup-mode</i> {<i>mode</i>}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures the GPU mode to be automatically set on system startup. '<i>nvidia_once</i>' boots into NVIDIA mode once, then reverts.<br><br><b><i>--unset-startup-mode</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clears any previously configured startup GPU mode, reverting to default behavior.<br><br><b><i>--temp-config</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a temporary Xorg configuration file for testing purposes without applying it system-wide.<br><br><b><i>--setup-system</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs initial setup, creating necessary system files and service configurations.<br><br><b><i>--unset-system</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes all system-wide <i>optimus-manager</i> configurations and files.<br><br><b><i>--no-confirm</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips interactive confirmation prompts for potentially destructive operations.<br><br><b><i>--reset</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resets all <i>optimus-manager</i> configurations to their default state and switches to integrated mode.<br><br><b><i>--daemon</i> {<i>action</i>}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls the <i>optimus-manager</i> background service (e.g., <i>start</i>, <i>stop</i>, <i>status</i>, <i>restart</i>).<br><br><b><i>--version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the installed version of <i>optimus-manager</i>.<br><br><b><i>--help</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the command's usage information and available options.<br><br>


title: DESCRIPTION
content:
<i>optimus-manager</i> is a comprehensive solution for managing NVIDIA Optimus hybrid graphics on Linux systems. It allows users to effortlessly switch between the integrated GPU (e.g., Intel, AMD) and the dedicated NVIDIA GPU, or utilize a "hybrid" mode where the integrated GPU handles primary display output while the NVIDIA GPU is available for compute tasks and specific application offloading via PRIME.<br><br>This tool significantly simplifies the complex setup traditionally associated with Optimus, automatically handling Xorg configurations and integrating with common display managers (GDM, LightDM, SDDM). By providing a streamlined command-line interface, <i>optimus-manager</i> aims to improve power efficiency by allowing the NVIDIA GPU to be fully powered off when not in use (in integrated mode) and to provide full performance when the dedicated GPU is required. It addresses long-standing challenges faced by Linux users with Optimus laptops, offering a robust and user-friendly mechanism for GPU mode control.


title: CAVEATS
content:
<ul><li>Requires a compatible display manager (e.g., GDM, LightDM, SDDM) for seamless operation.</li><li>Switching GPU modes typically requires logging out and back in, or a full system reboot.</li><li>In 'hybrid' mode, applications might need to be explicitly launched with tools like <i>prime-run</i> (from <i>nvidia-prime</i> package) to utilize the NVIDIA GPU.</li><li>While actively developed, compatibility issues can sometimes arise with specific kernel versions or bleeding-edge NVIDIA drivers.</li><li>Native Wayland sessions have evolving support; traditionally, <i>optimus-manager</i> is more robust with Xorg.</li></ul>


title: DAEMON AND CONFIGURATION
content:
<i>optimus-manager</i> operates via a background daemon that monitors display manager sessions and applies GPU configurations upon login/logout. It manages Xorg configuration files (e.g., in <i>/etc/X11/xorg.conf.d/</i>). Users can customize its behavior by creating a configuration file at <i>/etc/optimus-manager/optimus-manager.conf</i>.


title: PRIME RENDER OFFLOAD
content:
In 'hybrid' mode, <i>optimus-manager</i> leverages NVIDIA's PRIME Render Offload capabilities, allowing the integrated GPU to drive the display while the NVIDIA GPU can be used for demanding applications. This provides a balance between power efficiency and dedicated graphics performance, typically by prefixing commands with <i>prime-run</i>.


title: HISTORY
content:
<i>optimus-manager</i> emerged as a community-driven solution to the persistent challenges of managing NVIDIA Optimus hybrid graphics on Linux. Building upon earlier manual configurations (like NVIDIA PRIME), its development focused on automating and simplifying the GPU switching process. It aims to provide a more user-friendly and robust experience for Optimus laptop owners, addressing issues such as power consumption and performance control that were often problematic with traditional Linux setups.


title: SYNOPSIS
content:
<b><code>optipng [options] <files...></code></b><br><b><code>optipng [options] <directory></code></b>


title: PARAMETERS
content:
<b>-o <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set optimization level (0-7). Higher levels perform more trials for better compression, but take longer.<br><br><b>-zc <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Zlib compression level (1-9).<br><br><b>-zm <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Zlib memory level (1-9).<br><br><b>-zs <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Zlib compression strategy (0-3).<br><br><b>-f <filters></b><br>&nbsp;&nbsp;&nbsp;&nbsp;PNG filter strategies (e.g., 0-5, m, p, e, b, N). Combines multiple filter types.<br><br><b>-i <iterations></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of iterations (1-100). Increases chances of finding optimal compression.<br><br><b>-nb</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not reduce bit depth.<br><br><b>-nc</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not reduce color type.<br><br><b>-np</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not reduce palette.<br><br><b>-nx</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not change interlacing.<br><br><b>-fix</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fix common PNG errors.<br><br><b>-keep</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Keep original file attributes (timestamp, permissions).<br><br><b>-strip <filters></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Strip metadata chunks. Common filters: <code>all</code>, <code>iptexif</code>, <code>text</code>, <code>srgb</code>, <code>iccp</code>.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Quiet mode; suppress output.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verbose mode; display detailed information.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help message and exit.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br>


title: DESCRIPTION
content:
<i>OptiPNG</i> is a powerful command-line utility designed for <b>losslessly compressing PNG (Portable Network Graphics) image files</b> to their smallest possible size. Unlike lossy compression methods, <i>OptiPNG</i> ensures that the visual quality of the image remains identical to the original, only focusing on reducing file size through more efficient data storage. It achieves this by intelligently trying various compression methods, filter types, and color depth reductions, and then selecting the combination that yields the smallest output. This makes it an invaluable tool for web developers, designers, and anyone looking to optimize images for faster loading times, reduced bandwidth consumption, and lower storage requirements without any loss of quality. <i>OptiPNG</i> can process individual files, multiple files, or even entire directories, making batch optimization straightforward. Its meticulous approach often results in significant file size reductions, especially for images not previously optimized.


title: CAVEATS
content:
<i>OptiPNG</i> performs <b>lossless compression</b>; it will not achieve size reductions by degrading image quality. Results depend heavily on the original image's characteristics and prior optimization. Higher optimization levels (e.g., <code>-o7</code>) can be <b>CPU-intensive and time-consuming</b>, especially for large images or batch processing. While highly effective, it might not yield significant reductions for images already well-optimized or those with limited compression potential.


title: OPTIMIZATION LEVELS (-O)
content:
The <code>-o</code> option controls the optimization aggression, from 0 to 7.<br><i>Level 0:</i> No optimization, only writes a new file.<br><i>Level 1:</i> Basic optimization, equivalent to <code>-zc9 -zm8 -zs0 -f0</code>.<br><i>Level 2:</i> Good optimization, equivalent to <code>-zc9 -zm8 -zs0 -f5</code>.<br><i>Level 3-7:</i> Progressively more aggressive, trying more filter combinations, strategies, and iterations, taking significantly more time but potentially yielding smaller files. <code>-o7</code> is the most exhaustive.


title: COMMON USAGE EXAMPLE
content:
To optimize all PNG files in the current directory with a good balance of speed and compression:<br><code>optipng -o5 *.png</code><br>To optimize a single file and be very aggressive, displaying verbose output:<br><code>optipng -o7 -v input.png -out optimized.png</code>


title: HISTORY
content:
<i>OptiPNG</i> was initially developed by <b>Cosmin Truta</b>, with its first public release around 2001. The project's primary goal was to create a PNG optimizer that could achieve better compression ratios than existing tools, leveraging advanced algorithms and exhaustive search strategies. It quickly gained traction, particularly among web developers, due to its ability to significantly reduce file sizes without any loss of visual fidelity. Over the years, it has seen continuous development, incorporating new PNG specifications and compression techniques, solidifying its position as a go-to tool for lossless PNG optimization on Linux and other platforms.


title: SYNOPSIS
content:
<b>opusenc</b> [<i>options</i>] <I>input_filename</I> <I>output_filename</I><br><br><b>opusenc</b> [<i>options</i>] --raw-input --raw-rate <i>Hz</i> --raw-channels <i>N</i> [--raw-endianness <i>endianness</i>] <I>input_filename</I> <I>output_filename</I>


title: PARAMETERS
content:
<b><I>input_filename</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the input audio file. Supported formats typically include WAV, AIFF, FLAC, and Ogg/Vorbis, handled via <b>libsndfile</b>. Use '--raw-input' for raw PCM data.<br><br><b><I>output_filename</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path where the encoded Opus audio file will be saved. The file will have an '.opus' extension by convention.<br><br><b>--raw-input</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat the input file as raw (unheadered) PCM samples. Requires additional options like '--raw-rate' and '--raw-channels'.<br><br><b>--raw-rate <I>Hz</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When using '--raw-input', specifies the sampling rate of the raw input in Hertz (e.g., 48000).<br><br><b>--raw-channels <I>N</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When using '--raw-input', specifies the number of channels (1 for mono, 2 for stereo) of the raw input.<br><br><b>--raw-endianness <I>endianness</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When using '--raw-input', specifies the byte order of the raw input. Common values are 'little' or 'big'.<br><br><b>--bitrate <I>N</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the target average bitrate for encoding in kilobits per second (kb/s). Valid range typically 6-510. The default is usually 64 kb/s per channel.<br><br><b>--vbr</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables Variable Bit Rate (VBR) encoding. This is the default mode and aims for a consistent quality level by varying the bitrate.<br><br><b>--cvbr</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables Constrained Variable Bit Rate (CVBR) encoding. Similar to VBR but with stricter bitrate limits, useful for network streams with bandwidth constraints.<br><br><b>--cbr</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables Constant Bit Rate (CBR) encoding. Maintains a fixed bitrate throughout the audio, often at the cost of quality variability.<br><br><b>--framesize <I>ms</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the frame size (packet duration) in milliseconds. Typical values are 2.5, 5, 10 (default), 20, 40, or 60. Smaller framesizes lead to lower latency but higher overhead.<br><br><b>--comp <I>N</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the complexity level of the encoder, from 0 (lowest complexity, fastest) to 10 (highest complexity, slowest, best quality). Default is usually 10 for general audio.<br><br><b>--application <I>type</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the intended application type for optimization. Valid values are 'voip' (for speech), 'audio' (for general music/audio, default), or 'lowdelay' (for ultra-low latency, sacrifices some quality).<br><br><b>--downmix-mono</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Downmixes stereo input audio to a single mono channel before encoding.<br><br><b>--gain <I>dB</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjusts the input audio gain by the specified decibel (dB) value before encoding. Can be positive or negative.<br><br><b>--title <I>string</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a 'TITLE' comment tag to the output Opus file metadata.<br><br><b>--artist <I>string</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds an 'ARTIST' comment tag to the output Opus file metadata.<br><br><b>--comment <I>tag=value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a custom comment tag to the output Opus file metadata. Can be used multiple times for different tags.<br><br>


title: DESCRIPTION
content:
<i>opusenc</i> is the command-line utility for encoding audio into the highly versatile <b>Opus</b> interactive audio codec format. Developed by the Xiph.Org Foundation and standardized by the IETF (RFC 6716), Opus is a royalty-free, open, and extremely flexible codec capable of handling various audio types, from high-fidelity music to low-bitrate speech.<br><br><i>opusenc</i> takes various input audio formats, typically through <b>libsndfile</b>, such as WAV, AIFF, FLAC, and Ogg/Vorbis, and converts them into Opus. Its strengths lie in providing excellent quality across a wide range of bitrates (6 kb/s to 510 kb/s), low algorithmic delay, and high resilience to packet loss, making it ideal for real-time applications like Voice over IP (VoIP), video conferencing, and live streaming, as well as general audio storage and playback. It is part of the official <b>opus-tools</b> package.


title: CAVEATS
content:
<i>opusenc</i> primarily relies on <b>libsndfile</b> for input file format support. While common formats like WAV, AIFF, and FLAC are generally supported, less common or proprietary formats (e.g., some MP3 variants directly) might not be. For such cases, pre-conversion using tools like <b>ffmpeg</b> might be necessary.<br><br>When encoding, there's a fundamental trade-off between bitrate, quality, and algorithmic delay. Selecting appropriate parameters (e.g., '--bitrate', '--framesize', '--application') is crucial for achieving desired results for specific use cases.


title: SUPPORTED INPUT FORMATS
content:
By default, <i>opusenc</i> leverages <b>libsndfile</b> to support a wide array of uncompressed and lossless audio formats including WAV, AIFF, AU, FLAC, and unheadered raw PCM data. Support for compressed formats like Ogg/Vorbis is also often available. For other formats (e.g., MP3, AAC), you might need to pipe output from a converter like <b>ffmpeg</b>.


title: ENCODING MODES
content:
<i>opusenc</i> offers flexible encoding modes:<br><b>VBR (Variable Bit Rate):</b> Default mode, optimizes for perceptual quality by varying bitrate. Ideal for general audio where quality is paramount.<br><b>CVBR (Constrained Variable Bit Rate):</b> Similar to VBR but with a stricter upper bound on bitrate, suitable for bandwidth-limited streaming.<br><b>CBR (Constant Bit Rate):</b> Maintains a fixed bitrate throughout the audio, useful for predictable bandwidth usage, though it may sacrifice quality peaks.


title: APPLICATION TYPES
content:
The '--application' option fine-tunes the encoder for specific scenarios:<br><b>'voip':</b> Optimized for speech, prioritizing clarity and robustness for communication.<br><b>'audio':</b> Default for general audio, balanced for music and mixed content.<br><b>'lowdelay':</b> Minimizes latency by using smaller frame sizes and simpler encoding, suitable for real-time interactive applications where delay is critical.


title: HISTORY
content:
The Opus audio codec was developed collaboratively by the Xiph.Org Foundation and others, with significant contributions from Mozilla, Skype (Microsoft), and Google. It was standardized by the Internet Engineering Task Force (IETF) as RFC 6716 in September 2012, making it an open and royalty-free standard. <i>opusenc</i> is the official command-line encoder, part of the <b>opus-tools</b> package, which provides a reference implementation for encoding and decoding Opus audio. Its development closely tracks the evolution and adoption of the Opus codec itself, becoming a cornerstone for high-quality, low-latency audio in web communication, streaming, and more general audio applications.


title: SYNOPSIS
content:
<b>orca-c</b> [<i>OPTION</i>...] [<i>ARGUMENT</i>]<br>Example: <b>orca-c</b> <i>--speak</i> "Hello, world!"


title: PARAMETERS
content:
<b>--speak <text></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Speaks</i> the provided <i>text string</i> through Orca's speech synthesizer.<br><br><b>--show-last-spoken</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <i>last text spoken</i> by Orca on the console.<br><br><b>--list-voices</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all <i>available speech voices</i> configured in Orca.<br><br><b>--set-voice <voice_name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the current speech voice to the specified <i>voice name</i>.<br><br><b>--query-state</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the current operating <i>state of Orca</i>, including speech, braille, and magnifiers.<br><br><b>--read-line</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs Orca to <i>read the current line</i> of content under focus.<br><br><b>--read-paragraph</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs Orca to <i>read the current paragraph</i> of content under focus.<br><br><b>--toggle-speech</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Toggles speech on or off</i> in Orca, effectively muting or unmuting the screen reader.<br><br><b>--stop-speech</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Immediately <i>stops any currently speaking text</i> by Orca.<br><br><b>--quit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends a command to the Orca instance to <i>quit and terminate</i>.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <i>version information</i> of the <b>orca-c</b> utility.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a <i>brief help message</i> with common options.<br><br>


title: DESCRIPTION
content:
The <b>orca-c</b> command provides a <i>command-line interface</i> for interacting with the <b>Orca screen reader</b>. It allows users to control various aspects of Orca's behavior, such as speaking text, querying its state, managing speech output, and executing specific actions, directly from the terminal or within scripts.<br><br>This utility is particularly useful for automation, scripting accessibility tasks, or for developers and power users who need to test or debug Orca's functionality without direct GUI interaction. It acts as a bridge, sending commands to a running Orca instance, making it a powerful tool for integration into broader accessibility workflows or custom applications.


title: CAVEATS
content:
The <b>orca-c</b> command requires an active <b>Orca screen reader</b> instance to be running for most of its commands to function correctly. It is designed to interact with an existing Orca session rather than launching one. Its functionality is entirely dependent on the Orca application and its configuration.


title: SCRIPTING AND AUTOMATION
content:
<b>orca-c</b> is particularly valuable for scripting accessibility tests, creating custom shortcuts, or integrating Orca's speech output into shell scripts. For example, one could use it to announce system events or script automated navigations for testing web applications with accessibility in mind.


title: HISTORY
content:
<b>Orca</b>, and by extension <b>orca-c</b>, is a foundational part of the <i>GNOME Accessibility Project</i>. It was developed to provide a free and open-source screen reader for the GNOME desktop environment, initially released around 2006. The <b>orca-c</b> utility emerged as a way to extend Orca's scriptability and integrate it more deeply into automation and testing workflows, evolving alongside the main Orca application to support its expanding features.


title: DESCRIPTION
content:
The command 'osage' is <I>not recognized</I> as a standard or commonly available utility in most Linux distributions. Command-line tools typically have dedicated manual pages (man pages) providing detailed information about their usage, options, and purpose. As 'osage' does not appear in standard command repositories or common Linux documentation, a comprehensive analysis, including its syntax, parameters, and historical development, cannot be provided. It is possible that 'osage' refers to a very specific, custom, or application-specific executable within a particular environment, or it may be a typo for another existing command. Users are advised to verify the command name or consult documentation specific to their system or software environment if 'osage' is part of a custom installation.


title: CAVEATS
content:
This analysis is based on the general availability and documentation of Linux commands.<br>Since 'osage' is not a standard utility, any information pertaining to its functionality, options, or usage would be specific to its (unknown) implementation.


title: COMMAND VERIFICATION
content:
Please ensure the command name 'osage' is spelled correctly and that it is part of your system's installed utilities.<br>Use 'man osage' or 'which osage' to confirm its presence on your specific Linux distribution.


title: POSSIBLE SPECIFIC APPLICATION
content:
If 'osage' is encountered, it likely refers to an executable file associated with a particular third-party application or a custom script, rather than a general-purpose system command.


title: HISTORY
content:
There is no documented history for 'osage' as a standard Linux command. Its development and usage are not part of the common Linux ecosystem's record.


title: SYNOPSIS
content:
<b>oscap</b> [<i>global-options</i>] <I>module</I> [<i>module-specific-options</i>] [<i>arguments</i>]


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the command or a specific module.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the <i>oscap</i> tool's version information.<br><br><b><b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of output messages to standard error.<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug output, providing more detailed internal information for troubleshooting.<br><br><b><b>--root</b> <i>&lt;directory&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative root directory to scan instead of the live system's root (e.g., for scanning a chrooted environment).<br><br><b><b>--skip-valid</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips the validation of input XML files against their respective schemas. Use with caution as it may lead to unreliable results.<br><br><b><b>--local-files</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restricts scanning operations to local files and directories, preventing network access for content retrieval.<br><br>


title: DESCRIPTION
content:
<i>oscap</i> is the command-line utility for OpenSCAP, an open-source project providing a standardized platform for security automation. It enables users to scan systems for security compliance, assess vulnerabilities, and enforce security policies based on various open security content standards.<br><br>OpenSCAP leverages standards like SCAP (Security Content Automation Protocol), which includes sub-specifications such as XCCDF (Extensible Configuration Checklist Description Format) for checklists, OVAL (Open Vulnerability and Assessment Language) for vulnerability definitions, and CPE (Common Platform Enumeration) for system identification. <i>oscap</i> acts as the primary interface to perform these operations, allowing system administrators and security auditors to automate security audits, generate detailed reports, and ensure systems adhere to specific security baselines, such as DISA STIGs or CIS Benchmarks. It supports scanning local systems as well as remote machines, and can be used for both compliance reporting and remediation tasks.


title: CAVEATS
content:
Scanning with <i>oscap</i> often requires <i>root</i> privileges to access system configuration files and audit data for comprehensive and accurate assessments. The <b>--remediate</b> option (used with modules like <b>xccdf eval</b>) makes irreversible changes to the system; use it with extreme caution and ensure proper backups or a testing environment. <i>oscap</i> relies heavily on specific SCAP content files (e.g., XCCDF, OVAL) which must be installed and up-to-date for accurate and relevant security checks.


title: MODULES
content:
The <i>oscap</i> command operates through various modules, each performing a specific task related to SCAP content and system assessment. This modular design makes <i>oscap</i> highly versatile. Common modules include:<br><ul><li><b>info</b>: Displays metadata and information about SCAP content files (e.g., XCCDF, OVAL).</li><li><b>eval</b>: Evaluates a system against a security baseline defined in an XCCDF or OVAL file, producing a detailed assessment report.</li><li><b>scan</b>: A general-purpose module often used as a wrapper for evaluations or combined scanning tasks.</li><li><b>fix</b>: Applies remediations to a system based on rules defined in an XCCDF profile, attempting to bring the system into compliance.</li><li><b>cpe</b>: Manages Common Platform Enumeration dictionaries and checks system CPE identity.</li><li><b>ds</b>: Manages operations related to SCAP Data Streams, which bundle various SCAP content components.</li></ul>Each module typically has its own set of specific options.


title: SCAP CONTENT
content:
<i>oscap</i> is a tool that processes security content; it does not contain the security rules itself. It requires SCAP content, which defines the security baselines (XCCDF profiles) and vulnerability definitions (OVAL definitions) that <i>oscap</i> uses to perform scans and assessments. This content is typically provided by separate packages like <b>scap-security-guide</b> (SSG), which offers comprehensive security policies for various operating systems and compliance frameworks (e.g., CIS Benchmarks, DISA STIGs). Without relevant and up-to-date content, <i>oscap</i> cannot perform meaningful security checks or generate compliance reports.


title: OUTPUT FORMATS
content:
After an evaluation, <i>oscap</i> can generate results and reports in several standardized and human-readable formats. These outputs are crucial for auditing, compliance reporting, and identifying areas for remediation:<br><ul><li><b>SCAP Results (ARF)</b>: The standardized SCAP-Results XML format (Asset Reporting Format), which contains all findings and evidence.</li><li><b>HTML Reports</b>: Human-readable reports, often generated from the ARF, providing a user-friendly summary viewable in a web browser.</li><li><b>OVAL Results XML</b>: Specific XML output containing the results of OVAL evaluations.</li><li><b>XCCDF Results XML</b>: Specific XML output containing the results of XCCDF evaluations, detailing rule applicability and compliance status.</li></ul>


title: HISTORY
content:
OpenSCAP is an open-source project primarily initiated and developed by Red Hat. Its genesis was rooted in the need for a standardized, automated approach to security configuration and compliance within Linux environments. The project was designed to implement and facilitate the use of the National Institute of Standards and Technology (NIST) Security Content Automation Protocol (SCAP) standards. Over the years, OpenSCAP and its command-line interface <i>oscap</i> have evolved into a robust framework, widely adopted in enterprise Linux distributions and government systems for automated security auditing, vulnerability management, and policy enforcement, demonstrating a strong commitment to open security standards and automation.


title: SYNOPSIS
content:
osmium <I>subcommand</I> [options] [arguments]<br>Example: <I>osmium fileinfo</I> <I>input.osm.pbf</I><br>Example: <I>osmium extract</I> <I>--bbox</I> -1.0,50.0,1.0,51.0 <I>input.osm.pbf</I> <I>-o</I> <I>output.osm.pbf</I>


title: PARAMETERS
content:
<b><I>subcommand</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the primary operation to perform. Each subcommand has its own specific options and arguments.<br><br><b>fileinfo</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about an OpenStreetMap (OSM) file, including header data, object counts, and bounding box.<br><br><b>extract</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extracts a subset of OSM data from a larger file based on criteria such as a bounding box, polygon, or a list of IDs.<br><br><b>tags-filter</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters OSM objects (nodes, ways, relations) based on their tags, allowing for precise data selection.<br><br><b>cat</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Concatenates multiple OSM input files into a single output file, with optional filtering.<br><br><b>sort</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sorts an OSM file by object ID or by geographical location, which can optimize subsequent processing steps.<br><br><b>diff</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compares two OSM files and outputs the differences as an OSM change file (.osc).<br><br><b>apply-changes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies changes specified in an OSM change file (.osc) to an existing OSM data file.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the main command or a specified subcommand.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version of the Osmium Tool being used.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information during processing.<br><br><b>--progress</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a progress bar for long-running operations.<br><br>


title: DESCRIPTION
content:
Osmium Tool is a versatile command-line utility designed for high-performance manipulation of OpenStreetMap (OSM) data. Built upon the efficient libosmium C++ library, it enables users to perform a wide array of operations on OSM data files in various formats, including PBF, XML, and O5M. Its capabilities encompass reading, writing, filtering, extracting subsets, sorting, and diffing OSM datasets. <br><br>It is an essential tool for GIS professionals, researchers, and developers who need to process, analyze, or convert large volumes of OSM data. Osmium Tool excels in handling planet-scale datasets efficiently due to its streaming architecture and optimized data structures, making it a cornerstone for many OSM data workflows, from simple format conversions to complex geographical extractions and data validation tasks.


title: CAVEATS
content:
Osmium Tool is highly optimized for performance and memory efficiency, especially when dealing with very large OpenStreetMap datasets (e.g., planet files). However, processing extremely large files still requires significant RAM, potentially tens of gigabytes. It is primarily a command-line tool, and while powerful, it lacks a graphical user interface. Users should be familiar with command-line operations and basic OpenStreetMap data structures. Installation typically requires compiling from source or using package managers on specific Linux distributions (e.g., <I>osmium-tool</I> package).


title: SUPPORTED FORMATS
content:
Osmium Tool supports various OSM file formats including PBF (Protocol Buffer Binary Format), XML (.osm), O5M/O5C, and can often output to CSV or JSON for specific data types. PBF is generally the most efficient format for large inputs and outputs.


title: STREAMING PROCESSING
content:
Many Osmium operations are designed to work in a streaming fashion. This allows the tool to process very large datasets, such as the full OSM planet file, without needing to load the entire dataset into memory simultaneously, significantly reducing memory footprint for large tasks.


title: HISTORY
content:
The Osmium library and subsequently the Osmium Tool were developed by Jochen Topf. Osmium originated as a high-performance C++ library (<I>libosmium</I>) designed to efficiently parse, read, and write OpenStreetMap PBF (Protocol Buffer Binary Format) files, which are the most common and efficient format for distributing OSM data. The Osmium Tool was built on top of <I>libosmium</I> to provide a user-friendly command-line interface for common OSM data manipulation tasks. Its development has been driven by the need for faster and more memory-efficient processing of the ever-growing OpenStreetMap dataset, becoming a staple in many OSM data workflows since its inception.


title: SYNOPSIS
content:
As 'ouch' is <b>not a standard command</b>, there is no universally defined synopsis. However, if one were to define a hypothetical simple script, it might look like: <br> `ouch [<i>options</i>] [<i>text</i>]`


title: PARAMETERS
content:
<b>-s, --severity <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Hypothetical)</i> Sets the severity level of the 'ouch' message (e.g., 1-5).<br><br><b>-m, --message <text></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Hypothetical)</i> Specifies custom text to be displayed instead of a default 'ouch' message.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Hypothetical)</i> Displays a help message and exits.<br><br>


title: DESCRIPTION
content:
The 'ouch' command is <b>not a standard or officially documented Linux utility</b>. It does not exist as a pre-installed command in typical Linux distributions. Its appearance or reference is almost exclusively due to user-defined aliases, custom scripts, or humorous contexts within the Linux community. <br><br>While not a real command, its name suggests a potential use case related to indicating pain, errors, or a negative outcome. For instance, a user might create an alias like `alias ouch='echo "Ouch! Something went wrong." '` or `alias ouch='sudo !!'` (a common humorous alias to repeat the last command with `sudo` after a permission denied error). <br><br>If it were a hypothetical command, it might be designed to output a specific 'pain' message, log an event, or trigger a notification upon encountering an error or an undesirable situation. Without a standard definition, any functionality associated with 'ouch' is entirely dependent on how an individual user or system administrator has defined it in their specific environment.


title: CAVEATS
content:
The 'ouch' command is <b>not a part of standard Linux distributions</b>. Attempting to run it without a custom alias or script defined will result in a 'command not found' error. Its behavior, if it exists, is entirely custom and specific to the environment where it's defined.


title: COMMON ALIASES AND USAGE EXAMPLES
content:
Given that 'ouch' is not a built-in command, its 'usage' comes from how users define it. <br><br><b>1. Simple output:</b> <br> `alias ouch='echo "Ouch!"'` <br> Running `ouch` would simply print 'Ouch!' to the terminal. <br><br><b>2. Repeat last command with sudo:</b> <br> `alias ouch='sudo !!'` <br> If a command fails due to permission denied, typing `ouch` would re-execute the previous command with `sudo`. This is a very common humorous use. <br><br><b>3. Custom script:</b> <br> A user might create a script named `ouch` in their PATH (e.g., `/usr/local/bin/ouch`) that performs more complex actions like logging an error, playing a sound, or sending a notification.


title: HISTORY
content:
The 'ouch' command does not have a formal development history as it is <b>not a standard Unix-like utility</b>. Its 'usage' is primarily anecdotal, emerging from user-defined shell aliases or small personal scripts. It often appears in discussions about humorous or convenient custom commands, particularly when a user wants a quick way to express frustration or react to a command failure, often by simply echoing 'Ouch!' or re-running a command with elevated privileges (e.g., `alias ouch='sudo !!'`). It represents a playful aspect of shell customization rather than a formal command evolution.


title: SYNOPSIS
content:
<B>chown</B> [<I>OPTION</I>...] <I>OWNER</I>[:<I>GROUP</I>] <I>FILE</I>...<br><B>chown</B> [<I>OPTION</I>...] :<I>GROUP</I> <I>FILE</I>...<br><B>chown</B> [<I>OPTION</I>...] --reference=<I>RFILE</I> <I>FILE</I>...


title: PARAMETERS
content:
<b>-c, --changes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Like --verbose but report only when a change is made.<br><br><b>-f, --silent, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress most error messages.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output a diagnostic for every file processed.<br><br><b>-R, --recursive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on files and directories recursively.<br><br><b>--from=<CURRENT_OWNER>:<CURRENT_GROUP></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Change the owner and/or group of each FILE only if its current owner and/or group match those specified.<br><br><b>--dereference</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Affect the referent of each symbolic link (this is the default).<br><br><b>--no-dereference</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not affect the referent of each symbolic link (useful only on systems that can change the ownership of a symlink).<br><br><b>--reference=<RFILE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use RFILE's owner and group rather than specifying OWNER:GROUP values.<br><br>


title: DESCRIPTION
content:
<I>The term <B>ownership</B> in Linux refers to the fundamental concept of associating files and directories with a specific user and a specific group. This association dictates who can read, write, and execute a file based on permissions. While there is no single Linux command named <B>ownership</B>, this critical aspect of the filesystem is managed and viewed using several commands.</I><br><br><I>The primary commands for manipulating ownership are <B>chown(1)</B> (change owner) and <B>chgrp(1)</B> (change group). File ownership can be viewed using the <B>ls -l</B> command. For the purpose of analyzing how ownership is handled in Linux, this analysis focuses on the <B>chown</B> command as the most comprehensive tool for altering both user and group ownership.</I>


title: CAVEATS
content:
<I>It is crucial to understand that <B>ownership</B> is a concept, not a direct command in Linux. The commands mentioned, particularly <B>chown</B> and <B>chgrp</B>, are the tools used to implement changes to this concept. Changing file ownership often requires superuser privileges (<B>root</B> or <B>sudo</B>) because it directly affects system security and access control. Using <B>chown -R</B> (recursive) on system directories incorrectly can lead to severe system instability or security vulnerabilities.</I>


title: <I>EXAMPLE USAGE</I>
content:
<I>To change the owner of <B>myfile.txt</B> to <B>john</B>:<br><B>sudo chown john myfile.txt</B><br><br>To change the owner to <B>john</B> and the group to <B>developers</B> for <B>mydir</B> and its contents recursively:<br><B>sudo chown -R john:developers mydir/</B><br><br>To change only the group of <B>anotherfile.txt</B> to <B>users</B>:<br><B>sudo chown :users anotherfile.txt</B></I>


title: HISTORY
content:
<I>The <B>chown</B> command has been a fundamental part of Unix-like operating systems since their early days. It's an integral component of the file permission system, designed to allow administrators and users (under certain conditions) to manage file access rights. Its functionality has remained largely consistent over decades, underscoring its essential role in system administration.</I>


title: SYNOPSIS
content:
<b>oxipng</b> <i>[options]</i> <i>&lt;files&gt;...</i><br><b>oxipng</b> <i>--help</i><br><b>oxipng</b> <i>--version</i>


title: PARAMETERS
content:
<b><b>-o</b>, <b>--opt</b> <i>&lt;level&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the optimization level from 0 (no compression) to 6 (full compression). Higher levels take longer but compress more. Default is 2.<br><br><b><b>-i</b>, <b>--interlace</b> <i>&lt;0|1&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the interlace method (0: no interlace, 1: Adam7 interlacing).<br><br><b><b>-Z</b>, <b>--strip</b> <i>&lt;safe|all&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes metadata chunks from the PNG. <i>safe</i> preserves color profiles (sRGB, iCCP), while <i>all</i> removes everything possible.<br><br><b><b>-s</b>, <b>--stdout</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the optimized image to standard output instead of a file.<br><br><b><b>-f</b>, <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overwrites existing output files without prompting for confirmation.<br><br><b><b>-t</b>, <b>--threads</b> <i>&lt;count&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of threads to use for optimization. Set to 0 to use all available CPU cores.<br><br><b><b>-z</b>, <b>--force-zopfli</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the use of Zopfli compression, which is slower but typically achieves better compression ratios.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about the optimization process and savings.<br><br><b><b>-a</b>, <b>--alpha</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to optimize the alpha channel by removing unused alpha or simplifying transparency where possible.<br><br><b><b>-P</b>, <b>--preserve</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Preserves file permissions and timestamps of the original file after optimization.<br><br>


title: DESCRIPTION
content:
<b>oxipng</b> is a modern, high-performance PNG optimizer written in Rust. Its primary goal is to reduce the file size of PNG images without any loss of quality, making it a truly lossless compression tool. It achieves this by applying various sophisticated optimization techniques, including different deflate compression strategies, intelligent filter choices, and bit depth reductions where possible. A key feature of <b>oxipng</b> is its ability to efficiently utilize multiple CPU cores for parallel processing, significantly speeding up optimization, especially for batches of images or very large files. It supports various optimization levels, allowing users to balance compression thoroughness against processing time. It's a popular choice for web developers, designers, and anyone looking to optimize image assets efficiently for web delivery or storage.


title: CAVEATS
content:
<b>oxipng</b> performs <i>lossless</i> optimization only; it will not convert image formats or apply lossy compression. While generally very fast, using the <b>--force-zopfli</b> option can significantly increase processing time for potentially better compression. For very large images or high optimization levels, memory consumption can be noticeable.


title: DEFAULT BEHAVIOR
content:
By default, <b>oxipng</b> overwrites the original file with the optimized version and uses an optimization level of 2. This level provides a good balance between compression effectiveness and processing speed.


title: BATCH PROCESSING
content:
<b>oxipng</b> is highly efficient for optimizing multiple PNG files simultaneously. It automatically utilizes available CPU cores when processing a list of files, making it ideal for optimizing entire directories of images.


title: HISTORY
content:
<b>oxipng</b> is a relatively modern utility, written in Rust, which differentiates it from older PNG optimizers by leveraging Rust's performance and concurrency features. It was developed to provide a fast, multi-threaded alternative to existing tools like <b>optipng</b> and <b>pngcrush</b>, focusing on efficient lossless compression for contemporary computing environments.


title: SYNOPSIS
content:
<b>p0f</b> [ <b>-i</b> <i>interface</i> ] [ <b>-r</b> <i>file</i> ] [ <b>-s</b> <i>file</i> ] [ <b>-o</b> <i>file</i> ] [ <b>-M</b> <i>count</i> ] [ <b>-F</b> <i>file</i> ] [ <b>-c</b> <i>size</i> ] [ <b>-N</b> ] [ <b>-L</b> ] [ <b>-u</b> <i>user</i> ] [ <b>-P</b> <i>file</i> ] [ <b>-C</b> <i>file</i> ] [ <b>-v</b> ] [ <b>-h</b> ]


title: PARAMETERS
content:
<b><b>-i</b> <i>interface</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network interface to listen on for live packet capture.<br><br><b><b>-r</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads packets from the specified <i>pcap</i> file instead of a live interface.<br><br><b><b>-s</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads a previously saved <i>p0f</i> state file, allowing for continuation of analysis.<br><br><b><b>-o</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the output to the specified file instead of standard output.<br><br><b><b>-M</b> <i>count</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum number of concurrent connections <i>p0f</i> will track.<br><br><b><b>-F</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads configuration directives from the specified file.<br><br><b><b>-c</b> <i>size</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum size of the fingerprint cache in number of entries.<br><br><b><b>-N</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables promiscuous mode on the listening interface. Use with caution as it may miss packets.<br><br><b><b>-L</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables MAC address lookups, useful for speeding up processing or when MAC data is not needed.<br><br><b><b>-u</b> <i>user</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Drops root privileges after initialization and runs as the specified user.<br><br><b><b>-P</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Persists current state to the specified file upon exit, which can be reloaded later with <b>-s</b>.<br><br><b><b>-C</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads custom fingerprint signatures from the specified file, extending <i>p0f</i>'s detection capabilities.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about packets and internal operations.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br>


title: DESCRIPTION
content:
<i>p0f</i> is a versatile passive OS fingerprinting tool that identifies the operating system, type, and sometimes applications (e.g., HTTP user-agent, SSH version) of remote hosts. It works by passively observing network traffic, analyzing subtle variations in TCP/IP stack implementations, HTTP headers, SSH banners, and other application-level data. Unlike active scanners, <i>p0f</i> does not send any packets, making it undetectable to the target.<br><br>It's highly valuable for network reconnaissance, security audits, incident response, and understanding network composition without generating network noise. <i>p0f</i> can also detect NAT devices, load balancers, and identify connection types, relying on an extensive database of signatures to provide accurate, real-time insights into network participants.


title: CAVEATS
content:
Passive OS fingerprinting is not always 100% accurate; it can be affected by network middleboxes (NATs, proxies, firewalls) that modify packet headers, or by highly customized TCP/IP stacks. Accuracy also depends on an up-to-date signature database. Running <i>p0f</i> for live capture usually requires root privileges or appropriate capabilities.


title: OUTPUT FORMAT
content:
<i>p0f</i> outputs detailed information for each identified connection, typically including:<br><b><I>cli</I></b> / <b><I>srv</I></b>: Denotes client or server.<br><b><I>ID</I></b>: Unique connection identifier.<br><b><I>src</I></b> / <b><I>dst</I></b>: Source/destination IP addresses and ports.<br><b><I>os</I></b>: Operating system and version.<br><b><I>dist</I></b>: IP distance (number of hops).<br><b><I>uptime</I></b>: Estimated system uptime.<br><b><I>raw_mtu</I></b>: Reported MTU.<br><b><I>link</I></b>: Link type (e.g., Ethernet, PPP).<br><b><I>p0f_info</I></b>: Additional details like NAT detection, load balancer, or specific application versions.


title: HISTORY
content:
<i>p0f</i> was originally developed by Michał Zalewski (lcamtuf), with the first version appearing around 2000. It quickly gained recognition for its innovative passive fingerprinting approach. Version 2 was a significant rewrite, improving on its predecessor. The current stable version, <i>p0f</i> v3, released in 2012, represents another complete rewrite from scratch, significantly enhancing its accuracy, performance, and expanding its capabilities to include application-level fingerprinting (like HTTP and SSH). It continues to be a go-to tool for stealthy network intelligence.


title: PARAMETERS
content:
<b>configure</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches an interactive configuration wizard to customize the Powerlevel10k prompt. This is the primary way to personalize the theme.<br><br><b>help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information and usage instructions for the Powerlevel10k command.<br><br><b>reload</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reloads the Powerlevel10k theme configuration from the <I>.p10k.zsh</I> file without requiring a shell restart.<br><br>


title: DESCRIPTION
content:
<b>Powerlevel10k</b> (often referred to as <b>p10k</b> due to its configuration command) is a feature-rich and exceptionally fast theme for the <I>Zsh</I> (Z Shell) shell. It aims to provide a beautiful, informative, and responsive command prompt that enhances the user's terminal experience.<br><br>Key features include dynamic prompt segments displaying information like Git status, current directory, time, battery level, and more. Its distinguishing characteristic is the <I>p10k configure</I> interactive wizard, which allows users to extensively customize the prompt's appearance, layout, and information displayed without manually editing configuration files.<br><br>Powerlevel10k is renowned for its low latency, even with many segments enabled, and its highly optimized rendering. It relies on <I>Nerd Fonts</I> for the display of various icons and glyphs, providing a visually rich interface.


title: CAVEATS
content:
<b>Powerlevel10k</b> is exclusively designed for the <I>Zsh</I> shell and will not work with other shells like Bash or Fish. <br>Full display of icons and glyphs requires a <I>Nerd Font</I> to be installed and configured in your terminal emulator. Without a Nerd Font, some prompt elements may appear as broken characters. <br>While highly optimized, extreme customization or the use of many complex segments can still have a minor impact on prompt rendering speed.


title: INSTALLATION
content:
Installation typically involves cloning the Powerlevel10k Git repository into a Zsh plugin directory (e.g., using a plugin manager like Oh My Zsh, Antigen, or Zplug). After installation, it needs to be sourced from your <I>.zshrc</I> file.


title: CONFIGURATION FILE
content:
The <I>p10k configure</I> wizard generates a configuration file named <I>.p10k.zsh</I> in your home directory. This file contains all your prompt settings and is automatically sourced by your <I>.zshrc</I> when Zsh starts.


title: HISTORY
content:
<b>Powerlevel10k</b> was created by Roman Perekhrest and first released in 2018. It quickly gained popularity as a successor to and alternative to other Zsh themes, particularly Powerlevel9k, by significantly improving performance and introducing the user-friendly interactive configuration wizard. Its focus on speed, extensive customization, and ease of setup contributed to its rapid adoption among Zsh users, establishing it as one of the most widely used Zsh themes.


title: SEE ALSO
content:
zsh(1), oh-my-zsh(1) (framework), starship(1) (alternative prompt), fonts(7) (general font information)


title: PARAMETERS
content:
<b>list-modules</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all configured PKCS#11 modules recognized by <i>p11-kit</i>.<br><br><b>list-tokens</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerates cryptographic tokens found in the configured PKCS#11 modules, displaying their labels and IDs.<br><br><b>extract</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extracts certificates and trust information (e.g., CA certificates, anchors) from configured modules. Common options include <i>--module</i>, <i>--filter</i>, <i>--login</i>, and <i>--format</i>.<br><br><b>dump</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps raw PKCS#11 object attributes from tokens. Useful for detailed inspection of keys, certificates, and other cryptographic objects. Supports options like <i>--module</i>, <i>--token</i>, <i>--filter</i>, and <i>--login</i>.<br><br><b>server</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs a daemon that proxies PKCS#11 operations over a socket, allowing applications to communicate with tokens remotely or in sandboxed environments.<br><br><b>generate-proxy-config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a configuration file for applications to easily connect to the <i>p11-kit</i> proxy module.<br><br><b>module-lookup</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Looks up details about a specific PKCS#11 module by name or path.<br><br><b>test-trust</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Tests certificate trust policy application and certificate chain validation using the system's trust store.<br><br><b>test-pkcs11</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs a series of tests against a specified PKCS#11 module to verify its functionality and compliance.<br><br>


title: DESCRIPTION
content:
<i>p11-kit</i> is a set of tools and a library designed to manage and make PKCS#11 modules accessible to applications. PKCS#11 is a standard for cryptographic tokens, such as smart cards and Hardware Security Modules (HSMs). <i>p11-kit</i> acts as a central proxy, aggregating multiple installed PKCS#11 modules into a single, unified interface. This allows applications to discover and utilize any available cryptographic token without needing to know the specific path or details of each individual module. It provides a robust configuration system, typically through files in <i>/etc/pkcs11/modules/</i>, to register and configure modules system-wide. Beyond module aggregation, <i>p11-kit</i> also integrates with the system's trust store, making certificates and trust anchors available through its PKCS#11 interface. It simplifies the deployment and use of cryptography across various applications, from web browsers to SSH clients, by centralizing cryptographic token management.


title: CAVEATS
content:
For <i>p11-kit</i> to function correctly, PKCS#11 module libraries must be properly configured via `.module` files in standard paths like <i>/etc/pkcs11/modules/</i>.<br>PIN prompts for cryptographic tokens often occur on the terminal where the command is executed, which might require specific handling for GUI applications.


title: HISTORY
content:
<i>p11-kit</i> was developed by Red Hat and first appeared around 2011-2012. Its creation addressed the fragmented nature of PKCS#11 module management on Linux systems, aiming to provide a unified framework for applications to discover and utilize cryptographic tokens. It rapidly became a fundamental component in many Linux distributions, including Fedora and RHEL, standardizing system-wide access to hardware and software cryptographic modules and integrating with the common trust store.


title: SYNOPSIS
content:
<b>p4</b> [<i>global_options</i>] <i>command</i> [<i>command_options</i>] [<i>command_arguments</i>]<br><br>The <i>p4</i> command typically starts with global options that define connection parameters or output format, followed by a specific Perforce command (e.g., "sync", "submit", "edit"), and then options and arguments relevant to that specific command.


title: PARAMETERS
content:
<b><b>-p</b> <i>host:port</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Perforce server address and port to connect to. Can also be set via the <i>P4PORT</i> environment variable.<br><br><b><b>-u</b> <i>username</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the username for the Perforce connection. Can also be set via the <i>P4USER</i> environment variable.<br><br><b><b>-c</b> <i>clientname</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the client workspace (or 'client spec') to use for operations. Can also be set via the <i>P4CLIENT</i> environment variable.<br><br><b><b>-H</b> <i>hostname</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the host name for the local machine, overriding the default determined by the client.<br><br><b><b>-Ztag</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produces tagged output, which is a structured, machine-readable format often used for scripting and parsing <i>p4</i> command output.<br><br><b><b>-d</b> <i>charset</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the character set for the client, used for internationalization. Can also be set via the <i>P4CHARSET</i> environment variable.<br><br><b><b>-r</b> <i>retries</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of connection retries to attempt if the server connection fails.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Silences informational messages, showing only errors and warnings.<br><br>


title: DESCRIPTION
content:
<i>p4</i> is the command-line client for Perforce Helix Core, a comprehensive version control and collaboration platform widely used for managing source code, large digital assets, and binary files in various industries, including game development, semiconductors, and software development. Unlike decentralized systems like Git, Perforce operates as a centralized version control system where all files and their history reside on a central server.<br><br>The <i>p4</i> client allows users to interact with the Helix Core server to perform essential SCM operations such as adding, editing, deleting, submitting, syncing, branching, merging, and viewing file history. It is particularly renowned for its performance in handling large numbers of files and very large file sizes, making it suitable for projects with massive repositories. The command-line interface provides granular control over workspace configuration, changelist management, and server administration.


title: CAVEATS
content:
Perforce is a centralized system, meaning a server connection is generally required for most operations. Network latency can significantly impact performance, especially over wide area networks. Understanding workspace views and stream definitions is crucial for effective use. Resolving conflicts, particularly with large binary files, can sometimes be challenging without proper tools or defined workflows. Its default atomic commit model can require careful planning for very large or complex changes.


title: ENVIRONMENT VARIABLES
content:
Many global options for <i>p4</i> can be conveniently set using environment variables, such as <i>P4PORT</i>, <i>P4USER</i>, <i>P4CLIENT</i>, and <i>P4CHARSET</i>. These variables define default connection parameters, reducing the need to specify them with every command and simplifying scripting.


title: COMMON WORKFLOWS
content:
Typical <i>p4</i> workflows involve using <i>p4 sync</i> to get the latest files from the server, <i>p4 edit</i> to open files for modification, <i>p4 add</i> or <i>p4 delete</i> for new or removed files, <i>p4 revert</i> to discard local changes, <i>p4 diff</i> to view changes, and finally <i>p4 submit</i> to commit changes to the server as an atomic changelist.


title: HISTORY
content:
Perforce Software, Inc. was founded in 1995, and the <i>p4</i> client has been the primary command-line interface for its Helix Core (formerly Perforce SCM) version control system since its inception. Initially developed to handle large and complex software development projects, Perforce gained significant traction for its robust performance with large binary files and its support for atomic change lists, which bundle multiple file modifications into a single, indivisible transaction. Over the years, it has evolved to incorporate features like streams (a branching/merging paradigm), shelving, and deep integration with various CI/CD pipelines, maintaining its reputation as a high-performance solution for enterprise-scale version control.


title: SYNOPSIS
content:
<i><br>As <b>p5</b> is not a standard Linux command, a universally applicable synopsis cannot be provided.<br>If it exists on a specific system, its syntax would be entirely dependent on its local implementation (e.g., a custom script or alias).</i>


title: PARAMETERS
content:
<b><i>(Not applicable)</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>As <b>p5</b> is not a standard command, there are no predefined or common parameters. Any parameters would be unique to a custom script or application if 'p5' refers to one.</i><br><br>


title: DESCRIPTION
content:
The command <b>p5</b> is not a standard or commonly recognized command within mainstream Linux distributions or Unix-like operating systems. Typically, when users encounter 'p5', it might be a typo for other common and widely used commands such as <b><I>ps</I></b> (for process status) or <b><I>pstree</I></b> (for displaying process trees). It could also potentially refer to a highly specific, custom-developed script or alias on a particular system, or an extremely obscure, deprecated utility from a very niche computing environment. Without further context, defining its exact functionality, synopsis, or parameters is not possible as a general Linux command. Users encountering 'p5' should investigate if it's a local script, an alias, or part of a specialized software package on their specific system.


title: CAVEATS
content:
<b>p5</b> is not a standard Linux command and attempting to execute it on most systems will result in a 'command not found' error. Its existence and behavior would be specific to custom configurations or highly specialized environments. Do not confuse 'p5' with <b><I>ps</I></b> (process status), <b><I>pstree</I></b> (process tree), <b><I>p5.js</I></b> (a JavaScript library for creative coding, which is not a shell command), or references to Perl 5 (where 'perl' is the command).


title: HISTORY
content:
Given that <b>p5</b> is not a standard Linux command, there is no documented history of its development or widespread usage within the open-source Unix/Linux community. Any instances of a command named 'p5' would likely be isolated to specific legacy systems, educational projects, or custom administrative scripts created by individual users or organizations, with their own undocumented histories. It is not part of the GNU Core Utilities or typical Unix system V/BSD distributions.


title: SEE ALSO
content:
ps(1) - report a snapshot of the current processes., pstree(1) - display a tree of processes., pgrep(1) - look up processes based on name or other attributes., pkill(1) - send signals to processes based on name or other attributes.


title: PARAMETERS
content:
<b><b>a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add files to an archive.<br><br><b><b>x</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extract files with full paths.<br><br><b><b>e</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extract files to the current directory (without paths).<br><br><b><b>l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List contents of an archive.<br><br><b><b>d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Delete files from an archive.<br><br><b><b>t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Test integrity of an archive.<br><br><b><b>u</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Update files in an archive.<br><br><b><b>b</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Benchmark the system's compression/decompression performance.<br><br><b><b>-o<i><Dir></i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify output directory for extracted files.<br><br><b><b>-p<i><Passwd></i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a password for archive creation or extraction.<br><br><b><b>-m<i><Method></i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set compression method (e.g., <i>-mlzma2</i>, <i>-mdeflate</i>).<br><br><b><b>-mx<i><Level></i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set compression level (0-9, <i>x0</i>=no, <i>x1</i>=fastest, <i>x9</i>=ultra).<br><br><b><b>-t<i><Type></i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set archive type (e.g., <i>-t7z</i>, <i>-tzip</i>, <i>-ttar</i>).<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recurse subdirectories when processing files.<br><br><b><b>-v<i><Size></i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create multivolume archives (e.g., <i>-v1g</i> for 1 GB volumes).<br><br><b><b>-y</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assume 'yes' to all queries (non-interactive).<br><br>


title: DESCRIPTION
content:
<b>p7zip</b> is the Unix/Linux port of the <i>popular</i> 7-Zip archive program, renowned for its <i>exceptionally high compression ratio</i>, especially with its native <b>.7z</b> format. It provides a command-line utility, typically invoked as <b>7z</b>, <b>7za</b>, or <b>7zr</b>, allowing users to create, extract, update, and manage archives.<br><br>Unlike many traditional Unix archivers, <b>p7zip</b> supports a wide array of archive formats, including <i>ZIP, GZIP, BZIP2, TAR</i>, and more, in addition to its highly efficient <b>7z</b> format. Its primary strength lies in its advanced compression algorithms, such as <i>LZMA and LZMA2</i>, which can significantly reduce file sizes, making it ideal for backups, distribution, and saving disk space. It's a versatile tool for both simple archival tasks and complex data management.


title: CAVEATS
content:
While <b>p7zip</b> offers excellent compression, high compression levels (e.g., <i>-mx=9</i>) can be <i>very CPU and RAM intensive</i>, leading to longer processing times. Compatibility with certain obscure or proprietary archive formats may vary. Always ensure you have sufficient disk space, especially when extracting large archives, as the original compressed size can be misleading.


title: SUPPORTED FORMATS
content:
<b>p7zip</b> supports a vast range of archive formats for both compression and decompression. For compression, it typically supports <i>7z, XZ, BZIP2, GZIP, TAR, ZIP</i>. For decompression, it extends to <i>ARJ, CAB, CHM, CPIO, CramFS, DEB, DMG, FAT, HFS, ISO, LZH, LZMA, MBR, MSI, NSIS, NTFS, RAR, RPM, SquashFS, UDF, VHD, WIM, XAR, Z</i>, and many others. This broad support makes it an incredibly versatile tool for handling almost any archive encountered on a Linux system.


title: DEFAULT COMPRESSION
content:
When creating a <b>.7z</b> archive, <b>p7zip</b> uses the <i>LZMA2</i> compression method by default. This method is highly optimized for performance and compression ratio, offering a good balance for most use cases without requiring explicit configuration of compression parameters.


title: HISTORY
content:
<b>p7zip</b> is the official port of Igor Pavlov's <i>7-Zip</i> archiver to POSIX-compliant operating systems like Unix, Linux, and macOS. The original 7-Zip project began in 1999 for Windows. <b>p7zip</b> provides the same powerful compression algorithms, notably LZMA and LZMA2, to a command-line interface suitable for scripting and server environments. It was developed to bring the benefits of 7-Zip's high compression and broad format support to the wider open-source community, maintaining feature parity where possible with its Windows counterpart.


title: SYNOPSIS
content:
<i>pacat</i> [<i>OPTIONS</i>] [<i>FILE</i>]<br><i>pacat</i> <b>-r</b> [<i>OPTIONS</i>] [<i>FILE</i>]


title: PARAMETERS
content:
<b><b>-p</b>, <b>--playback</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate in playback mode (default). Reads audio from a file or stdin and plays it.<br><br><b><b>-r</b>, <b>--record</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate in record mode. Captures audio from a source and writes it to a file or stdout.<br><br><b><b>-s</b>, <b>--server</b>=<i>SERVER</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connect to the PulseAudio/PipeWire server specified by <i>SERVER</i>.<br><br><b><b>-d</b>, <b>--device</b>=<i>DEVICE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the sink (for playback) or source (for recording) by its name or index.<br><br><b><b>-f</b>, <b>--format</b>=<i>FORMAT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the sample format (e.g., <i>s16le</i> for signed 16-bit little-endian, <i>s32le</i>, <i>u8</i>, <i>float32ne</i>).<br><br><b><b>-c</b>, <b>--channels</b>=<i>CHANNELS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the number of audio channels (e.g., <i>1</i> for mono, <i>2</i> for stereo).<br><br><b><b>-R</b>, <b>--rate</b>=<i>RATE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the sample rate in Hertz (e.g., <i>44100</i>, <i>48000</i>).<br><br><b><b>--fix-format</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempt to convert the stream to a format supported by the device.<br><br><b><b>--fix-channels</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempt to convert the stream to a channel count supported by the device.<br><br><b><b>--fix-rate</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempt to convert the stream to a sample rate supported by the device.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing more details about the operation.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br>


title: DESCRIPTION
content:
<i>pacat</i> is a command-line utility for playing or recording raw audio streams through a PulseAudio or PipeWire sound server.<br><br>In playback mode (default or via <i>-p</i>), it reads raw PCM audio data from standard input or a specified file and sends it to an audio sink (output device). In record mode (via <i>-r</i>), it captures raw PCM audio data from an audio source (input device) and writes it to standard output or a specified file.<br><br>It's an essential tool for developers and advanced users to debug audio setups, test specific audio stream configurations, or programmatically manipulate raw audio data. It requires precise specification of audio parameters such as sample format, rate, and channel count, though it can attempt to automatically adapt these to the device's capabilities.


title: CAVEATS
content:
<i>pacat</i> exclusively handles raw PCM audio data; it does not support compressed audio formats like MP3, Ogg, or FLAC. For playback or recording of such formats, tools like <i>paplay</i> or <i>parecord</i> (which utilize GStreamer or FFmpeg) are more appropriate. It requires a running PulseAudio or PipeWire server to function.


title: RAW AUDIO STREAM HANDLING
content:
Unlike higher-level tools, <i>pacat</i> operates directly on raw PCM audio data. This makes it ideal for scenarios where the exact audio format (sample rate, channels, bit depth) needs to be precisely controlled for testing, development, or specific audio processing pipelines.


title: PIPEWIRE COMPATIBILITY
content:
While originally designed for PulseAudio, <i>pacat</i> works flawlessly with PipeWire. PipeWire provides a PulseAudio compatibility layer, allowing existing PulseAudio clients and utilities, including <i>pacat</i>, to connect and interact with the PipeWire multimedia server without modification, ensuring backward compatibility and a smooth transition.


title: HISTORY
content:
<i>pacat</i> is an integral part of the PulseAudio project, which was initially released in 2004. It has served as a low-level interface for raw audio streaming with the PulseAudio sound server since its early days. With the advent of PipeWire, which aims to replace PulseAudio, JACK, and ALSA directly, <i>pacat</i> continues to function seamlessly thanks to PipeWire's robust PulseAudio compatibility layer. Its core functionality has remained consistent, focusing on direct raw audio manipulation.


title: SYNOPSIS
content:
<I>pacaur</I> <I>[options]</I> <I>[targets]</I><br><I>pacaur</I> <I>{-S | --sync}</I> <I>[options]</I> <I>[packages]</I><br><I>pacaur</I> <I>{-R | --remove}</I> <I>[options]</I> <I>[packages]</I><br><I>pacaur</I> <I>{-Q | --query}</I> <I>[options]</I> <I>[packages]</I><br><I>pacaur</I> <I>{-G | --getpkgbuild}</I> <I>[options]</I> <I>[packages]</I>


title: PARAMETERS
content:
<b><b>-S, --sync</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Synchronize packages, installing or upgrading them. Often combined with <I>-u</I> and <I>-y</I> for system updates.<br><br><b><b>-R, --remove</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove specified packages from the system, potentially with their dependencies.<br><br><b><b>-Q, --query</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Query the package database for information about installed packages or files.<br><br><b><b>-u, --sysupgrade</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Upgrade all installed packages that are out-of-date. Typically used with <I>-S</I> and <I>-y</I>.<br><br><b><b>-y, --refresh</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Download fresh package databases from the server. Always recommended before an upgrade.<br><br><b><b>-a, --aur</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include results from the Arch User Repository in searches (e.g., <I>pacaur -SsA</I>).<br><br><b><b>-i, --info</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show package information before performing an action (e.g., install).<br><br><b><b>-G, --getpkgbuild</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Download the <I>PKGBUILD</I> file for a specified package from the AUR without installing it.<br><br><b><b>--noedit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not open <I>PKGBUILD</I> files for editing before building.<br><br><b><b>--noconfirm</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bypass all confirmation prompts. Use with extreme caution as it can lead to unintended installations or removals.<br><br><b><b>--clean</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove old downloaded packages and build directories from the cache to free up disk space.<br><br>


title: DESCRIPTION
content:
<I>pacaur</I> was a popular command-line <I>AUR helper</I> for <I>Arch Linux</I>, designed to simplify the process of installing and managing packages from the <I>Arch User Repository</I> (AUR). It acted as a wrapper around <I>pacman</I> and the <I>makepkg</I> utility, automating the steps required to download PKGBUILDs, resolve dependencies, build packages, and install them.<br><br>Its interface was largely inspired by <I>pacman</I>, making it intuitive for users familiar with the official package manager. <I>pacaur</I> aimed to provide a secure and reliable way to interact with the AUR, offering features like PGP signature checking and an interactive review of PKGBUILDs before building. While widely adopted for its efficiency and ease of use, <I>pacaur</I>'s development ceased, primarily due to the deprecation of its dependency <I>cower</I> and a shift in AUR helper development towards tools like <I>yay</I> and <I>paru</I>. It is now considered unmaintained and should not be used for new installations.


title: CAVEATS
content:
<I>pacaur</I> is <I>deprecated</I> and <I>unmaintained</I>. Its upstream dependency, <I>cower</I>, is also no longer maintained. Using <I>pacaur</I> is strongly discouraged as it may lead to security vulnerabilities, broken builds due to outdated code, or incompatibility issues with recent Arch Linux changes. Users should migrate to actively maintained <I>AUR helpers</I> such as <I>yay</I> or <I>paru</I> for safe and reliable AUR package management.


title: PKGBUILD REVIEW FEATURE
content:
<I>pacaur</I> was designed with security in mind, offering users the ability to review the <I>PKGBUILD</I> file before building a package. This crucial feature allowed users to inspect the build instructions, source URLs, and installation steps for any malicious code or unintended actions, fostering a more secure interaction with the community-maintained AUR.


title: HISTORY
content:
<I>pacaur</I> emerged as a popular <I>AUR helper</I> for <I>Arch Linux</I> users seeking a streamlined way to manage packages from the <I>Arch User Repository</I>. It gained significant traction due to its robust feature set, <I>pacman</I>-like interface, and emphasis on security through <I>PKGBUILD</I> review and PGP signature verification. For a period, it was one of the most recommended AUR helpers in the Arch Linux community.<br><br>However, its development largely ceased around 2018-2019, primarily driven by the deprecation of its key dependency, <I>cower</I>, and the rise of newer, more actively developed AUR helpers like <I>yay</I> and <I>paru</I> written in Go and Rust respectively. The community gradually shifted away from <I>pacaur</I> due to concerns about unmaintained code and potential future compatibility or security issues. It is no longer advisable to use <I>pacaur</I> for managing AUR packages.


title: DESCRIPTION
content:
<I>pacdiff</I> is a utility from the <I>pacman-contrib</I> package for Arch Linux. Its primary function is to help system administrators manage configuration file changes after a system upgrade or package installation.<br><br>When <I>pacman</I> updates a package, it may encounter situations where a configuration file provided by the package has changed, but the user has also modified their local version of that file. To prevent overwriting user customizations, <I>pacman</I> saves the new package version as a <B>.pacnew</B> file (e.g., <I>foo.conf.pacnew</I>) or saves the user's old version as a <B>.pacsave</B> file. <I>pacdiff</I> scans for these files (as well as <B>.pacorig</B> files, though less common) and presents them to the user, typically opening them in a diff viewer (like <I>vimdiff</I>, <I>meld</I>, or standard <I>diff</I>) to allow for merging, keeping the old/new version, or deleting the temporary file. This ensures that system configuration files are kept up-to-date while preserving user-specific modifications.


title: CAVEATS
content:
<ul><li>Requires manual intervention for each detected configuration file, which can be time-consuming after large upgrades.</li><li>Incorrectly merging or choosing the wrong version of a configuration file can lead to system instability or broken functionality.</li><li><I>pacdiff</I> relies on environment variables like <B>DIFFPROG</B>, <B>EDITOR</B>, or <B>PAGER</B> being set. If these are not configured to an interactive diff tool (e.g., <I>vimdiff</I>, <I>meld</I>), the default behavior might be less user-friendly (e.g., standard <I>diff</I> output followed by <I>less</I>).</li></ul>


title: HOW IT WORKS
content:
<I>pacdiff</I> scans key system directories, most notably <I>/etc</I>, for files ending with <B>.pacnew</B>, <B>.pacsave</B>, and <B>.pacorig</B>. For each such file found, it identifies its original counterpart and then typically prompts the user with a set of options.


title: INTERACTIVE PROMPT OPTIONS
content:
When <I>pacdiff</I> finds a modified configuration file, it presents a prompt. Common options include:<br><ul><li><B>y</B>: View the differences between the current file and the .pacnew/.pacsave file in the configured diff program.</li><li><B>n</B>: Skip this file and proceed to the next one.</li><li><B>v</B>: View the file in a pager (e.g., <I>less</I>) without opening a diff tool.</li><li><B>d</B>: Delete the <B>.pacnew</B> or <B>.pacsave</B> file, effectively keeping the current version and discarding the new/old package version.</li><li><B>q</B>: Quit <I>pacdiff</I>.</li></ul>


title: CONFIGURING DIFF PROGRAM
content:
The behavior of <I>pacdiff</I> when viewing differences is determined by environment variables, in order of precedence:<br><ul><li><B>DIFFPROG</B>: If set, <I>pacdiff</I> will use this command (e.g., <I>DIFFPROG=vimdiff pacdiff</I> or globally setting it in your shell profile).</li><li><B>EDITOR</B>: If <B>DIFFPROG</B> is not set, <I>pacdiff</I> falls back to using the program specified by <B>EDITOR</B> (e.g., <I>EDITOR=vim</I>).</li><li><B>PAGER</B>: If neither <B>DIFFPROG</B> nor <B>EDITOR</B> is set, it may use <B>PAGER</B> for viewing.</li><li>Default: If none of the above are set, <I>pacdiff</I> will typically use standard <I>diff</I> for comparisons and <I>less</I> for viewing. For an interactive and efficient workflow, setting <B>DIFFPROG</B> to a visual diff tool like <I>vimdiff</I>, <I>meld</I>, or <I>kdiff3</I> is highly recommended.</li></ul>


title: HISTORY
content:
<I>pacdiff</I> is an integral part of the <I>pacman-contrib</I> package, which provides a collection of helpful scripts and tools for the Arch Linux package manager, <I>pacman</I>. It has been a standard utility for Arch Linux users for many years, evolving alongside <I>pacman</I> to address the crucial aspect of configuration file management during system updates. Its design is minimalist, focusing on identifying the relevant files and then delegating the actual merging or comparison work to external diff programs configured by the user.


title: PARAMETERS
content:
<b><b>-c</b>, <b>--color</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Color nodes in the graph based on package type (e.g., base, explicitly installed, required, unrequired) for better visual distinction.<br><br><b><b>-d</b> <I>file</I>, <b>--dotfile</b>=<I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output file path for the generated <I>.dot</I> graph description. This file can then be processed by <I>Graphviz</I> tools.<br><br><b><b>-o</b> <I>file</I>, <b>--output</b>=<I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Directly specify the output file path for the final rendered image (e.g., PNG, SVG). This option requires the <I>dot</I> command to be available in the system's PATH.<br><br><b><b>-s</b> <I>size</I>, <b>--size</b>=<I>size</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the maximum size of the output graph image. Useful for controlling output dimensions, especially for very large graphs.<br><br><b><b>-t</b>, <b>--transitive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include transitive dependencies in the graph, showing not just direct dependencies but also dependencies of dependencies, and so on.<br><br><b><b>-u</b>, <b>--upto</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate a graph showing packages that depend on the specified target packages (reverse dependencies).<br><br><b><b>-w</b>, <b>--web</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate an interactive HTML web page with the graph, allowing for zooming and panning within a web browser.<br><br><b><b>-?</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show program's version number and exit.<br><br>


title: DESCRIPTION
content:
<i>pacgraph</i> is a powerful Python-based utility designed for Arch Linux users to visually represent their installed package dependencies. It leverages the <I>Graphviz</I> suite to generate graphical layouts from package relationship data. Users can choose to display direct and transitive dependencies, or explore reverse dependencies (which packages depend on a given one). This tool is invaluable for understanding the complex web of inter-package relationships on a system, helping to identify orphaned packages, visualize the impact of removing software, or simply gain insight into the system's structure. <br><br>The output is typically a <I>.dot</I> file, a plain text graph description language, which can then be rendered into various image formats like PNG, SVG, or JPEG using the <I>dot</I> command from Graphviz. It can also generate interactive web pages for exploration.


title: CAVEATS
content:
Generating a graph of an entire system can result in a very large and complex image, which may be slow to render or difficult to interpret visually. For large systems, it's often more effective to generate graphs for specific subsets of packages or use the interactive web output. <br><br>The quality and readability of the generated graphs heavily depend on the underlying <I>Graphviz</I> installation and its algorithms.


title: REQUIREMENTS
content:
<I>pacgraph</I> requires the <I>Graphviz</I> package (specifically the <I>dot</I> command) to be installed on the system to render the generated <I>.dot</I> files into image formats or interactive web pages. Without <I>Graphviz</I>, <I>pacgraph</I> can only output the raw <I>.dot</I> graph description files.


title: BASIC USAGE EXAMPLE
content:
To generate a PNG image of your system's package dependencies:<br><code><b>pacgraph -d system_deps.dot && dot -Tpng system_deps.dot -o system_deps.png</b></code><br><br>To generate an interactive web page:<br><code><b>pacgraph --web > index.html</b></code>


title: HISTORY
content:
<I>pacgraph</I> was developed as a complementary tool for Arch Linux's <I>pacman</I> package manager. Its creation aimed to provide a visual understanding of the package ecosystem, which is often challenging to grasp from text-based dependency listings alone. It leverages the robust and widely used <I>Graphviz</I> software, building upon its graph visualization capabilities to offer a more intuitive perspective on package relationships.


title: PARAMETERS
content:
<b><b>-</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When specified as the first argument, <i>pack</i> displays the percentage of reduction for each file and a checksum of the input and output files.<br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces compression even if it does not result in a smaller file, or if the file is already packed. By default, <i>pack</i> will not compress a file if the packed version is not smaller than the original.<br><br><b><b>-o</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;If a packed file (e.g., <i>name.z</i>) already exists, <i>pack</i> will overwrite it. Without this option, <i>pack</i> will exit with an error if the target <i>.z</i> file already exists.<br><br>


title: DESCRIPTION
content:
<i>pack</i> is an older Unix utility designed to compress files using Huffman coding. It aims to reduce file size by encoding frequently occurring characters with shorter bit sequences. When a file is packed, its original content is replaced by the compressed version, and the filename gains a <i>.z</i> suffix (e.g., <i>file.txt</i> becomes <i>file.txt.z</i>). <i>pack</i> is typically used for individual files, unlike archivers like <i>tar</i> which group multiple files.<br><br>While historically significant, it has largely been superseded by more efficient compression algorithms and tools like <i>gzip</i>, <i>bzip2</i>, and <i>xz</i>, which offer much better compression ratios and speed. It remains available on some systems primarily for compatibility with legacy data and files.


title: CAVEATS
content:
<b>Obsolescence:</b> <i>pack</i> is largely obsolete and has been replaced by modern compression tools (e.g., <i>gzip</i>, <i>bzip2</i>, <i>xz</i>) due to its inferior compression ratios and generally slower performance.<br><b>Single File:</b> It only compresses one file at a time; it does not archive or combine multiple files.<br><b>In-place Replacement:</b> The original file is deleted and replaced by its <i>.z</i> version. Always ensure you have backups if the original file is critical.<br><b>Limited Options:</b> Offers very few control options for compression level or algorithm, unlike modern compressors.


title: OUTPUT FILE EXTENSION
content:
Files compressed with <i>pack</i> typically gain a <i>.z</i> extension (e.g., <i>document.txt</i> becomes <i>document.txt.z</i>).


title: HISTORY
content:
<i>pack</i> was introduced in <b>UNIX Version 7</b> in the late 1970s, making it one of the earliest standard file compression utilities available on Unix-like systems. It utilized Huffman coding, a then-novel approach for data compression. For many years, it was a common tool for saving disk space, alongside <i>compress</i>.<br><br>However, with the advent of more sophisticated and efficient algorithms and the development of tools like <i>gzip</i> (based on DEFLATE) in the early 1990s, <i>pack</i> gradually fell out of favor due to its comparatively poor compression ratio and slower performance on larger files. While still available on some systems for backward compatibility, its practical use has largely ceased.


title: SYNOPSIS
content:
packer <command> [options] [arguments]<br><br><i>Examples:</i><br><code>packer build example.pkr.hcl</code><br><code>packer validate template.json</code>


title: PARAMETERS
content:
<b>-color=<true|false></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls colorized output from <i>Packer</i>. Defaults to <b>true</b>.<br><br><b>-machine-readable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs <i>Packer</i> log lines in a machine-readable format, useful for programmatic consumption.<br><br><b>-timestamp-format=<format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Go time format for timestamps in machine-readable output (e.g., '2006-01-02T15:04:05Z07:00').<br><br>


title: DESCRIPTION
content:
<i>Packer</i> is an open-source tool developed by <i>HashiCorp</i> for creating identical machine images from a single source configuration. It automates the generation of various types of machine images, including AMIs for AWS, VHDs for Azure, VMDKs for VMware, and Docker images, among others. The primary goal of <i>Packer</i> is to enable reproducible and consistent infrastructure by allowing organizations to create "golden images" that are pre-configured with operating systems, software, security patches, and application dependencies. This approach significantly reduces deployment time, minimizes configuration drift, and ensures environments are consistent from development to production.<br><br><i>Packer</i> uses a JSON or HCL (HashiCorp Configuration Language) template to define the image creation process. A template consists of three main components: <b>builders</b>, which define the target platforms (e.g., AWS EC2, VirtualBox); <b>provisioners</b>, which install and configure software on the running machine during the build process (e.g., Shell scripts, Ansible, Chef); and <b>post-processors</b>, which take the output of a builder and process it further (e.g., compressing an image, uploading to a repository). This modular design makes <i>Packer</i> highly flexible and extensible, integrating with a wide array of cloud providers, virtualization technologies, and configuration management tools.


title: CAVEATS
content:
Building images with <i>Packer</i> can be resource-intensive, requiring significant CPU, memory, and network bandwidth, especially for large images or multiple parallel builds.<br><br>While <i>Packer</i> automates image creation, it requires a solid understanding of the underlying cloud or virtualization platform and the provisioning tools being used.<br><br>Debugging failed builds can be challenging as issues often occur within the guest operating system or provisioning scripts, requiring detailed logging and iterative refinement.


title: TEMPLATE COMPONENTS
content:
<i>Packer</i> templates, written in JSON or HCL, define the entire image build process. They primarily consist of: <br><b>Builders</b>: Define the target platform (e.g., AWS EC2, VirtualBox) and how the base image is initially spun up. <br><b>Provisioners</b>: Install and configure software on the running instance during the build. Common provisioners include shell scripts, Ansible, Chef, and Puppet. <br><b>Post-processors</b>: Take the output of a builder (the created image) and perform additional actions, such as compressing it, uploading it to a specific registry, or converting it to another format.


title: IMMUTABILITY AND CONSISTENCY
content:
<i>Packer</i> promotes the concept of "immutable infrastructure." Once an image is built, it is not modified; any updates or changes necessitate building a new, updated image. This approach ensures consistency across environments, simplifies rollbacks (by deploying an older image), and reduces configuration drift, making deployments more reliable and predictable.


title: KEY SUB-COMMANDS
content:
<i>Packer</i>'s functionality is accessed via various sub-commands, each serving a specific purpose in the image building workflow:<br><b>build</b>: The primary command for executing a template and building machine images.<br><b>init</b>: Initializes a configuration directory by downloading necessary plugins.<br><b>validate</b>: Checks the syntax and validity of a <i>Packer</i> template without performing a build.<br><b>inspect</b>: Provides a summary of the builders, provisioners, and post-processors defined in a template.<br><b>fmt</b>: Formats <i>Packer</i> HCL configuration files to a canonical style.<br><b>version</b>: Displays the <i>Packer</i> version and plugin versions.


title: HISTORY
content:
<i>Packer</i> was first released by <i>HashiCorp</i> in 2013. Its development was driven by the need to streamline the creation of consistent, immutable infrastructure across diverse environments. Before <i>Packer</i>, teams often managed disparate image creation processes for different platforms, leading to "image sprawl" and inconsistencies. <i>Packer</i> offered a unified workflow and template language to address this, quickly gaining traction in DevOps and cloud engineering communities. Over time, it has evolved to support a broader range of builders (e.g., cloud platforms, containers, serverless runtimes) and provisioners, and adopted <i>HashiCorp Configuration Language (HCL2)</i> for enhanced template readability and maintainability.


title: SYNOPSIS
content:
<b>packtpub</b> [<i>options</i>] [<i>subcommand</i>] [<i>arguments</i>]<br><br><i>Common invocation examples:</i><br><b>packtpub login</b><br><b>packtpub claim</b><br><b>packtpub download</b> <i><product_id></i> <b>--format</b> <i>pdf</i><br><b>packtpub list</b>


title: PARAMETERS
content:
<b><b>login</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Authenticates the user with Packt Publishing using provided credentials (email/password). This command typically stores authentication tokens for subsequent operations.<br><br><b><b>claim</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Claims the current daily free ebook or video offer, adding it to the user's library. This prevents missing out on daily freebies.<br><br><b><b>download</b> <i><product_id></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Downloads a specific product from the user's claimed library using its unique identifier. The <i><product_id></i> is usually obtained from the <b>list</b> command or the Packt website URL.<br><br><b><b>list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a comprehensive list of all products currently claimed by the user in their Packt library, often including product IDs, titles, and available formats.<br><br><b><b>--format</b> <i><format></i>, <b>-f</b> <i><format></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the desired download format for ebooks (e.g., <i>pdf</i>, <i>epub</i>, <i>mobi</i>) or for videos. Not all products are available in all formats; the tool will usually default to the best available or a common one.<br><br><b><b>--output</b> <i><directory></i>, <b>-o</b> <i><directory></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Designates the local directory where downloaded files will be saved. If not specified, a default directory (often the current working directory or a configured location) is used.<br><br><b><b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with subcommands like <b>download</b> to indicate that all claimed products should be downloaded, or with <b>claim</b> to claim all currently available free offers if applicable (e.g., for a limited-time bundle).<br><br><b><b>--verbose</b>, <b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of the output, displaying more detailed information about the command's execution, progress, and potential debugging messages.<br><br><b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message for the command or a specific subcommand, showing available options, arguments, and usage examples.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the version information of the <b>packtpub</b> utility being used.<br><br>


title: DESCRIPTION
content:
The <b>packtpub</b> command refers to community-developed command-line tools designed to automate interaction with Packt Publishing's daily free learning offers and existing library. These utilities typically allow users to log in to their Packt account, automatically claim the daily free ebook or video, and download previously claimed content in various formats like PDF, EPUB, MOBI, and video files. While not a standard Linux system command, <b>packtpub</b> tools fill a niche for users who wish to programmatically manage their Packt library without navigating the website. They are often written in scripting languages like Python and require user credentials for authentication. The primary goal is to simplify the process of acquiring and organizing digital content from Packt Publishing's offerings.


title: CAVEATS
content:
The <b>packtpub</b> command is not a standard, pre-installed Linux utility; it typically refers to community-developed Python scripts or similar tools. <br>Its functionality is highly dependent on Packt Publishing's website structure and APIs, meaning updates to the Packt site can break the tool's operation, requiring updates from the script maintainers. <br>Users must provide their Packt account credentials, which should be handled securely, ideally via environment variables or a secure configuration method rather than hardcoding. <br>While designed for free content, aggressive or excessive use might trigger rate limiting or IP blocking by Packt's servers, although this is rare for normal usage.


title: INSTALLATION
content:
As <b>packtpub</b> is not a standard system command, it typically needs to be installed manually. This usually involves cloning a Git repository (e.g., from GitHub) and installing Python dependencies using <b>pip</b>. For example: <br><i>git clone https://github.com/someuser/packtpub-cli.git</i><br><i>cd packtpub-cli</i><br><i>pip install -r requirements.txt</i><br>Users often symlink the main script to a directory in their PATH, like <b>/usr/local/bin</b>, to make it globally accessible and callable as just '<b>packtpub</b>'.


title: CONFIGURATION AND CREDENTIALS
content:
The first step after installation is typically to configure the tool with your Packt Publishing account credentials (email and password). This is usually done via a <b>packtpub login</b> subcommand, which may prompt for credentials interactively or read them from environment variables or a secure configuration file. It's crucial to ensure these credentials are stored securely, ideally using a system's keyring or encrypted configuration.


title: TYPICAL WORKFLOW
content:
A common workflow for the <b>packtpub</b> command involves: <br>1. <b>Login:</b> Authenticate your session using <i>packtpub login</i> <br>2. <b>Claim daily free offer:</b> Regularly run <i>packtpub claim</i> to add new free titles to your library. <br>3. <b>List claimed products:</b> Use <i>packtpub list</i> to see what's in your library and their IDs. <br>4. <b>Download specific product:</b> Retrieve content using <i>packtpub download <product_id> --format pdf</i>. <br>5. <b>Automate with cron:</b> Many users schedule <i>packtpub claim</i> to run daily via <b>cron</b> to never miss a free offer.


title: HISTORY
content:
The concept of a 'packtpub' command-line utility emerged from the Packt Publishing 'Free Learning' initiative, which offers a daily free ebook or video. Users sought to automate the manual process of claiming these free titles. Independent developers, primarily within the open-source community, began creating scripts (most notably in Python) to achieve this. These tools gained popularity around the mid-2010s, with various implementations appearing on platforms like GitHub, each attempting to provide a robust and user-friendly interface for managing Packt's free offerings. The tools evolve as Packt's website and API change to maintain compatibility.


title: PARAMETERS
content:
<b>init</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initializes a new <i>packwiz</i> modpack in the current directory, setting up the basic configuration files.<br><br><b>refresh</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates all mods in the modpack based on their <i>.pw-mod</i> definitions, downloading or updating files as needed.<br><br><b>add <i>&lt;mod-id&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a new mod to the modpack, creating a <i>.pw-mod</i> file for it. Supports various platforms (CurseForge, Modrinth).<br><br><b>remove <i>&lt;mod-id&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes a mod from the modpack and its associated <i>.pw-mod</i> file.<br><br><b>update [<i>&lt;mod-id&gt;</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates a specific mod or all mods to their latest compatible versions, as specified by their <i>.pw-mod</i> files.<br><br><b>generate</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a distributable modpack archive (e.g., <i>.mrpack</i> or <i>.zip</i>) for release and distribution.<br><br><b>serve</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts a local HTTP server to serve the modpack for clients using the <i>packwiz</i> launcher or similar tools.<br><br><b>curseforge / modrinth</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Platform-specific subcommands for operations like importing existing modpacks or managing project data from CurseForge or Modrinth.<br><br>


title: DESCRIPTION
content:
<i>packwiz</i> is a command-line utility designed for managing Minecraft modpacks in a declarative and Git-friendly manner. It allows modpack developers to specify their mod lists and configurations using small, human-readable files (e.g., <i>.pw-mod</i>) instead of directly including large mod binaries in version control. This approach facilitates easy collaboration, versioning, and distribution of modpacks. <i>packwiz</i> automates the process of downloading, updating, and generating distributable modpack archives (like <i>.mrpack</i> files) from platforms such as CurseForge and Modrinth, ensuring reproducible builds and streamlined development workflows. It's a powerful tool for both individual modpack creators and large development teams.


title: CAVEATS
content:
<i>packwiz</i> primarily manages modpack definitions; a separate Minecraft launcher (e.g., MultiMC, Prism Launcher, or the <i>packwiz</i> launcher) is required to actually run the generated modpack. An active internet connection is necessary for downloading mods and updates. Familiarity with Git is beneficial for leveraging its version control capabilities for modpack development.


title: DECLARATIVE MODPACK DEFINITION
content:
Unlike tools that directly store mod binaries, <i>packwiz</i> uses small <i>.pw-mod</i> files containing metadata (like mod ID, file ID, download URL, checksum) to define each mod. This makes modpack repositories extremely small and easy to version control with Git.


title: CROSS-PLATFORM COMPATIBILITY
content:
<i>packwiz</i> is written in Go, providing native binaries for Windows, macOS, and Linux, ensuring consistent behavior across different operating systems without requiring a specific runtime environment like Java (for <i>packwiz</i> itself).


title: HISTORY
content:
<i>packwiz</i> emerged as a modern solution to the challenges of managing large, binary-heavy Minecraft modpacks with traditional version control systems. Its development focused on creating a lightweight, declarative, and Git-friendly alternative to previous methods, allowing for easier collaboration, automated updates, and more reliable modpack distribution. It has gained significant traction in the Minecraft modding community for its robust and efficient approach.


title: SYNOPSIS
content:
<b>pacman</b> <I>operation</I> [<i>options</i>] [<i>targets</i>]<br><br>Common operations include:<br>  <b>pacman -S</b> [<i>options</i>] <i>package(s)</i>  (Sync/Install)<br>  <b>pacman -R</b> [<i>options</i>] <i>package(s)</i>  (Remove)<br>  <b>pacman -U</b> [<i>options</i>] <i>package(s)</i>  (Upgrade/Install local)<br>  <b>pacman -Q</b> [<i>options</i>] <i>package(s)</i>  (Query)<br>  <b>pacman -F</b> [<i>options</i>] <i>file(s)</i>      (Files query)


title: PARAMETERS
content:
<b><b>-S</b>, <b>--sync</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Synchronizes packages with remote repositories. Used for installing new packages (e.g., <I>pacman -S package</I>), refreshing package databases (<I>pacman -Sy</I>), or performing a full system upgrade (<I>pacman -Syu</I>).<br><br><b><b>-R</b>, <b>--remove</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes packages from the system. Can also remove dependencies no longer required by other installed packages (e.g., <I>pacman -Rs package</I>) or configuration files (<I>pacman -Rns package</I>).<br><br><b><b>-U</b>, <b>--upgrade</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs or upgrades a package from a local file (e.g., a downloaded .pkg.tar.zst file). Useful for custom-built packages or those not in official repositories. Example: <I>pacman -U /path/to/package-1.0-1.pkg.tar.zst</I>.<br><br><b><b>-Q</b>, <b>--query</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Queries the local package database for installed packages. Used to list installed packages (<I>pacman -Q</I>), show detailed information about a package (<I>pacman -Qi package</I>), or list files owned by a package (<I>pacman -Ql package</I>).<br><br><b><b>-F</b>, <b>--files</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Queries the remote files database to find which package owns a specific file, or to search for files within packages. Example: <I>pacman -F /usr/bin/ls</I>.<br><br><b><b>-D</b>, <b>--database</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs various database maintenance tasks, such as checking package integrity, verifying dependencies, or changing the install reason of a package (e.g., marking as explicitly installed or a dependency).<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <i>pacman</i> version and build information.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a short help message with common command-line options and their usage.<br><br>


title: DESCRIPTION
content:
<i>pacman</i> (Package Manager) is the default package manager for Arch Linux and its derivatives. Written in C, it's designed to be simple, fast, and easy to use. It manages software packages, dependencies, and updates through a local database synchronized with remote repositories.<br><br>It combines a simple binary package format with an easy-to-use build system (<i>makepkg</i>), enabling users to build packages from source or install pre-compiled binaries. <i>pacman</i> efficiently handles package installation, removal, upgrades, and queries, making system maintenance straightforward in a rolling release environment.


title: CAVEATS
content:
Most <i>pacman</i> operations (installation, removal, system updates) require root privileges, typically invoked with <i>sudo</i>.<br><br>Partial upgrades are not supported and can lead to system instability; always perform a full system synchronization and update using <I>pacman -Syu</I>.<br><br>As Arch Linux is a rolling release, regular updates are crucial to maintain a stable and secure system, and to benefit from the latest features and bug fixes.


title: ROLLING RELEASE MODEL
content:
Arch Linux operates on a rolling release model, meaning there are no distinct 'versions' of the operating system. Instead, <i>pacman -Syu</i> continuously updates the system with the latest software and libraries, ensuring users always have access to the most current stable software without reinstallations.


title: ARCH USER REPOSITORY (AUR)
content:
While <i>pacman</i> directly manages packages from official repositories, the Arch User Repository (AUR) is a community-driven collection of PKGBUILD scripts that allow users to compile and install software not available in the official repos. Users often employ 'AUR helpers' (e.g., <i>yay</i>, <i>paru</i>) to automate the process of building and installing AUR packages, which internally leverage <i>makepkg</i> and <i>pacman</i>.


title: CONFIGURATION
content:
<i>pacman</i>'s behavior, including repository definitions, mirror lists, and various system-wide options (e.g., `Color`, `ParallelDownloads`), is configured via the <I>/etc/pacman.conf</I> file. Users can customize this file to tailor <i>pacman</i>'s operation to their specific needs and location.


title: HISTORY
content:
<i>pacman</i> was initially developed by Judd Vinet, the founder of Arch Linux, and first released in 2002. It was designed from the ground up to be the core package manager for Arch Linux, emphasizing simplicity, speed, and user control over the system. Written in C, it has remained central to Arch Linux's design philosophy, constantly evolving alongside the distribution while maintaining its core principles.


title: SYNOPSIS
content:
<b>pactree</b> [<i>options</i>] <i>&lt;package_name&gt;</i> [<<i>package_name</i>>...]<br>Specifically for depth:<br><b>pactree</b> {<b>-d</b> | <b>--depth</b>} <i>&lt;depth&gt;</i> [<i>options</i>] <i>&lt;package_name&gt;</i>


title: PARAMETERS
content:
<b><b>-d</b>, <b>--depth</b> <i>&lt;depth&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Limits the traversal depth of the dependency tree to the specified non-negative integer.</i><br><br><b><b>-r</b>, <b>--reverse</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays reverse dependencies (i.e., which packages depend on the specified package).</i><br><br><b><b>-u</b>, <b>--unique</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Shows each unique package only once, useful for large trees.</i><br><br><b><b>-s</b>, <b>--sync</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Includes sync dependencies from the configured repositories, not just installed packages.</i><br><br><b><b>-l</b>, <b>--linear</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Produces a linear, non-indented output, listing dependencies sequentially.</i><br><br><b><b>-c</b>, <b>--color</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enables colorized output for better readability.</i><br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Suppresses non-essential output, showing only the tree itself.</i><br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays a brief help message and exits.</i><br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Shows version information and exits.</i><br><br>


title: DESCRIPTION
content:
The command "pacman-d" is not a standard, standalone Linux command. It is highly probable that this refers to the usage of the <br> <b>pactree</b> utility with its <br> <b>-d</b> or <br> <b>--depth</b> option. <br><br><b>pactree</b> is a powerful tool within the Arch Linux ecosystem, specifically part of the <br> <b>pacman-contrib</b> package. Its primary function is to visualize the dependency tree of specified packages managed by <br> <b>pacman</b>. This is invaluable for understanding how different software components relate to each other, identifying direct and indirect dependencies, and debugging dependency-related issues. <br><br>When used with the <br> <b>-d &lt;depth&gt;</b> option, <br> <b>pactree</b> limits the traversal of the dependency graph to the specified numerical depth. For instance, <br> <b>-d 1</b> would show only immediate dependencies, <br> <b>-d 2</b> would show immediate dependencies and their immediate dependencies, and so on. This feature is particularly useful for focusing on specific layers of dependencies without being overwhelmed by a very large or deep tree. <br><br>The output typically presents a neatly indented, hierarchical view, making it easy to discern parent-child relationships between packages. It queries the local <br> <b>pacman</b> database to construct these trees, providing an accurate representation of the installed system's package structure.


title: CAVEATS
content:
The command "pacman-d" as a standalone executable does not exist in standard Linux distributions. This analysis assumes the request refers to the common usage of <br> <b>pactree -d</b> within the Arch Linux environment. Users on Arch-based systems might need to install the <br> <b>pacman-contrib</b> package to access <br> <b>pactree</b> (e.g., <br> <b>sudo pacman -S pacman-contrib</b>). This utility is specific to the <br> <b>pacman</b> package manager and its ecosystem, and thus is not applicable to systems using <br> <b>apt</b>, <br> <b>dnf</b>, <br> <b>zypper</b>, etc.


title: <I>USAGE EXAMPLES</I>
content:
<i>To view the immediate dependencies of a package (e.g., 'firefox'):<br><b>pactree -d 1 firefox</b><br><br>To view dependencies up to a depth of 3 for 'kde-applications':<br><b>pactree -d 3 kde-applications</b><br><br>To see what packages depend on 'zlib' up to depth 2:<br><b>pactree -d 2 -r zlib</b></i>


title: <I>OUTPUT STRUCTURE</I>
content:
<i>The output of <b>pactree</b> typically uses indentation to represent the hierarchical structure of dependencies. Each level of indentation signifies a deeper dependency. When combined with <b>-d</b>, the tree is truncated at the specified depth, ensuring a focused view. For instance:<br><br><b>firefox</b><br><i>  ├──</i><b>xulrunner</b><br><i>  │    ├──</i><b>glibc</b><br><i>  │    └──</i><b>libxau</b><br><i>  └──</i><b>gtk3</b><br><i>       └──</i><b>glib2</b><br><i>            └──</i><b>pcre2</b></i>


title: HISTORY
content:
<b>pactree</b> is an integral part of the <br> <b>pacman-contrib</b> package, which houses various auxiliary scripts and tools designed to extend the functionality of the <br> <b>pacman</b> package manager. It has been developed alongside <br> <b>pacman</b> itself, evolving as the package management system matured. Its inclusion provides Arch Linux users with advanced capabilities for inspecting and understanding package relationships, a critical aspect of maintaining a rolling-release distribution.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a short help message and exits.<br><br><b>-r <path>, --root <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative installation root path for database operations. This is useful for chroot environments or managing multiple system installations.<br><br>


title: DESCRIPTION
content:
<i>pacman-db-upgrade</i> is a utility designed to upgrade the format of the local package database used by <i>pacman</i>, the package manager for Arch Linux and its derivatives. This tool becomes essential when <i>pacman</i> undergoes significant updates that introduce backward-incompatible changes to its internal database structure. Instead of simply updating packages, this command specifically ensures that the metadata <i>pacman</i> stores about installed packages (such as file lists, dependencies, and versions) is compatible with the latest <i>pacman</i> version.<br><br>In most cases, users will not need to execute <i>pacman-db-upgrade</i> manually. The <i>pacman</i> utility itself, or the underlying <i>libalpm</i> library (Arch Linux Package Management library), typically detects when a database format upgrade is necessary and automatically executes this tool during a system upgrade. Manual intervention might only be required in rare scenarios, such as after a partial upgrade or if <i>pacman</i> prompts the user to do so due to a database integrity issue. Its primary role is to maintain the integrity and compatibility of the local package database with the evolving <i>pacman</i> package manager.


title: CAVEATS
content:
<i>pacman-db-upgrade</i> is almost exclusively managed automatically by <i>pacman</i> itself. Users typically do not need to run this command manually. Running it unnecessarily will usually have no effect or prompt that no upgrade is needed. Manual execution should only be considered if <i>pacman</i> explicitly recommends it or if you are encountering database-related errors following a <i>pacman</i> update. Incorrect manual use or running it in an unstable system state could potentially lead to database corruption, though the tool is generally robust.


title: AUTOMATIC EXECUTION
content:
<i>pacman-db-upgrade</i> is generally executed automatically by <i>pacman</i> or <i>libalpm</i> (the Arch Linux Package Management library) whenever a database format upgrade is detected as necessary during a standard <b>pacman -Syu</b> system update. This ensures database compatibility without requiring user intervention.


title: DATABASE LOCATION
content:
The local package database, which <i>pacman-db-upgrade</i> operates on, is typically located at <b>/var/lib/pacman/local/</b>. This directory contains subdirectories for each installed package, storing metadata such as file lists, dependencies, and versions for that package.


title: HISTORY
content:
<i>pacman-db-upgrade</i> emerged as a necessity alongside significant architectural shifts within <i>pacman</i> itself, particularly when major changes to its underlying database format were introduced. A notable instance was the transition from <i>pacman</i>'s version 3 database format to the version 4 format, which brought about improvements in efficiency and flexibility. This command was developed to facilitate a smooth, automatic migration of existing local package databases to the new structure, ensuring backward compatibility for users while allowing <i>pacman</i>'s core functionalities to evolve. Its existence is inherently tied to the progressive development of the <i>pacman</i> project, addressing the challenges of maintaining database integrity across different software versions.


title: PARAMETERS
content:
<b><b>-d</b> <i>&lt;database&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative database path instead of the default <b>/var/lib/pacman</b>. This allows testing against a different set of packages.<br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignore missing dependencies. This option tells <i>pacman-deptest</i> not to report dependencies that are completely absent, focusing only on version conflicts or unmet requirements for present dependencies.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show satisfied dependencies. By default, <i>pacman-deptest</i> only shows unsatisfied dependencies. This option makes it list all dependencies, indicating which ones are satisfied.<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check if a package <b>provides</b> a dependency. This is useful for packages that provide a virtual dependency (e.g., <i>virtual-display-manager</i> might be provided by <i>xorg-server</i>).<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress output for satisfied dependencies. This option is often used with <b>-s</b> to get a cleaner list, or alone to only get an exit code.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a help message and exit.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br>


title: DESCRIPTION
content:
<i>pacman-deptest</i> is a diagnostic tool for Pacman, primarily used to verify the dependencies of a specific package. It checks whether all required dependencies for a given package are satisfied by other packages either currently installed on the system or present in a specified package database.<br><br>This utility is invaluable for package maintainers to ensure their packages correctly declare dependencies and for users to diagnose dependency-related installation failures. It can operate on an installed package name, a local package file (like a <b>.pkg.tar.zst</b>), or a URL to a package file. The command reports missing or unsatisfied dependencies, helping to identify conflicts or prerequisites that are not met. Its exit code indicates success (0 for all dependencies met) or failure (non-zero for unsatisfied dependencies).


title: CAVEATS
content:
<i>pacman-deptest</i> relies on the local Pacman database or a specified database. If the database is outdated or corrupted, the results may be inaccurate.<br>It does not perform actual installation or resolution; it only checks dependencies against an existing state.<br>It's primarily a shell script wrapper around <i>pacman</i>'s database queries, meaning it might not be as performant as a native binary for very large datasets.<br>It doesn't resolve transitive dependencies beyond the immediate ones of the specified package.


title: EXIT STATUS
content:
The command returns an exit status that can be used in scripts:<br><b>0</b>: All dependencies are satisfied.<br><b>1</b>: One or more dependencies are unsatisfied.<br><b>2</b>: An invalid option or package argument was provided.


title: USAGE EXAMPLES
content:
To check dependencies for an installed package:<br><b>pacman-deptest firefox</b><br><br>To check a local package file against a specific database:<br><b>pacman-deptest -d /path/to/custom_db coreutils.pkg.tar.zst</b><br><br>To show all dependencies, including satisfied ones:<br><b>pacman-deptest -s mesa</b>


title: HISTORY
content:
<i>pacman-deptest</i> is an integral part of the Pacman package manager suite, originally developed by Judd Vinet for Arch Linux. Its evolution has closely mirrored that of Pacman itself, adapting to new features and changes in dependency resolution within the Pacman ecosystem. It serves as a specialized diagnostic tool for package maintainers and advanced users, embodying Pacman's philosophy of providing granular control and detailed information about package states.


title: PARAMETERS
content:
<b><i>-F</i>, <i>--file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Query the files database. This option is implicitly assumed when <i>pacman-f</i> is used, as it's typically an alias for <i>pacman -F</i>.<br><br><b><i>-y</i>, <i>--refresh</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Download fresh package databases from the server, including file lists. This is highly recommended before performing file searches (e.g., <i>pacman -Fy</i>) to ensure results are based on the latest package information.<br><br><b><i>-s</i>, <i>--search</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search for packages in the sync database whose names or descriptions match <i>&lt;pattern&gt;</i>. When used with <i>-F</i>, it searches for files that match the pattern.<br><br><b><i>-l</i>, <i>--list</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List files owned by a specified package (e.g., <i>pacman -Fl &lt;package_name&gt;</i>). When combined with <i>-F</i>, it can list files matching a pattern that are part of the file database.<br><br><b><i>-x</i>, <i>--regex</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat <i>&lt;pattern&gt;</i> as a regular expression. This allows for more powerful and flexible search queries.<br><br><b><i>-q</i>, <i>--quiet</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress output messages, showing only the results. Useful for scripting.<br><br><b><i>-p</i>, <i>--package</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the package name for each matched file. This is the default behavior for file searches.<br><br><b><i>-h</i>, <i>--help</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a short help message and exit.<br><br>


title: DESCRIPTION
content:
The command <i>pacman-f</i> is a common alias or wrapper for <i>pacman -F</i>, part of the Arch Linux package manager. Its primary function is to search for files provided by packages within the synchronized package databases. Unlike searching for files on the local filesystem, <i>pacman-f</i> queries the information stored in the package manager's indexes. This allows users to determine which package owns a specific file, or to find packages that provide files matching a certain pattern. It's particularly useful for identifying the source of system files, resolving dependency issues, or locating missing binaries by searching for the package that would install them. For accurate and up-to-date results, it is crucial to first synchronize the file database using the <i>-y</i> option (e.g., <i>pacman -Fy</i>).


title: CAVEATS
content:
For <i>pacman-f</i> to provide accurate and up-to-date results, it is essential to first synchronize the file database. This is achieved by running <i>pacman -Fy</i>. Without this step, the command will operate on potentially stale file lists, leading to incomplete or incorrect search results. The <i>pacman-f</i> command searches for files <i>within</i> the package manager's database, not on your local filesystem.


title: DATABASE SYNCHRONIZATION
content:
Before using <i>pacman-f</i> effectively, especially when searching for newly added or updated files, it is crucial to perform a file database synchronization. This is done via <i>pacman -Fy</i>. This command downloads the compressed file lists from the repositories and populates the local file database, ensuring your searches reflect the current state of available packages and their contents.


title: SEARCH EXAMPLES
content:
To find which package owns <i>/usr/bin/ls</i>: <i>pacman -F /usr/bin/ls</i><br>To search for packages that provide files matching 'libfoo.so': <i>pacman -F libfoo.so</i><br>To search for files matching a regular expression (e.g., 'bash' anywhere in the path): <i>pacman -Fx bash</i><br>To update the file database and then search: <i>pacman -Fy && pacman -F &lt;pattern&gt;</i>


title: HISTORY
content:
The <i>pacman-f</i> command is not a standalone utility but rather a common shorthand or alias for <i>pacman -F</i>, a core feature of the <i>pacman</i> package manager for Arch Linux. <i>Pacman</i> itself was initially released in 2002, and its file database querying capabilities (<i>-F</i>) have been an integral part of its feature set, evolving alongside the manager's development to provide robust package and file management for the Arch ecosystem.


title: SYNOPSIS
content:
<i>pacman-files</i> [<i>options</i>] [<i>target</i>...]<br><br>Example usages:<br><i>pacman-files</i> -o <i>/usr/bin/pacman</i><br><i>pacman-files</i> -l <i>bash</i><br><i>pacman-files</i> -s <i>'.*vim.*'</i><br><i>pacman-files</i> -S


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b>-l, --list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists files owned by specified packages. Targets must be package names.<br><br><b>-o, --owner</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the owning package of specified files. Targets must be file paths.<br><br><b>-s, --search</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for files whose paths match the specified pattern. Targets must be file patterns. Can be combined with -o.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses output of the owning package when used with -s, --search mode.<br><br><b>-S, --sync</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Synchronizes the file database with the local Pacman database. Requires root privileges.<br><br><b>-F, --files</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly tells the command to use the files database. This is the default behavior and is mostly for completeness with <i>pacman -F</i>.<br><br>


title: DESCRIPTION
content:
<i>pacman-files</i> is a command-line utility designed to query the Pacman file database, which tracks the files installed by various packages. It provides functionality to identify which package owns a specific file, list all files belonging to a particular package, or search for files matching a given pattern. This tool is especially useful for system administrators and users of Arch Linux and its derivatives to manage installed software, resolve file ownership, and diagnose issues related to package installations. It can also synchronize its file database with the main Pacman database.


title: CAVEATS
content:
The <i>-S, --sync</i> option typically requires root privileges (e.g., using <i>sudo</i>). If Pacman operations are performed without root, or if the file database becomes corrupted, a manual synchronization using <i>-S</i> might be necessary. The file database is maintained by <i>pacman-files</i> and separate from Pacman's main package database.


title: RETURN CODES
content:
<b>0</b>: All targets processed successfully.<br><b>1</b>: An unknown error occurred.<br><b>2</b>: An invalid option was passed.<br><b>3</b>: A target was not found.


title: ENVIRONMENT
content:
Refer to <i>pacman(8)</i> for environment variables that might influence its behavior, though <i>pacman-files</i> typically operates independently of most general Pacman environment settings.


title: HISTORY
content:
<i>pacman-files</i> is part of the <b>pacman-contrib</b> package, which provides a collection of supplementary scripts and utilities for the Pacman package manager. Pacman itself was initially written by Judd Vinet and first released in 2002. <i>pacman-files</i> was developed later as a dedicated utility to interact specifically with Pacman's file database, offering a more direct and efficient way to query file ownership and paths than relying solely on the broader <i>pacman</i> command's capabilities for file queries (<i>pacman -F</i>). Its continued development aims to enhance the maintainability and diagnostic capabilities for Arch Linux systems.


title: SYNOPSIS
content:
pacman-key <i>[options] &lt;operation&gt; [arguments]</i><br>pacman-key <i>[options] --recv-keys &lt;keys&gt;...</i><br>pacman-key <i>[-hVv] [--nocolor]</i>


title: PARAMETERS
content:
<b>init</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Initializes</i> the pacman keyring, creating necessary GnuPG directories and files.<br><br><b>populate [archlinux]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Populates</i> the keyring with a default set of trusted keys, typically official Arch Linux master keys.<br><br><b>add <file(s)></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Adds</i> public keys from specified key files to the keyring.<br><br><b>list [keys]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Lists</i> all keys in the keyring, or specific keys if arguments are provided.<br><br><b>refresh</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Refreshes</i> all keys in the keyring from a configured keyserver to update their status and trust.<br><br><b>finger [keys]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays</i> the fingerprints of all keys or specified keys in the keyring.<br><br><b>sign <keys>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Locally signs</i> specified keys, indicating your trust in them.<br><br><b>verify <file(s)></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Verifies</i> the cryptographic signatures on local files using keys in the keyring.<br><br><b>export <keys>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Exports</i> specified public keys from the keyring to standard output or a file.<br><br><b>delete <keys>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Deletes</i> specified keys from the keyring.<br><br><b>revoke <keys>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Revokes</i> specified keys, marking them as invalid within the keyring.<br><br><b>clean</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Removes</i> untrusted or revoked keys from the keyring.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Shows</i> a help message and exits.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays</i> version information and exits.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Increases</i> output verbosity.<br><br><b>--nocolor</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Disables</i> colored output.<br><br><b>--keyserver <server></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies</i> an alternative keyserver to use for key operations.<br><br><b>--keyserver-options <options></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Passes</i> additional options to the keyserver daemon (<i>dirmngr</i>).<br><br><b>--gpgdir <dir></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies</i> an alternative <i>GnuPG</i> home directory for keyring operations.<br><br><b>--recv-keys <keys>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Receives</i> specified keys directly from a keyserver.<br><br>


title: DESCRIPTION
content:
pacman-key is a critical utility for managing the <i>GnuPG</i> keyring used by <i>pacman</i>, the Arch Linux package manager.<br>Its primary function is to ensure the integrity and authenticity of packages downloaded and installed on your system.<br>By verifying cryptographic signatures attached to packages, pacman-key helps prevent the installation of tampered, malicious, or unofficial software.<br><br>The command facilitates various operations including initializing the keyring, populating it with official Arch Linux keys, refreshing keys from external keyservers, adding third-party developer keys, signing keys, and revoking or deleting compromised keys.<br>Proper management of the <i>pacman</i> keyring is paramount for maintaining the security and trustworthiness of your Arch Linux installation, protecting against supply chain attacks and ensuring that only trusted software is executed.


title: CAVEATS
content:
Most pacman-key operations require <b>root privileges</b> to modify the system-wide keyring.<br>Network connectivity is essential for operations like <i>refreshing</i> or <i>receiving</i> keys from keyservers.<br>Adding keys from untrusted sources can compromise system security; always verify key fingerprints.


title: <B>KEYRING LOCATION</B>
content:
The default location for the <i>pacman</i> keyring is <i>/etc/pacman.d/gnupg/</i>.<br>This directory contains the GnuPG key database used for signature verification.


title: <B>INITIAL SETUP</B>
content:
For a new Arch Linux installation, the keyring must first be initialized with <i><code>pacman-key --init</code></i>.<br>Subsequently, it's populated with official Arch Linux keys using <i><code>pacman-key --populate archlinux</code></i> to ensure trusted package installation from the outset.


title: <B>TRUST MANAGEMENT AND SIGLEVEL</B>
content:
The level of signature verification performed by <i>pacman</i> is configured via the <i><code>SigLevel</code></i> option in <i>/etc/pacman.conf</i>.<br>Common settings include <i><code>Required DatabaseOptional</code></i> (default) or <i><code>Required DatabaseRequired</code></i>, dictating how strictly signatures are checked against the keys managed by <i>pacman-key</i>.


title: HISTORY
content:
The pacman-key utility was introduced to Arch Linux as a crucial component of its <b>package signing initiative</b>.<br>This initiative aimed to significantly enhance the security of the Arch Linux distribution by ensuring the authenticity and integrity of all official packages.<br>Before its implementation, package verification was less robust, relying more on checksums than cryptographic signatures.<br>With pacman-key, signature verification became a standard and mandatory part of the package installation process, making Arch Linux installations inherently more secure against malicious package injection or tampering.


title: SEE ALSO
content:
pacman(8): The primary Arch Linux package manager., gpg(1): The <i>GnuPG</i> command-line tool, used by pacman-key for cryptographic operations., dirmngr(8): A <i>GnuPG</i> component managing interactions with keyservers., pacman.conf(5): The main configuration file for pacman, where signature verification levels are set.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br><b><b>-c</b> <i>&lt;COUNTRY&gt;</i>, <b>--country</b> <i>&lt;COUNTRY&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters mirrors by specified country or countries (e.g., <i>US</i>, <i>DE</i>). Can be used multiple times.<br><br><b><b>-f</b> <i>&lt;NUMBER&gt;</i>, <b>--fasttrack</b> <i>&lt;NUMBER&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the <i>&lt;NUMBER&gt;</i> fastest mirrors after ranking them by speed.<br><br><b><b>-i</b>, <b>--interactive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables interactive mode, allowing manual selection of mirrors from a list.<br><br><b><b>-g</b>, <b>--generate</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates the mirror list without performing any speed ranking.<br><br><b><b>-P</b> <i>&lt;PROTOCOL&gt;</i>, <b>--protocol</b> <i>&lt;PROTOCOL&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters mirrors by specified protocol (e.g., <i>https</i>, <i>http</i>, <i>ftp</i>). Can be used multiple times.<br><br><b><b>-a</b>, <b>--api</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses the official <i>api.manjaro.org</i> to retrieve the mirror list data.<br><br><b><b>-B</b> <i>&lt;BRANCH&gt;</i>, <b>--branch</b> <i>&lt;BRANCH&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Manjaro branch to use (<i>stable</i>, <i>testing</i>, or <i>unstable</i>).<br><br><b><b>-m</b> <i>&lt;METHOD&gt;</i>, <b>--method</b> <i>&lt;METHOD&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the ranking method for mirrors (e.g., <i>rank</i> for speed, <i>random</i>).<br><br><b><b>-o</b> <i>&lt;FILE&gt;</i>, <b>--outfile</b> <i>&lt;FILE&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the generated mirror list to a specified <i>&lt;FILE&gt;</i> instead of the default <i>/etc/pacman.d/mirrorlist</i>.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details during execution.<br><br><b><b>-d</b>, <b>--default</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resets the mirror list to its default configuration.<br><br><b><b>-R</b>, <b>--no-rank</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs the command to not rank mirrors by speed, using the filtered list directly.<br><br><b><b>-U</b> <i>&lt;URL&gt;</i>, <b>--url</b> <i>&lt;URL&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a custom <i>&lt;URL&gt;</i> as the source for retrieving the mirror list.<br><br>


title: DESCRIPTION
content:
<i>pacman-mirrors</i> is a robust script exclusive to Manjaro Linux distributions, designed to streamline the management and optimization of the <i>/etc/pacman.d/mirrorlist</i> file. This file dictates which repositories <i>pacman</i> utilizes for software downloads. Instead of manual intervention, <i>pacman-mirrors</i> automates the generation of a new mirror list, often by ranking mirrors based on speed and availability. It supports filtering mirrors by geographic location (countries), communication protocol (e.g., <i>https</i>, <i>http</i>), and Manjaro's specific branches (<i>stable</i>, <i>testing</i>, <i>unstable</i>). This functionality ensures that <i>pacman</i> leverages fast and reliable mirrors, significantly enhancing update and package installation speeds. Following its execution, it is standard practice to run <b>sudo pacman -Syy</b> to refresh the local package database against the newly configured mirrors.


title: CAVEATS
content:
The <i>pacman-mirrors</i> command typically requires <b>sudo</b> privileges to modify the system's <i>/etc/pacman.d/mirrorlist</i> file. It is a utility developed specifically for Manjaro Linux and its derivatives, and is not available on other distributions like vanilla Arch Linux or Debian-based systems.


title: POST-UPDATE ACTION
content:
After running <i>pacman-mirrors</i>, it is essential to synchronize your local package database with the newly selected mirrors by executing <b>sudo pacman -Syy</b>. Failing to do so might result in package mismatches or update errors.


title: MANJARO SPECIFIC
content:
It's important to note that <i>pacman-mirrors</i> is a Manjaro-specific utility. Users on other Linux distributions will not find this command or its equivalent functionality in their default package management tools.


title: HISTORY
content:
<i>pacman-mirrors</i> was developed as a core utility for Manjaro Linux, addressing the need for a user-friendly and efficient mechanism to manage Pacman's mirror list. In a rolling release distribution like Manjaro, effective mirror management is crucial for system stability and update speed. Its creation aimed to simplify the process, moving beyond manual file editing and offering automated ranking and filtering capabilities, thus significantly enhancing the overall user experience on Manjaro.


title: SYNOPSIS
content:
<b><I>pacman -Q</I></b> [<b><I>-options</I></b>] [<b><I>package(s)</I></b>]<br><b><I>pacman -Q</I></b> [<b><I>-q</I></b>] [<b><I>-e</I></b> | <b><I>-d</I></b> | <b><I>-t</I></b> | <b><I>-u</I></b>]<br><b><I>pacman -Q</I></b> [<b><I>-l</I></b> | <b><I>-k</I></b> | <b><I>-s</I></b> | <b><I>-i</I></b>] [<b><I>package(s)</I></b>]<br><b><I>pacman -Qo</I></b> <I>file</I>


title: PARAMETERS
content:
<b><b><I>-Q</I></b>, <b><I>--query</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The main subcommand to query the package database. Used without further options, it lists all installed packages and their versions.<br><br><b><b><I>-q</I></b>, <b><I>--quiet</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all output messages except the requested information. Often used with <I>-Q</I> to get a clean list of package names, e.g., <I>pacman -Qq</I>.<br><br><b><b><I>-e</I></b>, <b><I>--explicit</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List only explicitly installed packages (not dependencies).<br><br><b><b><I>-d</I></b>, <b><I>--deps</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List only implicitly installed packages (dependencies).<br><br><b><b><I>-t</I></b>, <b><I>--unrequired</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List packages that are not required by any other installed package.<br><br><b><b><I>-u</I></b>, <b><I>--unowned</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List files in the filesystem not owned by any package.<br><br><b><b><I>-l</I></b>, <b><I>--list</I></b> <I>&lt;package&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all files owned by the specified package(s).<br><br><b><b><I>-k</I></b>, <b><I>--check</I></b> <I>&lt;package&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check specified package(s) for missing or modified files. Use <I>-kk</I> for a more thorough check (file checksums).<br><br><b><b><I>-o</I></b>, <b><I>--owns</I></b> <I>&lt;file&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show which package owns the specified file. Useful for identifying the source of a particular file.<br><br><b><b><I>-s</I></b>, <b><I>--search</I></b> <I>&lt;regex&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search for installed packages matching the given regular expression.<br><br><b><b><I>-i</I></b>, <b><I>--info</I></b> <I>&lt;package&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display detailed information about the specified package(s), including version, size, dependencies, and description.<br><br><b><b><I>-p</I></b>, <b><I>--file</I></b> <I>&lt;package_file&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Query a local package file (not yet installed) for information.<br><br>


title: DESCRIPTION
content:
The command <I>pacman -Q</I> is the query subcommand for <I>pacman</I>, the Arch Linux package manager. While <I>pacman-q</I> is not a standalone command, it often refers to common usage of <I>pacman -Q</I> combined with the <I>-q</I> or <I>--quiet</I> option. <br><br>The primary function of <I>pacman -Q</I> is to interact with and retrieve information about packages installed on the system. It can list all installed packages, display detailed information about a specific package, verify package integrity, list files owned by a package, or determine which package owns a particular file. When the <I>-q</I> (quiet) option is used, <I>pacman -Q</I> minimizes output by showing only the requested information, suppressing non-essential messages like progress bars or status updates, making it suitable for scripting or when a clean, raw list of package names is desired. It is an essential tool for system administrators and users to inspect their installed software.


title: CAVEATS
content:
This command is specific to Arch Linux and its derivatives (e.g., Manjaro). It will not work on systems using other package managers like APT (Debian/Ubuntu), DNF (Fedora/RHEL), or Zypper (openSUSE). While most query operations do not require root privileges, querying local package files (<I>-p</I>) or checking file ownership (<I>-o</I>) often do not, but system-wide integrity checks (<I>-k</I>) might benefit from them.


title: COMMON USAGE EXAMPLES
content:
<b><I>pacman -Q</I></b><br> &nbsp;&nbsp;&nbsp;&nbsp;List all installed packages.<br><br><b><I>pacman -Qq</I></b><br> &nbsp;&nbsp;&nbsp;&nbsp;List all installed packages in quiet mode (only names and versions).<br><br><b><I>pacman -Qqe</I></b><br> &nbsp;&nbsp;&nbsp;&nbsp;List all explicitly installed packages in quiet mode.<br><br><b><I>pacman -Qi bash</I></b><br> &nbsp;&nbsp;&nbsp;&nbsp;Show detailed information about the 'bash' package.<br><br><b><I>pacman -Ql pacman</I></b><br> &nbsp;&nbsp;&nbsp;&nbsp;List all files owned by the 'pacman' package.<br><br><b><I>pacman -Qo /usr/bin/ls</I></b><br> &nbsp;&nbsp;&nbsp;&nbsp;Identify which package owns the '/usr/bin/ls' file.


title: HISTORY
content:
<I>pacman</I> (Package Manager) was created by Judd Vinet, the founder of Arch Linux, and first released in 2002. It was designed from the ground up to be simple, fast, and robust, aligning with Arch Linux's 'KISS' (Keep It Simple, Stupid) philosophy. The query functionality, including the <I>-Q</I> subcommand, has been a core part of <I>pacman</I> since its early versions, providing users with essential tools for inspecting and managing their installed software without unnecessary complexity. Its continuous development by the Arch Linux community has ensured its relevance and efficiency.


title: SYNOPSIS
content:
<b>pacman-query</b> <I>[options]</I> <I>[package(s)]</I><br>Equivalent to: <b>pacman -Q</b> <I>[options]</I> <I>[package(s)]</I>


title: PARAMETERS
content:
<b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show less information for certain query operations, suppressing non-essential output.<br><br><b>-i, --info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display package information such as version, description, build date, installed size, dependencies, and conflicts.<br><br><b>-l, --list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all files owned by a specified package. Can be combined with <I>--recursive</I> to show files for dependencies.<br><br><b>-o, --owns <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Identify the package that owns the specified file. Useful for troubleshooting file ownership.<br><br><b>-s, --search <regex></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search for installed packages matching the provided regular expression or string in their names and descriptions.<br><br><b>-f, --files <package_or_file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List files owned by a package based on the local database, or query information from a specified package file (.pkg.tar.zst) directly.<br><br><b>-k, --check</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check the local package database for integrity issues, such as missing files from installed packages.<br><br><b>-e, --explicit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List explicitly installed packages, i.e., those not installed as dependencies of other packages.<br><br><b>-d, --deps</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List packages installed as dependencies of other explicitly installed packages.<br><br><b>-t, --unrequired</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List packages that are unrequired by any other package; often used to find orphaned packages.<br><br><b>-u, --upgrades</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all packages that are outdated and have newer versions available in configured repositories.<br><br><b>-p, --file <package_file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Query information from a package file (.pkg.tar.zst) instead of the local database, useful for inspecting downloaded packages.<br><br><b>-g, --groups <group></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all packages belonging to a specified group, such as 'base-devel'.<br><br><b>-a, --all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all installed packages. When used with -Q, it provides a comprehensive list of every package on the system.<br><br><b>--foreign</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all foreign packages, meaning those not found in any of the configured sync databases (e.g., packages installed from AUR).<br><br><b>--native</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all native packages, meaning those installed from the official Arch Linux repositories.<br><br><b>--tree</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the dependency tree for specified packages, illustrating how they depend on other packages.<br><br>


title: DESCRIPTION
content:
The <I>pacman-query</I> command, which typically refers to the <I>query</I> operations of the <I>pacman</I> package manager (primarily via `pacman -Q`), allows users to inspect locally installed packages and their attributes. It provides a comprehensive set of options for retrieving information about packages, such as their version, size, dependencies, files they own, and installation status. Unlike other <I>pacman</I> operations like installation or removal, <I>pacman-query</I> (or `pacman -Q`) does not modify the system; it solely acts as an information retrieval tool. This command is crucial for system administration tasks, including verifying package integrity, listing package contents, identifying orphaned packages, and searching for specific software.


title: CAVEATS
content:
The command <b>pacman-query</b> is not a standard executable found in a typical Arch Linux installation. The functionality it implies, which is querying installed packages, is universally provided by the command <b>pacman -Q</b>. Users should primarily rely on <b>pacman -Q</b> for these operations. This command is specific to Arch Linux and its derivatives (e.g., Manjaro, EndeavourOS) and is not available on other Linux distributions that use different package managers (e.g., Debian/Ubuntu with apt, Fedora with dnf/rpm).


title: <I>USAGE CONTEXT</I>
content:
This command is an essential tool for system auditing, troubleshooting, and verifying installed software on Arch Linux systems. It helps administrators and users understand their system's software landscape without altering its state, making it a safe command to run for informational purposes.


title: <I>DATABASE INTERACTION</I>
content:
The command primarily interacts with the local package database, typically located at <I>/var/lib/pacman/local</I>. This means it can provide comprehensive information about installed packages even without an active internet connection, as it relies on locally cached metadata rather than live repository data for most operations.


title: HISTORY
content:
The <I>pacman</I> package manager was initially developed by Judd Vinet for Arch Linux, with its first release in 2002. From its inception, robust querying capabilities have been a fundamental part of <I>pacman</I>'s design, enabling users to easily inspect their installed software. The <I>-Q</I> flag for querying has been a consistent and central feature, evolving with new options to provide more granular control over package information retrieval as <I>pacman</I> itself has matured. While a dedicated 'pacman-query' command is not standard, the querying functionality of <I>pacman</I> has always been a core strength.


title: SYNOPSIS
content:
<i><b>pacman</b></i> <i><b>-r</b></i> <i><path_to_root></i> [<i>operation</i>] [<i>options</i>] [<i>targets</i>]<br>Example: <i><b>pacman</b></i> <i><b>-r</b></i> <i>/mnt</i> <i><b>-S</b></i> <i>linux</i>


title: PARAMETERS
content:
<b><i><b>-r</b></i> <i><path_to_root></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The primary option that specifies an alternative root directory for all subsequent <i><b>pacman</b></i> operations. All paths accessed by <i><b>pacman</b></i> (configuration, databases, package installation) will be relative to this root.<br><br><b><i><b>--root</b></i> <i><path_to_root></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Long form equivalent of <i><b>-r</b></i>, also specifies an alternative root directory for <i><b>pacman</b></i> operations.<br><br><b>[<i>operation</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Any standard <i><b>pacman</b></i> operation, such as <i><b>-S</b></i> (sync/install), <i><b>-R</b></i> (remove), <i><b>-Q</b></i> (query), <i><b>-U</b></i> (upgrade local package), etc. These operations are performed relative to the specified root.<br><br><b>[<i>options</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Additional <i><b>pacman</b></i> options that modify the behavior of the operation (e.g., <i><b>--noconfirm</b></i>, <i><b>--cachedir</b></i>, <i><b>--config</b></i>). These options also apply relative to the alternative root.<br><br><b>[<i>targets</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The specific packages or package groups to act upon, relative to the specified root. For example, a package name for installation or removal.<br><br>


title: DESCRIPTION
content:
<i><b>pacman</b></i> is the official package manager for Arch Linux and its derivatives. The <i><b>-r</b></i> or <i><b>--root</b></i> option allows users to perform package management operations (such as installing, removing, or querying packages) on a system root other than the currently running one. This feature is invaluable for various administrative and recovery tasks, including:<br><i><br></i><b>System Recovery:</b> Managing a broken system by booting from a live environment and using <i><b>pacman -r</b></i> to fix issues in the installed system.<br><i><br></i><b>Chroot Environments:</b> Installing or updating packages within a chroot, which is a common practice for building software, testing, or performing system maintenance in an isolated environment.<br><i><br></i><b>Parallel Installations:</b> Administering multiple Arch Linux installations from a single running system.<br><i><br></i>When used, <i><b>pacman</b></i> will search for its configuration files (e.g., <i>pacman.conf</i>) and package databases within the specified root directory, rather than the standard <i>/</i> path. This powerful capability ensures precise control over where packages are installed and from which system's perspective the operation is performed, making it a critical tool for advanced Arch Linux users and administrators.


title: CAVEATS
content:
When using <i><b>pacman -r</b></i>, it is crucial to ensure that the specified root directory (<i><path_to_root></i>) has a proper Linux Filesystem Hierarchy Standard (FHS) structure. The <i>pacman.conf</i> file must exist within <i><path_to_root></i>/etc/pacman.conf, and the package database should be located at <i><path_to_root></i>/var/lib/pacman. Incorrect setup can lead to package database inconsistencies, broken installations, or unintended modifications to the alternative system. Permissions must be correctly managed for successful operations. While <i><b>pacman -r</b></i> manages packages in the specified root, it does not automatically <i><b>chroot</b></i> into it; for a full chroot environment setup, tools like <i><b>arch-chroot</b></i> or manual <i><b>chroot</b></i> are often used in conjunction.


title: CONFIGURATION FILES AND DATABASE LOCATION
content:
When <i><b>pacman -r</b></i> is invoked, it specifically looks for its configuration file at <i><path_to_root></i>/etc/pacman.conf and its package database at <i><path_to_root></i>/var/lib/pacman. Users must ensure these directories and files are correctly set up within the alternative root for <i><b>pacman</b></i> operations to function as expected. If the configuration file is not at the standard path within the alternative root, the <i><b>--config</b></i> option can be used to specify its exact location.


title: HISTORY
content:
<i><b>pacman</b></i> was created by Judd Vinet and first released in 2002 as the core package manager for Arch Linux, emphasizing simplicity, speed, and reliability. The <i><b>--root</b></i> (or <i><b>-r</b></i>) option has been a fundamental part of <i><b>pacman</b></i> since its early development. This capability reflects the critical need for robust system recovery and management outside of a fully operational live environment, which is a common scenario in system administration. Its importance has grown significantly with the widespread adoption of chroot environments for software development, testing, and system maintenance tasks within the Arch Linux community.


title: PARAMETERS
content:
<b><b><code>-R</code></b>, <b><code>--remove</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;This is the primary operation flag to remove packages.<br><br><b><b><code>-s</code></b>, <b><code>--recursive</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the target package(s) and all of their dependencies that are not required by other installed packages.<br><br><b><b><code>-u</code></b>, <b><code>--unneeded</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b><code>-s</code></b>, it removes only unneeded dependencies. This is often used to clean up orphaned packages.<br><br><b><b><code>-c</code></b>, <b><code>--cascade</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the target package(s) and all packages that depend on the target(s). <i><b>Use with extreme caution</b></i>, as this can lead to removal of many critical system components.<br><br><b><b><code>-n</code></b>, <b><code>--nosave</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes configuration files along with the package. By default, configuration files are saved.<br><br><b><b><code>-d</code></b>, <b><code>--nodeps</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips dependency checks. This means it will remove a package even if other packages depend on it. <i><b>Use with extreme caution</b></i>, as this can break system functionality.<br><br><b><b><code>-g</code></b>, <b><code>--groups</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Targets a package group for removal. For example, <b><code>pacman -Rg &lt;groupname&gt;</code></b>.<br><br><b><b><code>-k</code></b>, <b><code>--dbonly</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the package only from the database, not the files from the filesystem. <i><b>Use with extreme caution</b></i>, as this leaves files on disk and can lead to inconsistencies.<br><br><b><b><code>--noconfirm</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bypasses any confirmation prompts. <i><b>Use with caution</b></i>, especially for destructive operations.<br><br><b><b><code>--dryrun</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulates the removal operation without actually making any changes to the system. Useful for seeing what would be removed.<br><br><b><b><code>-r</code></b> <i>&lt;path&gt;</i>, <b><code>--root</code></b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternate root directory for operations.<br><br><b><b><code>-b</code></b> <i>&lt;path&gt;</i>, <b><code>--dbpath</code></b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternate database path.<br><br><b><b><code>-q</code></b>, <b><code>--quiet</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses most output during the operation.<br><br><b><b><code>-v</code></b>, <b><code>--verbose</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows more information during the operation.<br><br>


title: DESCRIPTION
content:
<p>The <b><code>pacman -R</code></b> (or <b><code>--remove</code></b>) command is used to uninstall packages from an Arch Linux system. When invoked, it removes all files associated with the specified package(s), except for configuration files by default. It also handles dependencies: by default, it will not remove packages that are depended upon by other installed packages. This prevents accidental system breakage by removing essential components.</p><br><p>However, <b><code>pacman -R</code></b> offers several powerful options to modify its behavior. For instance, the <b><code>-s</code></b> (<b><code>--recursive</code></b>) option allows for the removal of dependencies that are no longer required by any other installed package. The <b><code>-n</code></b> (<b><code>--nosave</code></b>) option ensures that configuration files are also removed, which can be useful for a clean uninstallation. Care must be taken when using options like <b><code>-c</code></b> (<b><code>--cascade</code></b>) or <b><code>-d</code></b> (<b><code>--nodeps</code></b>), as they can lead to an unstable system if not fully understood. Proper use of <b><code>pacman -R</code></b> is crucial for maintaining a clean and functional Arch Linux installation.</p>


title: CAVEATS
content:
<b>Dependency Hell:</b> Incorrect use of <b><code>pacman -R</code></b>, especially with options like <b><code>-d</code></b> or <b><code>-c</code></b>, can lead to a broken system where essential packages are removed, making the system unstable or unbootable. Always understand the implications of removing packages and their dependencies.<br><b>Configuration Files:</b> By default, configuration files for a package are not removed. This is to preserve user settings if the package is reinstalled. To remove them, use the <b><code>-n</code></b> (<b><code>--nosave</code></b>) option.<br><b>Orphaned Packages:</b> While <b><code>-Rs</code></b> helps with unneeded dependencies, sometimes packages become "orphaned" (installed as a dependency but no longer required by any explicitly installed package). These won't be removed by a simple <b><code>pacman -R</code></b>. Manual cleanup or specific commands are needed.<br><b>File Conflicts:</b> Removing a package using <b><code>-k</code></b> (<b><code>--dbonly</code></b>) leaves files on the filesystem. This can lead to conflicts if another package tries to install files with the same names.


title: REMOVING ORPHANED PACKAGES
content:
<p>To identify packages installed as dependencies but no longer required by any explicitly installed package, use: <b><code>pacman -Qtdq</code></b><br>To remove them, combine this with <b><code>pacman -Rns</code></b>: <b><code>sudo pacman -Rns $(pacman -Qtdq)</code></b></p>


title: COMMON REMOVAL EXAMPLES
content:
<ul><li>Basic removal: <b><code>sudo pacman -R <i>packagename</i></code></b></li><li>Remove package and its unneeded dependencies: <b><code>sudo pacman -Rs <i>packagename</i></code></b></li><li>Remove package, its unneeded dependencies, and configuration files: <b><code>sudo pacman -Rns <i>packagename</i></code></b></li><li>Remove package, its dependencies, and packages that depend on it (<i>dangerous!</i>): <b><code>sudo pacman -Rsc <i>packagename</i></code></b></li></ul>


title: HISTORY
content:
<p>Pacman, the Arch Linux package manager, was originally developed by Judd Vinet in 2002. From its inception, the design philosophy behind Pacman was to provide a simple, robust, and fast package management system for Arch Linux, which is known for its "KISS" (Keep It Simple, Stupid) principle. The <b><code>-R</code></b> command for package removal has been a core component since early versions, reflecting the need for efficient package uninstallation while maintaining system integrity through dependency tracking.</p><br><p>Over the years, <b><code>pacman -R</code></b> has seen enhancements to its dependency resolution logic and the addition of various options, such as <b><code>--recursive</code></b> (<b><code>-s</code></b>) and <b><code>--cascade</code></b> (<b><code>-c</code></b>), to give users more granular control over package removal, accommodating different scenarios from simple uninstalls to comprehensive system cleanup. Its development continues to align with Arch Linux's rolling release model, ensuring that it remains a powerful and adaptable tool for managing the system's software.</p>


title: SEE ALSO
content:
<b><code>pacman(8)</code></b>: The primary manual page for the Pacman package manager., <b><code>pacman -S</code></b>: Used to synchronize, install, or upgrade packages., <b><code>pacman -Q</code></b>: Used to query the package database., <b><code>pacman -U</code></b>: Used to install or upgrade a local package., <b><code>pacman -D</code></b>: Used for database operations (e.g., changing package install reason).


title: PARAMETERS
content:
<b><b>-S, --sync</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Synchronize packages. This operation is implied when using '<b>pacman -S</b>'.<br><br><b><b>-y, --refresh</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Download fresh package databases from the server. Use twice (<b>-yy</b>) to force a refresh even if up-to-date.<br><br><b><b>-u, --sysupgrade</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Upgrade all installed packages to their newer versions available in the repositories. Always recommended with <b>-S</b> and <b>-y</b> (e.g., <b>pacman -Syu</b>).<br><br><b><b>-w, --downloadonly</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Download packages but do not install or upgrade them. Useful for caching packages for later offline installation.<br><br><b><b>-i, --info</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display information about the specified packages without installing them (e.g., <b>pacman -Si</b> <I>package</I>).<br><br><b><b>-s, --search</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search the local package databases for packages matching the provided regex (e.g., <b>pacman -Ss</b> <I>term</I>).<br><br><b><b>--noconfirm</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bypass all confirmation prompts. Use with extreme caution, especially in scripts.<br><br><b><b>--needed</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not reinstall packages that are already installed and up-to-date. Useful when installing multiple packages.<br><br><b><b>--asdeps</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Install packages as dependencies, meaning they can be automatically removed by 'pacman -Qtd'.<br><br><b><b>--asexplicit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Install packages as explicitly installed, preventing them from being removed automatically as orphans.<br><br><b><b>--ignore</b> <I>package</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude a package from being upgraded during a system upgrade. Can be specified multiple times.<br><br><b><b>--overwrite</b> <I>glob</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overwrite files that conflict with existing files on the system. Use with caution as it can lead to system instability.<br><br>


title: DESCRIPTION
content:
The "<b>pacman -S</b>" command is the core operation for package management in Arch Linux and its derivatives. It is primarily used for synchronizing the local package database with the remote repositories, installing new packages, and performing a full system upgrade. When executed, it downloads packages and their dependencies from configured repositories, verifies their integrity, and installs them onto the system. It's fundamental for maintaining an up-to-date and functional Arch Linux installation.


title: CAVEATS
content:
Always perform a full system upgrade with <b>pacman -Syu</b> before installing new packages to avoid partial upgrades, which can lead to system instability. Using options like <b>--noconfirm</b>, <b>--force</b>, or <b>--overwrite</b> can bypass important safety checks and potentially damage your system if not used carefully and with full understanding of their implications. Regularly check the Arch Linux news before major system upgrades for potential manual intervention steps.


title: FULL SYSTEM UPGRADE
content:
The most common and recommended way to update your Arch Linux system is by running '<b>pacman -Syu</b>'. This command first synchronizes the package databases and then upgrades all installed packages to their latest versions, ensuring consistency across the system.


title: INSTALLING NEW PACKAGES
content:
To install a specific package, use '<b>pacman -S</b> <I>package-name</I>'. You can install multiple packages at once by listing them: '<b>pacman -S</b> <I>package1 package2</I>'. It's best practice to run '<b>pacman -Syu</b>' first to ensure your databases are current.


title: DATABASE SYNCHRONIZATION ONLY
content:
To only refresh the package databases without performing any upgrades or installations, use '<b>pacman -Sy</b>'. Using '<b>pacman -Syy</b>' forces a refresh even if the databases appear up-to-date, which can be useful after mirror list changes.


title: HISTORY
content:
Pacman (Package Manager) was created by Judd Vinet, the founder of Arch Linux, and first released in 2002. It was designed to provide a simple, powerful, and fast way to manage packages on Arch Linux's rolling release model. The '<b>-S</b>' (sync) operation has been a fundamental part of pacman's functionality since its inception, enabling users to keep their systems up-to-date and install new software efficiently from centralized repositories.


title: PARAMETERS
content:
<b>-y, --refresh</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Download fresh package databases from the server. This option is typically implied or passed to <b>pacman</b> during full system upgrades.<br><br><b>-u, --sysupgrade</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Upgrade all installed packages that are out-of-date. This option is generally implied when <b>pacman-sync</b> performs a system upgrade without specific package arguments.<br><br><b>--noconfirm</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bypass all confirmation prompts. Use with caution, as this can lead to unintended changes.<br><br><b>--needed</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not reinstall targets that are already up-to-date. Useful when installing multiple packages where some might already be present.<br><br><b>--ignore &lt;package&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs <i>pacman</i> to ignore upgrades for the specified package(s). Can be specified multiple times to ignore several packages.<br><br><b>&lt;package&gt;...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more package names to install. If no packages are specified, <b>pacman-sync</b> typically performs a system upgrade.<br><br>


title: DESCRIPTION
content:
The command <i>pacman-sync</i> is a common utility or alias, primarily used within Arch Linux and its derivatives, to streamline operations of the <b>pacman</b> package manager. While not a standalone binary distributed by default with <i>pacman</i>, it typically acts as a wrapper or alias for common <i>pacman</i> commands.<br><br>Its most frequent use is to perform a full system update by synchronizing package databases and upgrading all installed packages, effectively acting as an alias for <b>pacman -Syu</b>. Alternatively, when invoked with package names, it functions as an installation command, analogous to <b>pacman -S &lt;package&gt;</b>.<br><br>The existence of <i>pacman-sync</i> simplifies common maintenance tasks for users, providing a memorable and concise way to keep a system updated or install new software without needing to remember specific <i>pacman</i> flags.


title: CAVEATS
content:
<i>pacman-sync</i> is generally not a standard, pre-installed binary in Arch Linux. Its behavior is highly dependent on how it's implemented (e.g., as a shell alias or a custom script by the user or a distribution). Users should verify its exact definition on their system to understand the underlying <b>pacman</b> commands it executes.<br><br>Relying on <i>pacman-sync</i> without understanding its specific implementation might lead to unexpected behavior compared to directly using <b>pacman</b> commands.


title: TYPICAL IMPLEMENTATIONS
content:
A common shell alias for <i>pacman-sync</i> might be `alias pacman-sync='sudo pacman -Syu'` for system updates, or a more complex script that distinguishes between system updates and package installations. For example:<br><code>#!/bin/bash<br>if [ "$#" -eq 0 ]; then<br>  sudo pacman -Syu "$@"<br>else<br>  sudo pacman -S "$@"<br>fi</code><br>This script executes <b>pacman -Syu</b> if no arguments are provided, otherwise it executes <b>pacman -S</b> with the provided arguments.


title: USAGE SIMPLIFICATION
content:
The primary purpose of <i>pacman-sync</i> is to provide a single, memorable command for common <i>pacman</i> operations. It abstracts away the need to remember specific flags like <b>-Syu</b> for system upgrades or just <b>-S</b> for package installations, making package management more intuitive for many users.


title: HISTORY
content:
The command <i>pacman-sync</i> does not have a formal, official development history as part of the <i>pacman</i> project itself. Instead, it emerged as a popular convention within the Arch Linux community. Users and distribution maintainers often create it as a convenient alias or simple shell script to simplify the very common tasks of updating the system (<b>pacman -Syu</b>) or installing new packages (<b>pacman -S</b>). Its history is therefore more of a community-driven ergonomic evolution rather than a direct software development timeline.


title: PARAMETERS
content:
<b>-r, --deptree</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the packages that the specified package requires. This is the default behavior if no other tree-type option is given.<br><br><b>-s, --reqby</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the packages that require the specified package. This shows the reverse dependency tree.<br><br><b>-u, --installed</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When displaying a dependency tree (--deptree), this option filters the output to show only explicitly installed packages, omitting those that are optional or merely suggested.<br><br><b>-l, --linear</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows dependencies in a simple, linear list rather than a hierarchical tree structure.<br><br><b>-c, --color</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables colorized output for better readability, highlighting different types of packages or relationships.<br><br><b>-d &lt;path&gt;, --dbpath &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative <i>pacman</i> database path to use instead of the default.<br><br><b>-y &lt;path&gt;, --sysroot &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative system root path for <i>pacman</i> operations, useful for chroot or container environments.<br><br><b>--indent &lt;string&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the string used for indenting levels in the tree output (e.g., '  ' for two spaces).<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses warnings and error messages, providing a cleaner output.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with usage information and available options.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of the <i>pacman-t</i> (<i>pactree</i>) script.<br><br>


title: DESCRIPTION
content:
The command `pacman-t` (often implemented as the <i>pactree</i> script from the <i>pacman-contrib</i> package) is a powerful utility for visualizing package relationships within Arch Linux and its derivatives. It allows users to display either the dependency tree of a specified package (i.e., what packages it requires) or the reverse dependency tree (i.e., what packages depend on it). This tool is invaluable for understanding why certain packages are installed, identifying potential candidates for removal when a package is uninstalled, or troubleshooting dependency conflicts. It operates by parsing the local <i>pacman</i> database to construct and present these hierarchical relationships in a human-readable format, often with color-coded output for clarity.


title: CAVEATS
content:
The command `pacman-t` is typically a script, most commonly provided as <i>pactree</i> within the <i>pacman-contrib</i> package. It relies on the consistency and integrity of the local <i>pacman</i> database. Complex or broken dependency chains might not be accurately represented, and it does not handle optional or 'make' dependencies directly in the same way as core <i>pacman</i> operations. Its performance can vary depending on the size of the dependency tree and system resources.


title: INSTALLATION
content:
The `pacman-t` utility (as <i>pactree</i>) is not part of the core <i>pacman</i> package. It is provided by the <b>pacman-contrib</b> package. To install it on Arch Linux, use: <i>pacman -S pacman-contrib</i>.


title: USAGE EXAMPLES
content:
To view the dependency tree for a package like 'firefox': <br><i>pacman-t firefox</i> <br><br>To see which packages depend on 'zlib': <br><i>pacman-t --reqby zlib</i> <br><br>To show only explicitly installed dependencies of 'gnome-shell': <br><i>pacman-t --deptree --installed gnome-shell</i>


title: HISTORY
content:
The `pacman-t` functionality, commonly provided by the <i>pactree</i> script, has been a part of the <i>pacman-contrib</i> tools since early in Arch Linux's development. These 'contrib' scripts emerged to provide auxiliary utilities that enhance the core <i>pacman</i> experience, offering advanced query and analysis capabilities not built into the main package manager executable itself. Its ongoing development focuses on improving dependency visualization and user experience.


title: SYNOPSIS
content:
<b>pacman -U</b> <i>&lt;package_file&gt;</i> ...<br><b>pacman --upgrade</b> <i>&lt;package_file&gt;</i> ...<br><i>Note: &lt;package_file&gt; refers to the path to one or more .pkg.tar.zst files or remote URLs.</i>


title: PARAMETERS
content:
<b><b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force install/upgrade, overwriting conflicting files. Use with caution.<br><br><b><b>--needed</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not reinstall the target if it is already installed and up-to-date.<br><br><b><b>--noconfirm</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not ask for confirmation during the installation process.<br><br><b><b>--asdeps</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Install packages as dependencies, marking them as implicitly installed.<br><br><b><b>--asexplicit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Install packages explicitly, marking them as intentionally installed by the user.<br><br><b><b>--cachedir</b> <i>&lt;dir&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set an alternate package cache location for downloaded packages.<br><br><b><b>--dbpath</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set an alternate database location for pacman's package information.<br><br><b><b>--root</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set an alternate installation root directory.<br><br><b><b>--config</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set an alternate configuration file for pacman.<br><br><b><b>--sysroot</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on a different system root, similar to <b>--root</b> but also adjusts other paths.<br><br><b><b>--overwrite</b> <i>&lt;glob&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bypass file conflict checks and allow pacman to overwrite files matching the specified <i>&lt;glob&gt;</i> pattern.<br><br>


title: DESCRIPTION
content:
The <i>pacman -U</i> (or <i>--upgrade</i>) command in Arch Linux is used to install or upgrade packages from a specified local package file (typically with a <i>.pkg.tar.zst</i> extension) or a remote URL. Unlike <i>pacman -S</i> which fetches packages from configured repositories, <i>-U</i> operates directly on a provided package file.<br><br>This is particularly useful for installing packages built locally using <i>makepkg</i>, installing development versions, or downgrading a package to a specific version you have on hand. It will attempt to resolve dependencies if they are already installed or provided by other specified local package files, but it does <b>not</b> automatically fetch missing dependencies from repositories.


title: CAVEATS
content:
<ul><li>Requires the package file to be present locally or accessible via URL.</li><li>Does <b>not</b> automatically fetch missing dependencies from configured repositories. You must ensure all dependencies are met, either by installing them beforehand or by providing their package files in the same command.</li><li>Careless use, especially with <b>--force</b> or incompatible packages, can lead to system instability or breakage.</li><li>Always verify the source and integrity of <i>.pkg.tar.zst</i> files before installing them.</li></ul>


title: DEPENDENCY HANDLING
content:
When using <b>pacman -U</b>, if a package has unsatisfied dependencies, <i>pacman</i> will report an error. You must either install those dependencies from repositories using <b>pacman -S</b> first, or include their respective package files in the same <b>pacman -U</b> command.


title: DOWNGRADING PACKAGES
content:
To downgrade a package, simply use <b>pacman -U</b> with an older version of the <i>.pkg.tar.zst</i> file. If newer versions are present and cause conflicts, you might need to use <b>--overwrite</b> to handle file conflicts or remove the newer version first using <b>pacman -R</b>.


title: HISTORY
content:
<i>pacman</i> (Package Manager) was developed by Judd Vinet, the founder of Arch Linux, and first released in 2002. It was designed to be a simple, fast, and efficient package manager. The <i>-U</i> (upgrade/install local) functionality has been a core part of <i>pacman</i> since its early versions, crucial for allowing users to install self-compiled packages or specific versions outside of the main repositories, complementing the repository-based installation (<i>-S</i>). Its continued development by the Arch Linux community has seen numerous improvements in dependency resolution, file handling, and performance.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the program's version information and exits.<br><br>


title: DESCRIPTION
content:
The <i>pacman4console</i> command provides a nostalgic, text-based rendition of the classic arcade game, Pac-Man, directly within your Linux terminal. Built using terminal capabilities, often leveraging libraries like ncurses, it transforms your console into a retro gaming arena. Players control a character, typically represented by a 'P' or 'C', navigating a maze made of ASCII characters to eat all the 'dots' (represented by '.' or '*') while avoiding four pursuing 'ghosts' (often 'G', 'O', 'H', 'S' or different colors). Consuming larger 'power pellets' temporarily reverses the roles, allowing Pac-Man to eat the ghosts for bonus points. The objective remains the same as the original: clear each maze of dots to advance to the next level, accumulating the highest possible score. It's a lightweight, fun diversion that demonstrates the versatility of the command line beyond system administration.


title: CAVEATS
content:
This command is typically not a part of standard core Linux distributions and may need to be installed from community repositories, third-party sources, or compiled from source code. Its visual presentation relies on the terminal's character set and color support, which might vary, potentially affecting the game's appearance. Performance can also depend on terminal emulator capabilities. Due to its nature as a simple game, advanced configuration options or persistent high score tracking are often absent or limited.


title: <B>GAMEPLAY</B>
content:
The game involves navigating a maze, eating all the 'dots' while avoiding four computer-controlled ghosts. Eating larger 'power pellets' temporarily makes the ghosts vulnerable, allowing Pac-Man to eat them for bonus points. The game ends when Pac-Man loses all his lives.


title: <B>CONTROLS</B>
content:
Movement is typically controlled using the standard arrow keys (Up, Down, Left, Right) on the keyboard. Pressing 'q' or 'Q' often allows the player to quit the game at any time.


title: <B>INSTALLATION</B>
content:
<i>pacman4console</i> is often available through your distribution's community or extra repositories (e.g., AUR for Arch Linux, universe for Ubuntu). Alternatively, it can be downloaded and compiled from its source code, usually found on platforms like GitHub.


title: HISTORY
content:
The concept of playing Pac-Man in a text-based environment predates modern graphical interfaces, with various implementations emerging in the early days of computing. <i>pacman4console</i> is one of many open-source projects that bring this classic arcade experience to the Linux command line. While a specific definitive origin for <i>this</i> exact iteration can be elusive due to the distributed nature of open-source development, it embodies the spirit of creating simple, entertaining diversions using readily available terminal capabilities. Its development is often community-driven, maintained by enthusiasts who appreciate the simplicity and nostalgia of console gaming, making it a popular choice for users looking for a quick, retro break without leaving their terminal.


title: PARAMETERS
content:
<b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help message and exit.<br><br><b>-p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the PulseAudio server to connect to. Takes an address as an argument.<br><br><b>-F <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute commands from the specified script <I>file</I>. This option can be used multiple times to execute several scripts.<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fork into the background after connecting to the server and executing any specified script files.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start an interactive shell session after connecting to the server and executing any script files.<br><br><b>-n <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the client name to use for this connection to the PulseAudio server.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase verbosity level. This option can be used multiple times for more detailed output.<br><br>


title: DESCRIPTION
content:
<b>pacmd</b> is a powerful command-line utility for interacting with the PulseAudio sound server daemon. It provides a flexible interface to query and modify the PulseAudio configuration and state dynamically. While it can be run in an interactive shell mode, allowing users to execute commands one by one, it's also highly scriptable, making it suitable for automated tasks and system configurations. <br><br>Users commonly employ <b>pacmd</b> to inspect current audio sinks and sources, adjust volumes, change default audio devices, manage module loading, and control audio routing within the PulseAudio ecosystem. Its comprehensive set of internal commands gives granular control over virtually every aspect of the audio daemon's operation. Although <b>pactl</b> is often preferred for simpler scripting tasks due to its more machine-friendly output, <b>pacmd</b> remains invaluable for complex diagnostics and interactive management of PulseAudio.


title: CAVEATS
content:
<b>pacmd</b> operates at a relatively low level and requires a running PulseAudio daemon to function. Users new to PulseAudio might find its internal commands complex and less intuitive than higher-level tools. For simpler, one-off scripting tasks or general user interaction, the <b>pactl</b> command is often a more suitable and user-friendly alternative due to its more consistent and parsable output format.


title: INTERACTIVE MODE AND COMMON COMMANDS
content:
When invoked with the <I>-s</I> option or without any command-line arguments, <b>pacmd</b> enters an interactive shell. In this mode, users can type commands directly to the PulseAudio server, similar to a mini-interpreter. The shell provides tab-completion for commands and arguments, making it easier to discover available functionalities. <br><br>Some frequently used internal commands within the <b>pacmd</b> interactive shell include:<br><br><i>list-sinks</i>: Displays detailed information about all available audio output devices (sinks).<br><i>list-sources</i>: Displays detailed information about all available audio input devices (sources).<br><i>set-sink-volume <I>index/name</I> <I>volume</I></i>: Sets the volume for a specific audio output device. Volume can be specified as a percentage (e.g., '100%'), a decibel value (e.g., '0dB'), or a raw hexadecimal value (e.g., '0x10000' for 100%).<br><i>set-default-sink <I>index/name</I></i>: Changes the default audio output device that applications will use.<br><i>load-module <I>module-name</I> [<I>arguments</I>]</i>: Loads a specific PulseAudio module with optional arguments.<br><i>unload-module <I>module-index</I></i>: Unloads a previously loaded module identified by its numeric index.


title: HISTORY
content:
<b>pacmd</b> has been a fundamental component of the PulseAudio project since its early development. It was designed as the primary interactive command-line interface for directly managing the PulseAudio sound server, complementing the server's background daemon capabilities. While newer tools like <b>pactl</b> have gained popularity for their scripting friendliness and cleaner output, <b>pacmd</b> continues to be maintained and widely used for its comprehensive interactive control, detailed diagnostics, and the ability to execute complex sequences of commands.


title: SYNOPSIS
content:
<b>pacstall</b> [<i>GLOBAL_OPTIONS</i>] <i>command</i> [<i>OPTIONS</i>] [<i>arguments</i>...]<br><br><b>Common Commands:</b><br><b>pacstall</b> <i>install</i> <<i>package_name</i>...><br><b>pacstall</b> <i>remove</i> <<i>package_name</i>...><br><b>pacstall</b> <i>update</i><br><b>pacstall</b> <i>search</i> <<i>query</i>>


title: PARAMETERS
content:
<b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a comprehensive help message for <i>pacstall</i> or a specific subcommand.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the current version information of the <i>pacstall</i> utility.<br><br><b>install <package(s)></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs one or more packages specified by name from the <i>pacstall</i> recipe repositories. Commonly used options include <b>-y</b> (assume yes to prompts) and <b>-d</b> (perform a dry run without actual installation).<br><br><b>remove <package(s)></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes one or more packages previously installed via <i>pacstall</i>. Can also be used with <b>-y</b> for automatic confirmation.<br><br><b>update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates all currently installed <i>pacstall</i> packages to their latest available versions according to the recipes.<br><br><b>search <query></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches the available <i>pacstall</i> recipe database for packages matching the provided query string.<br><br><b>build <recipe_path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Builds a package from a local <i>pacstall</i> recipe file or directory, typically for development or custom package creation.<br><br><b>list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a list of all packages that are currently installed on the system using <i>pacstall</i>.<br><br><b>sync</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Synchronizes the local <i>pacstall</i> recipe database with the remote Git repositories, ensuring access to the latest package definitions.<br><br><b>clear</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clears the build cache and any temporary files generated by <i>pacstall</i>, freeing up disk space.<br><br>


title: DESCRIPTION
content:
<i>pacstall</i> is a community-driven package manager for Arch Linux and its derivatives, designed to streamline the process of installing software not readily available in official repositories. It serves as an alternative to manual <i>makepkg</i> usage or certain AUR helpers by providing a simpler, more intuitive command-line interface for building and installing packages from its own ecosystem of community-maintained "recipes" (similar to Arch's PKGBUILDs).<br><br>The core philosophy of <i>pacstall</i> is to abstract away the complexities of source-based compilation, allowing users to install, update, and remove packages with commands reminiscent of <i>pacman</i>. It manages dependencies, fetches source code, compiles the software, and then integrates it into the system using <i>pacman</i>. While it utilizes the Arch User Repository (AUR) under the hood for some operations, its primary strength lies in its own dedicated set of recipes, aiming for a more curated and reliable source of third-party software.


title: CAVEATS
content:
Packages installed via <i>pacstall</i> are built from source, which can be a time-consuming and resource-intensive process compared to installing pre-compiled binaries. As a community-maintained tool, it is not officially supported by Arch Linux, and its stability and security rely on the quality and maintenance of its community recipes. Users should be aware that build failures or dependency conflicts can occur, especially if recipes become outdated or are not properly maintained. Requires <i>git</i> and the <i>base-devel</i> group to be installed on the system for successful compilation.


title: RECIPE SYSTEM AND PACKAGING
content:
<i>pacstall</i> utilizes its own system of 'recipes' (similar to PKGBUILDs) that define how a package should be built and installed. These recipes are stored in Git repositories, and when a user requests an installation, <i>pacstall</i> fetches the corresponding recipe, executes the build process, and then uses <i>pacman</i> to install the resulting binary package (a <i>.pkg.tar.zst</i> file). This system allows for community-driven package definitions and aims to simplify the distribution of software not present in official Arch repos.


title: CONFIGURATION AND HOOKS
content:
<i>pacstall</i> provides configuration options, often managed through a configuration file, allowing users to customize its behavior. This includes setting up custom recipe repositories, defining build flags, or adjusting parallelism for compilation. It may also support hooks, enabling the execution of custom scripts before or after certain package management operations, offering advanced customization for experienced users.


title: HISTORY
content:
<i>pacstall</i> emerged from the Arch Linux community's desire for a simpler, more user-friendly experience when managing third-party software beyond the official repositories or the manual complexities of <i>makepkg</i> and the Arch User Repository (AUR). Developed as an alternative to existing AUR helpers, it aimed to provide a more streamlined, '<i>pacman</i>-like' interface for source-based package management. Its development has focused on ease of use and a curated recipe system to simplify the process for users needing a broader software selection on Arch-based systems.


title: PARAMETERS
content:
<b><i>&lt;root_directory&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The absolute path to the target directory where the new system will be installed (e.g., <i>/mnt</i>). This directory must be a valid, pre-mounted filesystem.<br><br><b><i>&lt;packages&gt;</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional space-separated list of packages to install into the <i>root_directory</i>. Common packages include <i>base</i>, <i>linux</i>, and <i>linux-firmware</i>. If omitted, it typically defaults to installing the <i>base</i> package group.<br><br><b>-c, --clean</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Cleans the package cache after installation, removing downloaded package files.<br><br><b>-d, --nodeps</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips dependency checks, forcing installation even if dependencies are not met. Use with caution.<br><br><b>-G, --nogpgcheck</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips GPG package signature checks, potentially compromising security. Not recommended for general use.<br><br><b>-i, --noconfirm</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Does not prompt for confirmation for any operations, automatically assuming 'yes' to all questions.<br><br><b>-M, --noextract</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Downloads packages but does not extract or install them into the target system.<br><br><b>-N, --noprogressbar</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the display of the progress bar during downloads and installations.<br><br><b>-P, --print</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a list of packages that would be installed without actually performing the installation.<br><br><b>-U, --upgrade</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treats the operation as an upgrade for existing packages in the target system rather than a fresh install.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows more detailed information and debug messages during execution.<br><br><b>--sysroot <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternate sysroot path for installation, overriding the default behavior of using the first argument as the root directory.<br><br><b>--cachedir <i>&lt;dir&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets an alternate directory for the package cache, where downloaded packages are stored.<br><br><b>--config <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses an alternate configuration file for underlying <i>pacman</i> operations.<br><br><b>--ignore <i>&lt;pkg&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignores a specific package from being installed or upgraded. Can be specified multiple times.<br><br><b>--overwrite <i>&lt;glob&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a glob pattern to allow overwriting conflicting files during package installation.<br><br><b>--needed</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Does not reinstall targets that are already up-to-date in the destination.<br><br>


title: DESCRIPTION
content:
<i>pacstrap</i> is a crucial utility primarily used during the installation of Arch Linux. It enables users to install a foundational system, typically comprising the <i>base</i> and <i>base-devel</i> package groups, into a newly mounted partition. The command effectively sets up the initial environment, automatically configuring <i>pacman</i> to install packages relative to the specified <i>sysroot</i> directory. This streamlines the bootstrapping of a functional Arch Linux system onto a disk, preparing it for further configuration within a <i>chroot</i> environment. <i>pacstrap</i> handles package installation, dependency resolution, and the initial setup of the package database within the target system, simplifying what would otherwise be a complex manual process.


title: CAVEATS
content:
<b>Requires Mounted Target:</b> The <i>&lt;root_directory&gt;</i> must be a valid, pre-mounted filesystem (e.g., a partition) before running <i>pacstrap</i>.<br><b>Internet Connection:</b> An active internet connection is typically required to download packages from repositories.<br><b>Root Privileges:</b> <i>pacstrap</i> must be executed with root privileges.<br><b>Arch Linux Specific:</b> This command is integral to the Arch Linux ecosystem and is not found on other Linux distributions.<br><b>Internal Dependency:</b> It relies heavily on <i>pacman</i>'s underlying functionalities.


title: TYPICAL USAGE
content:
A common invocation for a fresh Arch Linux installation is <i>pacstrap /mnt base linux linux-firmware</i>, which installs the essential components (base system, Linux kernel, and firmware) onto the <i>/mnt</i> mount point.


title: POST-INSTALLATION STEPS
content:
After <i>pacstrap</i> completes, it is standard practice to use <i>arch-chroot /mnt</i> to enter the newly installed system. This allows for further configuration, such as generating the <i>fstab</i>, setting the locale, configuring the network, and installing a boot loader.


title: HISTORY
content:
<i>pacstrap</i> was introduced as a simpler and more robust method for bootstrapping an Arch Linux installation. Before its existence, users often had to manually mount the target partition, prepare directories, and then run <i>pacman -r /mnt -S base</i> or similar commands, a process prone to errors. <i>pacstrap</i> encapsulates these complex steps, providing a dedicated tool that correctly handles the <i>sysroot</i> and <i>chroot</i> environments for <i>pacman</i>. This has significantly simplified the initial system setup phase, making it a cornerstone of the official Arch Linux installation guide and improving user experience.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Show help message.</I><br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Show PulseAudio and protocol version information.</I><br><br><b><b>-s</b> <I>SERVER</I>, <b>--server</b>=<I>SERVER</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Connect to the specified PulseAudio server instead of the default one.</I><br><br><b><b>-n</b> <I>NAME</I>, <b>--client-name</b>=<I>NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specify the client name to be used when connecting to the server.</I><br><br><b><b>-f</b> <I>FORMAT</I>, <b>--format</b>=<I>FORMAT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Output information in a specific format (e.g., 'json' for machine-readable output).</I><br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Enable verbose output, providing more details on operations.</I><br><br><b><b>-i</b> <I>ID</I>, <b>--id</b>=<I>ID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specify an object ID for commands that operate on specific objects.</I><br><br>


title: DESCRIPTION
content:
<i><b>pactl</b></i> is a command-line utility used to control a running PulseAudio sound server. It provides a more programmatic and scriptable interface compared to <i>pacmd</i>, which is typically interactive. <i><b>pactl</b></i> can be used to perform a wide range of actions, such as listing sinks (output devices), sources (input devices), and clients; setting default audio devices; adjusting volumes; muting/unmuting; loading and unloading modules; and managing card profiles. Its non-interactive nature makes it ideal for shell scripts and automated tasks to manage the PulseAudio sound environment.


title: CAVEATS
content:
<I><code>pactl</code> requires a running PulseAudio daemon to function. If PulseAudio is not running, commands will fail to connect.</I><br><I>Permissions are crucial. The user running <code>pactl</code> must have sufficient rights to interact with the PulseAudio server, typically meaning they are logged into the same graphical session or configured for remote access.</I><br><I>While powerful, some advanced configurations might still require direct editing of PulseAudio configuration files or using the interactive <code>pacmd</code> for complex scenarios.</I>


title: COMMON SUBCOMMANDS
content:
<i><b>info</b></i>: <I>Displays detailed information about the PulseAudio server, including default sink/source, server version, and module list.</I><br><i><b>list</b></i> [<i>type</i>]: <I>Lists properties of various PulseAudio objects. Common types include <code>sinks</code>, <code>sources</code>, <code>sink-inputs</code>, <code>source-outputs</code>, <code>cards</code>, <code>clients</code>, and <code>modules</code>.</I><br><i><b>set-default-sink</b></i> <I>NAME|INDEX</I>: <I>Sets the default audio output device by its name or index.</I><br><i><b>set-sink-volume</b></i> <I>NAME|INDEX</I> <I>VOLUME</I>: <I>Sets the volume of a specific sink. Volume can be specified as a percentage (e.g., <code>100%</code>) or absolute value.</I><br><i><b>set-sink-mute</b></i> <I>NAME|INDEX</I> <I>0|1</I>: <I>Mutes (<code>1</code>) or unmutes (<code>0</code>) a specific sink.</I><br><i><b>load-module</b></i> <I>NAME</I> [<i>ARGUMENTS</i>]: <I>Loads a PulseAudio module, optionally with specific arguments.</I><br><i><b>unload-module</b></i> <I>INDEX|NAME</I>: <I>Unloads a previously loaded PulseAudio module by its index or name.</I><br><i><b>set-card-profile</b></i> <I>NAME|INDEX</I> <I>PROFILE</I>: <I>Changes the profile of a sound card (e.g., switching between stereo output, surround sound, or input-only profiles).</I>


title: HISTORY
content:
<I><code>pactl</code> is an integral part of the PulseAudio project, which began development around 2004 and gained significant traction in the Linux desktop environment in the late 2000s and early 2010s. It was designed to provide a modern, networked sound server capable of handling multiple audio sources and sinks, per-application volume control, and network audio. <code>pactl</code> emerged as the primary non-interactive tool for scripting and managing this complex audio system, complementing the interactive <code>pacmd</code>.</I>


title: PARAMETERS
content:
<b>-c, --color</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Colorizes the output for better readability.<br><br><b>-d, --depth &lt;N&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the depth of the dependency tree displayed to <i>N</i> levels.<br><br><b>-f, --files</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the files owned by the packages in the tree.<br><br><b>-g, --groups</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays package groups that packages belong to.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the help message and exits.<br><br><b>-i, --installed</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays only installed packages. This option implies <i>--local</i>.<br><br><b>-l, --local</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Queries the local package database. This is the default if no database selection options are given.<br><br><b>-r, --reverse</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows reverse dependencies, i.e., which packages depend on the specified package.<br><br><b>-s, --sync</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Queries the sync (remote) package database. This is the default if <i>--local</i> or <i>--installed</i> are not given.<br><br><b>-u, --unrequired</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows packages that are not explicitly required by any other installed package. Useful for identifying 'orphan' packages.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases verbosity of the output.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses warnings and errors during execution.<br><br>


title: DESCRIPTION
content:
<i>pactree</i> is a utility from the <i>pacman-contrib</i> package on Arch Linux. It's designed to visualize the dependency relationships between packages. It can show both direct dependencies (what a package needs to function) and reverse dependencies (which packages depend on a specified package). This command is invaluable for understanding the intricate web of package interconnections, aiding in system maintenance, troubleshooting, and identifying potentially orphaned packages. It provides a clear, tree-like representation, making complex dependency chains easy to follow.


title: CAVEATS
content:
<i>pactree</i> is specific to Arch Linux and systems using the <i>pacman</i> package manager. It is part of the <i>pacman-contrib</i> package and is not natively available on other Linux distributions like Debian, Ubuntu, or Fedora unless compiled from source.


title: USAGE EXAMPLES
content:
To show the dependency tree for a package like <b>firefox</b>:<br><i>pactree firefox</i><br><br>To show which packages depend on <b>pacman</b> (reverse dependencies):<br><i>pactree -r pacman</i><br><br>To limit the dependency depth to 2 levels for <b>coreutils</b>:<br><i>pactree -d 2 coreutils</i><br><br>To list packages that are not required by any other installed package:<br><i>pactree -u</i>


title: HISTORY
content:
<i>pactree</i> is a utility within the <i>pacman-contrib</i> package, a collection of helper scripts and tools for <i>pacman</i>, Arch Linux's official package manager. Its development is closely tied to the evolution of <i>pacman</i> and the Arch Linux ecosystem, continuously adapting to provide more insightful dependency analysis capabilities for users.


title: PARAMETERS
content:
<b>COMMAND</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The executable program you wish to run with OSS emulation enabled. <code>padsp</code> will launch this command, ensuring it can output sound via PulseAudio even if it expects to use an OSS device.<br><br><b>ARGUMENTS...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Any command-line arguments that should be passed directly to the <code>COMMAND</code> being executed. <code>padsp</code> does not interpret these arguments; it simply forwards them.<br><br>


title: DESCRIPTION
content:
<code>padsp</code> (<i>PulseAudio DSP</i>) is a utility provided by the PulseAudio sound server to enable legacy applications designed for the <i>Open Sound System</i> (OSS) to play audio through PulseAudio. Many older Linux audio applications were written to directly access OSS devices like <code>/dev/dsp</code>. When PulseAudio became the dominant sound server, these applications would fail to produce sound without a compatibility layer.<br><br><code>padsp</code> acts as a wrapper. When you run a command using <code>padsp</code> (e.g., <code>padsp &lt;application&gt;</code>), it preloads a special library (typically <code>libpulsedsp.so</code>) into the application's memory space. This library intercepts calls that the application makes to the OSS API (e.g., <code>open("/dev/dsp")</code>, <code>ioctl(DSP_SETFMT)</code>). Instead of interacting with a non-existent or conflicting <code>/dev/dsp</code> device, the preloaded library redirects these calls to the PulseAudio server, effectively translating OSS commands into PulseAudio operations. This allows older games, multimedia players, or audio tools to function seamlessly within a PulseAudio environment without needing to be recompiled or modified.


title: CAVEATS
content:
<ul><li><b>Compatibility Limitations</b>: While <code>padsp</code> works for many simple OSS applications, it might not be perfect for all. Complex or low-latency audio applications, or those relying on very specific OSS features (like direct hardware access for advanced mixing or effects), might still experience issues or sub-optimal performance.</li><li><b>Performance Overhead</b>: The emulation layer introduces a slight overhead. For modern applications, direct PulseAudio (or ALSA) integration is always preferred for better performance and lower latency.</li><li><b>Deprecation Context</b>: OSS is largely superseded by ALSA and PulseAudio on modern Linux systems. <code>padsp</code> is a legacy compatibility tool and not intended for new application development.</li><li><b>Environment Variables</b>: Its functionality heavily relies on the <code>LD_PRELOAD</code> mechanism, which can sometimes be affected by security policies or other preloaded libraries.</li></ul>


title: HOW IT WORKS
content:
<code>padsp</code> leverages the <code>LD_PRELOAD</code> environment variable. When <code>padsp</code> is invoked, it sets <code>LD_PRELOAD</code> to point to <code>libpulsedsp.so</code> (or a similar PulseAudio DSP emulation library) and then executes the specified command. The <code>ld.so</code> dynamic linker then loads <code>libpulsedsp.so</code> before any other libraries. This preloaded library contains replacement functions for the standard OSS API calls, which then reroute the audio operations to the active PulseAudio server instead of attempting to access a <code>/dev/dsp</code> device directly.


title: TYPICAL USE CASE
content:
Running older games or specific audio utilities that have not been updated to use modern audio APIs (like ALSA or PulseAudio directly). For example, <code>padsp quake3</code> to run an old game, or <code>padsp sox -d my_audio.wav</code> to use a legacy audio utility that expects OSS.


title: HISTORY
content:
With the increasing adoption of PulseAudio as the default sound server in many Linux distributions around the mid-2000s, there was a need to support existing applications that were written against the older <i>Open Sound System</i> (OSS) API. <code>padsp</code> was developed as part of the PulseAudio project to bridge this compatibility gap, allowing users to continue running their favorite legacy audio software without having to switch sound servers or modify application code. Its development mirrored the rise of PulseAudio itself, providing a smoother transition path for users.


title: SYNOPSIS
content:
<b>pageres</b> [<I>options</I>] <I>url</I> [<I>url</I>...]<br><b>pageres</b> [<I>options</I>] <I>url</I> [<I>width</I>] [<I>height</I>]


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information and exits.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the current version of <i>pageres</i> and exits.<br><br><b><I>url</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The URL of the web page to screenshot. Multiple URLs can be provided.<br><br><b><I>width</I> [<I>height</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The dimensions for the screenshot. <i>width</i> is required, <i>height</i> is optional. If only <i>width</i> is provided, <i>height</i> defaults to <i>width</i> or the page's actual height if <b>--full-page</b> is used. Can also be specified as <b>--size=1024x768</b> or <b>--size=1024</b>.<br><br><b>--size=<I>width</I>x<I>height</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the screenshot dimensions. Examples: <b>1024x768</b>, <b>1280x*</b> (maintain aspect ratio), <b>1024</b> (square).<br><br><b>--full-page</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Captures a screenshot of the entire scrollable page, not just the viewport.<br><br><b>--crop=<I>x,y,width,height</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Crops the screenshot to the specified region. Values are in pixels relative to the viewport.<br><br><b>--dest=<I>directory</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the destination directory where screenshots will be saved. Defaults to the current working directory.<br><br><b>--format=<I>format</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the output image format. Supported values include <b>png</b> and <b>jpg</b> (or <b>jpeg</b>).<br><br><b>--quality=<I>percentage</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the quality for JPEG images (0-100). Higher values result in larger file sizes. Ignored for PNG.<br><br><b>--filename=<I>pattern</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the naming pattern for output files. Supported variables include <b><%= url %></b>, <b><%= size %></b>, <b><%= format %></b>, <b><%= date %></b>, <b><%= time %></b>, <b><%= index %></b>.<br><br><b>--delay=<I>seconds</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Waits for a specified number of seconds before taking the screenshot. Useful for pages with animations or asynchronously loaded content.<br><br><b>--timeout=<I>seconds</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a timeout for page loading in seconds. If the page doesn't load within this time, an error is thrown.<br><br><b>--user-agent=<I>string</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a custom User-Agent string for the browser. Useful for mimicking different devices or browsers.<br><br><b>--cookie=<I>name=value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a custom cookie to the browser session. Can be specified multiple times.<br><br><b>--header=<I>name=value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a custom HTTP header to the request. Can be specified multiple times.<br><br><b>--javascript=<I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Injects a custom JavaScript file that executes after the page loads. Can be specified multiple times.<br><br><b>--css=<I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Injects a custom CSS file into the page. Can be specified multiple times.<br><br><b>--selector=<I>CSS_selector</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Takes a screenshot of a specific DOM element matched by the CSS selector, instead of the entire page.<br><br><b>--dark-mode</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Emulates dark mode preference for the web page, if supported by the site's CSS.<br><br><b>--scale=<I>factor</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the device scale factor (e.g., 2 for HiDPI/Retina screens). Defaults to 1.<br><br><b>--no-javascript</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables JavaScript execution on the target page.<br><br><b>--hide=<I>CSS_selector</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hides elements matching the CSS selector before taking the screenshot. Can be specified multiple times.<br><br><b>--transparent</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Makes the background of the screenshot transparent (PNG format only).<br><br><b>--incremental</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Appends an incremental index to the filename (e.g., <i>screenshot-0.png</i>, <i>screenshot-1.png</i>).<br><br><b>--ignore-https-errors</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignores HTTPS certificate errors during navigation.<br><br><b>--username=<I>username</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Username for HTTP basic authentication.<br><br><b>--password=<I>password</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Password for HTTP basic authentication.<br><br>


title: DESCRIPTION
content:
<i>pageres</i> is a powerful command-line interface (CLI) tool designed to effortlessly capture screenshots of web pages. Built on Node.js, it leverages headless browser technology (such as Puppeteer with Chromium) to render web content and then capture it as an image. This makes it ideal for automated tasks like visual regression testing, archiving web pages, generating thumbnails, or simply getting a quick snapshot of a site without a graphical browser. It supports various output formats (PNG, JPG), custom resolutions, full-page screenshots, element-specific captures, and advanced features like custom headers, cookies, JavaScript injection, and dark mode emulation, providing great flexibility for web developers and system administrators alike.


title: CAVEATS
content:
<i>pageres</i> requires Node.js and a working internet connection to fetch web pages. It downloads and uses a Chromium browser instance via Puppeteer, which can consume significant disk space and memory, especially when capturing many screenshots concurrently or at high resolutions. Complex, highly interactive web pages might require careful tuning of <b>--delay</b> or custom JavaScript injection to ensure all content is rendered before capture. Network issues or heavily protected sites (e.g., with strong CAPTCHAs or bot detection) may hinder its operation.


title: INSTALLATION
content:
<i>pageres</i> is typically installed globally using npm (Node Package Manager).<br><b>npm install --global pageres-cli</b><br><br>Ensure you have Node.js and npm installed on your system before attempting installation.


title: USAGE EXAMPLES
content:
Capture a basic screenshot of example.com at 1024x768 resolution:<br><b>pageres example.com 1024x768</b><br><br>Screenshot multiple URLs and sizes, saving them to a 'screenshots' directory:<br><b>pageres google.com twitter.com 1280x800 800x600 --dest=screenshots</b><br><br>Capture the full page of a specific element:<br><b>pageres wikipedia.org --full-page --selector='.mw-parser-output'</b><br><br>Add a 5-second delay before capturing:<br><b>pageres myanimatedsite.com --delay=5</b><br><br>Save as a JPEG with 80% quality:<br><b>pageres github.com 1024x768 --format=jpg --quality=80</b>


title: HISTORY
content:
<i>pageres</i> was created by Sindre Sorhus, a prolific Node.js developer known for many popular open-source packages. It emerged as a solution for programmatic web screenshotting in the Node.js ecosystem. Initially, it might have relied on libraries like PhantomJS, but it later transitioned to using Puppeteer, which provides a high-level API to control headless Chrome or Chromium. This shift greatly improved its performance, reliability, and modern web compatibility, making it a staple tool for web automation and development tasks since its inception.


title: DESCRIPTION
content:
The term <I>pake</I> does not correspond to a widely recognized or standard command-line utility in common Linux distributions like Debian/Ubuntu, Fedora/RHEL, or Arch Linux. Users encountering <B>pake</B> might be referring to a specific custom script, a typo for a different command (e.g., <I>make</I>, <I>pacman</I>, <I>apk</I>, <I>pkg</I>), or they might be thinking of <I>PAKE</I> which stands for <B>Password Authenticated Key Exchange</B>.<br><br>PAKE protocols are cryptographic methods that allow two parties to establish a secure session key using a pre-shared, low-entropy password, without transmitting the password itself and preventing offline dictionary attacks. While PAKE is a significant cryptographic concept, there isn't a standard command-line tool directly named <B>pake</B> to implement these protocols on typical Linux systems. Specific implementations might exist within cryptographic libraries or specialized tools.


title: CAVEATS
content:
The command <B>pake</B> is not part of standard Linux command-line utilities. Attempting to execute it on a typical system will likely result in a "command not found" error. It should not be confused with the cryptographic concept of <B>P</B>assword <B>A</B>uthenticated <B>K</B>ey <B>E</B>xchange (PAKE) protocols, which are theoretical constructs or implemented within specific software libraries rather than as a general-purpose command-line tool.


title: COMMAND NOT FOUND
content:
If you try to run <B>pake</B> in your terminal, you will most likely receive an error message such as 'command not found', indicating that the system does not recognize or have access to such a command.


title: POSSIBLE MISSPELLINGS
content:
Consider if you might have misspelled another command, such as <I>make</I>, <I>pacman</I>, <I>package</I> (related to package managers), or even a custom script you might have installed.


title: HISTORY
content:
There is no documented history for a standard <B>pake</B> Linux command as it does not exist in common distributions. The term "PAKE" (Password Authenticated Key Exchange) as a cryptographic concept has a rich history, with research and development dating back to the late 1990s and early 2000s, aiming to solve the challenge of secure key establishment using weak passwords. However, this concept is distinct from a standalone command-line utility named <B>pake</B>.


title: PARAMETERS
content:
<b><b>-index</b> <I>N</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the <I>N</I>th image from the input file. Some Palm database files can contain multiple bitmap images. This option specifies which one to convert. If omitted, the first image (index 1) is typically selected.<br><br><b><b>-forcecolor</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the output to be in <I>PPM</I> (color) format, even if the input Palm image appears to be grayscale or monochrome. By default, <I>palmtopnm</I> tries to determine the most appropriate PNM format (PBM, PGM, or PPM) based on the image content.<br><br><b><b>-verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints verbose information about the conversion process to standard error. This can be useful for debugging or understanding how the command interprets the input file.<br><br><b><I>palmfile</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the Palm Pilot image database file (<I>.pdb</I> or <I>.prc</I>) to be converted. If this parameter is omitted, <I>palmtopnm</I> reads its input from standard input.<br><br>


title: DESCRIPTION
content:
<b>palmtopnm</b> is a command-line utility that converts bitmap images found within Palm Pilot database files (commonly with <I>.pdb</I> or <I>.prc</I> extensions) into the <I>Portable Anymap (PNM)</I> format. PNM is a collective term for <I>PBM</I> (Portable Bitmap), <I>PGM</I> (Portable Graymap), and <I>PPM</I> (Portable Pixmap). This tool is part of the extensive <I>Netpbm</I> graphics toolkit, which provides a rich set of utilities for manipulating graphic images.<br><br>It reads the Palm image data, which can contain multiple images, and outputs the converted image to standard output, suitable for piping to other <I>Netpbm</I> tools or saving to a file. The command automatically determines the best PNM subformat (PBM, PGM, or PPM) based on the color depth of the input Palm image, unless overridden by options.


title: CAVEATS
content:
<b>palmtopnm</b> relies on the internal structure of Palm Pilot bitmap records, which can vary across different Palm OS versions or applications. It may not correctly parse all historical or future variations of Palm image formats.<br><br>The command always writes the converted PNM image to standard output. To save it to a file, you must redirect the output (e.g., <I>palmtopnm input.pdb > output.pnm</I>).<br><br>The quality of the conversion depends on the accuracy of the Palm image format specification implemented by the tool.


title: <B>STANDARD INPUT/OUTPUT USAGE</B>
content:
When no <I>palmfile</I> argument is provided, <I>palmtopnm</I> reads the Palm Pilot image data from standard input. This allows it to be used in pipelines, e.g., <I>cat image.pdb | palmtopnm > output.pnm</I>. The output PNM image is always written to standard output, making it highly compatible with other command-line tools.


title: <B>PART OF NETPBM</B>
content:
As a component of the <I>Netpbm</I> suite, <I>palmtopnm</I> is designed to integrate seamlessly with other <I>Netpbm</I> utilities. The PNM output can be easily piped to other tools for further processing, such as scaling (<I>pnmscale</I>), cropping (<I>pnmcut</I>), converting to other widely used formats (<I>pnmtojpeg</I>, <I>pnmtopng</I>, <I>pnmtogif</I>), or applying various image effects.


title: HISTORY
content:
<b>palmtopnm</b> is part of the <I>Netpbm</I> project, which evolved from the <I>PBMplus</I> package developed by Jef Poskanzer. The <I>Netpbm</I> toolkit has been a staple in Unix-like environments for image manipulation since the early 1990s, providing a modular and extensible set of tools for converting and transforming various image formats, including this specific utility for Palm Pilot images. Its development reflects the need for cross-platform image conversion tools in the era of early personal digital assistants (PDAs).


title: SYNOPSIS
content:
<b>pam-auth-update</b> [<b>--enable</b> <i>FEATURE</i> | <b>--disable</b> <i>FEATURE</i>] ... [<b>--remove</b> <i>FEATURE</i>] ... [<b>--force</b>] [<b>--preserve-local</b>]


title: PARAMETERS
content:
<b><b>--enable</b> <i>FEATURE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables the specified PAM <i>FEATURE</i> (e.g., 'unix', 'ldap') in the common configuration. This option can be used multiple times.<br><br><b><b>--disable</b> <i>FEATURE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the specified PAM <i>FEATURE</i> in the common configuration. This option can be used multiple times.<br><br><b><b>--remove</b> <i>FEATURE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the specified PAM <i>FEATURE</i> and removes it from the list of available choices for future updates. This option can be used multiple times.<br><br><b><b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces a full update of the PAM configuration without prompting for user interaction, even if no changes are detected.<br><br><b><b>--preserve-local</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <i>pam-auth-update</i> from modifying the <i>/etc/pam.d/common-local</i> file, preserving any local customizations.<br><br>


title: DESCRIPTION
content:
<i>pam-auth-update</i> is a utility primarily used on Debian-based systems to manage the common PAM (Pluggable Authentication Modules) authentication configuration files, typically found in <i>/etc/pam.d/</i>. These files, such as <i>common-auth</i>, <i>common-account</i>, <i>common-password</i>, and <i>common-session</i>, define the default authentication stack for various system services.<br><br>When PAM-aware packages are installed or updated, their post-installation scripts frequently invoke <i>pam-auth-update</i>. This ensures that any required PAM modules from the new or updated package are correctly integrated into the system's common authentication configuration. It provides a structured way for administrators to select which authentication profiles (e.g., Unix, Systemd, LDAP) are active. The command automates the process of maintaining consistent and up-to-date PAM configurations, thereby reducing the likelihood of manual errors and simplifying system administration. Essentially, it regenerates the <i>common-*</i> files based on available modules and previously stored user selections.


title: CAVEATS
content:
This command is primarily designed for Debian-based systems and might not be present or behave identically on other Linux distributions.<br>Manual modifications directly to the <i>/etc/pam.d/common-*</i> files will be overwritten by <i>pam-auth-update</i> unless those changes are encapsulated in <i>common-local</i> or the <b>--preserve-local</b> option is used.<br>Changes applied by <i>pam-auth-update</i> typically require affected services (e.g., sshd, login) to be restarted for the new PAM configurations to take effect.<br>Incorrect usage or disabling critical authentication features can potentially lead to system login issues.


title: CONFIGURATION FILES MANAGED
content:
<i>pam-auth-update</i> primarily manages the following files in <i>/etc/pam.d/</i>: <i>common-auth</i>, <i>common-account</i>, <i>common-password</i>, and <i>common-session</i>. It also considers the contents of <i>/etc/pam.d/common-local</i> for user-defined customizations.


title: PAM FEATURE DEFINITIONS
content:
The specific PAM <i>FEATURES</i> (e.g., 'unix', 'systemd', 'ldap') that <i>pam-auth-update</i> can enable or disable are defined by configuration files located in the <i>/usr/share/pam-configs/</i> directory. Each file describes the PAM module lines associated with a particular feature.


title: NON-INTERACTIVE MODE
content:
For use in scripts or automated environments, <i>pam-auth-update</i> can be run non-interactively by setting the <b>DEBIAN_FRONTEND</b> environment variable to 'noninteractive' or 'batch' (e.g., <b>DEBIAN_FRONTEND=noninteractive pam-auth-update --force</b>).


title: HISTORY
content:
<i>pam-auth-update</i> emerged as part of the <i>libpam-runtime</i> package in Debian-based distributions. Its development was driven by the need to standardize and simplify PAM configuration management across various installed packages. Prior to its introduction, managing PAM module interactions could be complex and prone to conflicts. The command's existence streamlines the process of integrating new authentication methods and ensuring system-wide PAM consistency, evolving with the distribution's approach to centralizing PAM configuration through the <i>common-*</i> files.


title: SYNOPSIS
content:
<i>pam_access.so</i> [<i>conf=/path/to/file</i>] [<i>debug</i>] [<i>fieldsep=char</i>] [<i>no_warn</i>]


title: PARAMETERS
content:
<b>conf=/path/to/file</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative access control file instead of the default <i>/etc/security/access.conf</i>.<br><br><b>debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose logging of debug information to <i>syslog</i>.<br><br><b>fieldsep=char</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the character used to separate fields (access, users, origins) in the configuration file. Default is a colon (:).<br><br><b>no_warn</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables logging of warnings generated by the module to <i>syslog</i>.<br><br>


title: DESCRIPTION
content:
The <b>pam_access</b> module provides a flexible mechanism for system access control within the Pluggable Authentication Modules (PAM) framework. It evaluates predefined rules to grant or deny login access based on the user's identity, group membership, and the origin of the login attempt (e.g., specific TTY, hostname, IP address, or time of day).<br><br>Access rules are typically defined in the <i>/etc/security/access.conf</i> file. Each rule specifies whether access is granted (+) or denied (-) for a given user or group, originating from a particular source. The module is usually invoked as part of the <i>auth</i> or <i>account</i> stack in PAM configuration files (e.g., <i>/etc/pam.d/sshd</i>). Its primary function is to enforce system-wide access policies, complementing other authentication and authorization mechanisms.


title: CAVEATS
content:
The effectiveness of <b>pam_access</b> heavily depends on its placement within the PAM configuration stack; it should typically be configured as an <i>account</i> or <i>auth</i> module and invoked before any modules that unconditionally grant access. Misconfigurations in <i>/etc/security/access.conf</i> can lead to unexpected access denials or, conversely, unauthorized access. Be cautious with hostnames as origin rules, as DNS resolution issues can impact login performance. Remember that rules are processed sequentially, and the first matching rule applies.


title: CONFIGURATION FILE (ACCESS.CONF) FORMAT
content:
The primary configuration for <b>pam_access</b> resides in <i>/etc/security/access.conf</i>. Each rule in this file is structured as:<br><br><b><i>&lt;permission&gt; : &lt;users&gt; : &lt;origins&gt;</i></b><br><br><ul><li><b>&lt;permission&gt;</b>: Must be either <b>+</b> (grant access) or <b>-</b> (deny access).</li><li><b>&lt;users&gt;</b>: A comma-separated list of usernames, group names (prefixed with <i>@</i>), or the special keyword <i>ALL</i>.</li><li><b>&lt;origins&gt;</b>: A comma-separated list of <i>tty</i> names, hostnames, IP addresses (with optional netmask), network group names (prefixed with <i>@</i>), or time intervals (e.g., <i>MoTuTh1000-1500</i>). The special keywords <i>ALL</i> and <i>LOCAL</i> are also available.</li></ul><br>Rules are processed sequentially from top to bottom, and the first matching rule determines the outcome. The <i>EXCEPT</i> operator can be used within the <i>users</i> or <i>origins</i> fields to specify exceptions.


title: HISTORY
content:
<b>pam_access</b> is part of the Linux-PAM (Pluggable Authentication Modules) project, which was developed to provide a standardized, modular framework for authentication services in Linux. PAM itself originated in SunSoft and was later adopted by various Unix-like systems. <b>pam_access</b> provides a standard way to implement host and user-based access control rules, offering a more granular control than simple <i>/etc/hosts.allow</i> and <i>/etc/hosts.deny</i> for login services.


title: SYNOPSIS
content:
As a PAM module, <i>pam_ck_connector</i> is not executed directly as a command-line utility by users. Instead, it is invoked by the PAM system during user login and logout processes. Its "invocation" is defined within PAM configuration files, typically located in <i>/etc/pam.d/</i>.<br><br>The common syntax for its inclusion in a PAM configuration file (e.g., <i>/etc/pam.d/login</i> or <i>/etc/pam.d/system-auth</i>) is:<br><br><pre><code>session  <i>optional</i>  pam_ck_connector.so</code></pre><br>Or, if used with specific control flags (rarely needed for this module):<br><br><pre><code>session  <i>[success=1 default=ignore]</i>  pam_ck_connector.so</code></pre><br>Here, "<i>session</i>" indicates it's part of the session management stack, and "<i>optional</i>" suggests that its failure should not prevent a session from being established, though this might lead to incomplete session tracking. The "<i>.so</i>" suffix denotes it as a shared library module.


title: PARAMETERS
content:
<b><i>(No direct command-line parameters)</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;As an internal PAM module, <i>pam_ck_connector</i> typically does not accept direct command-line parameters. Its behavior is largely fixed: to report session events to ConsoleKit or <i>systemd-logind</i>.<br><br><b><b><i>debug</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Like other PAM modules, it can be accompanied by standard PAM control flags in <i>/etc/pam.d/</i> configuration files. This flag enables logging of verbose debugging information, which can be useful for troubleshooting.<br><br><b><b><i>quiet</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A standard PAM control flag that suppresses non-essential messages from the module.<br><br><b><b><i>non_interactive</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A standard PAM control flag used in contexts where no user interaction is possible. It's important to note that <i>pam_ck_connector</i> itself rarely, if ever, uses these flags to modify its core functionality; they are primarily PAM framework directives.<br><br>


title: DESCRIPTION
content:
<i>pam_ck_connector</i> is a Pluggable Authentication Module (PAM) designed to integrate the PAM authentication stack with the session management capabilities provided by systems like ConsoleKit or <i>systemd-logind</i>. Its primary role is to inform these session managers about the creation and termination of user sessions. When a user logs in (e.g., via <i>login</i>, <i>sshd</i>, or a display manager), PAM processes the authentication, and if <i>pam_ck_connector</i> is configured in the session stack, it notifies the session manager that a new session has started. Similarly, upon logout, it signals the session manager to end the session. This interaction is crucial for tracking active user sessions, associating them with specific seats (physical or virtual terminals), and managing resources like display servers, power management, and device access. It ensures that system services are aware of who is logged in and what resources they are using, facilitating proper resource allocation and security policies. It operates in the background as part of the PAM workflow, making it an invisible but vital component of a desktop or server environment's user session management.


title: CAVEATS
content:
<ul><li><b>Dependency</b>: <i>pam_ck_connector</i> relies on the presence and proper functioning of a session manager like ConsoleKit or <i>systemd-logind</i>. If these services are not running or configured correctly, the module might fail to report session information, leading to issues with desktop environments, power management, and device access for logged-in users.</li><li><b>Superseded Technology</b>: In modern Linux distributions that use <i>systemd</i>, ConsoleKit has largely been superseded by <i>systemd-logind</i>. While <i>pam_ck_connector</i> might still be present for compatibility or specific niche setups, <i>pam_systemd</i> is the module typically used to integrate with <i>systemd-logind</i> directly. Users should verify which session manager their system employs.</li><li><b>Internal Use</b>: This module is intended for internal system use within the PAM framework and should not be manually invoked or modified by end-users unless they have a deep understanding of PAM and session management. Incorrect configuration can lead to authentication failures or incomplete session tracking.</li></ul>


title: SESSION CGROUP MANAGEMENT
content:
Beyond just reporting session starts and ends, <i>pam_ck_connector</i> (and its successor <i>pam_systemd</i>) plays a role in creating and managing control groups (CGroups) for user sessions. When a user logs in, the session manager (ConsoleKit or <i>systemd-logind</i>) typically creates a dedicated CGroup for that session. All processes launched within that session are then placed into this CGroup. This allows the system to accurately track resources used by the session, apply resource limits, and ensure that all session-related processes are properly terminated upon logout. This mechanism is fundamental for robust multi-user environments and modern desktop functionality.


title: INTEGRATION WITH DISPLAY MANAGERS
content:
Display managers like GDM, LightDM, or SDDM are often configured to use PAM for authentication and session management. When you log into your graphical desktop, the display manager uses PAM, and if <i>pam_ck_connector</i> (or <i>pam_systemd</i>) is in the session stack, it ensures that the session manager is informed about the graphical session's creation. This enables functionalities such as proper suspension/hibernation, user switching, and device hot-plugging to work seamlessly within the desktop environment.


title: HISTORY
content:
The <i>pam_ck_connector</i> module emerged as part of the ConsoleKit project, which aimed to centralize session management on Linux systems, particularly for desktop environments. Before ConsoleKit, managing user sessions, device access, and power management across various login methods was fragmented. ConsoleKit provided a unified D-Bus API for these tasks, and <i>pam_ck_connector</i> was its PAM-side interface, ensuring that PAM could communicate session start/end events to ConsoleKit.<br><br>With the rise of <i>systemd</i>, many distributions transitioned from ConsoleKit to <i>systemd-logind</i>, which provides similar session management capabilities integrated directly into the init system. While <i>pam_ck_connector</i> might still be found in some systems for legacy reasons or specific configurations, its role has largely been taken over by <i>pam_systemd</i>, which serves the same function but for <i>systemd-logind</i>. Its development and usage are closely tied to the evolution of desktop environments and system initialization on Linux.


title: SYNOPSIS
content:
This module is configured within PAM service files (e.g., <I>/etc/pam.d/sshd</I>).<br><br><b><I>module_type</I> &nbsp;&nbsp;&nbsp; <I>control_flag</I> &nbsp;&nbsp;&nbsp; <I>pam_debug.so</I> &nbsp;&nbsp;&nbsp; [options]</b><br><br><i>Example:</i><br><I>auth &nbsp;&nbsp;&nbsp; sufficient &nbsp;&nbsp;&nbsp; pam_debug.so &nbsp;&nbsp;&nbsp; debug</I><br><I>account &nbsp;&nbsp;&nbsp; required &nbsp;&nbsp;&nbsp; pam_debug.so &nbsp;&nbsp;&nbsp; log_pass</I><br><br><I>module_type</I>: Specifies the interface (e.g., <I>auth</I>, <I>account</I>, <I>password</I>, or <I>session</I>).<br><I>control_flag</I>: Dictates the module's behavior within the stack (e.g., <I>requisite</I>, <I>required</I>, <I>sufficient</I>, <I>optional</I>).


title: PARAMETERS
content:
<b>debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Logs all arguments passed to the PAM module and its return values. This is the most common and comprehensive debugging option.<br><br><b>log_pass</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Logs sensitive information such as user passwords (both new and old, if applicable) if they are passed to the module. <br><b><I>Use with extreme caution due to severe security implications. Never use in production environments.</I></b><br><br><b>log_user</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Logs the username involved in the PAM transaction.<br><br><b>log_ruser</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Logs the remote username, if the PAM transaction involves a remote user.<br><br><b>log_rhost</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Logs the remote host name or IP address, if the PAM transaction originates from a remote host.<br><br><b>log_tty</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Logs the name of the TTY (terminal) device associated with the PAM transaction.<br><br><b>log_service</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Logs the service name (e.g., 'sshd', 'login') that invoked the PAM stack.<br><br><b>log_item=<I>item_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Logs the value of a specific PAM item (e.g., <I>PAM_USER</I>, <I>PAM_AUTHTOK</I>, <I>PAM_CONV</I>). This option can be specified multiple times to log several items.<br><br>


title: DESCRIPTION
content:
<I>pam_debug</I> is a Pluggable Authentication Modules (PAM) module designed for <I>diagnostic purposes</I>. It is not a standalone executable command but rather a component configured within PAM service configuration files, such as those found in <I>/etc/pam.d/</I>.<br><br>When included in a PAM stack, <I>pam_debug.so</I> logs detailed information about the PAM calls made to it, including the arguments passed to the module and its return values. This logging capability is invaluable for <I>troubleshooting</I> complex PAM configurations, helping administrators identify why authentication, authorization, or session management might be failing.<br><br>It enables a deeper understanding of the flow of control within the PAM stack, allowing users to pinpoint which specific modules are behaving unexpectedly or returning undesired results. The logged information typically goes to the system's syslog, often at the <I>LOG_DEBUG</I> level.


title: CAVEATS
content:
<b>Security Risk:</b> The <I>log_pass</I> option can expose sensitive user passwords in plaintext within system logs. It must <I>never</I> be used in a production environment and only with extreme caution in isolated debugging setups.<br><br><b>Performance Impact:</b> Enabling extensive debug logging can introduce noticeable overhead, potentially slowing down authentication and authorization processes on the system.<br><br><b>Log Volume:</b> Debug logging generates a substantial volume of log entries, which can rapidly consume disk space and make it more challenging to sift through logs for other critical system events.<br><br><b>Temporary Use:</b> <I>pam_debug</I> is strictly intended for temporary troubleshooting. It is crucial to remove or comment out <I>pam_debug</I> entries from PAM configuration files once the issue is resolved to mitigate security risks and performance degradation.


title: LOGGING LOCATION
content:
By default, <I>pam_debug</I> logs messages to the system's syslog daemon. These messages are typically sent with the <I>auth</I> facility and a <I>debug</I> priority level. Depending on the system's <I>syslog</I> configuration (e.g., <I>/etc/rsyslog.conf</I>), these logs commonly appear in files like <I>/var/log/auth.log</I>, <I>/var/log/secure</I>, or <I>/var/log/messages</I>.


title: USAGE BEST PRACTICES
content:
When employing <I>pam_debug</I> for troubleshooting, consider the following best practices:<br>1.  <b>Limit Scope:</b> Add the <I>pam_debug</I> module to a specific PAM service file (e.g., <I>/etc/pam.d/sshd</I>) rather than a common, system-wide configuration file like <I>system-auth</I> to restrict the volume and scope of logging.<br>2.  <b>Strategic Placement:</b> Position the <I>pam_debug</I> entry strategically within the PAM stack, typically just before or after the modules you suspect are causing issues, to capture relevant information.<br>3.  <b>Immediate Removal:</b> Always remove or comment out the <I>pam_debug</I> module from your PAM configuration files immediately after debugging is complete to prevent security vulnerabilities, performance degradation, and excessive log generation.


title: HISTORY
content:
The Pluggable Authentication Modules (PAM) framework was originally developed by Sun Microsystems in the mid-1990s to provide a flexible and modular approach to authentication services on Unix-like operating systems. <I>pam_debug.so</I> has been an integral part of the Linux-PAM (an open-source implementation of PAM) suite since its early versions, serving as an essential tool for administrators and developers to diagnose and understand PAM interactions. Its core purpose and usage have remained consistent throughout PAM's evolution, solidifying its role as a fundamental diagnostic component.


title: SYNOPSIS
content:
<I>pam_deny</I> is a PAM module, not a standalone command. It is invoked within PAM configuration files, typically located in <I>/etc/pam.d/</I>.<br><br>The general syntax for including a PAM module in a configuration file line is:<br><br><I>module-interface</I>  <I>control-flag</I>  pam_deny.so  [<I>module-arguments</I>]<br><br>Example usage in a PAM configuration file:<br><pre>auth    requisite   pam_deny.so<br>account required    pam_deny.so</pre><br>Here, <I>module-interface</I> refers to the PAM management group (e.g., <I>auth</I>, <I>account</I>), and <I>control-flag</I> determines the module's behavior within the PAM stack (e.g., <I>requisite</I>, <I>required</I>, <I>sufficient</I>, <I>optional</I>). <I>pam_deny.so</I> is the module library. No module-specific arguments are typically used with <I>pam_deny.so</I>.


title: PARAMETERS
content:
<b><I>module-interface</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The PAM management group to which this module applies, such as <b>auth</b> (authentication), <b>account</b> (account management), <b>password</b> (password changes), or <b>session</b> (session management).<br><br><b><I>control-flag</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Determines the module's impact on the overall success or failure of the PAM transaction. Common flags include <b>requisite</b> (failure aborts immediately), <b>required</b> (failure eventually denies but stack continues), <b>sufficient</b> (success returns immediately if no prior <b>required</b> failure), and <b>optional</b> (success/failure not critical).<br><br><b><I>module-arguments</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Arguments specific to the PAM module. <b>pam_deny.so</b> does not accept any specific arguments. Any arguments listed after <I>pam_deny.so</I> on the configuration line would be ignored by this particular module.<br><br>


title: DESCRIPTION
content:
The <b>pam_deny</b> module is a core component of the Pluggable Authentication Modules (PAM) framework in Linux. Unlike typical authentication modules that verify user credentials, <b>pam_deny</b> serves a singular, explicit purpose: to unconditionally deny any authentication, account, password, or session management request it processes. It is designed to always fail, regardless of user input or system state.<br><br>This module is not a standalone command but rather a shared library (<I>pam_deny.so</I>) loaded and invoked by the PAM system based on configurations in files like <I>/etc/pam.d/service_name</I>. Its primary use cases include:<br><br>1.  <b>Hardening a Service</b>: Placing <I>pam_deny.so</I> with a <I>requisite</I> control flag at the beginning of a PAM stack can effectively disable access to a specific service.<br>2.  <b>Default Deny</b>: As a final module in a stack, ensuring that if all preceding modules permit access, a denial is issued instead.<br>3.  <b>Explicit Denial</b>: In complex PAM configurations, it can be used to ensure that certain conditions or specific users are always denied access, overriding other potential grants.<br><br>Due to its absolute denial behavior, <b>pam_deny</b> must be used with extreme caution within PAM configuration files to avoid unintentionally locking out legitimate users or administrators from critical services.


title: CAVEATS
content:
Using <b>pam_deny</b> incorrectly can lead to severe access issues, potentially locking users, including administrators, out of services or even the entire system. It should always be placed carefully within the PAM stack, considering the order of modules and their control flags. For instance, placing it too early with a <I>requisite</I> flag might deny all access, regardless of subsequent modules.


title: SECURITY IMPLICATIONS
content:
The primary security implication of <b>pam_deny</b> is its ability to enforce a 'default deny' or 'explicit deny' policy. This is a critical security principle, ensuring that access is only granted when explicitly allowed by other modules in the PAM stack. It can be used to permanently disable specific login methods or to create highly restrictive access policies for sensitive services.


title: HISTORY
content:
<b>pam_deny</b> is a foundational PAM module that has been part of the Linux PAM (Pluggable Authentication Modules) suite since its early development. The PAM framework itself was developed to provide a flexible and modular authentication mechanism, abstracting authentication details from applications. Modules like <I>pam_deny.so</I> (and its counterpart <I>pam_permit.so</I>) represent the most basic building blocks for defining access policies, making them essential components from the inception of PAM.


title: SYNOPSIS
content:
Usage in PAM configuration files (e.g., /etc/pam.d/common-auth):<br><pre><i>module_type control_flag pam_echo.so [options]</i></pre><br>Example:<br><pre><i>auth optional pam_echo.so text="Welcome to the system. Usage is logged."</i></pre><br>The <i>module_type</i> is typically <b>auth</b> or <b>session</b>.<br>The <i>control_flag</i> can be <b>required</b>, <b>requisite</b>, <b>sufficient</b>, or <b>optional</b>. <b>optional</b> is common for <i>pam_echo</i>.


title: PARAMETERS
content:
<b>file=/path/to/message</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a file from which the message to be displayed should be read. The entire content of the file will be printed.<br><br><b>text="message content"</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the message directly as a string. If both <b>file</b> and <b>text</b> are provided, <b>text</b> takes precedence.<br><br><b>term=true/false</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls whether the message should only be displayed if a TTY (terminal) is attached to the process. The default value is <b>true</b>. Set to <b>false</b> to display messages even without a TTY.<br><br><b>no_newline</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the module from appending a newline character after the displayed message. Useful if the message itself already includes a newline or for custom formatting.<br><br><b>echo_once</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ensures that the message is displayed only once per authentication conversation, even if the module is invoked multiple times in the PAM stack.<br><br><b>only_when_needed</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Causes the module to display its message only if there is an authentication prompt or an authentication failure that requires user interaction. This prevents messages from being shown unnecessarily.<br><br>


title: DESCRIPTION
content:
The <i>pam_echo.so</i> module is a utility module within the Linux-PAM (Pluggable Authentication Modules) framework. Its primary function is to display arbitrary messages to the user during the authentication or session management process. It does not perform any authentication itself, but rather serves as a means to provide informational, warning, or policy-related messages to the user. This module is typically configured in PAM configuration files (e.g., in /etc/pam.d/) and can be used with <b>auth</b> or <b>session</b> module types. Messages can be supplied directly as a string or read from a specified file. It's often used to remind users of security policies, system usage agreements, or to provide context for authentication prompts. Its non-critical nature allows it to be used with the <b>optional</b> control flag, meaning its failure won't necessarily halt the authentication process.


title: CAVEATS
content:
<ul><li><i>pam_echo</i> is designed for simple message display and should not be used for critical security warnings or handling sensitive user input.</li><li>The appearance and display of messages can vary depending on the terminal emulator, application, and PAM-aware service. Messages might be truncated or formatted differently.</li><li>Careful placement within the PAM stack is essential. Placing it too early might display messages before relevant context is established, or too late, making them redundant.</li></ul>


title: PAM MODULE TYPE USAGE
content:
<i>pam_echo</i> is typically configured as an <b>auth</b> or <b>session</b> module type in <i>pam.d</i> files.<br><ul><li>When used as an <b>auth</b> module, messages are displayed during the authentication phase (e.g., before or after username/password prompts).</li><li>When used as a <b>session</b> module, messages are displayed at the start or end of a user session.</li></ul>


title: PURPOSE
content:
This module is particularly useful for:<br><ul><li>Providing legal disclaimers or "banner" messages before login.</li><li>Reminding users about password expiration policies.</li><li>Notifying users about system maintenance or upcoming changes.</li><li>Displaying general welcome messages.</li></ul>


title: SYNOPSIS
content:
This module is configured within <I>PAM</I> service files, not executed directly from the command line.<br>The typical usage in a PAM configuration file looks like this:<br><b><i>service</i> <i>type</i> <i>control</i> pam_ecryptfs.so [<i>options</i>]</b><br><br>For example:<br><i>session    optional    pam_ecryptfs.so</i><br><i>auth       optional    pam_ecryptfs.so  passwd_auth</i>


title: PARAMETERS
content:
<b>ecryptfs_private=<path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the absolute path to the user's eCryptfs private directory. Defaults to <i>~/.Private</i> if not specified.<br><br><b>passwd_auth</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs the module to use the user's login passphrase to derive the key for unlocking the eCryptfs private directory. This is a common and often required option for seamless integration.<br><br><b>unlink_on_unmount</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When specified, the mount point directory will be unlinked (removed) after the eCryptfs filesystem is unmounted. Use with caution as this deletes the empty directory.<br><br><b>no_unmount_on_logout</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the module from automatically unmounting the eCryptfs directory when the user logs out. The directory will remain mounted.<br><br><b>auto_unmount</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ensures that the eCryptfs directory is automatically unmounted when the user's session ends. This is often the default and desired behavior.<br><br><b>verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables more verbose logging output from the module, useful for debugging and understanding its operations.<br><br><b>syslog</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Directs the module's log messages to syslog, making them visible in system logs (e.g., <i>/var/log/auth.log</i>).<br><br>


title: DESCRIPTION
content:
<b>pam_ecryptfs</b> is a <I>Pluggable Authentication Module</I> (PAM) designed to seamlessly integrate <I>eCryptfs</I> encrypted directories, most commonly user home directories, with the login and logout processes. When configured in PAM service files (e.g., <i>/etc/pam.d/common-auth</i> or <i>/etc/pam.d/common-session</i>), it facilitates the automatic mounting of a user's <I>eCryptfs</I> private directory upon successful authentication and its subsequent unmounting upon session termination.<br><br>This module leverages the user's login passphrase, or a derived key, to unlock the <I>eCryptfs</I> master passphrase, ensuring data privacy and security. It typically operates as a <I>session</I> module, handling the mount and unmount operations, but can also be used as an <I>auth</I> module for specific authentication-related tasks. Its primary role is to simplify the management of encrypted home directories, making them transparent to the end-user while maintaining robust encryption.


title: CAVEATS
content:
<b><I>Performance Overhead:</I></b> Encryption and decryption add computational overhead, which can slightly impact filesystem performance.<br><b><I>Key Management:</I></b> If the login passphrase used to derive the eCryptfs key is changed or forgotten, careful key management (e.g., passphrase re-wrapping) is necessary to avoid data loss.<br><b><I>Data Recovery:</I></b> Recovery of data from a corrupted or inaccessible eCryptfs directory can be challenging without the correct master passphrase or mount options.<br><b><I>Pre-setup Required:</I></b> <b>pam_ecryptfs</b> assumes that eCryptfs has been properly set up for the user's directory beforehand (e.g., using <i>ecryptfs-migrate-home</i>). It does not set up the encryption itself.<br><b><I>Troubleshooting Complexity:</I></b> Issues related to PAM and eCryptfs can be complex to diagnose, often requiring examination of system logs and PAM configuration files.


title: PAM MODULE TYPE
content:
<b>pam_ecryptfs</b> primarily functions as a <I>session</I> module, responsible for mounting the eCryptfs private directory at session start and unmounting it at session end. However, it can also be configured as an <I>auth</I> module in specific scenarios, particularly when the authentication process itself needs to interact with the eCryptfs keyring.


title: CONFIGURATION CONTEXT
content:
This module is configured by adding lines to service-specific <I>PAM</I> configuration files located in <i>/etc/pam.d/</i> (e.g., <i>login</i>, <i>sshd</i>, <i>common-session</i>, <i>common-auth</i>). Its effective behavior depends on the chosen <I>PAM</I> control flags (e.g., <i>requisite</i>, <i>required</i>, <i>sufficient</i>, <i>optional</i>) and its placement relative to other modules in the PAM stack.


title: HISTORY
content:
<b>pam_ecryptfs</b> was developed as an integral part of the <I>eCryptfs</I> project, aiming to provide seamless encrypted home directories for Linux users. It gained significant adoption, particularly within Ubuntu, where it was offered as a default or recommended option for encrypting user home directories during installation for several releases. Its development has been closely tied to the evolution of the <I>eCryptfs</I> filesystem itself, focusing on simplifying the user experience of encrypted data.


title: SYNOPSIS
content:
<i>pam_env.so</i> is configured in PAM service files.<br>Syntax in <I>/etc/pam.d/*</I> files:<br><b><I>auth optional pam_env.so [options]</I></b><br><b><I>session optional pam_env.so [options]</I></b>


title: PARAMETERS
content:
<b>debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debugging output to syslog.<br><br><b>file=path<br>envfile=path</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative system-wide environment file to load instead of <I>/etc/environment</I>.<br><br><b>conf=path<br>conffile=path</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file to load instead of <I>/etc/security/pam_env.conf</I>.<br><br><b>user_envrc</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables processing of <I>~/.pam_envrc</I> for user-specific environment variables. This file must be owned by the user and have strict permissions (0600).<br><br><b>override</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows variables defined in the <I>pam_env.conf</I> file to override those defined in <I>/etc/environment</I>. By default, <I>/etc/environment</I> variables take precedence.<br><br><b>var=value</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly sets a single environment variable directly within the PAM configuration line. This is less common for general use cases.<br><br>


title: DESCRIPTION
content:
<i>pam_env</i> is a <I>PAM (Pluggable Authentication Modules)</I> module responsible for setting and unsetting environment variables for a user's session during the authentication or session management phase. It is not a standalone command executed directly by users, but rather a shared library (<i>pam_env.so</i>) configured within PAM service files, typically found in <I>/etc/pam.d/</I> (e.g., <I>/etc/pam.d/login</I>, <I>/etc/pam.d/sshd</I>).<br><br>The module reads environment variable definitions from various sources, primarily the system-wide <I>/etc/environment</I> file and its dedicated configuration file, <I>/etc/security/pam_env.conf</I>. It allows system administrators to define default environment variables like <I>PATH</I>, <I>LANG</I>, or <I>TZ</I> that apply to all users or specific services before the user's shell is launched. This ensures a consistent environment for all applications and processes initiated via PAM-aware services.<br><br><i>pam_env</i> supports variable expansion, allowing new variables to be defined based on existing ones or dynamic information. It is crucial for ensuring that the necessary environment is established for user sessions, especially in environments where users may not have custom shell configuration files (like <I>.bashrc</I> or <I>.profile</I>) or where system-wide defaults are enforced.


title: CAVEATS
content:
<i>pam_env</i> processes environment variables at the PAM level, which is before shell-specific configuration files (<I>.bashrc</I>, <I>.profile</I>, <I>.zshrc</I>) are sourced. Variables set by <i>pam_env</i> can be overridden by later shell configurations.<br><br>Using the <I>user_envrc</I> option requires careful attention to file permissions (<I>0600</I>) to prevent security vulnerabilities, as it can be used for privilege escalation if not properly secured.<br><br>Variable expansion in <I>pam_env.conf</I> uses its own syntax (<I>$(VAR)</I> or <I>${VAR}</I>) and does not support arbitrary shell commands or complex logic.


title: CONFIGURATION FILES
content:
The two primary configuration files for <i>pam_env</i> are:<br><ul><li><b><I>/etc/environment</I></b>: A simple file containing <I>KEY=VALUE</I> pairs, one per line. It is system-wide and typically processed first.</li><li><b><I>/etc/security/pam_env.conf</I></b>: A more powerful configuration file supporting syntax like <I>VAR=[value]</I> and <I>VAR={DEFAULT=[value] LOCALE=[value]}</I>, as well as variable expansion. It allows for more granular control, including setting variables based on locale.</li></ul>If the <I>user_envrc</I> option is used, <i>pam_env</i> will also look for <I>~/.pam_envrc</I> in the user's home directory.


title: VARIABLE EXPANSION
content:
<i>pam_env</i> supports two forms of variable expansion within its configuration files: <br><ul><li><b><I>$(VAR)</I></b>: Expands to the value of the environment variable <I>VAR</I>.</li><li><b><I>${VAR}</I></b>: Similar to <I>$(VAR)</I>, expands to the value of <I>VAR</I>.</li></ul>If the variable is not set, it expands to an empty string. This allows for defining new variables based on existing ones.


title: PROCESSING ORDER
content:
When <i>pam_env</i> processes environment variables, it typically follows this order:<br><ol><li>Variables from <I>/etc/environment</I> are loaded.</li><li>Variables from <I>/etc/security/pam_env.conf</I> are loaded. By default, these do not override variables from <I>/etc/environment</I> unless the <I>override</I> module option is used.</li><li>If <I>user_envrc</I> is enabled, variables from <I>~/.pam_envrc</I> are processed last, overriding previously set variables.</li></ol>This order ensures a hierarchical approach to environment variable management.


title: HISTORY
content:
<i>pam_env</i> is an integral part of the <I>Linux-PAM</I> (Pluggable Authentication Modules) project, which provides a flexible and modular framework for authentication services in Linux. Its development has focused on providing a standardized way to manage user session environments at the authentication layer, ensuring consistency and security across various services that leverage PAM. It has been a stable component of the PAM framework for many years.


title: SYNOPSIS
content:
auth | account | password | session [success=N default=ignore] pam_exec.so [options] /path/to/command [arguments...]


title: PARAMETERS
content:
<b>debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Logs debug information to syslog.<br><br><b>expose_authtok</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<B>SECURITY WARNING</B>: Exposes the user's authentication token (e.g., password) via the <I>PAM_AUTHTOK</I> environment variable to the executed command. Use with extreme caution.<br><br><b>expose_account</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exposes the account management status via the <I>PAM_ACCT_MGMT</I> environment variable.<br><br><b>log</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Logs the command's standard output and standard error to syslog.<br><br><b>quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses error messages if the executed command fails.<br><br><b>seteuid</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<B>SECURITY WARNING</B>: Executes the command with the effective UID of the authenticating user (or root if the user isn't known yet). This can be a security risk if the script is not properly secured.<br><br><b>type=[auth|account|session|password]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the PAM management group for which the command should run. If omitted, the module runs for its current context.<br><br><b>stdout</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Redirects the command's standard output to syslog.<br><br><b>stderr</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Redirects the command's standard error to syslog.<br><br><b>shell</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the specified command via <I>/bin/sh -c</I>, enabling shell features like pipes, redirections, and variables.<br><br><b>return=[N]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If the command returns 0 (success), the module returns the specified PAM error code <I>N</I>.<br><br><b>return_on_non_zero</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If the command returns a non-zero exit code, the module returns a PAM error appropriate for its module type (e.g., <I>PAM_AUTH_ERR</I> for auth).<br><br><b>fail_on_non_zero</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Similar to <I>return_on_non_zero</I>, but explicitly causes the PAM stack to fail if the command returns a non-zero exit code.<br><br><b>env=[VAR=VAL]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds an additional environment variable to the command's execution environment. Can be specified multiple times.<br><br><b>env_file=/path/to/file</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads additional environment variables from the specified file. Each line should be in <I>VAR=VAL</I> format.<br><br><b>uid=[UID]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the command as the specified user ID.<br><br><b>gid=[GID]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the command as the specified group ID.<br><br>


title: DESCRIPTION
content:
pam_exec is a versatile <I>Pluggable Authentication Module (PAM)</I> that allows the execution of arbitrary external commands or scripts during various stages of the PAM authentication process. <br><br>It provides a powerful mechanism for system administrators to integrate custom logic, checks, or actions into the authentication workflow. This can include tasks like logging successful or failed login attempts to a database, performing additional pre-login validation (e.g., IP-based restrictions), or setting up specific user environments post-login.<br><br>The module can be configured to run a command during the <I>auth</I>, <I>account</I>, <I>session</I>, or <I>password</I> PAM management group, passing relevant PAM environment variables to the executed script. The return status of the executed command can then be used to influence the overall PAM stack's outcome, making it an essential tool for extending system security and management capabilities.


title: CAVEATS
content:
<B>Security Implications</B>: Options like <I>expose_authtok</I> and <I>seteuid</I> can introduce significant security vulnerabilities if the executed scripts are not extremely carefully written and secured. Avoid exposing sensitive information or granting unnecessary privileges.<br><br><B>Performance Overhead</B>: Executing external commands adds latency to the authentication process. Scripts should be efficient and avoid lengthy operations.<br><br><B>Error Handling</B>: Scripts should be robust and handle potential errors gracefully. Unexpected script failures can lead to authentication issues or system instability.<br><br><B>Absolute Path</B>: The command path must be an absolute path; relative paths are not supported and can lead to security risks if not strictly controlled.<br><br><B>Environment Limitations</B>: The command runs in a minimal environment; relying on system-wide PATH or complex environment setups might lead to unexpected behavior.


title: <B>ENVIRONMENT VARIABLES PASSED TO COMMAND</B>
content:
When <I>pam_exec</I> runs a command, it populates several PAM-related environment variables for the executed script's use. These commonly include:<br>- <I>PAM_USER</I>: The username attempting to authenticate.<br>- <I>PAM_SERVICE</I>: The PAM service name (e.g., "login", "sshd").<br>- <I>PAM_TTY</I>: The terminal device name, if available.<br>- <I>PAM_RHOST</I>: The remote hostname, if applicable.<br>- <I>PAM_TYPE</I>: The PAM module type currently being processed (e.g., "auth", "session").<br>- <I>PAM_AUTHTOK</I>: (Only if <I>expose_authtok</I> is used) The authentication token (e.g., password).<br>- <I>PAM_ACCT_MGMT</I>: (Only if <I>expose_account</I> is used) Indicates the account management status.


title: <B>COMMAND RETURN VALUES AND PAM OUTCOME</B>
content:
The exit status of the command executed by <I>pam_exec</I> is crucial. By default, a zero (0) exit status usually indicates success to <I>pam_exec</I>, which then typically results in <I>PAM_SUCCESS</I> for the module. A non-zero exit status signals an error. The <I>return</I>, <I>return_on_non_zero</I>, and <I>fail_on_non_zero</I> options provide fine-grained control over how the command's exit status translates into a PAM module return code, allowing administrators to dictate how external script success or failure impacts the overall authentication process.


title: HISTORY
content:
<I>PAM (Pluggable Authentication Modules)</I> originated in the mid-1990s as a flexible framework to separate authentication policy from application code. <I>Linux-PAM</I> adopted this concept and has been a standard component of Linux systems for decades. <I>pam_exec</I> was developed as an integral part of <I>Linux-PAM</I> to provide a general-purpose mechanism for custom integration and extensibility, offering administrators a powerful hook into the authentication flow without modifying core PAM or service code. Its design emphasizes flexibility and control over the execution environment.


title: SYNOPSIS
content:
This module is configured within PAM service files, typically in the <I>session</I> type:<br><br><b>session optional pam_filter.so [module options]</b>


title: PARAMETERS
content:
<b><b>filter=</b><I>/path/to/filter_program</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to an external program that will be used to filter the I/O. This program should be designed to read from <I>stdin</I> and write to <I>stdout</I>.<br><br><b><b>filter_user=</b><I>username</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the specified filter program as the given <I>username</I> instead of the user whose session is being filtered or root. This is useful for security sandboxing.<br><br><b><b>no_input</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the filtering of standard input (<I>stdin</I>). Only output streams (<I>stdout</I>, <I>stderr</I>) will be filtered.<br><br><b><b>no_output</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the filtering of standard output (<I>stdout</I>). Only input (<I>stdin</I>) and standard error (<I>stderr</I>) will be filtered.<br><br><b><b>no_stderr</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the filtering of standard error (<I>stderr</I>). Only input (<I>stdin</I>) and standard output (<I>stdout</I>) will be filtered.<br><br><b><b>quiet_filter_fail</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the logging of errors if the external filter program fails to execute or returns a non-zero exit status. This can be used to avoid excessive log spam from transient filter issues.<br><br><b><b>debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debugging messages to be logged to <I>syslog</I>, which can be helpful for troubleshooting filter configurations.<br><br>


title: DESCRIPTION
content:
The <b>pam_filter</b> module is a <I>Pluggable Authentication Modules (PAM)</I> component designed to intercept and process input and output streams during a user's session, typically for console logins. It acts as an intermediary, allowing an external filter program to be applied to the standard input (<I>stdin</I>), standard output (<I>stdout</I>), and standard error (<I>stderr</I>) of a user's session.<br><br>While not a standalone command, it is configured within PAM service files (e.g., in <I>/etc/pam.d/login</I> or <I>/etc/pam.d/sshd</I>) using the <I>session</I> module type. Its primary applications historically included implementing accessibility features (e.g., screen readers, magnifying tools), logging all console activity for auditing or security purposes, or enforcing specific input/output policies. It was often associated with the <I>pam_console</I> module for managing local console access.


title: CAVEATS
content:
Using <b>pam_filter</b> introduces a potential security risk if the external filter program is not carefully chosen, secured, and audited, as it runs with elevated privileges or within a user's session context.<br><br>It can also introduce performance overhead due to the inter-process communication and execution of an external program for every I/O operation. In modern Linux distributions, its functionality for console management has largely been superseded by <I>systemd-logind</I>, which manages console and seat access more robustly. Therefore, <b>pam_filter</b> is less commonly used today for general console management but might still be relevant for specific, niche I/O filtering requirements.


title: CONFIGURATION EXAMPLE
content:
To enable <b>pam_filter</b> for a service, you would add a line similar to the following in the relevant PAM configuration file (e.g., <I>/etc/pam.d/login</I>):<br><br><b>session optional pam_filter.so filter=/usr/local/bin/my_io_logger debug</b><br><br>This example pipes all console I/O through <I>/usr/local/bin/my_io_logger</I> and enables debugging. Ensure the filter program exists and has appropriate permissions.


title: FILTER PROGRAM REQUIREMENTS
content:
The external filter program specified by the <I>filter=</I> option must be executable and capable of reading from its standard input and writing to its standard output. It typically acts as a simple pipe, possibly modifying, logging, or analyzing the data passing through it. For example, a filter might convert character encodings, log every keystroke, or censor specific output.


title: HISTORY
content:
The <b>pam_filter</b> module emerged as part of older console management solutions, often bundled with or complementing <I>pam_console</I>, particularly in environments where direct console access required strict controls or specialized accessibility features. Its design reflects a time before the widespread adoption of modern session managers like <I>systemd-logind</I>, which now handle many aspects of user session and device allocation. While still available on some systems, its practical usage has significantly declined in favor of more integrated and secure system-level solutions.


title: SYNOPSIS
content:
`pam_ftp` is a PAM module configured in service files. Its typical usage within a PAM configuration file appears as:<br><br><b><pre>auth &lt;control_flag&gt; pam_ftp.so [module_arguments]</pre></b><br><br>Where `&lt;control_flag&gt;` can be `required`, `requisite`, `sufficient`, or `optional`, defining the module's criticality in the authentication stack. `[module_arguments]` are specific options passed to `pam_ftp.so` to customize its behavior.


title: PARAMETERS
content:
<b>db=&lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to a DBM database file (e.g., `/etc/ftpusers.db`) containing user or host entries to be checked.<br><br><b>file=&lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to a flat file (e.g., `/etc/ftpusers`) containing user or host entries to be checked. Each entry is typically on a new line.<br><br><b>ignore_missing_db</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If this option is present, the module will not fail if the specified DBM database file (`db` option) does not exist. It will simply act as if no entries were found in the database.<br><br><b>no_host_check</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the module's ability to perform host-based checks. When enabled, only user-based checks are performed.<br><br>


title: DESCRIPTION
content:
`pam_ftp` is a Pluggable Authentication Module (PAM) designed to control access for <I>anonymous</I> FTP users. It is not a standalone executable command but rather a shared library (`pam_ftp.so`) that is configured within PAM service files (e.g., `/etc/pam.d/ftp`). Its primary function is to deny or allow access based on a list of users or hostnames, typically stored in a flat file like `/etc/ftpusers` or a DBM database. When an anonymous FTP session attempts to authenticate, `pam_ftp` checks the provided credentials against its configured database or file, determining whether the connection should be permitted or denied according to predefined rules. This module helps enforce access policies, preventing specific users or hosts from connecting to an anonymous FTP server.


title: CAVEATS
content:
`pam_ftp` is specifically designed for controlling access to <I>anonymous</I> FTP accounts. It does not handle authentication for regular user accounts. Its usage might be less common in modern FTP server setups, which often provide more integrated and flexible access control mechanisms within the server software itself (e.g., `vsftpd`, `proftpd`). Ensuring the database or flat file it relies on is correctly maintained and secured is crucial for effective access control.


title: PAM CONFIGURATION CONTEXT
content:
When configuring `pam_ftp` in a PAM service file (e.g., `/etc/pam.d/ftp`), it is typically placed in the `auth` stack. For example:<br><br><b><pre>auth    required    pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed<br>auth    required    pam_ftp.so file=/etc/ftpusers.db</pre></b><br><br>The <I>order</I> and <I>control flags</I> (`required`, `sufficient`, etc.) of PAM modules are critical as they dictate the flow of authentication. `pam_ftp` provides a specific check within this sequence.


title: FLAT FILE FORMAT (/ETC/FTPUSERS)
content:
The flat file specified by the `file` option (commonly `/etc/ftpusers`) typically contains one user or hostname per line. Users listed in this file are usually denied access, though the exact interpretation can depend on the FTP server's configuration and other PAM modules.


title: DBM DATABASE FORMAT
content:
The DBM database (`db` option) stores key-value pairs. Keys could be usernames or hostnames, and values might represent permissions or flags. The exact schema for this database depends on how `pam_ftp` expects to query it, often mapping to simple presence/absence for access control.


title: HISTORY
content:
`pam_ftp` was developed as part of the Linux-PAM (Pluggable Authentication Modules) project. It emerged to provide a modular way for FTP daemons to manage access for anonymous users, particularly in environments where traditional `ftpusers` files or more complex DBM databases were used for access control. Its design aligns with the PAM philosophy of separating authentication policy from application logic, allowing system administrators to define and modify authentication schemes without recompiling applications. While still functional, its direct use for anonymous FTP control has sometimes been superseded by more comprehensive features built into modern FTP server software, which can handle similar access restrictions internally or via other PAM modules like `pam_listfile.so`.


title: SYNOPSIS
content:
This is a C library function, not a shell command.<br><br><b>#include &lt;security/pam_appl.h&gt;</b><br><b>const char *pam_getenv(pam_handle_t *</b><i>pamh</i><b>, const char *</b><i>name</i><b>);</b>


title: PARAMETERS
content:
<b>pamh</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A pointer to the PAM handle, which represents the current PAM transaction or session context. This handle is typically obtained via <i>pam_start()</i>.<br><br><b>name</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the environment variable (a C string) to retrieve. For example, &quot;DISPLAY&quot; or &quot;HOME&quot;.<br><br>


title: DESCRIPTION
content:
The <b>pam_getenv</b> is a function from the PAM (Pluggable Authentication Modules) library, not a standalone shell command. It is used by PAM service modules or PAM-aware applications to retrieve environment variables that have been set within the current PAM handle or session context. These variables are typically populated by other PAM modules (e.g., using <i>pam_putenv</i> or <i>pam_setenv</i>) and can include crucial information like <i>DISPLAY</i>, <i>XAUTHORITY</i>, or custom variables needed for session setup or application execution. This function is vital for ensuring that the correct environment is established and inherited by the user's session or by subsequent modules within the PAM stack, allowing for seamless integration of various system services during authentication and session management.


title: CAVEATS
content:
<b>pam_getenv</b> is a library function, not an executable command. It must be called programmatically from a C application or a PAM module. The returned string points to data within the PAM handle and should not be modified or freed by the caller. The string is only valid for the lifetime of the PAM transaction or until another PAM function call modifies the environment.


title: RETURN VALUE
content:
The <b>pam_getenv</b> function returns a constant pointer to the string value of the environment variable if found. If the variable is not found within the PAM handle's environment, it returns <i>NULL</i>.


title: USAGE CONTEXT
content:
This function is primarily used by PAM modules (e.g., session modules like <i>pam_systemd</i> or custom modules) or by applications that interact directly with PAM to retrieve environment variables that are set by other modules during the authentication, account, password, or session management phases. It allows modules to pass crucial context (like <i>DISPLAY</i>, <i>XAUTHORITY</i>, etc.) to the application or subsequent modules in the PAM stack.


title: HISTORY
content:
<b>pam_getenv</b> is an integral part of the PAM (Pluggable Authentication Modules) framework, which was developed to provide a flexible and extensible way to authenticate users and manage sessions. Its inclusion reflects the need for modules to communicate and share environmental context, ensuring that a consistent and secure environment is set up for a user's session. It has been a standard part of the PAM library since its early adoption and specification.


title: SEE ALSO
content:
pam(7), pam_appl(3), pam_putenv(3), pam_setenv(3), pam_getenvlist(3), pam_start(3), pam_end(3), pam_env(8), pam_exec(8)


title: SYNOPSIS
content:
This is a PAM module, not a standalone command. Its usage is within PAM configuration files (e.g., <I>/etc/pam.d/login</I>, <I>/etc/pam.d/sshd</I>).<br><br><I>type</I> <I>control</I> <I>pam_group.so</I> [<I>options</I>]


title: PARAMETERS
content:
<b>allow_groups=<I>group1</I>[,<I>group2</I>,...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a comma-separated list of groups. If the authenticating user is a member of <I>any</I> of these groups, the module succeeds. This is generally used with a <I>required</I> or <I>sufficient</I> control flag.<br><br><b>deny_groups=<I>group1</I>[,<I>group2</I>,...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a comma-separated list of groups. If the authenticating user is a member of <I>any</I> of these groups, the module fails and denies access. This is commonly used with a <I>required</I> control flag.<br><br><b>allow</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<B>Deprecated.</B> Use <I>allow_groups</I>. This option read group names from the default configuration file (<I>/etc/security/group.conf</I>).<br><br><b>deny</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<B>Deprecated.</B> Use <I>deny_groups</I>. This option read group names from the default configuration file (<I>/etc/security/group.conf</I>).<br><br><b>conf=<I>/path/to/file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file to load group settings from, instead of the default <I>/etc/security/group.conf</I>. This file typically contains rules in the format <I>service</I>;<I>ttys</I>;<I>users</I>;<I>groups</I>;<I>times</I>.<br><br><b>file=<I>/path/to/file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A synonym for the <I>conf=</I> option.<br><br><b>debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Causes the module to write debug information to the system log (syslog). Useful for troubleshooting.<br><br><b>non_interactive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the module from attempting to prompt the user for any input.<br><br><b>quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses syslog messages on success. Only messages on failure or errors are logged.<br><br>


title: DESCRIPTION
content:
pam_group is a Pluggable Authentication Module (PAM) that controls user access based on their membership in specified groups. It is typically configured within <I>/etc/pam.d/</I> service files (e.g., <I>login</I>, <I>sshd</I>, <I>sudo</I>) to enforce access policies during authentication or session management. This module allows system administrators to define which groups are permitted or denied access to a particular service. For instance, you can configure it to allow only members of the "wheel" group to use the <I>su</I> command or to deny access to a service for users belonging to a "guest" group. When invoked, pam_group checks the user's supplementary group memberships against the <I>allow_groups</I> or <I>deny_groups</I> directives. If the user's groups match the specified criteria, the module either succeeds or fails, influencing the overall PAM stack's decision.


title: CAVEATS
content:
<ul><li>pam_group only checks supplementary group memberships. It does not consider the user's primary group unless that primary group is also listed as a supplementary group.</li><li>The order of PAM modules in the stack is critical. If pam_group is placed after a module that already authenticates the user, its denial might be ignored, or its allowance might be redundant.</li><li>Using <I>allow</I> or <I>deny</I> (without <I>_groups</I>) relies on the <I>/etc/security/group.conf</I> file, which has a more complex syntax involving service, TTY, user, group, and time fields. For simple group checks, <I>allow_groups</I> and <I>deny_groups</I> are preferred.</li><li>Misconfiguration can lead to users being locked out of systems or services. Always test changes thoroughly in a controlled environment.</li></ul>


title: DEFAULT CONFIGURATION FILE: /ETC/SECURITY/GROUP.CONF
content:
When the <I>conf=</I> or <I>file=</I> options are used, or the deprecated <I>allow</I>/<I>deny</I> options are specified, pam_group looks for rules in <I>/etc/security/group.conf</I>. This file uses a specific format to define access rules, often including conditions based on the service, TTY, user, group, and time of day. This provides more granular control than simple <I>allow_groups</I>/<I>deny_groups</I> directives.


title: PAM CONTROL FLAGS
content:
The <I>control</I> field in a PAM configuration line (e.g., <I>required</I>, <I>sufficient</I>, <I>optional</I>, <I>requisite</I>) dictates how pam_group's success or failure affects the overall PAM stack. For instance, <I>required</I> means the module must succeed, but failure doesn't immediately stop the stack. <I>requisite</I> means the module must succeed, and failure immediately aborts the stack. <I>sufficient</I> means if it succeeds, the stack immediately returns success unless a preceding <I>requisite</I> module failed. Understanding these flags is crucial for effective PAM configuration.


title: HISTORY
content:
PAM (Pluggable Authentication Modules) was developed in the mid-1990s by Sun Microsystems, aiming to provide a flexible framework for authentication services. This allowed system administrators to choose and stack various authentication mechanisms without recompiling applications. pam_group is one of the foundational modules provided within the Linux-PAM (PAM for Linux) project, which became a standard component of most Linux distributions. Its purpose of enforcing group-based access control reflects a fundamental security requirement that has been present since the early days of multi-user Unix-like systems. The evolution of pam_group has primarily involved refinements in its configuration options (like the introduction of <I>allow_groups</I> and <I>deny_groups</I> for clearer inline configuration) and improved robustness.


title: SYNOPSIS
content:
This is a PAM module, not a direct shell command. Its synopsis describes how it's configured in PAM service files (e.g., <I>/etc/pam.d/login</I>):<br><br><B>session optional pam_issue.so [options]</B>


title: PARAMETERS
content:
<b>issue=FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative path to the local issue file instead of the default <I>/etc/issue</I>.<br><br><b>issue.net=FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative path to the remote issue file instead of the default <I>/etc/issue.net</I>.<br><br><b>nofail</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If specified, the module will not cause the authentication process to fail if the issue file cannot be opened or read (e.g., due to missing file or permissions).<br><br><b>filter_cr</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Replaces carriage return characters (\r) in the issue file with newline characters (\n), which can be useful for certain terminal types.<br><br><b>nonewline</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the trailing newline character that is normally added after the content of the issue file is displayed.<br><br><b>nonet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the display of the <I>/etc/issue.net</I> file, even if it exists and is relevant for the login type (e.g., remote SSH).<br><br><b>nodetach</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the module from forking a child process to display <I>/etc/issue.net</I>. This option can be relevant for services like <I>sshd</I> to prevent issues with pseudo-terminal allocation.<br><br><b>remap_net</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies escape sequence remapping (e.g., converting \m to machine architecture) to the content of <I>/etc/issue.net</I>. By default, remapping only applies to <I>/etc/issue</I>.<br><br>


title: DESCRIPTION
content:
pam_issue is a <I>Pluggable Authentication Module</I> (PAM) designed to display the contents of the system's issue files, typically <I>/etc/issue</I> and <I>/etc/issue.net</I>, to users during the authentication process. It operates as a <B>session</B> module within the PAM stack. Its primary use case is to provide important system information, legal disclaimers, or welcome messages <B>before</B> the user is prompted for credentials or after a successful login but before the shell starts.<br><br>The module can interpret and replace specific escape sequences within the issue files (e.g., \m for machine architecture, \s for operating system name) with dynamic system information, making the displayed content more informative. It is commonly configured in PAM service files such as <I>/etc/pam.d/login</I> or <I>/etc/pam.d/sshd</I> to ensure that the message is presented consistently across different login methods.


title: CAVEATS
content:
pam_issue is a PAM module and is not executed directly from the command line. Its behavior is entirely dependent on its configuration within PAM service files. <br><br>Care should be taken not to include sensitive information in <I>/etc/issue</I> or <I>/etc/issue.net</I> as these files are displayed <B>before</B> user authentication.<br><br>The interpretation of escape sequences may vary slightly depending on the system's underlying libraries or specific PAM version.


title: PAM MODULE TYPE
content:
pam_issue functions as a <B>session</B> type PAM module. Session modules are invoked after the authentication and account management phases and are responsible for setting up or tearing down the user's environment. For pam_issue, this means displaying the issue file content during the session establishment.


title: COMMON ESCAPE SEQUENCES
content:
The following escape sequences, if present in <I>/etc/issue</I> or <I>/etc/issue.net</I>, are commonly interpreted and replaced by pam_issue with dynamic system information:<br><ul><li><B>\d</B>: Current date</li><li><B>\D</B>: NIS domain name</li><li><B>\h</B>: Hostname</li><li><B>\l</B>: TTY line</li><li><B>\m</B>: Machine architecture (e.g., i686, x86_64)</li><li><B>\n</B>: Nodename (usually hostname)</li><li><B>\o</B>: Domain name (DNS)</li><li><B>\O</B>: Domain name (NIS)</li><li><B>\r</B>: Kernel release version</li><li><B>\s</B>: Operating system name</li><li><B>\t</B>: Current time (24-hour format)</li><li><B>\T</B>: Current time (12-hour format with AM/PM)</li><li><B>\u</B>: Number of currently logged-in users</li><li><B>\U</B>: Number of unique currently logged-in users</li><li><B>\v</B>: Kernel version</li></ul>


title: HISTORY
content:
pam_issue has been a standard component of the Linux-PAM (Pluggable Authentication Modules for Linux) suite since its early development in the mid-1990s. Its functionality stems from the traditional Unix practice of displaying system information or warnings from <I>/etc/issue</I> and <I>/etc/issue.net</I> at login. As PAM became the standard authentication framework on Linux, pam_issue was created to integrate this long-standing feature into the modular and flexible PAM system, ensuring consistency and configurability for pre-login messages across various services.


title: SYNOPSIS
content:
To use <i>pam_keyinit</i>, it is configured in a PAM service file (e.g., <b>/etc/pam.d/login</b> or <b>/etc/pam.d/system-auth</b>) typically as a <b>session</b> module type:<br><br><b>session optional pam_keyinit.so [options]</b><br><br>The <b>optional</b> control flag ensures that the session can still be established even if keyring initialization fails, though this might compromise security features reliant on the keyring.


title: PARAMETERS
content:
<b><b>debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose logging for debugging purposes. Information is typically sent to syslog.<br><br><b><b>force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the creation of a new session keyring, even if a session keyring already exists for the user. This ensures a fresh keyring for the session.<br><br><b><b>revoke</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Revokes any existing session keyrings belonging to the user at the start of the session. This is important for ensuring session isolation and preventing old keys from being reused or accessed.<br><br><b><b>keyring=<I>name</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the session keyring to be created. The default name is <I>_ses</I>.<br><br><b><b>alt_keyring=<I>name</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative name for the session keyring, primarily for backwards compatibility or specific integration scenarios.<br><br><b><b>root_keyring</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Causes the session keyring to be attached to the user's <b>uid_keyring</b> instead of the default process or thread keyring. This is useful for system services or specific use cases where the keyring needs to be persistent across all processes of a user ID.<br><br>


title: DESCRIPTION
content:
<i>pam_keyinit</i> is a <b>PAM (Pluggable Authentication Modules)</b> module designed to manage kernel keyrings for user sessions.<br>When a user logs in and a PAM session is initialized, <i>pam_keyinit</i> creates a unique <b>session keyring</b> for that user's session.<br>This keyring provides a secure, dedicated storage space within the kernel for cryptographic keys and other credentials that are specific to the user's current login session.<br>Applications that rely on kernel keyrings for security operations, such as disk encryption (e.g., LUKS) or secure communication, utilize this session keyring.<br>By establishing a distinct keyring for each session, <i>pam_keyinit</i> helps to isolate cryptographic material, enhancing security by ensuring that keys from one session do not leak or interfere with another. It is typically configured as a <b>session</b> type module in PAM configuration files (e.g., <i>/etc/pam.d/system-auth</i> or <i>/etc/pam.d/login</i>).


title: CAVEATS
content:
Misconfiguration of <i>pam_keyinit</i> within the PAM stack can lead to unexpected behavior or security vulnerabilities. It is crucial to place it correctly as a <b>session</b> module.<br>If the <b>revoke</b> option is not used, previously created session keyrings might persist, potentially allowing access to old cryptographic material.<br>Understanding the lifecycle of kernel keyrings and their interaction with processes and threads is essential for effective use.


title: <B>KEYRING TYPES</B>
content:
<i>pam_keyinit</i> primarily manages <b>session keyrings</b>, which are distinct from <b>user keyrings</b> (<i>uid_keyring</i>). A session keyring is tied to a specific login session and is typically destroyed when the session ends, while a user keyring is tied to the user ID and persists across different sessions (unless explicitly revoked).


title: <B>PAM MODULE TYPE</B>
content:
It is essential that <i>pam_keyinit</i> is configured as a <b>session</b> module in PAM configuration files. This ensures that the keyring is correctly set up when a user's session begins and managed appropriately upon session termination.


title: HISTORY
content:
The concept of kernel keyrings in Linux has evolved to provide a secure mechanism for managing cryptographic keys and authentication tokens within the kernel.<br><i>pam_keyinit</i> was developed as a PAM module to seamlessly integrate this kernel keyring functionality into the user's login and session management process.<br>Its development reflects the ongoing effort to enhance security in Linux environments by providing better isolation and management of sensitive cryptographic material associated with user sessions.


title: SYNOPSIS
content:
<b>In PAM configuration files (e.g., /etc/pam.d/login, /etc/pam.d/sshd):</b><br><i><pre>auth       optional     pam_lastlog.so [options]<br>session    optional     pam_lastlog.so [options]</pre></i><br><b>Note:</b> <i>pam_lastlog</i> is a PAM module, not a direct shell command.


