# Default configuration file location
/opt/ripple/etc/rippled.cfg

Backup the original before modifying

sudo cp /opt/ripple/etc/rippled.cfg /opt/ripple/etc/rippled.cfg.original

Edit the configuration

sudo nano /opt/ripple/etc/rippled.cfg
```

rippled.cfg uses INI-style syntax:

# Comments start with hash
# Empty lines are ignored

[section_name]
# Settings for this section
key = value
another_key

# Some sections have no values (just enable by presence)
[feature_section]

# Some values are JSON objects
[json_section]
{ "key": "value", "number": 42 }

Important Syntax Rules:

✓ Section names in square brackets [section]
✓ Key-value pairs with = separator
✓ Some keys standalone (presence enables feature)
✓ Comments with #
✓ Whitespace is generally ignored
✓ Order of sections doesn't matter (usually)

✗ No quotes around string values (usually)
✗ No trailing commas in lists
✗ Case-sensitive section names

Some settings require restart, others can be changed dynamically:

• Port configurations

• Database paths

• validator_token

• Most [server] settings

• Log levels

• Some peer settings

• Amendment voting (after server restart once configured)

When in doubt, restart the service after changes:
sudo systemctl restart rippled

---

The [server] section defines which protocol handlers are active:

What each entry means:

• Enables HTTP RPC admin interface

• For running rippled commands

• Should be localhost only

• Enables peer-to-peer protocol

• Required for network participation

• Must be accessible from internet

• Enables WebSocket admin interface

• Alternative to RPC for admin commands

• Should be localhost only

• Public WebSocket for applications

• Usually NOT enabled on validators

• Would allow public to query your server

Each port referenced in [server] needs its own configuration section:

Admin RPC Port:

[port_rpc_admin_local]
port = 5005
ip = 127.0.0.1
admin = 127.0.0.1
protocol = http

# Explanation:
# port: TCP port number
# ip: Interface to bind (127.0.0.1 = localhost only)
# admin: IP addresses allowed to use admin commands
# protocol: http for RPC

Peer Protocol Port:

[port_peer]
port = 51235
ip = 0.0.0.0
protocol = peer

# Explanation:
# port: 51235 is the standard XRPL peer port
# ip: 0.0.0.0 = all interfaces (must be reachable)
# protocol: peer for P2P communication

Admin WebSocket Port:

[port_ws_admin_local]
port = 6006
ip = 127.0.0.1
admin = 127.0.0.1
protocol = ws

# Explanation:
# Similar to RPC but WebSocket protocol
# Useful for applications needing push notifications

For validators, the principle is: expose only what's necessary.

# SECURE configuration for validators:

[server]
port_rpc_admin_local
port_peer
port_ws_admin_local

[port_rpc_admin_local]
port = 5005
ip = 127.0.0.1        # Localhost only
admin = 127.0.0.1     # Admin from localhost only
protocol = http

[port_peer]
port = 51235
ip = 0.0.0.0          # Must be public for P2P
protocol = peer

[port_ws_admin_local]
port = 6006
ip = 127.0.0.1        # Localhost only
admin = 127.0.0.1     # Admin from localhost only
protocol = ws

# DO NOT add public WebSocket or RPC for validators
# Validators should not serve public API traffic

Controls the main ledger database:

Options explained:

• NuDB: Default, optimized for rippled (recommended)

• RocksDB: Alternative, more general-purpose

• For validators: Use NuDB

• Location of database files

• Use fast storage (NVMe)

• Ensure adequate space

• Number of ledgers to keep

• 512 = ~30 minutes of history

• Higher = more history, more disk

• Lower = less disk, faster recovery

• 0: Delete old ledgers immediately

• 1: Mark for deletion but delay

• For validators: 0 is fine

Disk Space Estimation:

Approximate disk usage:

online_delete=512:    ~30-50 GB
online_delete=2048:   ~100-150 GB
online_delete=32768:  ~500+ GB
full history:         Several TB

- online_delete=512 to 2048
- Balance between history and disk usage
- Full history not needed for validation

[database_path]
/var/lib/rippled/db

This is where auxiliary databases are stored

Usually same parent as node_db

Should be on fast storage

# Verify your database is on NVMe
df -h /var/lib/rippled/db/
lsblk

Check disk type

cat /sys/block/nvme0n1/queue/rotational

0 = SSD/NVMe, 1 = HDD

Test disk performance (quick check)

sudo hdparm -Tt /dev/nvme0n1

For production, consider:

- fio benchmarks for IOPS

- Sustained write performance testing

Controls memory allocation and performance characteristics:

[node_size]
large

# Options:
# tiny    - Minimal resources (not for production)
# small   - Limited resources
# medium  - Default (suitable for 32-64 GB RAM)
# large   - Production validators (64+ GB RAM)
# huge    - High-performance deployments

Memory impact by node_size:

Approximate memory usage:

tiny:    1-2 GB   (testing only)
small:   2-4 GB   (limited deployments)
medium:  8-16 GB  (default production)
large:   16-32 GB (recommended for validators)
huge:    32-64 GB (high-performance)

- 64 GB RAM server: Use 'large'
- 128 GB RAM server: Use 'large' or 'huge'
- Always leave headroom for OS and other processes

Controls how much ledger history to maintain:

[ledger_history]
full

# Options:
# full      - Maintain all available history
# none      - Minimum history (not recommended)
# <number>  - Specific number of ledgers

# For validators:
# 'full' means full online history (up to online_delete)
# This is different from archival "full history"

Controls transaction history fetching depth:

[fetch_depth]
full

# Options:
# full      - Fetch all available transaction history
# none      - Don't fetch historical transactions
# <number>  - Fetch specific number of ledgers

# For validators: 'full' is recommended
# Ensures complete validation context

Generally should NOT be modified:

# [validation_quorum]
# Commented out = use automatic calculation
# DO NOT set manually unless you understand implications

# Automatic behavior:
# - Uses 80% of trusted validators
# - Adjusts as network changes
# - This is correct for normal operation

Specifies persistent peer connections:

[ips_fixed]
# r.ripple.com 51235
# zaphod.alloy.ee 51235

# When to use:
# - Connecting to known reliable peers
# - Operating behind restrictive firewall
# - Building private network relationships

# For most validators:
# Leave commented - automatic peer discovery works well

Controls whether to advertise your IP:

[peer_private]
0

# Options:
# 0 - Allow your address to be shared with other peers
# 1 - Don't share your address (private mode)

# For validators:
# Usually 0 (allow sharing)
# Set to 1 if hiding behind proxy servers

NTP servers for time synchronization:

[sntp_servers]
time.google.com
time.cloudflare.com
time.nist.gov
pool.ntp.org

# rippled has internal NTP client
# These supplement OS-level NTP
# Multiple servers provide redundancy

Advanced peer connection settings:

Points to external validator list file:

[validators_file]
validators.txt

# Location: /opt/ripple/etc/validators.txt
# Contains UNL publisher information

Default validators.txt content:

[validator_list_sites]
https://vl.ripple.com 
https://vl.xrplf.org 

[validator_list_keys]
ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
EDA2C0EB8F44854984BFBBE5855D1598E9EC0B5F7D8A22F17BB633E0D34989C4A3

Explanation:

• URLs where UNL lists are published

• Your server downloads fresh lists from here

• Multiple sites provide redundancy

• Public keys of trusted list publishers

• Used to verify list signatures

• First key: Ripple's publisher key

• Second key: XRPLF's publisher key

For servers using multiple UNL publishers:

# In validators.txt (optional):
[validator_list_threshold]
1

# Number of lists a validator must appear on
# to be trusted
# Default calculated automatically
# Usually don't need to set manually

[debug_logfile]
/var/log/rippled/debug.log

Main log file location

Ensure directory exists with proper permissions

Logs can grow large - configure rotation

Initial commands run at startup:

[rpc_startup]
{ "command": "log_level", "severity": "warning" }

# Sets initial log level
# Options: trace, debug, info, warning, error, fatal
# 
# For production validators:
# warning - Normal operation (less verbose)
# info    - More details for troubleshooting
# debug   - Very verbose (fills disk quickly)

Configure logrotate for rippled logs:

Add:

[ssl_verify]
1

Options:

1 - Verify SSL certificates (recommended)

0 - Don't verify (insecure)

Always use 1 for production

0 only for testing with self-signed certs

For servers offering TLS-secured connections:

# [ssl_key]
# /path/to/server.key

# [ssl_cert]
# /path/to/server.crt

# Only needed if serving TLS connections
# Validators typically don't need this
# Peer protocol doesn't require SSL certificates

#===============================================================================
# rippled Configuration for XRPL Validator
# Server: validator.example.com
# Operator: Your Organization
# Last Updated: [DATE]
# Configuration Version: 1.0
#===============================================================================

#-------------------------------------------------------------------------------

Server Interfaces

Define which protocol handlers are active

#-------------------------------------------------------------------------------
[server]
port_rpc_admin_local # Admin RPC for local management
port_peer # Required for P2P network
port_ws_admin_local # WebSocket admin interface

#-------------------------------------------------------------------------------

Admin RPC Port Configuration

Localhost only for security

#-------------------------------------------------------------------------------
[port_rpc_admin_local]
port = 5005
ip = 127.0.0.1
admin = 127.0.0.1
protocol = http

#-------------------------------------------------------------------------------

Peer Protocol Port Configuration

Must be accessible from internet for network participation

#-------------------------------------------------------------------------------
[port_peer]
port = 51235
ip = 0.0.0.0
protocol = peer

#-------------------------------------------------------------------------------

Admin WebSocket Port Configuration

Localhost only for security

#-------------------------------------------------------------------------------
[port_ws_admin_local]
port = 6006
ip = 127.0.0.1
admin = 127.0.0.1
protocol = ws

#-------------------------------------------------------------------------------

Node Size / Performance Profile

Options: tiny, small, medium, large, huge

Server has 64 GB RAM - using 'large'

#-------------------------------------------------------------------------------
[node_size]
large

#-------------------------------------------------------------------------------

Database Configuration

NuDB database with 30-minute history retention

#-------------------------------------------------------------------------------
[node_db]
type=NuDB
path=/var/lib/rippled/db/nudb
online_delete=512
advisory_delete=0

#-------------------------------------------------------------------------------

Database Path

#-------------------------------------------------------------------------------
[database_path]
/var/lib/rippled/db

#-------------------------------------------------------------------------------

Ledger History

Maintain full online history (within online_delete limit)

#-------------------------------------------------------------------------------
[ledger_history]
full

#-------------------------------------------------------------------------------

Transaction Fetch Depth

#-------------------------------------------------------------------------------
[fetch_depth]
full

#-------------------------------------------------------------------------------

Logging Configuration

#-------------------------------------------------------------------------------
[debug_logfile]
/var/log/rippled/debug.log

[rpc_startup]
{ "command": "log_level", "severity": "warning" }

#-------------------------------------------------------------------------------

NTP Time Servers

Supplements OS-level NTP configuration

#-------------------------------------------------------------------------------
[sntp_servers]
time.google.com
time.cloudflare.com
time.nist.gov
pool.ntp.org

#-------------------------------------------------------------------------------

Validator List Configuration

References external validators.txt file

#-------------------------------------------------------------------------------
[validators_file]
validators.txt

#-------------------------------------------------------------------------------

SSL Certificate Verification

Always verify for production

#-------------------------------------------------------------------------------
[ssl_verify]
1

#-------------------------------------------------------------------------------

Peer Privacy Setting

0 = Allow address sharing (normal for validators)

#-------------------------------------------------------------------------------
[peer_private]
0

#===============================================================================

VALIDATOR CONFIGURATION

The following section will be added when enabling validation

(See Lesson 7-8)

#===============================================================================

[validator_token]

#===============================================================================

END OF CONFIGURATION

#===============================================================================
```

