Showing posts with label Linux. Show all posts
Showing posts with label Linux. Show all posts

Wednesday, January 1, 2025

mailx vs. s-nail

mailx vs. s-nail: A Comparison

mailx and s-nail are command-line utilities used for sending and receiving emails on Unix-like operating systems. While they serve the same fundamental purpose, s-nail is often considered a modern, enhanced successor to the traditional mailx.

mailx

mailx is a traditional command-line mail utility that has been around for a long time. It's part of the POSIX standard and is widely available on most Unix-like systems. Note: mailx is deprecated in Red Hat Enterprise Linux (RHEL) 9.

Key Characteristics of mailx:

  • Traditional: It provides basic functionality for composing, sending, and reading emails from the command line.

  • Simplicity: Its syntax and features are relatively straightforward, making it easy for basic email tasks.

  • Standard: As a POSIX standard utility, its behavior is generally consistent across different systems.

  • Limited Features: Compared to more modern mail clients, mailx has limited features for handling complex email scenarios, advanced authentication, or modern protocols.

  • Security: Older versions might have limitations regarding modern encryption standards or authentication methods.

Common Use Cases for mailx:

  • Sending simple notifications or alerts from scripts.

  • Basic email composition and sending from the command line.

  • Reading local mailboxes.

Usage Examples for mailx:

  • Sending a simple email:

    echo "This is the body of the email." | mailx -s "Subject of the Email" recipient@example.com
    
  • Reading local mailbox:

    mailx
    

s-nail

s-nail is a modern, feature-rich mail client that aims to be a compatible replacement for mailx while offering significant enhancements. It is often found as the default mailx implementation on newer Linux distributions (e.g., Debian, Ubuntu, RHEL/CentOS 8+).

Key Characteristics of s-nail:

  • Enhanced Functionality: s-nail extends the capabilities of mailx with features like:

    • Improved Protocol Support: Better support for SMTP, IMAP, POP3, and SMTPS/IMAPS/POP3S (secure versions).

    • Advanced Authentication: Support for various authentication mechanisms (e.g., PLAIN, LOGIN, CRAM-MD5, NTLM).

    • TLS/SSL Support: Robust handling of encrypted connections for secure email transmission.

    • MIME Support: Better handling of MIME types for attachments and rich text.

    • Internationalization: Improved handling of character sets and encodings.

    • Configuration: More flexible and powerful configuration options via ~/.s-nailrc or system-wide files.

  • mailx Compatibility: s-nail strives to be largely command-line compatible with mailx, meaning scripts written for mailx often work seamlessly with s-nail.

  • Security Focus: Designed with modern security considerations in mind, making it a more secure choice for sensitive email operations.

  • Active Development: It benefits from ongoing development and improvements.

Common Use Cases for s-nail:

  • Sending emails from scripts with advanced requirements (e.g., secure connections, specific authentication).

  • Acting as a robust command-line email client for users who prefer a terminal-based interface.

  • Automated reporting and alerting in modern environments where security and protocol support are critical.

Usage Examples for s-nail:

  • Sending an email with an attachment (using a common mailx compatible syntax):

    echo "Please find the report attached." | s-nail -s "Daily Report" -a /path/to/report.pdf recipient@example.com
    
  • Sending an email via a specific SMTP server with authentication:

    s-nail -v -S smtp-use-starttls -S smtp=smtp.example.com:587 \
           -S smtp-auth=login -S smtp-auth-user=your_username \
           -S smtp-auth-password=your_password \
           -s "Secure Email Test" recipient@example.com <<EOF
    This is a secure email sent via s-nail.
    EOF
    

Comparison Summary

Feature

mailx (Traditional)

s-nail (Modern)

Protocol Support

Basic SMTP, local mailboxes

SMTP, SMTPS, IMAP, IMAPS, POP3, POP3S, local mailboxes

Authentication

Limited

Extensive (PLAIN, LOGIN, CRAM-MD5, NTLM, etc.)

Encryption (TLS/SSL)

Often limited or external configuration

Built-in and robust TLS/SSL support

MIME Support

Basic, often requires external tools for complex attachments

Improved, better handling of various MIME types and attachments

Configuration

Simpler, often via command-line options or basic ~/.mailrc

More powerful, extensive options via ~/.s-nailrc and system-wide files

Development Status

Mature, less active development

Actively developed and maintained

Default on Systems

Older Unix/Linux systems (e.g., CentOS 7, older BSDs)

