Pages

AIX OS Patching

Patching AIX keeps your IBM Unix systems secure, performant, and up-to-date. Whether you're fixing bugs, sealing vulnerabilities, or adding features, updates come as filesets or fixes in Technology Levels (TL), Service Packs (SP), or Interim Fixes (iFIX). AltDisk patching shines here—it clones your rootvg on spare disk, patches safely, and lets you reboot into the new version with minimal downtime and easy rollback.

Why AltDisk Patching?
Traditional patching risks your live system. AltDisk creates a bootable copy of rootvg on another disk (like hdisk5), applies updates there, verifies everything, then switches at reboot. Benefits include zero production impact during patching and instant revert if issues arise.

Patches live on IBM's Fix Central, downloaded as .bff filesets. Filesets group software components; patches target them with version numbers (level, release, modification).

Prerequisites
  • Free disk (e.g., hdisk5) in rootvg.
  • NFS share with TL/SP packages (e.g.,aixnimserver:/exports/software/aix_72.05.10).
  • Backup rootvg fully—patching mishaps happen.
Step-by-Step AltDisk Patching Process

1. Prepare the Alternate Disk
Reduce and clear the target disk from rootvg, then set it up for booting.
# unmirrorvg rootvg hdisk5
# reducevg -df rootvg hdisk5
# chpv -c hdisk5
# ipl_varyon -i  # Check bootable devices
# bootlist -m normal -o
# bosboot -ad /dev/hdisk5

2. Mount NFS Share with Packages
# mount aixnimserver:/exports/software/aix_72.05.10 /mnt
This pulls TL/SP .bff files from your NFS server to /mnt.

3. Clone Active rootvg
# alt_disk_copy -d hdisk5 -P1
Phase 1 clones the running rootvg to hdisk5.

4. Apply Emergency Fixes (EMGR)
# chroot /alt_inst /usr/sbin/emgr -P
chroot switches context to the clone; emgr -P prioritizes EMGR packages.

5. Remove EMGR Status
# chroot /alt_inst /usr/sbin/emgr -r -L <Fix>
Clears applied EMGR tracking (-r -L).

6. Commit Filesets
# chroot /alt_inst /usr/sbin/installp -c all
Locks in all applied filesets on the clone.

7. Verify LPP Integrity
# chroot /alt_inst /usr/bin/lppchk -vm3
Level 3 check (-vm3) scans for inconsistencies, dependencies, and more.

8. Apply TL/SP Updates
# alt_disk_copy -d hdisk5 -P23 -l /mnt -b update_all
-P23 handles multiple patch levels; -l /mnt sources packages; -b update_all grabs everything.

Validate the Patched Clone
Wake the alternate rootvg for checks.
# alt_root_op -W -d hdisk5  # Wake for verification
  • OS Level: chroot /alt_inst /usr/bin/oslevel -s (e.g., 7200-05-09-2446).
  • Compare Target: chroot /alt_inst /usr/bin/oslevel -sl 7200-05-092446.
  • Missing ML Fixes: chroot /alt_inst /usr/bin/instfix -i | grep ML.
  • Missing SP Fixes: chroot /alt_inst /usr/bin/instfix -i | grep SP.
  • Package Consistency: chroot /alt_inst /usr/bin/lppchk -vm3.
Sleep it back when done:
# alt_root_op -S -d hdisk5
Reboot with bootlist -m normal -o hdisk5 to switch. Monitor errpt -a for errors.

Best Practices
  • Backup First: Always snapshot rootvg.
  • Pre-Patch Audit: instfix -i lists current fixes.
  • Test Environment: Pilot in staging.
  • Order Matters: TL → SP → iFIX.
  • Logs: errpt -a during/after.
  • Downtime: Plan reboots.

AIX LVM (Logical Volume Manager)

Physical Volumes (PVs):
A Physical Volume (PV) is any AIX-recognized disk, like hdisk0. It's the base layer of LVM, divided into equal Physical Partitions (PPs), each with a fixed size per VG. Every PV has a unique PVID to prevent mix-ups if device names change after a reboot.

Commands & Examples
# List all PVs
lspv

# Show details of a specific PV
lspv hdisk0

# Assign a PVID to a disk
chdev -l hdisk2 -a pv=yes

# Clear a PVID
chdev -l hdisk2 -a pv=clear

Example lspv output:
hdisk0          00c1a2b3c4d5e678    rootvg      active
hdisk1          00d9e2f3a4b5c678    datavg      active
hdisk2          none                None
(none) indicates the disk has no PVID yet.

Volume Groups (VGs):
A Volume Group (VG) pools one or more PVs into a single logical storage unit. Logical Volumes (LVs) are carved from this pool.

VGDA (Volume Group Descriptor Area): Metadata stored on each PV, containing VG name, PV/LV mapping, and quorum info. Redundant copies ensure recoverability.

Quorum: Ensures that >50% of PVs are active before a VG is used. Prevents corruption. Can be disabled for mirrored or test VGs:

# chvg -Qn rootvg

VG Types Comparison
FeatureNormal VGBig VGScalable VG
Max PVs321281024–4096
Max PPs/PV1016130,0482,097,152
Max PV Size~128 GB1 TB1 PB
Max VG Size128 GB8 TB4 PB
PP Size Range1–256 MB1–256 MB1 MB–1 GB
QuorumYesYesOptional

VG Commands

List all VGs
# lsvg

Show VG details
# lsvg rootvg

Show PVs in VG
# lsvg -p datavg

Show LVs in VG
# lsvg -l datavg

Create VG (Normal/Big/Scalable)
# mkvg -y datavg hdisk1
# mkvg -B -y bigvg hdisk2
# mkvg -S -y scalablevg hdisk3

Add/Remove PV
# extendvg datavg hdisk2
# reducevg datavg hdisk2

Import/Export VG
# importvg -y datavg hdisk1
# exportvg datavg

Physical & Logical Partitions:
Physical Partition (PP): Smallest allocatable unit on a PV. Size fixed per VG (e.g., 4–512 MB).
lsvg datavg | grep "PP SIZE"

Output: 32 megabyte(s)
Logical Partition (LP): Virtual allocation in an LV. 1 LP maps to 1+ PPs.
Example: 100 LPs × 32 MB PP = 3.2 GB LV (6.4 GB mirrored)
Check PV PPs:
# lspv hdisk0
TOTAL PPs: 6399 (204 GB)

