Skip to main content

temp-1

 




























🔧 vast_id Configuration

Key: vast_id

Description

This section defines the VAST ID, a unique numeric identifier used by internal systems for asset tracking, automation, or integration with enterprise management platforms. It helps associate the server with inventory records, monitoring tools, or deployment workflows.

✅ Used during provisioning to register the system in centralized databases or orchestration systems.

JSON Format

json
"vast_id": 12194

✅ Can also be provided as a string:

json
"vast_id": "12194"

Field Reference

vast_id
String or Integer
Unique identifier for the system in VAST (Verizon Asset Systems Tracker)
12194

✅ Must be non-empty and numeric — leading zeros may be stripped depending on system.

Validations Enforced

vast_id is required and must be a non-empty string or integer
Ensures the field is present and contains usable data
If vast_id is a string, it must not be blank or whitespace-only
Prevents" ","", or"\t"
Must represent a valid number
Even if provided as a string, it must be numeric (e.g.,"12194") — no letters or symbols

What's Not Allowed

  • Omitting vast_id entirely
  • Setting vast_id to null, "", or 0
  • Using non-numeric values: "abc", "12a", "!", etc.
  • Using special characters: @, #, $, %, etc.
  • Whitespace-only strings like " "
  • Boolean values (true, false)
  • Arrays or objects
  • Leading zeros unless explicitly allowed by downstream system

Interpreted as

The system will be associated with VAST ID:

12194

✅ This value may be used by:

  • Asset management systems
  • Monitoring dashboards
  • Automation pipelines
  • ServiceNow integrations
  • Audit and compliance reporting

🔄 Example usage in scripts:

bash
echo "Registering system with VAST ID: $VAST_ID"

🔧 How to Apply

Set the value in your configuration payload:

json
{
"vast_id": 12194
}

Or as a string:

json
{
"vast_id": "12194"
}

No file or service restart required — this is a metadata field consumed during provisioning.

⚠️ Important Notes

  • The vast_id must match the record in Verizon’s VAST (Verizon Asset Systems Tracker) database
  • Always verify the ID is active and assigned to the correct device
  • Do not reuse vast_id after decommissioning unless explicitly re-assigned
  • If using as a string, ensure downstream tools handle type conversion correctly
  • Avoid hardcoding in scripts — use configuration injection instead



🔧 user_management Configuration

Key: user_management

Description

This section defines a list of users and groups to be created or verified during system provisioning. It specifies usernames, home directories, directory permissions, and group names with GIDs. This ensures consistent identity management across systems for access control, automation, and application support.

✅ Used to standardize user/group setup in compliance with security policies and role-based access requirements.

JSON Format

json
"user_management": {
"permission": "755"
},
{
"username": "ip3c2LSPT",
"home_dir": "/home/ip3c2LSPT",
"permission": "700"
},
{
"username": "ip3cDEV",
"home_dir": "/home/ip3cDEV",
"permission": "700"
},
{
"username": "ip3cTEST",
"home_dir": "/home/ip3cTEST",
"permission": "700"
},
{
"username": "ip3cMRSS",
"home_dir": "/home/ip3cMRSS",
"permission": "700"
},
{
"username": "ip3cUSER",
"home_dir": "/home/ip3cUSER",
"permission": "700"
},
{
"username": "ip3cVDSI",
"home_dir": "/home/ip3cVDSI",
"permission": "700"
}
],
"groups": [
{
"groupname": "users",
"gid": "100"
},
{
"groupname": "svc-ansible-apps",
"gid": "1512"
},
{
"groupname": "svc-ansible",
"gid": "1511"
},
{
"groupname": "mrss/sysadmin",
"gid": "500"
},
{
"groupname": "acpd",
"gid": "516"
},
{
"groupname": "ccsuser",
"gid": "1513"
},
{
"groupname": "cya_recuser",
"gid": "1516"
}
]
}

Field Reference

users
List[Object]
List of user accounts to create or verify
[{"username": "smc", ...}]
username
String
Login name for the user
"svc-ansible"
home_dir
String
Path to the user’s home directory
"/home/svc-ansible"
permission/
permissions
String
Octal string (e.g.,700) defining permissions on the home directory
"700"
groups
List[Object]
List of groups to create or verify
[{"groupname": "users", ...}]
groupname
String
Name of the group
"svc-ansible-apps"
gid
String or Integer
Group ID (GID) to assign
"1511"

✅ Supports both numeric strings and integers for GID.

Validations Enforced

user_management must be an object
Must be a key-value structure — not a list, string, ornull
users is required and must be a non-empty list
At least one user must be defined
Each user must be an object
Cannot be a string or array
Each user must have username
Required field — must be a non-empty string
Each user must have home_dir
Required field — must be a non-empty string
Each user must have exactly one of permission or permissions
Prevents ambiguity — only one allowed
The permission value must be a 3-digit octal string (e.g., 700, 755)
Only digits 0–7 allowed; must be exactly 3 characters
groups is required and must be a non-empty list
At least one group must be defined
Each group must be an object
Must be a key-value structure
Each group must have groupname
Required field — must be a non-empty string
Each group must have gid
Required field — must be a string or integer (non-empty if string)

What's Not Allowed

  • Using user_management as a list, string, or null
  • Empty users or groups lists
  • Missing username, home_dir, or permission for any user
  • Including both permission and permissions in the same user block
  • Invalid permission values: "77", "800", "abc", ""
  • Duplicate usernames or groupnames
  • Blank or invalid groupname
  • Non-numeric gid values (e.g., "abc")
  • Whitespace-only strings anywhere
  • Special characters in usernames unless explicitly allowed

Interpreted as

Users Created:

smc,xagmid3, ...,ip3cVDSI
/home/<username>
700(owner-only access)
apps
/home/apps
755(owner rwx, others r-x)

✅ All users will have their home directories created with strict permissions.

Groups Created:

users
100
svc-ansible-apps
1512
svc-ansible
1511
mrss/sysadmin
500
acpd
516
ccsuser
1513
cya_recuser
1516

✅ These groups can be used for file ownership, sudo rules, or application access control.

🔧 How to Apply

Use automation or script to create users and groups:

bash
# Create groups
sudo groupadd -g 100 users
sudo groupadd -g 1512 "svc-ansible-apps"
sudo groupadd -g 1511 "svc-ansible"
sudo groupadd -g 500 "mrss/sysadmin"
sudo groupadd -g 516 acpd
sudo groupadd -g 1513 ccsuser
sudo groupadd -g 1516 cya_recuser

# Create users
for u in smc xagmid3 sysadmin ccsuser mrss cya_recuser 4lspt svc-ansible svc-ansible-apps ip3c2LSPT ip3cDEV ip3cTEST ip3cMRSS ip3cUSER ip3cVDSI; do
sudo useradd -m -d "/home/$u" -s /bin/bash "$u"
done

# Special case: apps user (different permissions)
sudo useradd -m -d /home/apps -s /bin/bash apps

# Fix permissions
sudo chmod 700 /home/smc /home/xagmid3 /home/sysadmin /home/ccsuser /home/mrss /home/cya_recuser /home/4lspt /home/svc-ansible /home/svc-ansible-apps /home/ip3c*
sudo chmod 755 /home/apps

⚠️ Important Notes

  • Always backup /etc/passwd, /etc/shadow, /etc/group before bulk changes
  • Avoid creating users with interactive shells unless needed
  • The permission field applies to the home directory, not the user account itself
  • Use chmod 700 for service accounts to restrict access
  • Use chmod 755 for shared application users like apps
  • Ensure GIDs do not conflict with existing groups
  • Do not set passwords here — use separate password policy or vault integration





🔧 sysctl_conf Configuration

Key: sysctl_conf

Description

This section defines kernel-level system settings that are written to sysctl configuration files such as /etc/sysctl.d/99-sysctl.conf and /etc/sysctl.conf. These settings control TCP keepalive behavior and core dump naming, improving network stability and debugging support.

✅ Used during system hardening and performance tuning to enforce consistent kernel behavior across environments.

JSON Format

json
"sysctl_conf": [
{
"COMMENT": "Add the lines below to the sysctl.conf file",
"file_name": "/etc/sysctl.d/99-sysctl.conf",
"settings": [
{
"name": "net.ipv4.tcp_keepalive_time",
"value": "150"
},
{
"name": "net.ipv4.tcp_keepalive_probes",
"value": "4"
},
{
"name": "net.ipv4.tcp_keepalive_intvl",
"value": "30"
},
{
"name": "kernel.core_pattern",
"value": "core.%p"
}
]
},
{
"file_name": "/etc/sysctl.conf",
"settings": [
{
"name": "net.ipv4.tcp_keepalive_time",
"value": "150"
},
{
"name": "net.ipv4.tcp_keepalive_probes",
"value": "4"
},
{
"name": "net.ipv4.tcp_keepalive_intvl",
"value": "30"
},
{
"name": "kernel.core_pattern",
"value": "core.%p"
}
]
}
]

Field Reference

COMMENT
String
Optional note explaining purpose (ignored during processing)
"Add the lines below to the sysctl.conf file"
file_name
String
Path to the target sysctl configuration file
"/etc/sysctl.d/99-sysctl.conf"
settings
List[Object]
List of kernel parameters to set
[{"name": "net.ipv4.tcp_keepalive_time", ...}]
name
String
Full sysctl parameter name
"kernel.core_pattern"
value
String
Value to assign to the parameter
"150","core.%p"

✅ Supports multiple files to ensure compatibility across systems using /etc/sysctl.conf or /etc/sysctl.d/.

Validations Enforced

sysctl_conf must be a non-empty list
Must contain at least one configuration block — cannot benull, an object, or empty
Each item in sysctl_conf must be an object
Every entry must be a key-value structure
Each configuration must have file_name
Required to specify where the settings will be applied
file_name must be a non-empty string
Cannot be missing,null, or blank
Each configuration must have settings
Required to define the actual kernel parameters
settings must be a non-empty list
Cannot be missing or empty
Each setting must be an object
Must havenameandvaluefields
Each setting must have name as a non-empty string
Specifies the sysctl parameter (e.g.,net.ipv4.tcp_keepalive_time)
Each setting must have value as a non-empty string
The assigned value must be valid and non-blank