Newer Linux distributions (e.g., Debian, Ubuntu, RHEL/CentOS 8+, often aliased as mailx)

Security

May have limitations with modern security requirements

Designed with modern security in mind

Conclusion

While mailx remains a functional tool for basic email tasks, s-nail is the preferred choice for modern environments due to its expanded feature set, improved protocol support, and enhanced security capabilities. On many contemporary Linux distributions, the mailx command itself often points to the s-nail binary, providing a seamless upgrade path for users and scripts.

Monday, July 12, 2021

ORA-01017: invalid username/password; logon denied while creating DB using DBCA

Problem: DBCA ORA-01017 due to OS user/group permissions.

Verify:

  1. oracle User: Ensure you're running DBCA as the oracle OS user (or grid for Grid Infrastructure).
  2. oinstall Group: Check if oracle (and grid) are in the oinstall group.
    • Command: getent group oinstall | egrep -i 'oracle|grid'
    • Fix (if missing, as root): usermod -a -G oinstall oracle (repeat for grid)
    • Action: Log out and back in as oracle (or grid) after changes.
  3. Other Groups: Confirm oracle is in dba and other relevant groups (e.g., asmdba for ASM).
    • Command: id -Gn oracle

Summary: Ensure oracle (or grid) OS user is correctly part of oinstall and other necessary Oracle groups.

Monday, August 31, 2020

All about oracle-database-preinstall-19c (Oracle Linux 8, 7)

Installing oracle-database-preinstall-19c RPM

This document outlines the process for downloading and installing the oracle-database-preinstall-19c RPM package, and explains its effects on your Oracle Linux system.

1. How to Download

The oracle-database-preinstall-19c RPM is available directly from Oracle's YUM repositories. Choose the correct link based on your Oracle Linux version:

  • For Oracle Linux 8 (OEL8): https://yum.oracle.com/repo/OracleLinux/OL8/baseos/latest/x86_64/getPackage/oracle-database-preinstall-19c-1.0-1.el8.x86_64.rpm

  • For Oracle Linux 7 (OEL7 - Latest): https://yum.oracle.com/repo/OracleLinux/OL7/latest/x86_64/getPackage/oracle-database-preinstall-19c-1.0-2.el7.x86_64.rpm

  • For Oracle Linux 7 (OEL7 - Older Version): https://yum.oracle.com/repo/OracleLinux/OL7/latest/x86_64/getPackage/oracle-database-preinstall-19c-1.0-1.el7.x86_64.rpm

To download the RPM: You can use wget or curl directly from your Linux server. For example, for OEL8:

Bash
wget https://yum.oracle.com/repo/OracleLinux/OL8/baseos/latest/x86_64/getPackage/oracle-database-preinstall-19c-1.0-1.el8.x86_64.rpm

Note: It's generally recommended to use yum install oracle-database-preinstall-19c (or dnf install on OL8) as it will automatically download the correct version and handle dependencies.

2. How to Install

Once downloaded, you can install the RPM package using the yum (or dnf on OL8) command as root.

Command:

Bash
sudo yum install oracle-database-preinstall-19c-1.0-1.el8.x86_64.rpm
# Replace the RPM filename with the one you downloaded for your specific OS version.

Using yum directly (recommended for dependency resolution):

Bash
sudo yum install oracle-database-preinstall-19c
# Or on OL8:
sudo dnf install oracle-database-preinstall-19c

To verify installation:

Bash
rpm -qa | grep oracle-database-preinstall-19c

(Note: The command rpm -qa oracle-database-preinstall-19c-1.0-1.el8.x86_64.rpm you provided would only work if the full filename matches exactly and is not the standard way to query all installed packages containing a string.)

3. What it Will Do

The oracle-database-preinstall-19c RPM automates many of the prerequisite configurations required for Oracle Database 19c installation:

  • Create an oracle user: A dedicated operating system user named oracle is created for database administration.
  • Create groups: Essential OS groups such as oinstall, dba, backupdba, dgdba, kmdba, and racdba are created.
  • Update kernel parameters: System kernel parameters (e.g., shmmax, shmall, semaphores, file-max, ip_local_port_range) are adjusted to recommended values for Oracle Database.
  • Install dependencies: Installs various dependent packages required by Oracle Database.

4. What Happens if Existing User/Group Exists?