Logical Volumes (LVs):
Logical Volumes (LVs) are carved from VGs, acting as virtual disks. They can be used for:
  • File systems: JFS2, JFS
  • Raw volumes: Databases, paging
  • Boot/root volumes
  • Mirrored LVs
Commands & Examples

Create LV
# mklv -y lvdata datavg 100   # 100 LPs

List LVs in VG
# lsvg -l datavg

Show LV details and mapping
# lslv lvdata
# lslv -m lvdata

Extend LV
# extendlv lvdata 50  # Add 50 LPs

Remove LV
# rmlv lvdata

Create filesystem on LV
# crfs -v jfs2 -d lvdata -m /data

LV Mapping Example
LP   PP    PV
1    100   hdisk1
2    101   hdisk2
...


Tips & Best Practices
  • Always check quorum before performing VG operations.
  • Keep VGDA redundancy intact for recovery.
  • Start small and scale VGs as storage needs grow.
  • Use lsvg -l, lslv -m, and lspv to visualize mappings before critical changes.
  • Mirror critical LVs for production systems using mklvcopy.
Assign PVs:
# chdev -l hdisk2 -a pv=yes
# chdev -l hdisk3 -a pv=yes

Create a VG:
# mkvg -S -y appvg hdisk2 hdisk3

Create a mirrored LV:
# mklvcopy -m 2 -y applv appvg 200

Create filesystem and mount:
# crfs -v jfs2 -d applv -m /appdata
# mount /appdata

AIX Networking

IBM AIX offers robust networking features tailored for enterprise reliability and performance on Power Systems. Whether you’re managing physical NICs, virtual adapters in LPARs, or advanced setups like RDMA and link aggregation, understanding AIX networking is crucial for admins aiming to maximize throughput, security, and uptime.

This post dives into network interfaces, IP configuration, VLANs, TCP/IP tuning, monitoring, advanced features, and troubleshooting, with examples and a detailed ASCII diagram to visualize your architecture.

Network Interface Basics
AIX distinguishes between:
  • Physical adapters (entX) – Real network interfaces.
  • Logical interfaces (enX) – Virtual interfaces, including VLANs.
Listing Adapters:
# lsdev -Cc adapter   # List physical NICs
# lsdev -Cc if        # List logical interfaces

Each interface has attributes like:
  • MTU – Default 1500 bytes; jumbo frames up to 65,536.
  • Speed & Duplex
  • State – Available / Defined / Failed
Detailed Stats:
# lsattr -El ent0      # Attribute settings
# entstat -d ent0      # Adapter stats: errors, drops, collisions

Virtual Ethernet adapters in PowerVM LPARs enable inter-partition communication without physical hardware.

IP Configuration

Temporary:
# ifconfig en0 192.168.1.10 netmask 255.255.255.0 up
# route add default 192.168.1.1

Persistent:
# chdev -l en0 -a netaddr=192.168.1.10 -a netmask=255.255.255.0
# chdev -l inet0 -a route=192.168.1.1

Aliases & Name Resolution:
# ifconfig en0 192.168.1.11 netmask 255.255.255.0 alias

Edit /etc/hosts for static hostnames and /etc/resolv.conf for DNS. Use SMIT for easier management:
# smitty tcpip
# smit mktcpip

VLAN and SEA Support

VLANs:
# mkdev -c if -s vlan -t ent0 -a vlan_id=10  # Creates ent0.10
ifconfig ent0.10 10.0.10.5 up              # Assign IP

SEA (Shared Ethernet Adapter) in PowerVM:
# mkvdev -sea ent0 -vlanid 20

FeatureCommand ExampleUse Case
Base VLANmkvdev -vlan ent0 -vlanid 20Single NIC segmentation
SEA VLANmkvdev -sea entX -vlanid 30LPAR traffic isolation
IP on VLANifconfig ent1 10.0.20.5 upPer-VLAN addressing

TCP/IP Stack and Routing
Protocols: TCP (reliable), UDP (fast), ICMP (ping/traceroute), IPv6.
Static Route:
# chdev -l inet0 -a route=10.0.0.0 -a netmask=255.255.0.0 -a gateway=10.0.0.1

Dynamic Routing: Enable via:
# no -o ipforwarding=1

Performance Tuning

Buffers:
# no -o tcp_sendspace=1048576 -o tcp_recvspace=1048576

MTU:
# chdev -l en0 -a mtu=9000  # Jumbo frames

Queues:
# chdev -l ent0 -a receive_size=60 -a transmit_size=60

Latency:
# no -o tcp_nodelayack=1
# no -o thewall=4096

Link Aggregation (EtherChannel):
# smitty etherchannel  # Combine up to 8 NICs for throughput/failover

Security essentials: IPSec, VLAN isolation, SSH, Kerberos, TCP wrappers (/etc/hosts.allow).

AIX Job Scheduler

In AIX, job schedulers are your secret weapon for automating repetitive or one-off tasks. From backups to reports to cleanup scripts, they reduce manual work and ensure consistency. Whether you rely on cron for recurring jobs or at for single-run tasks, mastering these tools is essential for any AIX administrator.

Let's break down how each works and share practical tips for reliability.

Cron (crontab): Perfect for Recurring Jobs
The cron daemon runs scheduled jobs repeatedly at defined intervals. Each user has a crontab file that specifies their job schedules.
Crontab Syntax:
Each line defines when and what to execute:
* * * * * command
- - - - -
| | | | |
| | | | ----- Day of week (0-7, Sunday=0 or 7)
| | | ------- Month (1-12)
| | --------- Day of month (1-31)
| ----------- Hour (0-23)
------------- Minute (0-59)

Example: Daily backup at 2:00 AM
0 2 * * * /home/user/backup.sh

Common Crontab Commands
CommandPurpose
crontab -eEdit your crontab
crontab -lList your crontab entries
crontab -rRemove your crontab
Multi-job Example:
30 1 * * 1 /home/user/weekly_report.sh    # Every Monday at 1:30 AM
0 0 1 * * /home/user/monthly_cleanup.sh   # First day of each month at midnight
System-wide job locations:
/var/spool/cron/crontabs/ (per-user)
/etc/cron.d/ and /etc/crontab