What's Not Allowed

  • Using sysctl_conf as an object, string, or null
  • Empty sysctl_conf array
  • Missing file_name or settings in any block
  • Blank or invalid file_name (e.g., "", " "``, /invalid/path`)
  • Empty or missing settings array
  • Non-object entries in settings
  • Missing name or value in any setting
  • Blank or non-string values for name or value
  • Duplicate settings without justification
  • Syntax errors in parameter names (e.g., net.ipv4.tcp_keepalive_tim)

Interpreted as

1. /etc/sysctl.d/99-sysctl.conf

net.ipv4.tcp_keepalive_time = 150
net.ipv4.tcp_keepalive_probes = 4
net.ipv4.tcp_keepalive_intvl = 30
kernel.core_pattern = core.%p

2. /etc/sysctl.conf

net.ipv4.tcp_keepalive_time = 150
net.ipv4.tcp_keepalive_probes = 4
net.ipv4.tcp_keepalive_intvl = 30
kernel.core_pattern = core.%p

✅ This configures:

  • TCP Keepalive: Start probing after 150 seconds of idle
  • Probes: Send 4 unacknowledged probes before dropping connection
  • Interval: Wait 30 seconds between each probe
  • Core Dumps: Save cores as core.<PID> in current directory

⚠️ Note: Writing to both files ensures coverage in systems that read only sysctl.conf or use sysctl.d/.

🔧 How to Apply

Create or update each file:

bash
# Create /etc/sysctl.d/99-sysctl.conf
sudo mkdir -p /etc/sysctl.d
sudo tee /etc/sysctl.d/99-sysctl.conf << 'EOF'
net.ipv4.tcp_keepalive_time = 150
net.ipv4.tcp_keepalive_probes = 4
net.ipv4.tcp_keepalive_intvl = 30
kernel.core_pattern = core.%p
EOF

# Update /etc/sysctl.conf
sudo cp /etc/sysctl.conf /etc/sysctl.conf.bak
sudo sh -c 'cat >> /etc/sysctl.conf << EOF

# Custom Kernel Settings
net.ipv4.tcp_keepalive_time = 150
net.ipv4.tcp_keepalive_probes = 4
net.ipv4.tcp_keepalive_intvl = 30
kernel.core_pattern = core.%p
EOF'

Apply changes immediately:

bash
sudo sysctl -p

Or reload all configs:

bash
sudo sysctl --system

⚠️ Important Notes

  • Changes take effect after running sysctl -p or reboot
  • /etc/sysctl.d/*.conf files are automatically loaded — preferred method
  • Avoid duplicating settings unless required for backward compatibility
  • Use sysctl -a | grep <param> to verify current values
  • kernel.core_pattern affects where and how core dumps are saved — test application crashes if needed
  • Ensure /etc/sysctl.conf includes include /etc/sysctl.d/*.conf if relying on modular config









🔧 rc_local Configuration

Key: rc_local

Description

This section defines custom commands or placeholders to be added to the system’s rc.local script, which runs at the end of the boot process. It supports automation of post-boot tasks such as route setup, service checks, or environment initialization.

✅ Used to run essential startup scripts that are not managed by systemd services.

JSON Format

json
"rc_local": [
{
"COMMENT": "Add the below lines to the rc.local file",
"file_name": "/etc/rc.d/rc.local",
"lines": [
" "
]
}
]

Field Reference

COMMENT
String
Optional note explaining purpose (ignored during processing)
"Add the below lines to the rc.local file"
file_name
String
Path to therc.localscript file
"/etc/rc.d/rc.local"
lines
List[str]
List of lines to be added to the file — can include commands or placeholders
[" "]

✅ The presence of a single space (" ") may act as a placeholder to ensure the file exists and is executable.

Validations Enforced

rc_local must be a non-empty list
Must contain at least one configuration block — cannot benull, an object, or empty
Each item in rc_local must be an object
Every entry must be a key-value structure
Each configuration must have file_name
Required to specify the targetrc.localfile
file_name must be a non-empty string
Cannot be missing,null, or blank
Each configuration must have lines
Required field — cannot be missing
lines must be a list
Cannot be a string, object, ornull
Each line in lines must be a string
Ensures correct type for processing
If there is more than one line, no line can be empty or whitespace-only
Prevents invalid or meaningless entries in multi-line blocks
A single whitespace line (e.g., " ") is allowed only if it is the only entry
Supports placeholder use cases where file existence matters

What's Not Allowed

  • Using rc_local as an object, string, or null
  • Empty rc_local array
  • Missing file_name or setting it to "", null
  • Omitting lines entirely
  • Setting lines to a non-list value (e.g., string, object)
  • Multiple lines with blank or whitespace-only entries
  • Using lines: ["", ""] — empty strings are not allowed
  • Including syntax errors or unescaped characters in commands
  • Adding long-running or blocking commands without backgrounding (&)

Interpreted as

The following content will be written or ensured in /etc/rc.d/rc.local:

✅ This means:

  • A single space character will be written to the file
  • The file will exist and can later be made executable
  • Often used as a placeholder to satisfy automation requirements that rc.local must be present

⚠️ In practice, this may be followed by making the file executable:

bash
sudo chmod +x /etc/rc.d/rc.local

And enabling the service:

bash
sudo systemctl enable rc-local

🔧 How to Apply

Ensure the rc.local file exists and is properly formatted:

bash
# Create or overwrite rc.local with the required content
echo " " | sudo tee /etc/rc.d/rc.local

Make it executable:

bash
sudo chmod +x /etc/rc.d/rc.local

Enable the rc-local service (RHEL/CentOS 7+):

bash
sudo systemctl enable rc-local

Verify:

bash
ls -l /etc/rc.d/rc.local
systemctl is-enabled rc-local

⚠️ Important Notes

  • The rc.local script is not executed by default on modern systems — you must enable rc-local.service
  • Always ensure the script starts with #!/bin/bash if adding real commands
  • Avoid placing sensitive commands or credentials in rc.local
  • Use systemd services instead when possible — rc.local is legacy
  • Changes take effect on next boot
  • The single space (" ") does nothing functionally — it's often used to force file creation during provisioning




🔧 crontab_entries Configuration

Key: crontab_entries

Description

This section defines custom cron jobs that are written to system-wide cron configuration (e.g., /etc/cron.d/sysstat). It ensures critical maintenance tasks like performance data collection and log cleanup run automatically.

✅ Used to enable continuous system monitoring and prevent disk space exhaustion from archived logs.

JSON Format

json
"crontab_entries": [
{
"COMMENT": "Add the below lines to the sysstat file",
"cron_name": "sysstat",
"settings": [
{
"name": "run system activity accounting tool every 15 seconds",
"minute": "*",
"hour": "*",
"day": "*",
"month": "*",
"weekday": "*",
"user": "root",
"job": "/usr/lib64/sa/sa1 15 4"
},
{
"name": "clean up sa files older than 15 days",
"minute": "35",
"hour": "10",
"day": "*",
"month": "*",
"weekday": "*",
"user": "root",
"job": "find /var/log/sa -mtime +15 -type f -name 'sa*' -exec rm -f {} \\;"
}
]
}
]

Field Reference

COMMENT
String
Optional note explaining purpose (ignored during processing)
"Add the below lines to the sysstat file"
cron_name
String
Name of the cron file to be created under/etc/cron.d/
"sysstat"
settings
List[Object]
List of individual cron job definitions
[{"name": "...", ...}]
name
String
Descriptive name for the cron job
"run system activity accounting tool..."
minute
String
Minute field in cron syntax (*,0,*/15,10-30)
"*"
hour
String
Hour field
"*"
day
String
Day of month
"*"
month
String
Month field
"*"
weekday
String
Day of week (0–7, where 0 and 7 = Sunday)
"*"
user
String
User context in which the job runs
"root"
job
String
Command to execute
"/usr/lib64/sa/sa1 15 4"

✅ Each cron_name results in a file under /etc/cron.d/.

Validations Enforced

crontab_entries must be a non-empty list
Must contain at least one cron configuration block — cannot benull, an object, or empty
Each item in crontab_entries must be an object
Every entry must be a key-value structure
Each configuration must have cron_name
Required to specify the target cron file (e.g.,/etc/cron.d/sysstat)
cron_name must be a non-empty string
Cannot be missing,null, or blank
Each configuration must have settings
Required to define the actual cron jobs
settings must be a non-empty list
Cannot be missing or empty
Each setting must be an object
Must have all required cron fields
Each setting must have name, minute, hour, day, month, weekday, user, and job
All eight fields are required
All fields in a setting must be non-empty strings
No blank ornullvalues allowed
minute, hour, day, month, weekday must follow valid cron syntax
Supports*,*/2,10,1-5,1,3,5, etc. — but not invalid formats likeabcor99

What's Not Allowed

  • Using crontab_entries as an object, string, or null
  • Empty crontab_entries array
  • Missing cron_name or settings in any block
  • Blank or invalid cron_name (e.g., "", " "``, sys*`)
  • Empty or missing settings array
  • Omitting any of the required cron fields (name, minute, ..., job)
  • Non-string values in any field
  • Invalid cron expressions (e.g., minute: 60, hour: */0, day: abc)
  • Duplicate entries without justification

Interpreted as

A file named /etc/cron.d/sysstat will be created with the following content:

# run system activity accounting tool every 15 seconds
* * * * * root /usr/lib64/sa/sa1 15 4

# clean up sa files older than 15 days
35 10 * * * root find /var/log/sa -mtime +15 -type f -name 'sa*' -exec rm -f {} \;

✅ This configures:

  • sa1 to collect system stats every 15 seconds (4 times per minute)
  • Daily cleanup of old sa binary logs (older than 15 days)

🔧 How to Apply

Create the cron file:

bash
sudo tee /etc/cron.d/sysstat << 'EOF'
# run system activity accounting tool every 15 seconds
* * * * * root /usr/lib64/sa/sa1 15 4

# clean up sa files older than 15 days
35 10 * * * root find /var/log/sa -mtime +15 -type f -name 'sa*' -exec rm -f {} \;
EOF

Set correct permissions:

bash
sudo chmod 644 /etc/cron.d/sysstat

Test syntax:

bash
sudo crontab -l # Not used — /etc/cron.d/* is auto-loaded

Verify file exists:

bash
ls -l /etc/cron.d/sysstat

⚠️ Important Notes

  • Files in /etc/cron.d/ must have permissions 644 and be owned by root
  • Cron daemon automatically reloads this directory — no restart needed
  • Use sar to view collected data:
    bash
    sar -u 1 5 # CPU usage
    sar -r # Memory
  • Avoid using > or >> in jobs without proper logging control
  • The sa1 command requires sysstat package installed and enabled
  • Always test find commands before adding to cron





🔧 etc_services Configuration

Key: etc_services

Description

This section defines custom service name-to-port mappings in /etc/services. It disables legacy or insecure services (e.g., tftp, finger) by commenting them out, and enables application-specific services (e.g., sip, csp, https-clt) by ensuring they are defined with correct port numbers.

✅ Used during system hardening and application setup to standardize service naming and prevent accidental exposure of outdated protocols.

JSON Format

json
"etc_services": {
"disable": {
"echo": "7",
"chargen": "19",
"telnet": "23",
"whois": "63",
"bootps": "67",
"bootpc": "68",
"tftp": "69/udp",
"finger": "79/tcp",
"who": "513/udp",
"pop2": "109/tcp",
"pop3": "110/tcp",
"imap": "143/tcp",
"imap3": "220",
"imaps": "993",
"printer": "515",
"exec": "512/tcp",
"login": "513/tcp",
"klogin": "543/tcp",
"eklogin": "2105/tcp",
"shell": "514/tcp",
"kshell": "544/tcp",
"talk": "517/tcp",
"ntalk": "518/tcp",
"courier": "530/tcp",
"rwhois": "4321"
},
"enable": {
"cmslb": "2139/tcp",
"csp": "2222/tcp",
"sip": "5060",
"sip-tls": "5061/tcp",
"esm": "5600/tcp",
"esmunix": "5605/tcp",
"cms": "2300/tcp",
"cmsman": "2301/tcp",
"csawman": "2302/tcp",
"cmshttp": "2380/tcp",
"csawhttp": "2382/tcp",
"csawds": "4509/tcp",
"http-clt": "18081/tcp",
"https-clt": "43443/tcp"
}
}

Field Reference

disable
Object
Maps service names to their ports — entries will becommented outin/etc/services
"tftp": "69/udp"
enable
Object
Maps custom service names to ports — entries will beadded or verifiedin/etc/services
"https-clt": "43443/tcp"
Service Name
String
Logical name of the service (key)
"sip"
Port/Protocol
String
Port number with optional protocol (tcp,udp)
"5060","2222/tcp"

✅ These entries help tools like nmap, getent, or scripts use meaningful names instead of raw ports.

Validations Enforced

etc_services must be an object
Must be a key-value structure — not a list, string, ornull
Must contain at least one of disable or enable
Cannot be an empty or placeholder object
If disable is present, it must be a non-empty object
Each entry maps a service name to its port
If enable is present, it must be a non-empty object
Each entry defines a custom service mapping
Each service name (key) must be a non-empty string
Cannot be blank ornull
Each port value must be a non-empty string
Must specify port in correct format
Port must be a valid number between 1–65535, optionally followed by /tcp or /udp
e.g.,5060,2222/tcp,69/udp

What's Not Allowed

  • Using etc_services as a list, string, or null
  • Empty disable or enable blocks
  • Invalid service names (e.g., spaces, special characters)
  • Missing or malformed port values (e.g., "abc", "65536", "5060/tcpp")
  • Duplicate service names across disable and enable
  • Omitting both disable and enable
  • Using invalid protocols (e.g., /http, /ssh) — only /tcp, /udp allowed

Interpreted as

Services to Disable (Comment Out):

The following lines in /etc/services will have # added at the start:

echo 7/tcp
chargen 19/tcp
telnet 23/tcp
tftp 69/udp
finger 79/tcp
...

❌ Prevents accidental use of legacy/insecure services.

Services to Enable (Add/Ensure):

The following entries will be added if missing:

cmslb 2139/tcp
csp 2222/tcp
sip 5060/tcp
sip-tls 5061/tcp
esm 5600/tcp
...
http-clt 18081/tcp
https-clt 43443/tcp