When modifying configuration, document changes:

# Test configuration without starting server
sudo /opt/ripple/bin/rippled --conf /opt/ripple/etc/rippled.cfg --fg &

Watch for errors in first few seconds

Press Ctrl+C to stop test

If configuration errors exist, they'll be displayed

# Restart rippled to apply changes
sudo systemctl restart rippled

Check status

sudo systemctl status rippled

Watch logs for startup

sudo journalctl -u rippled -f
```

# Check server info (confirms some settings)
/opt/ripple/bin/rippled server_info

Key items to verify:

- Server is running

- Correct peer port listening

- Expected state (full after sync)

Verify ports are listening correctly

ss -tlnp | grep rippled

Should show:

127.0.0.1:5005 (admin RPC - localhost)

0.0.0.0:51235 (peer port - all interfaces)

127.0.0.1:6006 (admin WS - localhost)

✅ Default configuration is production-viable - Package defaults work for most validators with minimal changes

✅ node_size significantly impacts resource usage - Choosing appropriate size for your hardware matters

✅ Admin ports must be localhost-only - Exposing admin interfaces is a serious security vulnerability

✅ NuDB is recommended for validators - Purpose-built for rippled workloads

⚠️ Optimal online_delete for your needs - Balance between history retention and disk usage depends on your use case

⚠️ Best node_size for your hardware - May require experimentation to find optimal setting

⚠️ Future configuration requirements - Amendments and updates may require configuration changes

📌 Exposing admin ports to network - Common misconfiguration that enables remote compromise

📌 Using debug log level in production - Fills disk rapidly, impacts performance

📌 Insufficient online_delete - Very low values may cause issues during network stress

📌 Missing configuration backup - Changes without backup make rollback difficult

Most validators can use near-default configuration with minimal changes. The key decisions are: node_size (match to your RAM), online_delete (balance disk vs. history), and port security (admin ports localhost-only). Everything else can usually remain at defaults.

The value of this lesson isn't memorizing every option—it's understanding the structure so you can troubleshoot issues and make informed decisions when changes are needed.

Assignment: Create and document a complete rippled.cfg customized for your deployment.

Requirements:

• Complete rippled.cfg with all sections

• Comments explaining each setting

• Your specific customizations documented

• Change log section for future modifications

• What you changed from default

• Why you made this choice

• Expected impact

• When you might change it

• Verify all admin ports bind to 127.0.0.1

• Document firewall rules allowing peer port

• Confirm no public API exposure

• Note any security considerations

• Screenshot of ss -tlnp | grep rippled showing correct port bindings

• Screenshot of server_info after restart

• Confirmation server reached "full" state with new config

• Annotated rippled.cfg file (actual file or markdown copy)

• Rationale document (PDF or Markdown)

• Screenshots as required

• Complete, working configuration (40%)

• Thoughtful rationale documentation (30%)

• Security verification (15%)

• Working server evidence (15%)

Time investment: 2-3 hours
Value: A documented configuration you understand and can maintain

1. Port Security (Tests Security Understanding):

Which of the following is a CRITICAL security requirement for validator port configuration?

A) Peer port should bind to 127.0.0.1 for security
B) Admin RPC port should bind to 0.0.0.0 for remote management
C) Admin ports should bind to 127.0.0.1, peer port to 0.0.0.0
D) All ports should use SSL encryption

Correct Answer: C
Explanation: Admin ports (RPC, WebSocket) allow commands that could compromise the server—they must only be accessible locally (127.0.0.1). The peer port (51235) must be accessible from the internet (0.0.0.0) for P2P network participation. This configuration exposes only what's necessary while protecting administrative functions.

2. Node Size Selection (Tests Performance Understanding):

A server has 64 GB RAM. Which node_size setting is most appropriate?

A) medium (to leave RAM for other processes)
B) large (matches the available RAM well)
C) huge (maximize performance)
D) small (minimize resource usage)

Correct Answer: B
Explanation: "large" node_size is designed for servers with 64+ GB RAM. It provides good performance while leaving headroom for the OS and monitoring. "medium" would underutilize available resources, while "huge" might consume too much RAM and cause swapping. The goal is matching node_size to available RAM for optimal performance.

3. Database Configuration (Tests Technical Knowledge):

What does the online_delete setting control?

A) The number of validators in your UNL
B) How many ledgers of history to retain before deleting old data
C) The number of database connections
D) How often to compact the database

Correct Answer: B
Explanation: online_delete specifies how many ledgers to retain. Once the ledger count exceeds this, old ledgers are deleted to manage disk space. 512 ledgers ≈ 30 minutes of history. Higher values retain more history but use more disk space. For validators, moderate values (512-2048) provide sufficient history for validation while managing storage.

4. Validator List (Tests Operational Knowledge):

What information is contained in validators.txt?

A) Your validator's private keys
B) URLs of UNL publishers and their public keys for verification
C) IP addresses of validators to connect to
D) Configuration for the validator token

Correct Answer: B
Explanation: validators.txt contains [validator_list_sites] (URLs where UNL lists are published) and [validator_list_keys] (public keys to verify those lists). This tells your server where to get trusted validator lists and how to verify their authenticity. It does NOT contain your validator credentials—those go in rippled.cfg.

5. Configuration Management (Tests Best Practices):

Why should configuration files include detailed comments?

A) rippled requires comments to parse correctly
B) Comments improve server performance
C) Documentation aids troubleshooting and explains decisions for future reference
D) Comments are required for validator UNL inclusion

Correct Answer: C
Explanation: Comments serve as documentation explaining why specific settings were chosen. When troubleshooting issues or planning upgrades, understanding the rationale behind configuration choices is invaluable. A well-commented configuration file also helps if someone else needs to manage the server or if you return to it after months of stable operation.

For Next Lesson:
With a fully configured and documented rippled server, Lesson 6 will verify synchronization quality and prepare you for the stable stock server operation that precedes validator enablement. We'll establish baseline metrics and ensure your server is ready for the responsibilities of validation.

End of Lesson 5

Total words: ~5,500
Estimated completion time: 65 minutes reading + 2-3 hours for configuration work