Pro Tip: Cron jobs run in a minimal environment—always use absolute paths in scripts.

At: Ideal for One-Time Jobs
While cron handles repeats, at schedules a job for a single execution at a specific time or date.
Scheduling with At
# at 14:30               # 2:30 PM today
# at now + 1 hour        # 1 hour from now
# at 23:00 09/30/2025    # 11:00 PM on Sep 30, 2025
After entering at, type commands, then press Ctrl+D:
at 14:30
> /home/user/script.sh
> <Ctrl+D>

Managing At Jobs
CommandPurpose
atqList pending jobs (shows job number, user, time)
atrm <job_number>Remove a scheduled job
Example:
# atq
1   user   2025-09-26 14:30 a
# atrm 1

Cron vs. At: Quick Comparison
FeatureCronAt
Job TypeRecurringOne-time
SchedulingMinute/Hour/DaySpecific time/date
StorageCrontab fileAt queue
Use CaseDaily backupsTomorrow’s report

Pro Tips for Reliable Scheduling

Use absolute paths (cron/at lack your full shell PATH):
0 2 * * * /home/user/backup.sh

Log output for debugging:
0 2 * * * /home/user/backup.sh > /tmp/backup.log 2>&1

Set execute permissions:
# chmod +x /home/user/backup.sh

Define PATH if needed:
PATH=/usr/bin:/usr/local/bin

Final Thoughts
Automating with cron and at transforms AIX system administration. Your backups, reports, and cleanups will run reliably, freeing you for strategic work.

Next Steps:
  • Combine cron and at for hybrid workflows
  • Monitor job logs regularly
  • Handle environment variables to dodge "works in terminal, fails in cron" issues
With these practices, your AIX scheduling will be rock-solid.

AIX Performance Management

IBM AIX is engineered for reliability and throughput, but no system is immune to performance degradation. Performance problems rarely announce themselves as “CPU issues” or “disk issues”—they surface as slow applications, timeouts, paging storms, or missed SLAs.

Effective AIX performance management is systemic, not reactive. It follows a continuous lifecycle:

Monitor → Analyze → Tune → Validate → Report → Repeat

This guide covers what to measure, why it matters, how to tune it, and how to avoid common traps—with real AIX commands and proven thresholds.

The Performance Management Lifecycle
  • Monitor: Track CPU, memory, disk I/O, and network in real-time using tools like topas, nmon, and vmstat.
  • Analyze: Spot bottlenecks through trends with sar and nmon reports.
  • Tune: Adjust kernel parameters (vmo, ioo, no), apps, or hardware.
  • Report: Summarize data for audits using nmon and custom scripts.
Pro Tip: Generate HTML reports effortlessly with nmon in analyzer mode:
# nmon -f perf.nmon
# nmonanalyser perf.nmon

CPU Performance: 
CPU metrics quickly reveal if user processes or the kernel are hogging cycles.

Key Metrics
MetricMeaningHealthy Range
%userUser processes<70%
%sysKernel time<30%
%idleIdle CPU>20%
%waitI/O wait<10%
Load AvgProcesses waiting (1/5/15m)< #cores
Bottleneck Signs
  • High %user: CPU-bound apps (e.g., heavy compiles).
  • High %sys: Kernel thrashing (network or filesystem issues).
  • Low %idle + high load: Add cores or tune processes.
  • High %wait: Address I/O bottlenecks first.
Top Tools & Commands
# vmstat 5        # CPU stats every 5s
  kthr   -----memory---------- ---swap-- -----io--- ---CPU---
  r  b   avm  fre  fi fo pi po fr  sr  in  sy  cs us sy id wa
  1  0  1024 512   0  0  0  0 10  5 100 200  50 20 10 60 10

# mpstat 1 5      # Per-CPU stats
CPU   %usr %sys %wio %idle
 0    15    5    2    78
 1    25   10    5    60

Other essentials: topas (interactive; 't' for top processes), nmon ('c' for CPU, 'C' for per-core), sar -u 1 10 (historical data).

Tune It: Check scheduler with schedo -i; bind apps to cores via bindprocessor.

Memory Performance: Avoid Paging Hell
Memory shortages trigger paging and swapping, which spike CPU %wait and kill performance.

Key Metrics
  • Free RAM: vmstat -v or svmon -G.
  • Paging: pgspcn (pages scanned), pgin/pgout.
  • Swap: lsps -a; keep usage <20%.
Bottleneck Signs
  • High paging + low free RAM: Time to buy more memory.
  • High cache but thrashing: Optimize inefficient apps.
Commands
# svmon -G        # Global summary
Memory Size:          16384 MB
Fixed:                1024 MB
Persistent:            256 MB
Client:             15000 MB
Pinned:                512 MB
Free:                  800 MB   # Low? Alert!
Also try svmon -P (top processes), vmstat 5 (paging columns like pi/po/fr/sr), and topas (memory view).

Tune It:
# vmo -a          # Check current params
vmo -p -o minperm%=3     # Boost file cache
vmo -p -o maxperm%=80    # Cap computational memory
vmo -p -o maxclient%=80  # Limit client memory
Disk I/O: Speed Up Your Storage
Slow disks throttle apps—focus on IOPS, queues, and service times.

Key Metrics
MetricMeaningTarget
%busyDisk utilization<70%
Queue LengthWaiting requests<2
Service TimeAvg response (ms)<20ms
IOPSOps/secDevice max

Bottleneck Signs
  • High %busy or queue: Overloaded hdisk.
  • High CPU %wait: Disk-bound workload.
Commands
# iostat -d 5 3   # Disk I/O stats
     hdisk0  hdisk1
KB/t  tps KB/t  tps
32.5 150 45.2 200   # High tps? Rebalance
More: lsvg -p rootvg (VG to hdisk map), lsattr -El hdisk0 (attributes like queue_depth), topas ('d' for disk detail), nmon ('D' disks, 'j' JFS).

Tune It:
  • Stripe LVs: mklv -S stripe rootvg 4 hdisk1 hdisk2 hdisk3 hdisk4.
  • Use JFS2: mkfs -V jfs2 /dev/lv.
  • Boost queue: chdev -l hdisk0 -a queue_depth=32.