✅ Enables application-specific port naming for clarity and consistency.

🔧 How to Apply

Use automation to update /etc/services:

bash
# Backup original file
sudo cp /etc/services /etc/services.bak

# Comment out disabled services
sed -i '/^echo[[:space:]]\+7\//s/^/#/' /etc/services
sed -i '/^tftp[[:space:]]\+69\/udp/s/^/#/' /etc/services
sed -i '/^finger[[:space:]]\+79\/tcp/s/^/#/' /etc/services
# ... repeat for all in 'disable'

# Add enabled services (if not present)
grep -q "http-clt.*18081/tcp" /etc/services || echo "http-clt 18081/tcp" | sudo tee -a /etc/services
grep -q "https-clt.*43443/tcp" /etc/services || echo "https-clt 43443/tcp" | sudo tee -a /etc/services
# ... repeat for all in 'enable'

Verify:

bash
getent services sip
getent services http-clt

⚠️ Important Notes

  • Disabling in /etc/services does not stop running services — only removes name-to-port mapping
  • To fully disable a service, also:
    • Stop it: systemctl stop <service>
    • Disable it: systemctl disable <service>
  • Use getent services <name> to verify mappings
  • Avoid editing /etc/services manually — use automation for consistency
  • Changes do not require reboot — tools read the file live




🔧 services Configuration

Key: services

Description

This section defines system service management policies by specifying which services should be disabled or enabled at boot time. It ensures only necessary services are active, reducing attack surface and aligning with security hardening standards.

✅ Used during system provisioning to enforce secure-by-default service states.

JSON Format

json
"services": {
"disable": [
"cups",
"sendmail",
"network",
"httpd.service",
"firewalld",
"iptables"
],
"enable": [
"sshd"
]
}

Field Reference

disable
List[str]
List of service names to be disabled (will not start at boot)
"cups","firewalld"
enable
List[str]
List of service names to be enabled (will start at boot)
"sshd"

✅ Service names must match systemd unit files (e.g., sshd.service) or SysVinit scripts.

Validations Enforced

services must be an object
Must be a key-value structure — not a list, string, ornull
Must contain at least one of disable or enable
Cannot be an empty or placeholder object
At least one of disable or enable must be a non-empty list
Prevents{ "disable": [], "enable": [] }
If disable is present, it must be a list
Cannot be a string, object, ornull
Each item in disable must be a non-empty string
Individual service names must be valid strings
If enable is present, it must be a list
Cannot be a string, object, ornull
Each item in enable must be a non-empty string
Individual service names must be valid strings

What's Not Allowed

  • Using services as a list, string, or null
  • Empty object: {} or {"disable": null, "enable": []}
  • Missing both disable and enable
  • Setting disable or enable to a string or object instead of a list
  • Blank or invalid service names (e.g., "", " "``, "123"`)
  • Non-string values in disable or enable lists
  • Duplicate service names
  • Using .service suffix inconsistently (e.g., sshd vs sshd.service) — both work, but consistency is preferred

Interpreted as

Services to Disable:

cups
Printing service
Not needed on headless servers
sendmail
Legacy MTA
Replaced by external relay orpostfix
network
SysVinit networking script
Replaced byNetworkManageror static config
httpd.service
Apache web server
Only if not used locally
firewalld
Dynamic firewall manager
Replaced bynftables
iptables
Legacy packet filtering
Replaced bynftablesrules

❌ These services will be stopped and disabled:

bash
sudo systemctl disable --now cups sendmail network httpd.service firewalld iptables

Services to Enable:

sshd
Secure shell access

✅ Will be enabled to start at boot:

bash
sudo systemctl enable sshd

🔧 How to Apply

Run the following commands:

bash
# Disable unnecessary services
sudo systemctl disable --now \
cups \
sendmail \
network \
httpd.service \
firewalld \
iptables

# Enable essential services
sudo systemctl enable --now sshd

✅ Use --now to stop/disable or start/enable immediately.

Verify:

bash
systemctl is-enabled sshd
systemctl is-active sshd

⚠️ Important Notes

  • Always test remotely-accessible systems with console access before disabling sshd
  • Disabling network may break connectivity on RHEL 7 systems using SysVinit networking
  • firewalld and iptables should only be disabled if nftables is actively managing firewall rules
  • Avoid disabling sshd unless replaced by another secure access method
  • Use systemctl list-unit-files --type=service to audit all enabled services
  • Automation tools (Ansible, Puppet) should manage this to ensure consistency





🔧 system_security_policies Configuration

Key: system_security_policies

Description

This section defines critical system security policies by writing configuration blocks to key files under /etc/security/. It configures:

  • Maximum file descriptor limits (limits.conf)
  • Strong password complexity rules (pwquality.conf)

✅ Used during system hardening to enforce resource limits and high-entropy passwords across all users.

JSON Format

json
"system_security_policies": [
{
"COMMENT": "Add the lines below to the limits.conf file",
"file_name": "/etc/security/limits.conf",
"lines": [
"* - nofile 65536",
"* soft core unlimited",
"core file size (blocks, -c) unlimited"
]
},
{
"COMMENT": "Add the below lines to the pwquality.conf file",
"file_name": "/etc/security/pwquality.conf",
"lines": [
"PASS_MAX_DAYS = 99999",
"minlen = 16",
"dcredit = -1",
"ucredit = -1",
"lcredit = -1",
"ocredit = -1",
"minclass = 3"
]
}
]

Field Reference

COMMENT
String
Optional note explaining purpose (ignored during processing)
"Add the lines below to the limits.conf file"
file_name
String
Path to the target security configuration file
"/etc/security/limits.conf"
lines
List[str]
List of directives to be added or updated in the file
["* soft core unlimited", ...]

✅ Each block applies settings to a different security policy file.

Validations Enforced

system_security_policies must be a non-empty list
Must contain at least one policy block — cannot benull, an object, or empty
Each item in system_security_policies must be an object
Every entry must be a key-value structure (not a string or array)
Each configuration must have file_name
Required to specify where the policy will be applied
file_name must be a non-empty string
Cannot be missing,null, or blank
Each configuration must have lines
Required to define the actual policy directives
lines must be a non-empty list
Cannot be missing or empty
Each line in lines must be a non-empty string
Individual policy entries must be valid strings

What's Not Allowed

  • Using system_security_policies as an object, string, or null
  • Empty system_security_policies array
  • Missing file_name or lines in any block
  • Blank or invalid file_name (e.g., "", " "``, /invalid/path`)
  • Empty or missing lines array
  • Non-string values in lines
  • Syntax errors in lines — even though not validated here, they will break PAM or limit enforcement
  • Using uppercase or spaces in keys without proper quoting

Interpreted as

1. /etc/security/limits.conf

* - nofile 65536
* soft core unlimited
core file size (blocks, -c) unlimited

✅ This configures:

  • All users (*) can open up to 65,536 files
  • Core dumps are unlimited in size
  • Prevents application crashes due to file handle exhaustion

2. /etc/security/pwquality.conf

PASS_MAX_DAYS = 99999
minlen = 16
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
minclass = 3

✅ This configures:

  • Password never expires (99999 ≈ 273 years)
  • Minimum length: 16 characters
  • Requires at least one digit, uppercase, lowercase, and special character
  • At least 3 character classes must be used

⚠️ Note: These rules apply only if enforced by PAM (e.g., via pam_pwquality.so in /etc/pam.d/system-auth)

🔧 How to Apply

Update each file:

bash
# Configure limits.conf
sudo tee /etc/security/limits.conf << 'EOF'
# Increase file descriptor and core dump limits
* - nofile 65536
* soft core unlimited
core file size (blocks, -c) unlimited
EOF

# Configure pwquality.conf
sudo tee /etc/security/pwquality.conf << 'EOF'
# Password Quality Settings
PASS_MAX_DAYS = 99999
minlen = 16
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
minclass = 3
EOF

Ensure PAM is configured to use pam_pwquality:

bash
grep pam_pwquality /etc/pam.d/system-auth

Test password strength:

bash
echo "weakpass" | pamtester system-auth username passwd validate

⚠️ Important Notes

  • Changes to limits.conf take effect at next login session
  • Use ulimit -n to verify file limit
  • pwquality.conf does not enforce rules by itself — must be linked in PAM
  • Avoid setting PASS_MAX_DAYS=0 — forces password change every login
  • Always test with a non-root user before deployment
  • These policies apply to local accounts — may not affect LDAP, SSO, or CyberArk-managed users





🔧 site_name Configuration

Key: site_name

Description

This section defines the logical site identifier for the system, used during provisioning, automation, and inventory tracking. The site_name helps classify systems by location, environment, or role (e.g., rchmtv2t for RCH Media Server Test Environment).

✅ Used by deployment tools, monitoring systems, and logging platforms to group and report on systems consistently.

JSON Format

json
"site_name": "rchmtv2t"

Field Reference

site_name
String
Logical name identifying the site, environment, or deployment zone
"rchmtv2t"

✅ Must follow strict naming rules to ensure compatibility with automation and DNS policies.

Validations Enforced

site_name must be a non-empty string
Cannot benull,"",[], or missing
site_name must contain only lowercase letters, digits, hyphens, or underscores
No uppercase letters, spaces, or special characters allowed
site_name must be between 3 and 30 characters long
Minimum 3, maximum 30 — e.g.,dev,rchmtv2t,prod-us-west

What's Not Allowed

  • Using uppercase letters (e.g., "RCHMTV2T")
  • Spaces or whitespace (e.g., "rch mtv2t")
  • Special characters: @, ., !, #, $, (, ), etc.
  • Leading or trailing hyphens/underscores (e.g., -rchmtv2t, rchmtv2t_)
  • Names shorter than 3 characters (e.g., "r1")
  • Names longer than 30 characters
  • Using IP addresses or FQDNs as site names
  • Empty or null values

Interpreted as

The system will be tagged with the site identifier:

rchmtv2t

✅ This value may be used in:

  • Hostname generation
  • Log routing
  • Monitoring dashboards
  • Automation playbooks
  • Asset management systems

🔄 Example derived hostname: cml-rchmtv2t-app01.vzbi.com

🔧 How to Apply

Set the value in your configuration payload:

json
{
"site_name": "rchmtv2t"
}

Or use it in templates/scripts:

bash
SITE_NAME="rchmtv2t"
echo "Deploying to site: $SITE_NAME"

No file or service restart required — this is a metadata field consumed during provisioning.

⚠️ Important Notes

  • Always use lowercase only — case-sensitive systems may reject mixed-case names
  • Avoid abbreviations that are unclear to others
  • Coordinate naming with your infrastructure team to avoid conflicts
  • This field is often used in auto-generated hostnames, so accuracy is critical
  • Does not affect network or DNS directly — but influences naming standards





🔧 sysconfig_files Configuration

Key: sysconfig_files

Description

This section defines custom configurations for system service environment files located under /etc/sysconfig/. These files are used by init scripts or systemd to pass startup parameters to services such as snmpd, sshd, named, network interfaces, and nftables.

✅ Used to fine-tune service behavior, disable unwanted logging, enforce NIC settings, and include custom rules at boot.

JSON Format

json
"sysconfig_files": [
{
"COMMENT": "Add the following line in snmpd file to only log critical messages in /var/log/messages",
"file_name": "/etc/sysconfig/snmpd",
"lines": [
"OPTIONS -LS0-2d -Lf /dev/null -p /var/run/snmpd.pid -a"
]
},
{
"COMMENT": "Add the below lines to the sshd file",
"file_name": "/etc/sysconfig/sshd",
"lines": [
"SSH_USE_STRONG_RNG 0",
"CRYPTO_POLICY \"\""
]
},
{
"COMMENT": "Add the below line to the named file to disable the IPv6 logs in messages file",
"file_name": "/etc/sysconfig/named",
"lines": [
"OPTIONS= -4"
]
},
{
"COMMENT": "Setting to add and remove parameters in ifcfg-ens192 file",
"file_name": "/etc/sysconfig/network-scripts/ifcfg-ens192",
"lines": [
"ETHTOOL_OPTS=autoneg off speed 1000 duplex full",
"#DNS1=xxx.xxx.xxx.xxx",
"#DNS2=xxx.xxx.xxx.xxx",
"#DOMAIN=",
"#PEERDNS="
]
},
{
"COMMENT": "Setting to add and remove parameters in ifcfg-ens224 file",
"file_name": "/etc/sysconfig/network-scripts/ifcfg-ens224",
"lines": [
"ETHTOOL_OPTS=autoneg off speed 1000 duplex full",
"#DNS1=xxx.xxx.xxx.xxx",
"#DNS2=xxx.xxx.xxx.xxx",
"#DOMAIN=",
"#PEERDNS=",
"#GATEWAY="
]
},
{
"COMMENT": "Add the following line to nftables.conf",
"file_name": "/etc/sysconfig/nftables.conf",
"lines": [
"include \"/etc/nftables/nftablesrules.nft\""
]
}
]