The preinstall RPM is designed to handle existing configurations gracefully:

  • Existing oracle user: If an oracle user already exists, the RPM will ignore its creation. It will not modify the existing user's home directory, UID, or primary group unless specifically necessary for group membership.
  • Existing groups: If any of the required groups (e.g., oinstall, dba) already exist, the RPM will add the oracle user to these groups if they are not already members. It will not recreate or modify the GIDs of existing groups. New required groups that don't exist will be created.
  • Kernel parameters: The RPM will replace existing kernel parameters (typically found in /etc/sysctl.conf or a file under /etc/sysctl.d/) with the recommended values for Oracle Database 19c. It's crucial to review these changes if you have custom kernel parameter settings.

Tuesday, July 28, 2020

All about Logical Volume Management (LVM) (PV, VG,LV)

Logical Volume Management (LVM) Explained

Logical Volume Management (LVM) introduces a flexible layer of abstraction over physical storage devices in Linux. This abstraction allows for dynamic management of storage volumes, making it easier to resize, move, and manage disk space without necessarily stopping applications or unmounting file systems. LVM hides the underlying physical disk sizes from the software, providing greater agility in storage administration.

LVM Components

LVM is built upon three core components:

  • Physical Volume (PV):

    • A PV is a raw block device, which can be an entire hard disk (e.g., /dev/sdb) or a partition of a disk (e.g., /dev/sda2).

    • PVs are the foundational building blocks of LVM.

  • Volume Group (VG):

    • A VG is a collection of one or more Physical Volumes (PVs).

    • It acts as a container for Logical Volumes, pooling the storage capacity of its constituent PVs.

  • Logical Volume (LV):

    • An LV represents a portion of a Volume Group (VG).

    • It is the equivalent of a traditional disk partition but with the added flexibility of LVM.

    • A Logical Volume can only belong to one Volume Group.

    • It is on a Logical Volume that you create a file system (e.g., ext4, XFS) and mount it for use by the operating system and applications.

LVM Commands and Examples

Here are common LVM commands and their output examples, demonstrating how to inspect your LVM setup:

Physical Volumes (PVs)

  • pvs (or pvdisplay, pvscan): Displays information about Physical Volumes.

    PV          VG                 Fmt  Attr PSize    PFree
    /dev/sda2   osvg               lvm2 a--  <59.00g      0
    /dev/sdb    oracle_application lvm2 a--  <330.00g <25.00g
    
    • /dev/sda2 is a PV belonging to the osvg Volume Group, with no free space.

    • /dev/sdb is a PV belonging to the oracle_application Volume Group, with 25.00GB of free space.

Volume Groups (VGs)

  • vgs (or vgdisplay, vgscan): Displays information about Volume Groups.

    VG                 #PV #LV #SN Attr   VSize    VFree
    oracle_application   1   4   0 wz--n- <330.00g <25.00g
    osvg                 1   5   0 wz--n-  <59.00g      0
    
    • oracle_application VG has 1 PV, 4 LVs, a total size of <330.00GB, and <25.00GB free.

    • osvg VG has 1 PV, 5 LVs, a total size of <59.00GB, and 0GB free.

Logical Volumes (LVs)

  • lvs (or lvdisplay, lvscan): Displays information about Logical Volumes.

    LV          VG                 Attr       LSize    Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
    app         oracle_application -wi-ao----   5.00g
    gridinfra   oracle_application -wi-ao---- 100.00g
    oracle      oracle_application -wi-ao---- 100.00g
    orasoftware oracle_application -wi-ao---- 100.00g
    homelv      osvg               -wi-ao----   4.00g
    rootlv      osvg               -wi-ao----  19.00g
    swaplv      osvg               -wi-ao---- <16.00g
    tmplv       osvg               -wi-ao----  12.00g
    varlv       osvg               -wi-ao----   8.00g
    
    • This output shows various Logical Volumes, their corresponding Volume Groups, and their allocated sizes.

Basic LVM Creation Commands

Here are the fundamental commands for creating LVM components:

  • Create a Physical Volume (PV):

    pvcreate /dev/sdb
    # To create multiple PVs:
    pvcreate /dev/sdb /dev/sdc
    
  • Create a Volume Group (VG):

    vgcreate oracle_application /dev/sdb
    # To create a VG from multiple PVs:
    vgcreate oracle_application /dev/sdb /dev/sdc
    
  • Create a Logical Volume (LV):

    lvcreate -L 5G -n app oracle_application
    # This creates a 5GB Logical Volume named 'app' within the 'oracle_application' Volume Group.
    