Network Performance: Keep Data Flowing
Network issues hammer NFS, databases, and clusters.

Key Metrics
  • Throughput: pkt/s, B/s.
  • Errors: drops, collisions, retransmits.
  • Latency: ping or app response times.
Bottleneck Signs
  • High errors: Faulty cable or switch.
  • Low throughput: Undersized buffers.
Commands
# netstat -i      # Interface stats
Input     Output
ent0:   1.2G     800M   # Packets/errors
Try entstat -d ent0 (detailed), netstat -an (TCP/UDP), topas ('n' network), nmon ('N' nets), tcpdump -i ent0 (capture).

Tune It:
# no -p -o tcp_sendspace=262144  # Larger buffers
# no -a | grep tcp               # Verify
# chdev -l ent0 -a mtu=9000      # Jumbo frames

Quick-Start Dashboard Script
Drop this into a ksh script for instant AIX perf snapshots:

#!/bin/ksh
echo "AIX Perf Snapshot $(date)"
vmstat 1 3 | tail -1
svmon -G | head -5
iostat -d 1 2 | tail -1
netstat -i | tail -1

Bookmark this guide, run these commands, and watch your AIX systems fly. Got a specific bottleneck? Dive in and tune!

AIX File & Folder Ownership

Every file or folder in AIX has three key players:
  • Owner (user) – The user who created the file.
  • Group – Users who share access to the file.
  • Others – Everyone else.
Permissions define what each category can read, write, or execute. Master these, and you’ll tame any AIX filesystem.

Permission Basics: Read, Write, Execute
Permissions come in three flavors for each category (owner, group, others):

Permission Meaning
PermissionMeaning
Read (r)View file or list folder contents
Write (w)Modify file or add/delete in folder
Execute (x)Run file (if program) or enter folder

Check file permissions using:
# ls -l filename
Example output:
-rwxr-xr--
  • - = File type (d for directory)
  • rwx = Owner: full access
  • r-x = Group: read/execute, no write
  • r-- = Others: read-only
Changing Permissions with chmod
You can tweak file access in two modes:
Symbolic Mode (Easy Adds/Removes)
Letters represent categories:
  • u = owner
  • g = group
  • o = others
  • a = all
Examples:
# chmod u+r filename # Owner gains read permission
# chmod g-w filename # Group loses write permission
# chmod o+x filename # Others gain execute permission

Numeric (Octal) Mode

Assign numbers:

  • Read = 4
  • Write = 2
  • Execute = 1
Add them up for each category:

NumberPermissionsMeaning
7rwxFull access
6rw-Read + write
5r-xRead + execute
4r--Read only

Example:
# chmod 755 filename
  • Owner = 7 (rwx)
  • Group = 5 (r-x)
  • Others = 5 (r-x)
Perfect for scripts and executable files.

Ownership: chown and chgrp
Files can change ownership if you’re root:
# chown newuser filename # Change file owner
# chgrp newgroup filename # Change file group

Special Permissions:
AIX has advanced flags to control behavior:
  • Setuid (s): Runs the file as the file owner instead of the caller. Example: rwsr-xr-x
  • Setgid (s): New files inherit the folder’s group.
  • Sticky bit (t): Only the owner can delete a file in the directory. Common in /tmp:
drwxrwxrwt 14 root system 4096 Sep 26 12:00 /tmp
That t keeps your temp files safe from accidental deletion by others.

Hidden Files: 
Files starting with a dot (.) are hidden—ideal for configuration files like .bashrc or .ssh/.
# ls -l → skips hidden files
# ls -la → shows all files, including hidden ones

Example:
-rw-r--r-- 1 user group 123 Sep 26 12:00 file.txt
-rw-r--r-- 1 user group 50 Sep 26 12:05 .hiddenfile

Why hide?
  • Prevent accidental modifications
  • Keep configuration files safe
  • Permissions still apply (e.g., chmod 600 .hiddenfile = owner-only read/write)
Quick Hidden File Actions
# touch .myhiddenfile # Create a hidden file
# echo "Hello" > .myhiddenfile
# cd .ssh # Enter a hidden directory
# rm .hiddenfile # Delete hidden file

IBM AIX – User ID Management

IBM AIX (Advanced Interactive eXecutive) is a UNIX‑based operating system that uses a combination of flat files and, optionally, LDAP directories to define and control user identities, authentication, and access privileges.

AIX provides a set of native command‑line utilities and system files that are used by system administrators to create, modify, and manage users and groups securely.

AIX user and group management involves:
  • Creating, modifying, and removing user accounts
  • Managing group definitions
  • Assigning privileges, roles, and group memberships
  • Configuring authentication sources (local or LDAP)
  • Managing passwords and authentication policies
  • Delegating administrative privileges via sudo
  • Identification and Authentication
AIX uses an identification and authentication model to establish user identity and verify credentials. By default, users are stored in local files (/etc/passwd, /etc/security/user, etc.), 
but AIX also supports LDAP as an alternative registry for authentication and account information.

Core AIX Security Files
AIX maintains user and group information across several system files. These flat files form the backbone of local user management:

File                             Purpose
/etc/passwd                     Contains basic user account attributes (UID, primary group, shell, home directory).
/etc/security/user             Contains extended attributes for users (password strength, roles, limits).
/etc/security/user.roles            Defines administrative roles and associations.
/etc/security/limits             Specifies resource quotas and limits per user.
/etc/security/environ              Environment variable settings for users.
/etc/group                     Contains basic group attributes.
/etc/security/group             Contains extended group attributes (admins, group policies).
/usr/lib/security/mkuser.default    Default attribute template used by mkuser when creating new accounts.
/usr/lib/security/mkuser.sys     System‑specific overrides for new user defaults.
/etc/security/lastlog             Records the last login information for user accounts.
/etc/security/audit/config     Audit subsystem configuration.
/etc/security/domains             Defines valid security domains on the system.
/etc/sudoers                     Configuration file for granting users or groups privileged access via sudo. 

/etc/passwd – Structure and Fields
The /etc/passwd file contains basic user account information. Each line represents one user and has seven fields, separated by colons (:):
username:password:UID:GID:comment:home_directory:shell