Field Reference

COMMENT
String
Optional note explaining purpose (ignored during processing)
"Add the following line..."
file_name
String
Path to the sysconfig file being modified
"/etc/sysconfig/sshd"
lines
List[str]
List of lines to be added or updated in the file
["OPTIONS= -4", ...]

✅ Supports both adding new directives and commenting out existing ones (via # prefix).

Validations Enforced

sysconfig_files must be a non-empty object or list of objects
Can be a single config block or an array of blocks
Each item in sysconfig_files must be an object
Every entry must be a key-value structure
Each configuration must have file_name
Required to specify the target configuration file
file_name must be a non-empty string
Cannot be missing,null, or blank
Each configuration must have lines
Required to define the content to be written
lines must be a non-empty list
Cannot be missing or empty
Each line in lines must be a non-empty string
Individual entries must be valid strings (e.g.,SSH_USE_STRONG_RNG 0)

What's Not Allowed

  • Using sysconfig_files as a string, number, or null
  • Empty sysconfig_files array or object
  • Missing file_name or lines in any block
  • Blank or invalid file_name (e.g., "", " "``, /invalid/path`)
  • Empty or missing lines array
  • Non-string values in lines
  • Syntax errors in lines — even though not validated here, they will break service startup
  • Using > or | without escaping in values

Interpreted as

1. /etc/sysconfig/snmpd

bash
OPTIONS -LS0-2d -Lf /dev/null -p /var/run/snmpd.pid -a

Logs only critical SNMP messages (0=emergency, 1=alert, 2=critical), suppresses debug noise.

2. /etc/sysconfig/sshd

bash
SSH_USE_STRONG_RNG 0
CRYPTO_POLICY ""
  • Disables blocking on /dev/random (faster SSH startup)
  • Disables system crypto policy to allow custom ciphers in sshd_config

3. /etc/sysconfig/named

bash
OPTIONS= -4

Runs BIND in IPv4-only mode — prevents IPv6-related messages in /var/log/messages

4. /etc/sysconfig/network-scripts/ifcfg-ens192

bash
ETHTOOL_OPTS=autoneg off speed 1000 duplex full
#DNS1=...
#DNS2=...
#DOMAIN=
#PEERDNS=

Sets fixed 1Gbps link and disables DHCP-managed DNS settings.

5. /etc/sysconfig/network-scripts/ifcfg-ens224

bash
ETHTOOL_OPTS=autoneg off speed 1000 duplex full
#DNS1=...
#DNS2=...
#DOMAIN=
#PEERDNS=
#GATEWAY=

Same as above, but also disables gateway override on this interface.

6. /etc/sysconfig/nftables.conf

bash
include "/etc/nftables/nftablesrules.nft"

Ensures custom firewall rules are loaded at boot.

🔧 How to Apply

Create or update each file:

bash
# snmpd
echo 'OPTIONS -LS0-2d -Lf /dev/null -p /var/run/snmpd.pid -a' | sudo tee /etc/sysconfig/snmpd

# sshd
cat << 'EOF' | sudo tee /etc/sysconfig/sshd
SSH_USE_STRONG_RNG 0
CRYPTO_POLICY ""
EOF

# named
echo 'OPTIONS= -4' | sudo tee /etc/sysconfig/named

# ifcfg-ens192
cat << 'EOF' | sudo tee /etc/sysconfig/network-scripts/ifcfg-ens192
ETHTOOL_OPTS=autoneg off speed 1000 duplex full
#DNS1=xxx.xxx.xxx.xxx
#DNS2=xxx.xxx.xxx.xxx
#DOMAIN=
#PEERDNS=
EOF

# ifcfg-ens224
cat << 'EOF' | sudo tee /etc/sysconfig/network-scripts/ifcfg-ens224
ETHTOOL_OPTS=autoneg off speed 1000 duplex full
#DNS1=xxx.xxx.xxx.xxx
#DNS2=xxx.xxx.xxx.xxx
#DOMAIN=
#PEERDNS=
#GATEWAY=
EOF

# nftables.conf
echo 'include "/etc/nftables/nftablesrules.nft"' | sudo tee /etc/sysconfig/nftables.conf

Then restart affected services:

bash
sudo systemctl restart snmpd sshd named network nftables

⚠️ Important Notes

  • Always backup original files before modifying
  • Changes take effect after service restart or reboot
  • Use systemctl status <service> to verify services start correctly
  • Commented-out lines (e.g., #DNS1=) prevent automatic re-addition by DHCP
  • SSH_USE_STRONG_RNG=0 uses /dev/urandom — safe unless FIPS requires /dev/random
  • The include directive in nftables.conf is required for rule persistence




🔧 user_login_definition Configuration

Key: user_login_definition

Description

This section defines default password policies for user accounts by modifying the /etc/login.defs file. It sets password expiration, minimum length, and warning periods that apply to new users created via useradd. This configuration helps standardize account behavior across systems.

✅ Used during system provisioning to enforce baseline security policies for local accounts.

JSON Format

json
"user_login_definition": {
"COMMENT": "Add the below lines to the login.defs file",
"file_name": "/etc/login.defs",
"settings": {
"PASS_MAX_DAYS": "99999",
"PASS_MIN_DAYS": "0",
"PASS_MIN_LEN": "5",
"PASS_WARN_AGE": "7"
}
}

Field Reference

COMMENT
String
Optional note for documentation (ignored during processing)
"Add the below lines to the login.defs file"
file_name
String
Path to the login configuration file
"/etc/login.defs"
settings
Object
Key-value pairs defining password aging and length policies
{ "PASS_MAX_DAYS": "99999", ... }
PASS_MAX_DAYS
String
Maximum number of days a password may be used before it must be changed
"99999"
PASS_MIN_DAYS
String
Minimum number of days between password changes
"0"
PASS_MIN_LEN
String
Minimum acceptable password length
"5"
PASS_WARN_AGE
String
Number of days before password expiry to warn the user
"7"

Validations Enforced

user_login_definition must be an object
Must be a key-value structure — not a list, string, ornull
file_name is required and must be a non-empty string
Specifies where the settings will be applied (e.g.,/etc/login.defs)
settings must be a non-empty object
Must contain the password policy fields — cannot be missing,null, or empty
PASS_MAX_DAYS must be present and a non-empty string containing only digits
Ensures valid numeric input (e.g.,99999)
PASS_MIN_DAYS must be present and a non-empty string containing only digits
Prevents invalid values likeoffor-1
PASS_MIN_LEN must be present and a non-empty string containing only digits
Enforces numeric value for minimum length
PASS_WARN_AGE must be present and a non-empty string containing only digits
Must be a number (e.g.,7)

What's Not Allowed

  • Using user_login_definition as a list or string
  • Missing file_name or setting it to "", null
  • Omitting settings or setting it to null, [], {} (empty)
  • Missing any of the four required keys: PASS_MAX_DAYS, PASS_MIN_DAYS, PASS_MIN_LEN, PASS_WARN_AGE
  • Setting any value to a non-digit string (e.g., "five", "abc")
  • Using negative numbers or decimals (e.g., -1, 5.5)
  • Including extra or unsupported keys without approval

Interpreted as

The following lines will be added or updated in /etc/login.defs:

PASS_MAX_DAYS 99999
PASS_MIN_DAYS 0
PASS_MIN_LEN 5
PASS_WARN_AGE 7

✅ This configures:

  • Passwords never expire (99999 ≈ 273 years)
  • No minimum wait between changes (0 days)
  • Minimum length of 5 characters
  • User warned 7 days before expiration (if enabled)

⚠️ Note: PASS_MIN_LEN=5 is enforced only if paired with pam_pwquality.so — not by login.defs alone.

🔧 How to Apply

Update /etc/login.defs:

bash
sudo cp /etc/login.defs /etc/login.defs.bak

sudo sh -c 'cat >> /etc/login.defs << EOF

# Password Policy Settings
PASS_MAX_DAYS 99999
PASS_MIN_DAYS 0
PASS_MIN_LEN 5
PASS_WARN_AGE 7
EOF'

Or use sed to replace existing values:

bash
sudo sed -i 's/^PASS_MAX_DAYS.*/PASS_MAX_DAYS 99999/' /etc/login.defs
sudo sed -i 's/^PASS_MIN_DAYS.*/PASS_MIN_DAYS 0/' /etc/login.defs
sudo sed -i 's/^PASS_MIN_LEN.*/PASS_MIN_LEN 5/' /etc/login.defs
sudo sed -i 's/^PASS_WARN_AGE.*/PASS_WARN_AGE 7/' /etc/login.defs

⚠️ Important Notes

  • These settings apply only to new users created with useradd
  • Existing users must be updated using chage:
    bash
    chage -M 99999 username
  • PASS_MIN_LEN requires pam_pwquality or pam_cracklib to be active in /etc/pam.d/system-auth
  • Avoid setting PASS_MAX_DAYS=0 — forces password change every login
  • In environments using LDAP, SSO, or CyberArk, these settings may have limited impact
  • Always test with a non-root user before deployment






🔧 logrotation_conf Configuration

Key: logrotation_conf

Description

This section defines custom log rotation settings by writing configuration blocks to /etc/logrotate.conf and individual files under /etc/logrotate.d/. It sets global policies (e.g., daily rotation, 30-day retention) and service-specific rules for critical logs like wtmp, btmp, and syslog-managed files.

✅ Used to standardize log management, prevent disk space exhaustion, and ensure auditability across systems.

JSON Format

json
"logrotation_conf": [
{
"COMMENT": "Add the below lines to the logrotate.conf file",
"file_name": "/etc/logrotate.conf",
"lines": [
"daily",
"rotate 30",
"create",
"dateext",
"include /etc/logrotate.d"
]
},
{
"file_name": "/etc/logrotate.d/syslog",
"lines": [
"/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron {",
"sharedscripts",
"postrotate",
"/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true",
"/bin/kill -HUP `cat /var/run/rsyslogd.pid 2> /dev/null` 2> /dev/null || true",
"chmod -f 644 /var/log/messages* || true",
"chmod -f 644 /var/log/boot.log* || true",
"chmod -f 644 /var/log/dmsg* || true",
"chmod -f 644 /var/log/cron* || true",
"endscript",
"}"
]
},
{
"file_name": "/etc/logrotate.d/wtmp",
"lines": [
"/var/log/wtmp {",
"create 0644 root utmp",
"minsize 1M",
"monthly",
"rotate 1",
"}"
]
},
{
"file_name": "/etc/logrotate.d/btmp",
"lines": [
"/var/log/btmp {",
"create 0644 root utmp",
"monthly",
"rotate 12",
"}"
]
}
]

Field Reference

file_name
String
Path to the logrotate configuration file (global or service-specific)
"/etc/logrotate.conf"
lines
List[str]
List of directives to be added to the file
["daily", "rotate 30", ...]
COMMENT
String
Optional note for documentation (ignored during processing)
"Add the below lines..."

Validations Enforced

logrotation_conf must be a non-empty list
Must contain at least one configuration block — cannot benull, an object, or empty
Each item in logrotation_conf must be an object
Every entry must be a key-value structure (not a string or array)
Each configuration must have file_name
Required to specify where the logrotate rules will be applied
file_name must be a non-empty string
Cannot be missing,null, or blank
Each configuration must have lines
Required to define the log rotation behavior
lines must be a non-empty list
Cannot be missing or empty
Each line in lines must be a non-empty string
Individual logrotate directives must be valid strings

What's Not Allowed

  • Using logrotation_conf as an object, string, or null
  • Empty logrotation_conf array
  • Missing file_name or lines in any block
  • Blank or invalid file_name (e.g., "", `" "``)
  • Empty or missing lines array
  • Non-string values in lines
  • Syntax errors in lines — even though not validated here, they will break logrotate

Interpreted as

1. Global Settings (/etc/logrotate.conf)

daily
rotate 30
create
dateext
include /etc/logrotate.d

Rotates logs daily, keeps 30 copies, uses date suffixes, and includes service-specific configs.

2. Syslog Logs (/etc/logrotate.d/syslog)

Rotates:

  • /var/log/messages
  • /var/log/secure
  • /var/log/maillog
  • /var/log/spooler
  • /var/log/boot.log
  • /var/log/cron

With:

  • postrotate script to reload syslogd/rsyslogd and fix permissions
  • sharedscripts: runs postrotate once per group

3. Login History (/etc/logrotate.d/wtmp)

/var/log/wtmp {
create 0644 root utmp
minsize 1M
monthly
rotate 1
}

Rotates only if ≥1MB, keeps 1 archive — useful for low-traffic systems.

4. Failed Logins (/etc/logrotate.d/btmp)

/var/log/btmp {
create 0644 root utmp
monthly
rotate 12
}

Keeps 12 months of failed login history for security auditing.

🔧 How to Apply

Create each file:

bash
# Global config
sudo tee /etc/logrotate.conf << 'EOF'
daily
rotate 30
create
dateext
include /etc/logrotate.d
EOF

# Syslog rules
sudo tee /etc/logrotate.d/syslog << 'EOF'
/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron {
sharedscripts
postrotate
/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
/bin/kill -HUP `cat /var/run/rsyslogd.pid 2> /dev/null` 2> /dev/null || true
chmod -f 644 /var/log/messages* || true
chmod -f 644 /var/log/boot.log* || true
chmod -f 644 /var/log/dmsg* || true
chmod -f 644 /var/log/cron* || true
endscript
}
EOF

# wtmp rotation
sudo tee /etc/logrotate.d/wtmp << 'EOF'
/var/log/wtmp {
create 0644 root utmp
minsize 1M
monthly
rotate 1
}
EOF

# btmp rotation
sudo tee /etc/logrotate.d/btmp << 'EOF'
/var/log/btmp {
create 0644 root utmp
monthly
rotate 12
}
EOF

Test configuration:

bash
sudo logrotate -d /etc/logrotate.conf

⚠️ Important Notes

  • Always backup original files before updating
  • The postrotate script ensures logging continues after rotation
  • Use || true to prevent failures if PID file is missing
  • chmod -f suppresses errors if file doesn’t exist
  • dateext uses YYYYMMDD suffix (e.g., messages-20250828)
  • Test with -d (debug mode) before production use
  • Monitor /var/lib/logrotate/status to see last run times











Perfect! Based only on your provided validate_networkmanager_conf() validator function, here is the accurate, user-friendly "Validations Enforced" section — in the same clean and consistent format you've approved.

All rules are in bold, written clearly for end users, and reflect exactly what the validator checks — no assumptions, no extras.

Validations Enforced

networkmanager_conf must be an object
The configuration must be a key-value structure — not a list, string, ornull
file_name is required and must be a non-empty string
Specifies the target NetworkManager config file (e.g.,/etc/NetworkManager/NetworkManager.conf)
lines is required and must be a non-empty list
Must contain at least one configuration line
Each line in lines must be a non-empty string
Individual directives (e.g.,dns=none) must be valid strings

✅ This matches your validator 100%:

  • Checks networkmanager_conf is an object ✅
  • file_name is present, non-empty, and a string ✅
  • lines is present, a list, and non-empty ✅
  • Each item in lines is a non-empty string ✅

🚫 Does not validate:

  • Whether the file_name path is correct or writable
  • If the lines contain valid NetworkManager.conf syntax (e.g., [main], dns=none)
  • Duplicate or conflicting settings
  • Use of unsupported parameters

So we do not include those in the validations.

💡 Note: This validator ensures correct JSON structure only — actual configuration correctness (e.g., valid INI sections) must be verified during deployment or by the system. 







Perfect! Based only on your provided validate_extra_packages() validator function, here is the accurate, user-friendly "Validations Enforced" section — in the same clean and consistent format you've approved.

All rules are in bold, written clearly for end users, and reflect exactly what the validator checks — nothing more, nothing less.

Validations Enforced

extra_packages must be a non-empty list
Must contain at least one package name — cannot benull, an object, or empty
Each item in extra_packages must be a non-empty string
Every entry must be a valid package name (e.g.,"gcc","openssl-devel")

✅ This matches your validator 100%:

  • Checks extra_packages is a non-empty list ✅
  • Each item must be a non-empty string ✅
  • No other types (e.g., numbers, objects, null) are allowed ✅

🚫 Does not validate:

  • Whether the package exists in repositories
  • If it's a valid RPM or system package
  • Duplicates (e.g., libstdc++ appearing twice)
  • Case sensitivity or spelling (e.g., Python3-pexpect vs python3-pexpect)
  • Use of wildcards (e.g., nmap*) or invalid formats

So we do not include those in the validations.

💡 Note: This validator ensures correct structure only — actual package validity is checked during system provisioning or by dnf/yum. 




Perfect! Based only on your provided validate_base_packages() validator function, here is the accurate, user-friendly "Validations Enforced" section — in the same clean and consistent format you've approved.

All rules are in bold, written clearly for end users, and reflect exactly what the validator checks — no assumptions, no extras.

Validations Enforced

base_packages must be a non-empty list
Must contain at least one package name — cannot benull, an object, or empty
Each item in base_packages must be a non-empty string
Every entry must be a valid package name (e.g.,"@Core","wget")

✅ This matches your validator 100%:

  • Checks base_packages is a non-empty list ✅
  • Each item must be a non-empty string ✅
  • No other types allowed (e.g., numbers, objects, null) ✅

🚫 Does not validate:

  • Whether the package name exists in repositories
  • If it's a valid group (e.g., @Core) or individual package
  • Duplicate entries
  • Case sensitivity or spelling (e.g., Wget, wGet)
  • Use of wildcards or invalid formats

So we do not include those in the validations.

💡 Note: The validator ensures correct structure and basic formatting, but does not verify package validity — that happens during system provisioning. 






Perfect! Based only on your provided validate_symbolic_links() validator function, here is the accurate, user-friendly "Validations Enforced" section — in the same clean and consistent format you've approved.

All rules are in bold, written clearly for end users, and reflect exactly what the validator checks — no assumptions, no extras.

Validations Enforced

symbolic_links must be a non-empty list
Must contain at least one link definition — cannot benull, an object, or empty
Each item in symbolic_links must be an object
Every entry must be a key-value structure (not a string or array)
Each object must have src and dest fields
Required to define the source (target) and destination (link path)
src must be a non-empty string (valid path)
Specifies the actual directory or file being linked to
dest must be a non-empty string (valid path)
Specifies where the symbolic link will be created

✅ This matches your validator 100%:

  • Checks symbolic_links is a non-empty list ✅
  • Each item is a dict/object ✅
  • Both src and dest are required, non-empty strings ✅
  • No extra fields or types allowed without breaking validation ✅

🚫 Does not validate:

  • Whether the src path exists
  • If the dest path is already in use or conflicts with a file/directory
  • Absolute vs relative paths (though absolute is expected)
  • Duplicate entries

So we do not include those in the validations.

💡 Note: The format is { "src": "/actual/path", "dest": "/link/path" } — this validator ensures structure and non-empty strings, but does not verify filesystem state. 





Perfect! Based only on your provided validate_ntp_servers() validator function, here is the accurate, user-friendly "Validations Enforced" section — in the same clean and consistent format you've approved.

All rules are in bold, written clearly for end users, and reflect exactly what the validator checks — no assumptions, no extras.

Validations Enforced

ntp_servers must be an object
The configuration must be a key-value structure — not a list, string, ornull
ntp_servers must not be empty
Must contain at least one NTP server entry
Each key (hostname) must be a non-empty string
Hostnames likendcdns.vzbi.commust be valid strings — not blank ornull
Each value (IP address) must be a non-empty string
IP addresses must be provided as strings (e.g.,"166.37.162.103")
Each IP address must be a valid IPv4 address
Only valid dotted-decimal format allowed (e.g.,166.37.162.103)

✅ This matches your validator 100%:

  • Checks ntp_servers is an object ✅
  • Not empty (if not data) ✅
  • Each key is a non-empty string ✅
  • Each value is a non-empty string and a valid IPv4 address ✅

🚫 Does not validate:

  • Whether the hostname resolves to the given IP
  • If the NTP server is reachable or synchronized
  • Use of duplicate IPs or hostnames
  • Case sensitivity or formatting (e.g., extra spaces)

So we do not include those in the validations.

💡 Note: The format is "hostname": "ip_address" — this validator ensures both are valid, but does not check DNS consistency. 






Perfect! Based only on your provided validate_server_details() validator function, here is the accurate, user-friendly "Validations Enforced" section — in the same clean and consistent format you've approved.

All rules are in bold, written clearly for end users, and reflect exactly what the validator checks — nothing more, nothing less.

Validations Enforced

server_details must be an object
The configuration must be a key-value structure — not a list, string, ornull
servername is required and must be a non-empty string
Specifies the fully qualified server name (e.g.,cml-testvm.vzbi.com)
total_storage_size is required and must be a non-empty string
Must specify the total allocated storage
total_storage_size must be specified in GB or MB (e.g., 100GB, 500MB, 10G, 250M)
Supports case-insensitiveG,M,GB,MB— must start with a number
namespace is required and must be a non-empty string
Used for automation grouping or environment tagging (e.g.,vm-automation)

✅ This matches your validator 100%:

  • Checks server_details is an object ✅
  • servername, total_storage_size, and namespace are all required fields ✅
  • Each is validated as a non-empty string ✅
  • total_storage_size must match the regex pattern: ^\d+\s?(GB|MB|G|M)$ (case-insensitive) ✅

🚫 Does not validate:

  • Whether servername is unique or DNS-resolvable
  • If total_storage_size matches actual disk allocation
  • Whether namespace is an approved value (e.g., vm-automation, prod)
  • Trailing spaces (though .strip() is used)

So we do not include those in the validations.





Perfect! Based only on your provided validate_email_notification_list() validator function, here is the accurate, user-friendly "Validations Enforced" section — in the exact same clean and consistent format you've approved.

All rules are in bold, written clearly for end users, and reflect exactly what the validator checks — no assumptions, no extras.

Validations Enforced

email_notification_list must be an object
The configuration must be a key-value structure — not a list, string, ornull
to is required and must be a non-empty string
Specifies the recipient email address for alerts and notifications
to must be a valid email address
Must follow standard email format (e.g.,user@domain.com) — checked via regex pattern

✅ This matches your validator 100%:

  • Checks email_notification_list is an object ✅
  • to field is present, non-empty, and a string ✅
  • to value passes email format validation (using regex for local@domain.tld ) ✅

🚫 Does not validate:

  • Whether the email domain is internal (e.g., @verizon.com)
  • If the email address actually exists or is active
  • Multiple recipients (e.g., comma-separated list)
  • Use of distribution lists vs personal emails

So we do not include those in the validations.

💡 Note: The validator does not allow lists or multiple addresses — only a single valid email string. 






Perfect! Based only on your provided validate_postfix_configs() validator function, here is the accurate, user-friendly "Validations Enforced" section — in the exact same clean and consistent format you've approved.

All rules are in bold, written clearly for end users, and reflect exactly what the validator checks — no assumptions, no extras.

Validations Enforced

postfix_configs must be a non-empty list
Must contain at least one configuration block — cannot benull, an object, or empty
Each item in postfix_configs must be an object
Every entry must be a key-value structure (e.g., withfile_nameandsettings)
Each configuration must have file_name
Required to specify the target Postfix config file (e.g.,/etc/postfix/main.cf)
file_name must be a non-empty string
Cannot be missing,null, or blank
Each configuration must have settings
Required to define the Postfix parameters
settings must be a non-empty list
Must contain at least one setting (e.g.,relayhost)
Each item in settings must be an object
Must havenameandvaluefields
Each setting must have name as a non-empty string
Specifies the Postfix parameter (e.g.,relayhost)
Each setting must have value
Can be either anon-empty stringor anon-empty list of non-empty strings
If value is a list, every item in it must be a non-empty string
Ensures all values are valid and usable (e.g.,["vzsmtp.verizon.com"])

✅ This matches your validator 100%:

  • Checks postfix_configs is a non-empty list of objects ✅
  • Each block has file_name and settings ✅
  • settings is a list of objects with name and value ✅
  • value can be string or list — but must not be empty or invalid ✅

🚫 Does not validate:

  • Whether the file_name is a valid Postfix config path
  • If the name is a real Postfix parameter (e.g., relayhost, not relay_host)
  • Syntax of email addresses or hostnames in value
  • Duplicate settings across blocks

So we do not include those in the validations.







Perfect! Based only on your provided validate_custom_commands() validator function, here is the accurate, user-friendly "Validations Enforced" section — in the exact same clean and consistent format you've approved.

All rules are in bold, written for end users, and reflect exactly what the validator checks — nothing more, nothing less.

Validations Enforced

custom_commands must be a non-empty list
Must contain at least one command — cannot benull, an object, or empty
Each item in custom_commands must be a non-empty string
Every entry must be a valid shell command (e.g.,echo "1 sip" >> /etc/iproute2/rt_tables)

✅ This matches your validator 100%:

  • Checks custom_commands is a non-empty list ✅
  • Each item must be a non-empty string ✅
  • No other fields or types are allowed (e.g., objects, numbers, null) ✅

🚫 Does not validate:

  • Whether the command syntax is correct
  • If the command is safe or idempotent
  • Command effects (e.g., file creation, system changes)
  • Duplicate or conflicting commands

So we do not include those in the validations.





Perfect! Based only on your provided validate_application_specific_logging_configuration() validator function, here is the accurate, user-friendly "Validations Enforced" section — in the same clean, consistent format you've approved.

All key rules are in bold, written for end users (not developers), and reflect exactly what the validator checks — no assumptions, no extras.

Validations Enforced

application_specific_logging_configuration must be an object
The configuration must be a key-value structure — not a list, string, ornull
file_name is required and must be a non-empty string
Specifies the path to the systemd service file (e.g.,/etc/systemd/system/cores-script-on-boot.service)
lines is required and must be a non-empty list
Must contain at least one line of systemd unit configuration
Each line in lines must be a non-empty string
Individual lines (e.g.,[Unit],ExecStart=...) must be valid strings
If command is present, it must be a non-empty string
Optional field — used to run post-configuration commands (e.g.,systemctl daemon-reload)

✅ This matches your validator 100%:

  • Checks the top-level is an object ✅
  • file_name is required and non-empty ✅
  • lines is required, a list, and non-empty ✅
  • Each line is a non-empty string ✅
  • command (if present) must be a non-empty string ✅

🚫 Does not validate:

  • Whether the file_name is a valid systemd unit path
  • Syntax of the lines (e.g., correct [Service] format)
  • If the script in ExecStart exists or is executable
  • Whether the command is safe or valid

So we do not include those in the validations.






Perfect! Based only on your provided validate_chroot_configuration() validator function, here is the accurate, user-friendly "Validations Enforced" section — in the same clean and consistent style you've approved.

All rules are in bold, written for end users, and reflect exactly what the validator checks — nothing more, nothing less.

Validations Enforced

chroot_configuration must be a non-empty list
Must contain at least one command — cannot benull, an object, or empty
Each item in chroot_configuration must be a non-empty string
Every entry must be a valid shell command (e.g.,mkdir -p /logging/tune/bin)

✅ This matches your validator 100%:

  • Checks chroot_configuration is a non-empty list ✅
  • Each item must be a non-empty string ✅
  • No other fields or structures are validated (e.g., no file_name, no lines object) ✅

🚫 Does not validate:

  • Whether the command is safe or valid shell syntax
  • If directories or users exist
  • Command order or dependencies (e.g., mkdir before cp)
  • Duplicate or conflicting commands

So we do not include those in the validations.





Perfect! Based only on your provided validate_nvn_cache_configuration() validator function, here is the accurate, user-friendly "Validations Enforced" section — in the exact same style you've approved.

All rules are in bold, written for end users, and reflect exactly what the validator checks — no assumptions, no extras.

Validations Enforced

nvn_cache_configuration must be an object
The configuration must be a key-value structure — not a list, string, ornull
All fields (except COMMENT) must be non-empty strings
Every value (e.g.,command) must be a valid, non-blank string
No empty or blank values are allowed
Fields likecommandmust contain actual content — not""or whitespace

✅ This matches your validator 100%:

  • Checks nvn_cache_configuration is an object ✅
  • Skips validation on COMMENT ✅
  • Ensures all other keys (e.g., command) are non-empty strings ✅
  • No other rules are enforced by this validator

🚫 Does not validate:

  • Whether the command syntax is correct
  • If the target file or directory exists
  • Command execution safety or side effects

So we do not include those in the validations.





Perfect! Based only on your provided validate_selinux_configuration() validator function, here is the accurate, user-friendly "Validations Enforced" section — formatted in the same clean, consistent style you've approved.

All key rules are in bold, written for end users (not developers), and reflect exactly what the validator checks — no extra assumptions.

Validations Enforced

selinux_configuration must be an object
The configuration must be a key-value structure — not a list, string, ornull
selinux_configuration.file_name is required and must be a non-empty string
Specifies the path to the SELinux config file (e.g.,/etc/selinux/config)
selinux_configuration.settings must be an object
Must contain key-value pairs for SELinux parameters
selinux_configuration.settings.SELINUX is required and must be a non-empty string
Defines the enforcement mode
selinux_configuration.settings.SELINUX must be one of: enforcing, permissive, disabled
Only these three values are allowed (case-insensitive)
selinux_configuration.settings.SELINUXTYPE is required and must be a non-empty string
Specifies the policy type (e.g.,targeted)

✅ This matches your validator 100%:

  • Checks selinux_configuration is an object ✅
  • file_name is present and valid ✅
  • settings is an object ✅
  • SELINUX is a non-empty string and one of the allowed values ✅
  • SELINUXTYPE is a non-empty string ✅

🚫 Does not validate:

  • Whether the SELINUXTYPE value (e.g., targeted) actually exists on the system
  • File permissions or SELinux relabeling
  • Runtime state vs config mismatch

So we do not include those in the validations.





erfect! Based only on your provided validate_chrony_conf() validator function, here is the accurate, user-friendly, and properly formatted "Validations Enforced" section — in the exact same style you've approved.

All key rules are in bold, written for end users (not developers), and reflect exactly what the validator checks — no assumptions, no extras.

Validations Enforced

chrony_conf must be a non-empty list
Must contain at least one configuration block — cannot benull, an object, or empty
Each item in chrony_conf must be an object
Each entry must be a key-value structure (not a string or array)
Each configuration must have file_name
Required to specify the target chrony configuration file (e.g.,/etc/chrony.conf)
file_name must be a non-empty string
Cannot be missing,null, or blank
Each configuration must have lines
Required to define the NTP server entries
lines must be a non-empty list
Cannot be missing or empty
Each line in lines must be a non-empty string
Individual entries must be valid strings
Each line must start with server followed by an address
Onlyserverdirectives are allowed (e.g.,server ndcdns.vzbi.com iburst)
The server address must be a valid IPv4 address or domain name
Supports formats like166.37.162.103orndcdns.vzbi.com

✅ This matches your validator 100%:

  • Checks chrony_conf is a non-empty list ✅
  • Each item is a dict/object ✅
  • file_name and lines are required and non-empty ✅
  • Each line must be a non-empty string starting with server ✅
  • Server address must be valid IPv4 or domain ✅

🚫 Does not validate:

  • Whether the NTP server is reachable
  • Syntax of optional parameters like iburst, minpoll, etc.
  • Duplicate entries

So we do not include those in the validations.






Absolutely! Based only on your provided validate_sshd_conf() validator function, here is the accurate, user-friendly, and properly formatted "Validations Enforced" section — in the exact same style you've approved.

All key rules are in bold, clear for end users, and reflect exactly what the validator checks — no more, no less.

Validations Enforced

sshd_conf must be a non-empty list
Must contain at least one configuration block — cannot benull, an object, or empty
Each item in sshd_conf must be an object
Every entry must be a key-value structure (not a string or array)
Each configuration must have file_name
Required to specify the target SSH daemon config file
file_name must be a non-empty string
Cannot be missing,null, or blank (e.g.,/etc/ssh/sshd_config)

✅ This matches your validator 100%:

  • Checks sshd_conf is a non-empty list ✅
  • Each item is a dict/object ✅
  • Each has file_name as a non-empty string ✅

Note:
Your validator does not check any other fields (e.g., Port, PermitRootLogin, UsePAM, etc.) — so we do not include them in validations.





Absolutely! Based only on your provided validate_securetty() validator function, here is the accurate and user-friendly "Validations Enforced" section — formatted in the exact same style you've approved.

All key rules are in bold, clear for end users, and reflect exactly what the validator checks — no assumptions, no extras.

Validations Enforced

securetty must be an object
The configuration must be a key-value structure — not a list, string, ornull
securetty.file_name is required and must be a non-empty string
Specifies the path to the securetty file (e.g.,/etc/securetty)
securetty.lines is required and must be a non-empty list
Must contain at least one TTY/device name (e.g.,console,tty1)
Each line in securetty.lines must be a non-empty string
Each TTY entry must be a valid, non-blank string

✅ This matches your validator 100%:

  • Checks securetty is an object ✅
  • file_name is present and valid ✅
  • lines is present and a non-empty list ✅
  • Each line is a non-empty string ✅

No validation of TTY names (e.g., whether tty1 is valid), no syntax checks — only structural validation.



Absolutely! Based only on your provided validate_custom_scripts() function, here is the accurate, user-friendly, and properly formatted "Validations Enforced" section — in the same style you've approved.

All key rules are in bold, clear for end users, and reflect exactly what the validator checks — nothing more, nothing less.

Validations Enforced

custom_scripts must be a non-empty list
Must contain at least one script definition — cannot benull, an object, or empty
Each item in custom_scripts must be an object
Every script block must be a key-value structure (not a string or array)
Each script must have file_name
Required to specify the target script file (e.g.,/etc/profile.d/custom.sh)
file_name must be a non-empty string
Cannot be missing,null, or blank
Each script must have lines
Required to define the shell commands to be written
lines must be a non-empty list
Cannot be missing or empty
Each line in lines must be a non-empty string
Individual shell commands must be valid strings (e.g.,umask 007)

✅ This matches your validator 100%:

  • Checks custom_scripts is a non-empty list ✅
  • Each item is an object ✅
  • file_name and lines are present and valid ✅
  • Each line is a non-empty string ✅





All key rules are highlighted in bold, and the language is clear for end users (no code references or array indices).

Validations Enforced

nftables must be an object
The configuration must be a key-value structure — not a list, string, ornull
nftables.file_name is required and must be a non-empty string
Specifies the target nftables rules file (e.g.,/etc/nftables/nftables.conf)
nftables.lines is required and must be a non-empty list
Must contain at least one rule or command
Each line in nftables.lines must be a non-empty string
Individualnftcommands must be valid strings (e.g.,add table ip filter)

✅ This reflects exactly what your validate_nftables() function checks — no more, no less.



🔧 snmp_conf Configuration

Key: snmp_conf

Description

This section defines custom configuration for the SNMP daemon (snmpd) by specifying a list of configuration blocks. Each block includes the target file path, site identifier, and SNMP directives (e.g., pass-through modules, access control, views). It also supports optional trap sink IP addresses.

✅ Used to standardize SNMP monitoring setup across systems in environments like RCH.

JSON Format

json
"snmp_conf": [
{
"file_name": "/etc/snmp/snmpd.conf",
"site": "RCH",
"lines": [
"pass .1.3.6.1.4.1.4413.4.1 /usr/bin/ucd5820stat",
"trapsink_1\": \"166.33.186.10",
"dlmod cmaX /usr/lib64/libcmaX64.so",
"group notConfigGroup v2c notConfigUser",
"view systemview included .1.3.6.1.2.1.1",
"view systemview included .1.3.6.1.2.1.25.1.1",
"access notConfigGroup /\"/\" any noauth exact systemview none none"
]
}
]

Field Reference

file_name
String
Path to the SNMP daemon configuration file
"/etc/snmp/snmpd.conf"
site
String
Optional identifier for the deployment site (e.g., RCH, PDC)
"RCH"
lines
List[str]
List of validsnmpd.confdirectives to be added to the file
["pass .1.3...", ...]
trapsink_1,
trapsink_2,
trapsink_3
String (optional)
IP addresses for SNMP trap destinations
"166.33.186.10"

Validations Enforced

snmp_confmust be a non-empty list
Must contain at least one configuration block — cannot benull, empty, or a single object
Each item insnmp_confmust be an object
Each configuration must be a key-value structure (not a string or array)
Each configuration must havefile_name
Required field — specifies the target config file
file_namemust be a non-empty string
Cannot be missing,null, or blank
Each configuration must havelines
Required to define the SNMP directives
linesmust be a non-empty list
Cannot be missing or empty
Each line inlinesmust be a non-empty string
Individual SNMP commands must be valid strings
site(if used) must be a string
Optional field — if present, must be a valid string
trapsink_1,trapsink_2,trapsink_3(if used) must be valid IPv4 addresses
Ensures trap destinations are real IPs

What's Not Allowed

  • Using snmp_conf as an object, string, or null
  • Empty snmp_conf array
  • Missing file_name or lines in any block
  • Blank or invalid file_name (e.g., "", " ")
  • Empty or missing lines array
  • Non-string values in lines
  • site as a number or boolean
  • trapsink_1 with invalid IP (e.g., "166.33.186", "abc")
  • Syntax errors in lines — even though not validated here, they will break snmpd

Interpreted as

The following content will be written to /etc/snmp/snmpd.conf:

pass .1.3.6.1.4.1.4413.4.1 /usr/bin/ucd5820stat
trapsink_1": "166.33.186.10
dlmod cmaX /usr/lib64/libcmaX64.so
group notConfigGroup v2c notConfigUser
view systemview included .1.3.6.1.2.1.1
view systemview included .1.3.6.1.2.1.25.1.1
access notConfigGroup "/" any noauth exact systemview none none

⚠️ Note: The second line appears to have a syntax error (trapsink_1\": \"166.33.186.10) — likely meant to be:

conf
trapsink 166.33.186.10 public

Please verify with your SNMP team.

🔧 How to Apply

Create or update the SNMP config:

bash
sudo mkdir -p /etc/snmp
sudo tee /etc/snmp/snmpd.conf << 'EOF'
pass .1.3.6.1.4.1.4413.4.1 /usr/bin/ucd5820stat
trapsink 166.33.186.10 public
dlmod cmaX /usr/lib64/libcmaX64.so
group notConfigGroup v2c notConfigUser
view systemview included .1.3.6.1.2.1.1
view systemview included .1.3.6.1.2.1.25.1.1
access notConfigGroup "/" any noauth exact systemview none none
EOF

Restart SNMP service:

bash
sudo systemctl restart snmpd

Verify:

bash
sudo systemctl status snmpd

⚠️ Important Notes

  • Always backup the original snmpd.conf before updating
  • The lines are not syntax-validated by the JSON validator — errors may cause snmpd to fail
  • Use sudo snmpd -T -Dinit,config -f to test config before restart
  • trapsink lines should follow standard format: trapsink <IP> <community>
  • Ensure UDP port 162 is open for traps
  • The pass directive allows external scripts to respond to specific OIDs
  • This config uses v2c — consider upgrading to v3 for encryption and authentication

💡 Best Practice Tip

Use configuration management (Ansible, Puppet) to deploy snmpd.conf consistently.

Avoid manual edits — they are not auditable.




✅ Corrected: storage Configuration (Based Only on Your Validator)

Validations Enforced

storagemust be a non-empty list
Must be a list with at least one item — cannot benull, object, or empty
Each item instoragemust be an object
Cannot be a string, array, or invalid type
Each volume group must have avgname
Required field — must be present
vgnamemust be a non-empty string
Cannot benull, blank, or non-string
vgsizemust be present and be a non-empty string matching pattern like100G
Must follow format: digits followed byM,G, orT(e.g.,500G)
logical_volumesmust be present and be a non-empty list
Cannot be missing,null, or empty
Each logical volume must be an object
Must be a key-value structure, not a string or number
Each logical volume must have alvname
Required field — must be present
lvnamemust be a non-empty string
Cannot benull, blank, or non-string
lvsizemust be present and be a non-empty string matching pattern like10G
Must follow size format: digits +M/G/T
lvfs_typemust be present and be a non-empty string
Must specify file system (e.g.,xfs)
lv_mountpointmust be present, be a non-empty string, and start with/
Must be an absolute path (e.g.,/apps)

✅ This reflects exactly what your validate_storage() function checks — no more, no less.

✅ Corrected: network_interfaces Configuration (Based Only on Your Validator)

Validations Enforced

network_interfacesmust be a non-empty list
Must be a list with at least one interface — notnull, object, or empty
Each interface must be an object
Cannot be a string, array, or invalid type
Each interface must havename,ip_address,subnet, andgateway
These fields are required
name,ip_address,subnet, andgatewaymust be non-empty strings
Cannot be missing,null, or blank
ip_addressmust be a valid IPv4 address
Must followxxx.xxx.xxx.xxxformat (e.g.,108.11.69.167)
gatewaymust be a valid IPv4 address
Same format rules asip_address
subnetmust be a valid IPv4 netmask
Must be a valid mask like255.255.255.0or255.255.255.224
vlan(if present) must be numeric
Must be a number (as string or int), no letters
nad(if present) must be a non-empty string
Cannot benullor blank
static_routes(if present) must be a non-empty list
Cannot benullor empty if used
Each item instatic_routesmust be a non-empty string and a valid IPv4 subnet in CIDR format
Must be like166.37.162.0/23
custom_routes(if present) must be a non-empty list
Cannot benullor empty if used
Each item incustom_routesmust be a non-empty string
Must be a valid route command
Any IP address or subnet incustom_routesmust be valid
Extracted and validated by the script (e.g.,108.11.69.0/24)

✅ This reflects exactly what your validate_network_interfaces() function checks — including deep validation of IPs in custom_routes.

📌 Summary

✅ All three validations are now strictly aligned with your Python code:

  • sudo_configurations → done ✅
  • storage → corrected above ✅
  • network_interfaces → corrected above ✅

No extra assumptions. No "best practice" rules mixed into validation.
Only what the system will reject if not followed.





✅ Corrected: Validations Enforced (Based Only on Your Validator)

sudo_configurationsmust be a non-empty list
You must define at least one sudo configuration block
Each item in the list must be an object (key-value pair)
Cannot be a string, null, or invalid JSON structure
Each configuration must have afile_name
Required to specify where the sudo rules will be applied
file_namemust be a non-empty string
Cannot be missing, null, or blank
Each configuration must have alinesfield
Required to define the sudo rules or aliases
linesmust be a non-empty list
Cannot be missing, null, or an empty array
Each item inlinesmust be a non-empty string
Individual sudo rules must be valid strings (but syntax is not validated here)

🔍 Why This Matters

Your validator:

  • ✅ Checks structure: list → objects → strings
  • ✅ Ensures required fields exist
  • ❌ Does not validate:
    • File path format (e.g., must be in /etc/sudoers.d/)
    • Sudoers syntax (e.g., ALL=(ALL) NOPASSWD: ALL)
    • Duplicate files
    • File extensions or permissions
    • Command correctness

Those validations may be done later (e.g., by visudo -c, deployment tools, or system hardening scripts), but not by this function.



🔧 sudo_configurations Configuration

Key: sudo_configurations

Description

This section defines custom sudo permissions for specific users or service accounts by creating individual files in /etc/sudoers.d/. These files grant controlled, passwordless access to system commands, enabling automation, monitoring, or administrative tasks without requiring full root login.

✅ Used to implement the principle of least privilege — granting only the necessary access to perform required tasks.

JSON Format

json
"sudo_configurations": [
{
"file_name": "/etc/sudoers.d/ccsuser02",
"lines": [
"ccsuser ALL=(ALL:ALL) NOPASSWD: ALL"
]
},
{
"file_name": "/etc/sudoers.d/svc-ansible",
"lines": [
"svc-ansible ALL=(ALL:ALL) NOPASSWD: ALL"
]
},
{
"file_name": "/etc/sudoers.d/svc-ansible-apps",
"lines": [
"svc-ansible-apps ALL=(apps) NOPASSWD: ALL"
]
},
{
"file_name": "/etc/sudoers.d/IVRAPPSCMDS",
"lines": [
"Cmnd_Alias IPIVRCMDS = /usr/sbin/tcpdump, /bin/netstat, /sbin/shutdown, /usr/sbin/service httpd, /usr/sbin/nft list ruleset, /usr/bin/lsof, /usr/bin/cat /etc/named.conf, /usr/bin/cat /etc/ssh/sshd_config, /usr/bin/cat /etc/snmp/snmpd.conf, /usr/bin/cat /etc/cron.d/sysstat",
"apps ALL=(ALL) NOPASSWD: IPIVRCMDS",
"smc ALL=(ALL) NOPASSWD: ALL"
]
}
]

Field Reference

file_name
String
Path to the sudoers file under/etc/sudoers.d/
"/etc/sudoers.d/svc-ansible"
lines
List[str]
List of valid sudoers entries or command aliases to be added to the file
"svc-ansible ALL=(ALL) NOPASSWD: ALL"

✅ Each file must contain valid sudoers syntax — tested with visudo -c

Validations Enforced

Must define at least one sudo configuration
sudo_configurationsmust be a non-empty list
Each entry must have afile_name
Required to specify where the rules are applied
file_namemust be a valid path under/etc/sudoers.d/
Ensures security and correct sudoers inclusion
file_namemust not contain spaces or special characters
Prevents parsing errors
Each entry must includelinesas a non-empty list
Rules must be provided
Each line must be a non-empty string
Blank or null lines are not allowed
All lines must follow validsudoerssyntax
Must use correct format (e.g.,user host=(user:group) COMMAND)
No duplicate file names allowed
Prevents conflicts or overwrites
Files must not end in.tmp,.bak, or similar
Only files without extensions are processed bysudo

What's Not Allowed

  • Omitting file_name or leaving it blank
  • Using invalid paths (e.g., /tmp/sudoers, /home/user/sudo)
  • Setting lines to null, "", or an empty array
  • Including syntax errors (e.g., missing ALL, incorrect command paths)
  • Using Defaults or global settings unless justified
  • Granting NOPASSWD: ALL without approval
  • Adding unescaped special characters (e.g., %, #, *)
  • Using wildcards in command paths (e.g., /usr/bin/*) unless explicitly allowed

Interpreted as

1. /etc/sudoers.d/ccsuser02

bash
ccsuser ALL=(ALL:ALL) NOPASSWD: ALL

Grants ccsuser full passwordless sudo access.

2. /etc/sudoers.d/svc-ansible

bash
svc-ansible ALL=(ALL:ALL) NOPASSWD: ALL

Allows Ansible automation user full passwordless access for remote management.

3. /etc/sudoers.d/svc-ansible-apps

bash
svc-ansible-apps ALL=(apps) NOPASSWD: ALL

Allows svc-ansible-apps to run commands as the apps user only.

4. /etc/sudoers.d/IVRAPPSCMDS

bash
Cmnd_Alias IPIVRCMDS = /usr/sbin/tcpdump, /bin/netstat, /sbin/shutdown, /usr/sbin/service httpd, /usr/sbin/nft list ruleset, /usr/bin/lsof, /usr/bin/cat /etc/named.conf, /usr/bin/cat /etc/ssh/sshd_config, /usr/bin/cat /etc/snmp/snmpd.conf, /usr/bin/cat /etc/cron.d/sysstat
apps ALL=(ALL) NOPASSWD: IPIVRCMDS
smc ALL=(ALL) NOPASSWD: ALL

Defines a command group IPIVRCMDS for troubleshooting and service control, granted to apps user.
Also gives full access to smc user.

🔧 How to Apply

Create each file using visudo -f or secure redirection:

bash
# Example: Create IVRAPPSCMDS file
sudo sh -c 'cat > /etc/sudoers.d/IVRAPPSCMDS << EOF
Cmnd_Alias IPIVRCMDS = /usr/sbin/tcpdump, /bin/netstat, /sbin/shutdown, /usr/sbin/service httpd, /usr/sbin/nft list ruleset, /usr/bin/lsof, /usr/bin/cat /etc/named.conf, /usr/bin/cat /etc/ssh/sshd_config, /usr/bin/cat /etc/snmp/snmpd.conf, /usr/bin/cat /etc/cron.d/sysstat
apps ALL=(ALL) NOPASSWD: IPIVRCMDS
smc ALL=(ALL) NOPASSWD: ALL
EOF'

# Set correct permissions
sudo chmod 440 /etc/sudoers.d/IVRAPPSCMDS

✅ Always test syntax:

bash
sudo visudo -c

⚠️ Important Notes

  • Files in /etc/sudoers.d/ must have permissions 440 and be owned by root:root
  • Never edit sudoers files with a regular text editor — always use visudo or validated automation
  • Avoid NOPASSWD: ALL unless absolutely necessary — prefer command-specific access
  • The Cmnd_Alias allows grouping commands for reuse and clarity
  • Changes take effect immediately — no restart required
  • Use sudo -l -U <username> to verify allowed commands

💡 Best Practice Tip

Use command aliases to limit access:

bash
Cmnd_Alias APP_CMDS = /usr/sbin/service httpd *, /bin/systemctl restart httpd

And avoid giving full shell access unless required.




🔧 network_interfaces Configuration

Key: network_interfaces

Description

This section defines the network interface configuration for the system, including IP addressing, VLAN, gateway, and advanced routing. It supports both standard interfaces and custom static routes for traffic isolation or policy-based routing (e.g., using routing tables like idn).

✅ Used during provisioning to configure multi-homed systems with dedicated paths for application, SIP, or management traffic.

JSON Format

json
"network_interfaces": [
{
"name": "ens224",
"ip_address": "108.11.69.167",
"subnet": "255.255.255.0",
"gateway": "108.11.69.1",
"vlan": "228",
"nad": "br0-idn-bridge-resident-jellyfish",
"static_routes": [
"166.40.83.128/25",
"166.34.101.0/24",
"166.35.160.64/26",
"166.40.199.160/29",
"166.40.224.176/29",
"162.47.144.32/28",
"166.38.90.0/25",
"152.184.64.0/22",
"159.98.168.0/22",
"162.47.142.128/25",
"166.37.162.0/23",
"166.37.218.0/23",
"166.37.130.0/23",
"166.33.186.0/24",
"63.91.193.198/32",
"63.91.193.196/32",
"100.5.76.25/32",
"100.5.76.27/32",
"100.5.76.26/32",
"159.98.86.240/32",
"159.98.86.241/32",
"159.98.86.242/32",
"159.98.86.243/32",
"159.98.86.244/32",
"159.98.86.245/32",
"146.1.185.0/25",
"146.1.148.128/25",
"166.34.123.5/32",
"166.34.123.4/32",
"63.29.112.0/21",
"63.25.128.0/21",
"138.83.16.0/21",
"137.188.136.243/32",
"63.27.208.147/32"
],
"custom_routes": [
"108.11.69.0/24 dev ens224 src 108.11.69.167 table idn",
"default via 108.11.69.1 dev ens224 table idn"
]
},
{
"name": "ens192",
"ip_address": "166.34.69.139",
"subnet": "255.255.255.224",
"gateway": "166.34.69.129",
"vlan": "413",
"nad": "br413-inner-bat"
}
]

Field Reference

name
String
Name of the network interface (as seen inip link)
"ens224"
ip_address
String
IPv4 address assigned to the interface
"108.11.69.167"
subnet
String
Subnet mask in dotted-decimal format (e.g.,255.255.255.0)
"255.255.255.0"
gateway
String
Default gateway for the interface
"108.11.69.1"
vlan
String
VLAN ID associated with the interface (must be numeric)
"228"
nad
String
Network Attachment Device or bridge name
"br0-idn-bridge-resident-jellyfish"
static_routes
List[str]
List of CIDR-formatted subnets to be added as static routes
"166.40.83.128/25"
custom_routes
List[str]
Advanced routing commands (e.g., withtable,src,dev)
"108.11.69.0/24 dev ens224 src ..."

Validations Enforced

Must define at least one network interface
network_interfacesmust be a non-empty list
Each interface must have aname,ip_address,subnet, andgateway
These are required fields for all interfaces
ip_addressandgatewaymust be valid IPv4 addresses
Format:xxx.xxx.xxx.xxx(e.g.,108.11.69.167)
subnetmust be a valid IPv4 netmask
Only values like255.255.255.0,255.255.255.224are allowed
vlanmust be a number (if provided)
Use digits only — no letters or special characters
nadmust be a valid string if specified
Cannot be blank ornull
static_routes(if used) must be a non-empty list of valid CIDR subnets
Each entry must be inx.x.x.x/yformat (e.g.,166.37.162.0/23)
custom_routes(if used) must be a non-empty list of valid routing commands
Must followip routesyntax; any IP or subnet in the command must be valid
All route entries must use valid IP addresses or subnets
Invalid IPs (e.g.,999.1.1.1) will cause failure

What's Not Allowed

  • Omitting required fields: name, ip_address, subnet, gateway
  • Using invalid IP formats: "108.11.69", "108.11.69.256"
  • Invalid subnet masks: "255.255.0", "255.255.254.0" (if not CIDR-aligned)
  • Non-numeric vlan values: "vlan228", "228a"
  • Blank or null nad if included
  • static_routes containing host IPs without /32 (e.g., "63.91.193.198")
  • custom_routes with syntax errors (e.g., missing via, invalid device)
  • Using unsupported routing keywords (e.g., metric, mtu) unless required

Interpreted as

Interface: ens224

  • IP: 108.11.69.167/24
  • Gateway: 108.11.69.1
  • VLAN: 228
  • Bridge: br0-idn-bridge-resident-jellyfish
  • Static Routes: 35+ subnets added via routing table (e.g., Verizon internal networks)
  • Custom Routes: Adds a policy-based routing table idn for local subnet and default route

Interface: ens192

  • IP: 166.34.69.139/27
  • Gateway: 166.34.69.129
  • VLAN: 413
  • Bridge: br413-inner-bat
  • No additional routes

✅ These interfaces support multi-path networking with dedicated routing for security and performance.

🔧 How to Apply

This configuration is used by automation to:

  • Generate interface config files (e.g., ifcfg-ens224)
  • Apply IP and VLAN settings
  • Add static and custom routes at boot
  • Bind to the correct NAD (bridge)

No manual setup required — ensure physical or virtual network is provisioned with correct VLANs.

⚠️ Important Notes

  • Always verify VLANs are allowed on the switch port
  • custom_routes often require ip route and ip rule support — ensure network-scripts or equivalent is used
  • Static routes are typically added via route-<interface> files or NetworkManager
  • Use ip route show table idn to verify custom routing table
  • Avoid overlapping subnets between interfaces
  • Double-check gateway reachability



🔧 storage Configuration

Key: storage

Description

This section defines the LVM (Logical Volume Manager) storage layout for the system. It includes one or more volume groups (VGs) and their associated logical volumes (LVs). Each volume group has a total size, and within it, logical volumes are created with specific sizes, file systems, and mount points.

✅ Used to define scalable, flexible storage for applications, logs, or databases.

JSON Format

json
"storage": [
{
"vgname": "vgapps",
"vgsize": "500G",
"logical_volumes": [
{
"lvname": "lvapps",
"lvsize": "70G",
"lvfs_type": "xfs",
"lv_mountpoint": "/apps"
},
{
"lvname": "lvlogging",
"lvsize": "300G",
"lvfs_type": "xfs",
"lv_mountpoint": "/logging"
}
]
}
]

Field Reference

vgname
String
Name of the volume group
"vgapps"
vgsize
String
Total size of the volume group (must include unit:M,G, orT)
"500G"
logical_volumes
List[Object]
List of logical volumes to be created inside this volume group
[{"lvname": "lvapps", ...}]
lvname
String
Name of the logical volume
"lvapps"
lvsize
String
Size of the logical volume (must include unit:M,G, orT)
"70G"
lvfs_type
String
File system type to be created (supported:xfs,ext4)
"xfs"
lv_mountpoint
String
Directory where the logical volume will be mounted (must be an absolute path starting with/)
"/apps"

Validations Enforced

storagemust be a list with at least one item
You must define at least one volume group
Each volume group must have avgname
A name is required to identify the volume group
vgnamemust be a valid string (not empty or blank)
Use names likevgapps,vgdata— no spaces or special characters
vgsizemust be provided and follow size format (e.g.,100G,500M)
Must include a number and unit (M,G,T); case-sensitive — use uppercase
Each volume group must includelogical_volumesas a non-empty list
You must define at least one logical volume per volume group
Each logical volume must have alvname
Required to identify the LV
lvsizemust be provided and follow size format (e.g.,20G,1T)
Same format rules asvgsize
lvfs_typemust be specified and be a supported file system
Onlyxfsandext4are allowed
lv_mountpointmust be a valid absolute path starting with/
Examples:/apps,/logging,/data/db— relative paths likeappsare not allowed

What's Not Allowed

  • Using storage as an object, string, or empty value — must be a list
  • Leaving vgname, lvname, or lvsize blank
  • Omitting logical_volumes or leaving it empty
  • Using invalid size formats: "500", "30g", "twentyG"
  • Using unsupported file systems: ntfs, zfs, btrfs
  • Mount points that are not full paths: "apps", "C:\logs", ~/data
  • Duplicate LV names within the same VG

Interpreted as

Volume Group: vgapps (500G)

lvapps
70G
xfs
/apps
lvlogging
300G
xfs
/logging

✅ This means:

  • A volume group named vgapps will be created with 500GB of space
  • Two logical volumes will be carved out: one for apps, one for logging
  • Both will be formatted with XFS and mounted at boot

🔧 How to Apply

This configuration is used by automation tools to:

  • Create physical volumes
  • Set up volume groups
  • Create and format logical volumes
  • Mount them to the specified directories

No manual action is needed — just provide the correct structure.

⚠️ Important Notes

  • Ensure the underlying disk or LUN has enough space for the defined vgsize
  • Sizes are case-sensitive: always use uppercase G, M, T (not g, m, t)
  • The mount points (e.g., /apps) must not already exist as files
  • Avoid using /, /boot, /var, or other system-reserved paths as mount points
  • This configuration does not handle physical device assignment — that’s done separately

Comments

Post a Comment

Popular posts from this blog

testing

09052025 T-1 { "volume_groups" : { "vgroot" : { "vgsize" : "304G" , "fs_type" : "xfs" } } , "logical_volumes" : { "root" : { "lvroot" : { "vgname" : "vgroot" , "lvname" : "lvroot" , "lvsize" : "12G" , "mountpoint" : "/" , "purpose" : "root filesystem" , "disk" : 1 , "partition" : 2 } } , "swap" : { "lvswap" : { "vgname" : "vgroot" , "lvname" : "lvswap" , "lvsize" : "4G" , "mountpoint" : "NA" , "purpose" : "swap" , "disk" : 1 , "partit...
Post a Comment
Read more

temp

 {   "_id": {     "$oid": "6841e4b0fd270b2ab92d7eaa"   },   // 📌 [Auto-generated]   // Description: Unique system identifier for internal use (MongoDB ObjectId).   // Type: ObjectId (string)   // Required: No (automatically handled)   "vast_id": "21452",   // 📌 [Required]   // Description: Your unique request ID or reference number.   // Type: string   // Format: Numeric string (e.g., "21452")   // Example: "21452"   "env": "dev",   // 📌 [Required]   // Description: The environment where the VM will be deployed.   // Type: string   // Allowed values: "dev", "qa", "uat", "prod"   // Example: "dev" for development, "prod" for production   "ver": "0.2",   // 📌 [Do Not Modify]   // Description: Template version. Used by automation to ensure compatibility.   // Type: string   // Format: Semantic versioning (e.g., "...
Post a Comment
Read more