Wednesday, July 31, 2019

Udev rules - SYMLINK - Device Persistence - Oracle ASM - Linux

Udev Rules for Oracle ASM Device Persistence on Linux

This document explains how to configure Udev rules in Linux to ensure persistent device naming for Oracle Automatic Storage Management (ASM) disks. This is crucial for maintaining stable disk paths across reboots, which is a requirement for ASM.

Understanding Device Persistence with Udev

In Linux, device names like /dev/sda, /dev/sdb, etc., are not guaranteed to be consistent across reboots. This can cause issues for applications like Oracle ASM, which rely on stable paths to storage. Udev is a device manager for the Linux kernel that allows you to define rules to create persistent symbolic links (symlinks) to your disks, ensuring they always have the same, predictable name regardless of their boot-time enumeration.

Steps to Configure Udev Rules for ASM

This example demonstrates the process for a single disk (/dev/sda), but the principles apply to multiple disks.

1. Present Raw Disks

Ensure that the raw disks intended for Oracle ASM are presented to the Linux operating system. These disks should be unpartitioned and not formatted with any file system.

2. Identify the SCSI ID of the Disk

The SCSI ID (or ID_SERIAL) provides a unique, persistent identifier for the disk. This is the key to creating a stable Udev rule.

  • Command:

    /lib/udev/scsi_id -g -u -d /dev/sda
    

    (Replace /dev/sda with the actual device path of your raw disk.)

  • Example Output:

    3600224800cbc991b76c2a957f833fc66
    

    This hexadecimal string is the unique SCSI ID for the disk.

3. Create/Update the Udev Rules File

Create a new Udev rules file (e.g., 99-asm.rules) in the /etc/udev/rules.d/ directory. The 99 prefix ensures that these rules are processed late in the Udev sequence, typically after other system-generated rules.

  • File: /etc/udev/rules.d/99-asm.rules

  • Content Example (for one disk):

    KERNEL=="sd*", SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", ENV{ID_SERIAL}=="3600224800cbc991b76c2a957f833fc66", SYMLINK+="asmdatadisk1", OWNER="grid", GROUP="asmadmin", MODE="0660"
    
    • KERNEL=="sd*": Matches any block device with a name starting with sd (e.g., sda, sdb, sdc).

    • SUBSYSTEM=="block": Specifies that the rule applies to block devices.

    • ENV{DEVTYPE}=="disk": Ensures the rule applies only to whole disks, not partitions.

    • ENV{ID_SERIAL}=="3600224800cbc991b76c2a957f833fc66": This is the critical part. It matches the unique SCSI ID obtained in step 2.

    • SYMLINK+="asmdatadisk1": Creates a symbolic link named asmdatadisk1 in /dev/ (e.g., /dev/asmdatadisk1) that points to the actual device (e.g., /dev/sda). The += ensures that if other rules also create symlinks, this one is added.

    • OWNER="grid", GROUP="asmadmin", MODE="0660": Sets the ownership and permissions of the symlink.

      • OWNER="grid": Sets the owner to the grid OS user (typically the Oracle Grid Infrastructure owner).

      • GROUP="asmadmin": Sets the group to asmadmin (the ASM administrative group).

      • MODE="0660": Sets permissions to read/write for owner/group, and no access for others.

  • Important Note for Cloud Databases: The ENV{ID_SERIAL} attribute might not be consistently available or reliable for device persistence in some cloud environments (e.g., certain cloud-specific block storage types). In such cases, other attributes like ID_PATH or ID_WWN might be more appropriate, or cloud provider-specific persistent naming mechanisms should be used. The commented-out line in the original input (#ACTION=="add|change", ENV{ID_SCSI_SERIAL}=="...", SYMLINK+="asmdatadisk1", OWNER="grid", GROUP="asmadmin", MODE="0660") suggests an alternative that might be considered, but ID_SERIAL is generally preferred for on-premises setups.

4. Reload Udev Rules

After modifying the Udev rules file, you must reload the Udev rules and trigger the Udev system to apply the changes without requiring a system reboot.

  • Command:

    udevadm control --reload-rules && udevadm trigger
    

After these steps, you should see the new symlink in the /dev/ directory, pointing to your raw disk, and it will persist across reboots. You can then use this persistent symlink (e.g., /dev/asmdatadisk1) when configuring your ASM disk groups.