username
The login name of the user (e.g., root, sysadm, smith).
Must be unique on the system.
Used to identify the user in commands, processes, and file ownership.

password
In modern AIX systems, this field usually contains x or *.
The actual password hash is stored securely in /etc/security/passwd or managed by the authentication subsystem.
Older systems may store the hashed password directly in this field.

UID (User ID)
Numeric unique identifier for the user.
The UID determines ownership of files and processes.
Common UID ranges:
0 → root (superuser)
1–99 → System accounts
100–999 → Local administrative accounts
1000+ → Regular users

GID (Primary Group ID)
Numeric group ID representing the user's primary group.
Maps to a group entry in /etc/group.
Determines default group ownership for files created by the user.

comment (GECOS)
Optional descriptive field (also called the GECOS field).
Often contains full name, department, or contact info.
Example: sysadm Admin User

home_directory
Absolute path to the user’s home directory (e.g., /home/sysadm).
This is the default working directory when the user logs in.
Shell initialization files (e.g., .profile, .kshrc) reside here.

shell
Absolute path to the user’s login shell (e.g., /usr/bin/ksh, /usr/bin/bash).
Determines the command interpreter for interactive logins and scripts executed as that user.
Can be set to /usr/bin/false or /sbin/nologin for accounts that should not log in.

Security User:
The /etc/security/user file defines extended security attributes for every user on an AIX system. It controls:
Authentication policies
Password rules
Resource limits
Roles and privileges
Access restrictions (e.g., remote login, su)
Unlike /etc/passwd, which contains only basic user info, this file allows fine-grained security and system administration control.

File Format:
The file is structured in stanzas, one per user, or a default stanza for new users. Each stanza looks like:
username:
    attribute1 = value1
    attribute2 = value2
    ...
username: → the user account name or default for global defaults
attribute = value → a specific security or system setting

Common Attributes:
Here are the most important attributes in /etc/security/user:
Attribute          Purpose
admin             Determines whether the user is an administrator. true or false.
login             Enables or disables login for the user. true or false.
su             Allows or disallows switching to another user via su. true or false.
rlogin / rsh / ftp  Controls remote access for the user. true or false.
expires             Specifies an account expiration date (format: MMDDHHMMYY).
password     Defines password properties such as min/max length, aging rules, and history.
pwdwarntime     Number of days before password expiration to warn the user.
minage             Minimum number of days before password can be changed.
maxage             Maximum number of days before password must be changed.
maxexpired     Maximum number of days after password expiration before account is locked.
loginretries     Maximum failed login attempts before account lockout.
umask             Default file creation mask for the user.
groups             List of secondary groups the user belongs to.
roles             Administrative roles assigned to the user.
tcb             Trusted Computing Base attributes for enhanced security (Trusted AIX).
auth1, auth2, auth3 Specifies authentication methods and modules (e.g., SYSTEM, LDAP).
clearance     Security clearance level for the user (Trusted AIX).

Default Stanza:
There is usually a default stanza, which defines attributes applied to all newly created users unless overridden:
default:
    login = true
    admin = false
    su = true
    rlogin = false
    rsh = false
    ftp = false
    maxage = 90
    minage = 1
    pwdwarntime = 7

This ensures consistent security policies across all accounts.
Attributes can be overridden per user by creating a specific stanza for the username.

Example User Entry:
sysadm:
    admin = true
    login = true
    su = true
    rlogin = true
    rsh = false
    ftp = false
    maxage = 180
    minage = 7
    pwdwarntime = 14
    groups = staff,finance
    roles = SecurityAdmin

Explanation:
admin = true → sysadm has administrative privileges.
su = true → sysadm can switch to other users using su.
rlogin = true → remote login is allowed.
maxage = 180 → password must be changed every 180 days.
groups → sysadm belongs to staff and finance.
roles → sysadm has the SecurityAdmin role.

Security User.roles:
The /etc/security/user.roles file defines administrative roles and assigns them to specific users. This allows role-based access control (RBAC), where users can perform certain privileged operations only if they have the required role.
While /etc/security/user defines individual attributes for each user (e.g., login, password policies, remote access), /etc/security/user.roles focuses exclusively on roles and role-related privileges.

File Structure:
The file is organized in stanzas, one per role assignment:
username:
    roles = role1, role2, ...
username: → Name of the user account.
roles = ... → Comma-separated list of administrative roles assigned to the user.
There may also be a default stanza specifying roles automatically applied to new users if not overridden.

Common Administrative Roles in AIX:
AIX defines several preconfigured roles, but custom roles can also be created:
Role         Purpose
SystemAdmin Full system administration privileges, similar to root.
SecurityAdmin Can modify users, groups, passwords, and security policies.
AuditAdmin Can view and configure audit subsystem.
ResourceAdmin Can modify resource limits and environment attributes.
UserAdmin Can create, modify, and delete regular users.

The exact roles available may vary based on AIX version and installed security modules.

Example /etc/security/user.roles Entry:
sysadm:
    roles = SecurityAdmin, UserAdmin

user1:
    roles = AuditAdmin

Explanation:
sysadm has both SecurityAdmin and UserAdmin roles:
Can manage users and security policies.
user1 has the AuditAdmin role:
Can access and configure auditing features, but may not modify users.

Integration with Commands:
Roles defined here are used by AIX commands like:
mkuser -a → create an administrative user with specific roles.
chuser roles=... → modify the roles of an existing user.
Only root or users with proper UserAdmin authority can assign or modify roles.
Roles enforce principle of least privilege, allowing users to have only the privileges necessary for their tasks.

Security Limits:
The /etc/security/limits file in AIX defines resource restrictions for users or groups. These limits help control system resource usage, prevent accidental overconsumption, and enhance system stability and security.
It is part of AIX’s extended security configuration, complementing /etc/security/user and /etc/security/group.

File Structure:
The file uses stanzas, either per user, per group, or a default:
username_or_group:
    resource_name = value
    ...
username_or_group: → The name of the user, group, or default (applies to all users not otherwise specified).
resource_name = value → Specifies the type of limit and its value.
Example:
sysadm:
    maxprocesses = 200
    maxdata = 1048576

default:
    maxfiles = 1024
Common Resource Attributes:
Attribute Description
maxprocesses Maximum number of simultaneous processes a user can run. Prevents runaway processes.
maxfiles Maximum number of open file descriptors per user. Controls file handle usage.
maxswapsize Maximum virtual memory (swap) a user can allocate.
maxdata Maximum data segment size (heap) in bytes.
maxcore Maximum size of core files generated by the user.
maxrss Maximum resident set size (physical memory) for a user’s processes.
cpu Maximum CPU time (seconds) a user can consume.
fsize Maximum size of files a user can create.
nofiles Alias for maxfiles in some AIX versions.

Limits can be hard (enforced by kernel) or soft (warnings or advisories for users).

Examples:
Per-user limit
sysadm:
    maxprocesses = 150
    maxfiles = 2048
    cpu = 3600

sysadm can run up to 150 processes, open 2048 files, and use 3600 CPU seconds per session.

Default limits for all users:
default:
    maxprocesses = 50
    maxfiles = 1024

Users not explicitly listed inherit these limits.

Group-specific limits:
staff:
    maxprocesses = 100

All members of staff group are limited to 100 processes.

Integration with AIX Commands:
Limits in /etc/security/limits are automatically applied during user login and process creation.
Can be modified temporarily at runtime using the ulimit shell command:
ulimit -u 150   # set max processes
ulimit -n 2048  # set max open files
Permanent limits should always be defined in /etc/security/limits for consistency and security.

Security Environ:
The /etc/security/environ file defines environment variables that are applied per user or per group when they log in. Unlike shell startup files (like .profile), which are shell-specific, this file provides a centralized and system-wide mechanism for setting environment attributes for AIX users.
It is part of AIX’s extended security infrastructure and works alongside /etc/security/user and /etc/security/limits to provide a consistent runtime environment.

File Structure:
The file is organized in stanzas, one for each user, group, or a default stanza:

username_or_group:
    ENV_VAR1 = value1
    ENV_VAR2 = value2
    ...
username_or_group: → The name of the user, group, or default (applies to users not listed explicitly).
ENV_VAR = value → Environment variable name and its value.

Common Environment Attributes:
Attribute          Purpose
PATH                  Specifies directories to search for executable commands.
MAIL                  Path to user’s mailbox file.
LOGNAME                  Stores the login name of the user.
SHELL                  Overrides the login shell defined in /etc/passwd.
TMPDIR                  Directory used for temporary files.
LANG / LC_ / LANGUAGE* Locale and language settings.
DISPLAY                  Default X11 display for GUI applications.
USER                  Another representation of the login name.

Custom environment variables can also be set for application-specific needs.

Example /etc/security/environ Entry:
default:
    PATH = /usr/bin:/usr/sbin:/bin:/sbin
    MAIL = /var/mail/$USER
    TMPDIR = /tmp

sysadm:
    PATH = /usr/local/bin:/usr/bin:/usr/sbin
    LANG = en_US.UTF-8

Explanation:
default stanza applies to all users unless overridden.
sysadm has a custom PATH and locale, while other users inherit the default settings.
$USER can be used as a variable that resolves to the login name.

Integration with AIX Login:
When a user logs in, the AIX login process reads /etc/security/environ and sets the environment variables defined in the user or group stanza.
Variables defined here override defaults but can be further customized in user shell profiles (.profile, .kshrc, etc.).
Environment variables defined here can also affect system services and sudo sessions if configured to inherit the environment.

Group:
The /etc/group file contains basic definitions of groups on the AIX system. Groups are used to organize users and control access to files, directories, and resources based on shared permissions.
This file complements /etc/security/group, which contains extended group attributes, and /etc/passwd, which links each user to a primary group.

File Structure:
Each line in /etc/group represents a single group, with fields separated by colons (:):
group_name:password:GID:member_list
group_name → Name of the group (e.g., staff, finance)
password → Optional group password (historically used for newgrp; usually * or x)
GID → Numeric group ID (unique identifier for the group)
member_list → Comma-separated list of users belonging to the group

Field Explanation:
Field         Purpose
group_name Unique name identifying the group. Used in commands like chgrp, groups, and id.
password Group password for newgrp command (rarely used today; typically *).
GID         Numeric group identifier. Maps group ownership of files and directories.
member_list Users who are secondary members of this group. Primary group of a user is set in /etc/passwd.

Example /etc/group Entry:
finance:x:1001:sysadm,user1,carol
staff:x:1002:frank,steve

Explanation:
finance group:
GID = 1001
Members = sysadm, user1, carol
Password field x indicates no group password is set.
staff group:
GID = 1002
Members = frank and steve
Primary group membership is determined in /etc/passwd by the GID field for each user.

Integration with AIX Commands:
Add user to group:
chgroup users=sysadm,user1 finance
Remove user from group:
chgroup users=user1 finance
Create a new group:
mkgroup payroll
/etc/group is automatically updated by these commands; manual editing is discouraged.

Security Group:
The /etc/security/group file stores extended security attributes for groups, including administrative privileges, default roles, and policy settings.
While /etc/group contains basic group membership and GID, /etc/security/group provides fine-grained control for system security and RBAC (Role-Based Access Control).
It is used by AIX commands like mkgroup and chgroup to create or modify groups safely.

File Structure:
The file is organized into stanzas, one per group:
group_name:
    attribute1 = value1
    attribute2 = value2
    ...
group_name: → Name of the group (must match /etc/group)
attribute = value → Security-related attribute or policy setting

Common Attributes:
Attribute Description
adms         List of users with administrative privileges for this group. These users can manage group membership and attributes.
roles         Default roles assigned to members of this group. Useful for RBAC.
users         Explicit list of users in the group (secondary membership; also reflected in /etc/group).
minage         Minimum password age for group members.
maxage         Maximum password age for group members.
login         Controls whether members of this group are allowed to log in (true or false).
expires         Expiration date for the group or its members’ accounts.
tcb         Trusted Computing Base attributes (for Trusted AIX environments).
auth1, auth2 Authentication methods applicable to group members (e.g., SYSTEM, LDAP).

Not all attributes are mandatory; the set depends on the system’s security policies.

Example /etc/security/group Entry:
finance:
    adms = steve,mike
    roles = ResourceAdmin,UserAdmin
    users = sysadm,user1,carol

payroll:
    adms = root
    roles = SecurityAdmin
    users = frank

Explanation:
finance group:
Administrators: steve and mike
Default roles: ResourceAdmin and UserAdmin
Members: sysadm, user1, carol
payroll group:
Admin: root
Default role: SecurityAdmin
Member: frank
The adms attribute allows these users to modify the group membership and roles without needing full root privileges.

Integration with AIX Commands:
Create group with administrators:
mkgroup -A managers
Add or remove group members:
chgroup users=sam,carol finance
Modify group administrators or roles:
chgroup adms=steve,mike roles=ResourceAdmin,UserAdmin finance
Changes in /etc/security/group are automatically reflected in the behavior of chgroup, mkgroup, and RBAC enforcement.

Default Attributes Setting User:
This file contains default attributes that are applied when creating a new user with the mkuser command without specifying custom options.
It acts as a template for new user accounts, ensuring consistency in security, environment, and resource attributes.
Attributes here are used unless overridden by command-line options or by settings in /etc/security/user.

File Structure:
The file uses a key-value format, similar to /etc/security/user, defining default attributes for newly created users:
attribute1 = value1
attribute2 = value2
...
Each line sets a default attribute applied to all users created via mkuser.
Comments can be added using #.
Common Attributes in mkuser.default:
Attribute                 Purpose
login                    Whether the new user is allowed to log in (true or false).
admin                    Default administrative privileges (true or false).
su                         Whether the user can switch to other users with su.
rlogin / rsh / ftp        Default remote access permissions (true or false).
shell                         Default login shell (e.g., /usr/bin/ksh).
groups                         Secondary groups the user belongs to by default.
roles                         Default RBAC roles assigned to the user.
expires                         Default account expiration date (optional).
pwdwarntime, minage, maxage Password aging defaults.
umask                    Default file creation permissions mask.
ENV variables            Default environment variables inherited from /etc/security/environ.

Example mkuser.default Entry:
login = true
admin = false
su = true
rlogin = false
shell = /usr/bin/ksh
groups = staff
roles = UserAdmin
pwdwarntime = 7
minage = 1
maxage = 90
umask = 022

Explanation:
New users can log in (login=true) but are not administrators (admin=false).
su=true allows switching to other users.
Default shell is Korn shell.
Assigned to the staff group and given the UserAdmin role.
Password policies and umask are applied automatically.

Integration with Commands:
When you run:
mkuser sysadm
The system uses mkuser.default for any attributes not explicitly provided on the command line.
Examples with overrides:
mkuser -a sysadm      # Creates sysadm as an administrator, overriding admin=false
mkuser su=false sysadm # Overrides su attribute
mkuser -R LDAP sysadm  # Uses LDAP as authentication source
This allows consistent user creation across the system, while still permitting customization per user.

System Defined Settings:
This file contains system-defined settings and defaults that are applied when creating new users with the mkuser command.
Unlike /usr/lib/security/mkuser.default, which can be customized for organizational defaults, mkuser.sys is maintained by AIX and defines system-level defaults and mandatory attributes.
It provides the baseline environment and security attributes that the system expects every user to have.
Think of mkuser.sys as the "system template", while mkuser.default is the "site-specific template."

Purpose of mkuser.sys:
Ensures consistency and integrity for new users across the system.
Provides mandatory fields and values used by mkuser.
Supports automation of user creation, especially in combination with mkuser.default and LDAP integration.
Helps prevent creating users with incomplete or invalid attributes that might break system security or login functionality.

File Structure:
Similar to mkuser.default, it uses a key-value format:
attribute1 = value1
attribute2 = value2
...
Attributes here are generally system-defined and should not be edited manually.
They provide fallback values if mkuser.default or command-line options do not specify certain attributes.

Types of Attributes in mkuser.sys:
Attribute        Purpose
login            Indicates whether the user can log in (usually true).
shell             Default shell for new users (e.g., /usr/bin/ksh).
groups          Default primary or secondary groups.
umask             Default file creation permissions mask.
rlogin / rsh / ftp  Remote access defaults.
admin / su     Administrative and privilege attributes.
roles             Default RBAC roles for system users.
password policy     Minimum/maximum password age, expiration defaults.

These attributes ensure that all users, even if created programmatically, conform to AIX security expectations.

Interaction with mkuser:
When you create a new user:
mkuser sysadm

The mkuser command determines attribute values in the following order:
Command-line options (e.g., -a for admin, -R LDAP)
/usr/lib/security/mkuser.default (site-specific defaults)
/usr/lib/security/mkuser.sys (system defaults)
Attributes not specified in the first two sources are filled from mkuser.sys, ensuring the account is complete and functional.

Security Lastlog:
The /etc/security/lastlog file stores the last login information for each user on the system.
It is used by commands such as lastlog, finger, or login shells to display when and from where a user last logged in.
This file is read-only for regular users and maintained automatically by the system.
Unlike /var/adm/lastlog in some other Unix systems, AIX keeps its last login records in /etc/security/lastlog as part of the security framework.

File Structure:
/etc/security/lastlog is typically a binary file.
It contains records indexed by user ID (UID). Each record usually stores:
Field                 Description
last login time         Timestamp of the last successful login.
last login terminal The terminal or device used to log in.
remote host / IP Remote host if the login was via network (rlogin, ssh, ftp, etc.).
failures         Optional field tracking failed login attempts (in some configurations).

Direct manual editing is not recommended; use system commands to view or reset login info.

Accessing Last Login Information:
lastlog command – displays the last login for all users:
lastlog

Example output:
Username         Port     From             Latest
sysadm           pts/1    192.168.10.10    Fri Mar  7 08:15:22 2026
user1            pts/2    192.168.10.12    Thu Mar  6 17:42:10 2026
finger username – also reads /etc/security/lastlog to show last login info.

Integration with AIX Security:
The login process updates /etc/security/lastlog automatically after successful login.
Failed logins are often tracked in /etc/security/failedlogin (different file).
Security policies and auditing tools may reference last login times to detect unusual activity or account inactivity.

Security Audit:
This file defines audit policies and configuration settings for the AIX audit subsystem, which tracks security-relevant events.
It is part of AIX Trusted Computing Base (TCB) and works alongside other security files to provide accountability and compliance.
The audit subsystem monitors login/logout activity, file access, administrative actions, and system events for auditing and forensic purposes.

File Structure:
The file is a text-based configuration file organized in key-value pairs or stanzas, often per audit class or subsystem.
Common sections include:
audit_classes:
    class_name = event_list

audit_flags:
    flag_name = value

audit_devices:
    device_name = value

audit_policy:
    policy_item = value

Exact format can vary with AIX version, but the goal is to define what events to audit and how to record them.

Key Configuration Attributes:
Attribute / Section    Purpose
audit classes           Define groups of audit events (e.g., login, useradmin, file_access).
audit_flags           Enable or disable auditing for specific event classes.
audit_devices           Specify devices or files to monitor.
audit_policy           Define global audit behaviors such as event storage, retention, and log rotation.
minfree                   Minimum free space required to continue auditing.
naflags                   Flags to log non-attributable events (events not tied to a UID).
local_host / remote_host  Settings for auditing networked or remote logins.

Example /etc/security/audit/config:
classes:
    login = su, rlogin, ssh
    useradmin = mkuser, chuser, rmuser

flags:
    enabled = login,useradmin
    disabled = ftp

policy:
    audit_dir = /audit
    minfree = 50
    naflags = on

Explanation:
classes: Groups specific commands and events into audit classes.
flags: Turns auditing on or off for selected classes.
policy: Sets audit log directory, minimum disk space for logs, and how to handle non-attributable events.

Integration with AIX Security:
The audit subsystem uses this file to determine what events to log.
Logged events are stored in audit log files (often in /audit or /var/audit).

Auditing interacts with user accounts and RBAC:
/etc/security/user → tracks login policies
/etc/security/user.roles → ensures only authorized users perform privileged actions
/etc/security/limits → limits on resources may trigger audit events
Commands like auditpr and audit read this configuration to generate reports and analyze security events.

Security Domains:
The /etc/security/domains file defines valid security domains for the AIX system.
A domain in AIX is a logical grouping of users, applications, or resources that share a security or administrative boundary.
Domains are used primarily in Role-Based Access Control (RBAC) and user authorization, allowing users to be associated with specific domains for access control.

This file works in conjunction with:
/etc/security/user → assigns domains to individual users (domains attribute)
/etc/security/user.roles → controls what roles are active within each domain
/etc/security/group → groups can also be associated with domains
Domains provide an extra layer of segmentation and security, especially in multi-application or multi-department environments.

File Structure:
The file is organized in stanzas, one per domain:
domain_name:
    attribute1 = value1
    attribute2 = value2
    ...
domain_name: → Name of the security domain (e.g., INTRANET, APPLICATION)
attribute = value → Optional domain-level properties
Often, domains have minimal attributes, mostly acting as identifiers for user and role association.

Common Usage:
Users can be assigned one or more domains in /etc/security/user:
sysadm:
    domains = INTRANET,APPLICATION

Roles assigned to users may be limited to specific domains, controlling access to applications or resources.
Commands like chuser domains=... are used to modify domain assignments.

Example /etc/security/domains Entry:
INTRANET:
    description = "Internal corporate network"

APPLICATION:
    description = "Business-critical applications"

Explanation:
INTRANET and APPLICATION are logical domains.
These can be referenced in user attributes (domains), roles, and access policies.

Integration with AIX Security:
Domains provide a logical layer of separation for RBAC:
Users → belong to domains
Roles → may be restricted to specific domains
Permissions → apply within the domain context

Example: A user might have the ResourceAdmin role in the APPLICATION domain but not in INTRANET.
Helps enforce least privilege and access segregation.

sudoers:
The /etc/sudoers file defines who can run commands as another user, usually root, and under what conditions.
It is part of AIX system security and enables delegation of administrative tasks without giving full root access.
This file is read by the sudo command and must be edited only using the visudo command to prevent syntax errors or permission issues.
Direct editing with a text editor is strongly discouraged, as a syntax error can disable sudo entirely.

File Structure
The file is divided into several sections:
Host Aliases – define groups of hosts.
User Aliases – define groups of users.
Command Aliases – define groups of commands.
Defaults – configure sudo behavior, environment, logging, and security options.
User Privilege Specification – grants users or groups permission to run commands.
Include Directives – includes additional sudoers configuration files (like /etc/sudoers.d).

Key Fields and Directives:
Field / Directive                  Purpose
root ALL=(ALL:ALL) ALL                  Root can execute any command as any user/group on all hosts.
%wheel ALL=(ALL:ALL) ALL          Members of the wheel group can execute all commands (requires uncommenting).
Defaults secure_path=...          Sets a system-wide PATH for sudo commands to prevent running malicious scripts.
Defaults env_keep += "VAR"          Preserves selected environment variables when running commands via sudo.
Cmnd_Alias NAME = /path/to/command Creates an alias for a group of commands to simplify permissions.
User_Alias NAME = user1,user2          Groups users together for simplified privilege assignment.
Host_Alias NAME = host1,host2          Groups hosts for targeting rules.
@includedir /etc/sudoers.d          Includes extra configuration files for modular sudo rules.
NOPASSWD                          Allows users to run commands without entering a password.
Defaults!COMMAND !log_output          Applies Defaults to specific commands.

Example /etc/sudoers Entry:
# Root has full privileges
root ALL=(ALL:ALL) ALL
# Members of wheel can run any command
%wheel ALL=(ALL:ALL) ALL
# Keep editor environment variables for visudo
Defaults!/opt/freeware/sbin/visudo env_keep += "SUDO_EDITOR EDITOR VISUAL"
# Include additional sudoers files
@includedir /etc/sudoers.d

Explanation:
root ALL=(ALL:ALL) ALL → Root can run any command as any user.
%wheel ALL=(ALL:ALL) ALL → Optional group-based privilege delegation.
Defaults!/opt/freeware/sbin/visudo env_keep += ... → Ensures safe editing of sudoers.
@includedir → Allows modular configuration for additional users or applications.

Integration with AIX Security:
/etc/sudoers works with users and groups:
Users defined in /etc/passwd and /etc/security/user can be granted sudo privileges.
Group-based sudo access (%wheel, %sudo) leverages /etc/group membership.
Combined with /etc/security/user.roles and /etc/security/domains, sudo can support role-based administration.
sudo commands respect environment settings, resource limits, and auditing policies.