Before installation, verify your system meets requirements:

# Connect to your server
ssh validator@YOUR_SERVER_IP

# Verify Ubuntu version (22.04 or 24.04)
lsb_release -a
# Expected: Ubuntu 22.04.x LTS or Ubuntu 24.04.x LTS

# Verify architecture
uname -m
# Expected: x86_64

# Verify sufficient disk space (need ~50 GB minimum)
df -h /
# Verify root partition has adequate space

# Verify memory
free -h
# Should show 32+ GB (64+ GB recommended)

# Update package lists
sudo apt update

# Ensure prerequisites are installed
sudo apt install -y apt-transport-https gnupg wget

Ripple signs their packages with a GPG key. Installing this key allows apt to verify package authenticity.

# Create keyring directory if it doesn't exist
sudo install -m 0755 -d /etc/apt/keyrings

Download and install Ripple's GPG key

wget -qO- https://repos.ripple.com/repos/api/gpg/key/public" target="_blank" rel="noopener noreferrer" class="text-cyan-400 hover:text-cyan-300 underline hover:no-underline transition-colors inline-flex items-center gap-1">https://repos.ripple.com/repos/api/gpg/key/public">https://repos.ripple.com/repos/api/gpg/key/public |
sudo gpg --dearmor -o /etc/apt/keyrings/ripple.gpg

Verify the key was installed

ls -la /etc/apt/keyrings/ripple.gpg

Should show the file exists

View key details

gpg --show-keys /etc/apt/keyrings/ripple.gpg
```

Expected key details:

Security Note: The key fingerprint (C0010EC205B35A3310DC90DE395F97FFCCAFD9A2) should match what's published on xrpl.org. If it doesn't match, stop and investigate before proceeding.

Add Ripple's repository to your apt sources:

# For Ubuntu 24.04 (Noble Numbat):
echo "deb [signed-by=/etc/apt/keyrings/ripple.gpg] https://repos.ripple.com/repos/rippled-deb  noble stable" | \
    sudo tee /etc/apt/sources.list.d/ripple.list

# For Ubuntu 22.04 (Jammy Jellyfish):
# echo "deb [signed-by=/etc/apt/keyrings/ripple.gpg] https://repos.ripple.com/repos/rippled-deb  jammy stable" | \
#     sudo tee /etc/apt/sources.list.d/ripple.list

# Verify the file was created correctly
cat /etc/apt/sources.list.d/ripple.list

Repository Options:

• stable: Release versions (recommended for validators)
• unstable: Development builds (not for production)
• nightly: Latest builds (not for production)

Always use 'stable' for validator operation.
```

# Update apt to include new repository
sudo apt update

Verify rippled package is available

apt-cache policy rippled

Should show available versions, e.g.:

rippled:

Installed: (none)

Candidate: 2.x.x-1

Version table:

2.x.x-1 500

500 https://repos.ripple.com/repos/rippled-deb" target="_blank" rel="noopener noreferrer" class="text-cyan-400 hover:text-cyan-300 underline hover:no-underline transition-colors inline-flex items-center gap-1">https://repos.ripple.com/repos/rippled-deb">https://repos.ripple.com/repos/rippled-deb noble/stable...

# Install rippled
sudo apt install -y rippled

This installs:

- rippled: The main server binary

- validator-keys: Tool for managing validator keys

- Default configuration files

- Systemd service configuration

Installation creates these important paths:

File Locations:

/opt/ripple/bin/rippled          - Main server binary
/opt/ripple/bin/validator-keys   - Key management tool
/opt/ripple/etc/rippled.cfg      - Main configuration file
/opt/ripple/etc/validators.txt   - Validator list configuration
/var/lib/rippled/                - Data directory (database, etc.)
/var/log/rippled/                - Log files

Service Configuration:
/lib/systemd/system/rippled.service - Systemd service file

# Check rippled version
/opt/ripple/bin/rippled --version

Expected output (version will vary):

rippled version 2.x.x

Check validator-keys is available

/opt/ripple/bin/validator-keys --version

Check that service file exists

systemctl cat rippled
```

The package installs a default configuration that connects to the production network:

Key sections in default configuration:

[server]
port_rpc_admin_local
port_peer
port_ws_admin_local

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

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

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

[node_size]
medium

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

[database_path]
/var/lib/rippled/db

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

[sntp_servers]
time.windows.com
time.apple.com
time.nist.gov
pool.ntp.org

[validators_file]
validators.txt

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

[ssl_verify]
1

Understanding key settings:

• Port 51235 binds to all interfaces (0.0.0.0)

• This is required for P2P communication

• Your firewall allows this port

• Port 5005 binds to localhost only (127.0.0.1)

• Admin commands only accessible locally

• Secured by not exposing to network

• Options: tiny, small, medium, large, huge

• medium is default

• For production validator with 64GB RAM, consider large

• NuDB is the default database backend

• online_delete=512 keeps ~512 ledgers of history

• Adjustable based on your needs

# Start the rippled service
sudo systemctl start rippled

Check if it started successfully

sudo systemctl status rippled

Expected output:

● rippled.service - rippled

Loaded: loaded (/lib/systemd/system/rippled.service; enabled; vendor preset: enabled)

Active: active (running) since ...

Main PID: XXXXX (rippled)

...

Configure rippled to start automatically on boot:

# Enable auto-start
sudo systemctl enable rippled

# Verify it's enabled
systemctl is-enabled rippled
# Expected: enabled

# Start service
sudo systemctl start rippled

Stop service

sudo systemctl stop rippled

Restart service

sudo systemctl restart rippled

Reload configuration (if supported)

sudo systemctl reload rippled

Check status

sudo systemctl status rippled

View recent logs

sudo journalctl -u rippled -n 50

Follow logs in real-time

sudo journalctl -u rippled -f
```

rippled provides a command-line interface for interaction:

# Check server status
/opt/ripple/bin/rippled server_info

# This command is verbose—key information to find:
# - "server_state": Current synchronization state
# - "complete_ledgers": Range of ledgers you have
# - "peers": Number of connected peers
# - "validated_ledger": Latest validated ledger (if synced)

# Shorter server state query
/opt/ripple/bin/rippled server_state

# Count connected peers
/opt/ripple/bin/rippled peers | grep -c "address"

After starting, rippled progresses through several states:

Server State Progression:

1. connected

1. syncing

1. tracking

1. full

1. proposing (validator only)

For a stock server (no validator token):
Goal state is 'full'

For a validator:
Goal state is 'proposing'

# Watch server state changes
watch -n 10 '/opt/ripple/bin/rippled server_info 2>/dev/null | grep -E "(server_state|complete_ledgers|peers)"'

Example output during sync:

"server_state" : "syncing",

"complete_ledgers" : "75000000-75000500",

"peers" : 10

After synchronization:

"server_state" : "full",

"complete_ledgers" : "75000000-75001000",

"peers" : 21

Synchronization Time Factors:

- Time to "full" state: 15-60 minutes typical
- Depends on network speed and peer availability
- Will have limited ledger history initially

- Time to sync: Variable
- May take longer if behind network
- Builds on existing ledger history

- Network bandwidth
- Storage speed (NVMe essential)
- Peer connectivity
- How far behind current ledger

Once server_state shows "full", verify synchronization quality:

# Get full server info
/opt/ripple/bin/rippled server_info

Key metrics to check:

1. Server state

"server_state" : "full"

(or "proposing" if validator token configured)

2. Peer count

Should be 10+ peers for good connectivity

3. Complete ledgers

Range should be recent and continuous

4. Validated ledger

Should show recent ledger info with seq number

Compare your ledger to network

Visit: https://livenet.xrpl.org" target="_blank" rel="noopener noreferrer" class="text-cyan-400 hover:text-cyan-300 underline hover:no-underline transition-colors inline-flex items-center gap-1">https://livenet.xrpl.org">https://livenet.xrpl.org

Your validated_ledger.seq should be close to network

---

Service Won't Start:

# Check for configuration errors
sudo /opt/ripple/bin/rippled --conf /opt/ripple/etc/rippled.cfg --fg

# If there's a config error, it will be displayed
# Fix the error and try again

# Check system logs
sudo journalctl -u rippled -n 100 --no-pager

No Peers Connected:

# Verify firewall allows port 51235
sudo ufw status | grep 51235

# Check if port is listening
ss -tlnp | grep 51235

# If not listening, check logs for bind errors
sudo grep -i "error\|failed" /var/log/rippled/debug.log

Stuck in "syncing" State:

# Check peer count
/opt/ripple/bin/rippled peers | grep -c "address"

# If very few peers, may be connectivity issue
# Check that peers can reach your port 51235

# From another machine (if possible):
# telnet YOUR_SERVER_IP 51235
# Should connect (then disconnect with Ctrl+])

High Disk Usage:

# Check disk usage
df -h /var/lib/rippled/

# If filling up, verify online_delete setting in config
sudo grep online_delete /opt/ripple/etc/rippled.cfg

# Default 512 should limit history
# Lower numbers = less disk usage but less history

# View recent log entries
sudo tail -100 /var/log/rippled/debug.log

Search for errors

sudo grep -i "error" /var/log/rippled/debug.log | tail -20

Search for warnings

sudo grep -i "warning" /var/log/rippled/debug.log | tail -20

Watch logs in real-time

sudo tail -f /var/log/rippled/debug.log
```

# Check rippled resource usage
ps aux | grep rippled

Monitor in real-time

top -p $(pgrep rippled)

Expected resource usage during sync:

- CPU: 20-80% (varies during sync)

- Memory: 10-40 GB (depends on node_size)

After sync, normal operation:

- CPU: 5-30% typically

- Memory: Stable at allocated level

# 1. Service running
sudo systemctl status rippled | grep Active
# Expected: active (running)

2. Enabled at boot

systemctl is-enabled rippled

Expected: enabled

3. Server responding to commands

/opt/ripple/bin/rippled server_state

Expected: Returns state information

4. Peers connected

/opt/ripple/bin/rippled peers | grep -c "address"

Expected: 5+ peers

5. Configuration file readable

sudo cat /opt/ripple/etc/rippled.cfg | head -5

Expected: Shows config content

6. Log file being written

ls -la /var/log/rippled/debug.log

Expected: File exists with recent timestamp

7. Database directory populated

ls -la /var/lib/rippled/db/

Expected: NuDB or RocksDB files present

Create a simple monitoring script:

Add this content:

#!/bin/bash
# Simple rippled status check

echo "=== rippled Status Check ==="
echo "Date: $(date)"
echo ""

# Service status
echo "Service Status:"
systemctl is-active rippled

# Server state
echo ""
echo "Server State:"
/opt/ripple/bin/rippled server_info 2>/dev/null | grep -E "(server_state|complete_ledgers|validated_ledger)"

# Peer count
echo ""
echo "Peer Count:"
/opt/ripple/bin/rippled peers 2>/dev/null | grep -c "address"

# Resource usage
echo ""
echo "Resource Usage:"
ps aux | grep [r]ippled | awk '{print "CPU: "$3"%, MEM: "$4"%, RSS: "$6"KB"}'

# Disk usage
echo ""
echo "Database Disk Usage:"
du -sh /var/lib/rippled/db/ 2>/dev/null

echo ""
echo "=== End Status Check ==="

# Make executable
sudo chmod +x /opt/ripple/bin/rippled-status.sh

# Test it
sudo /opt/ripple/bin/rippled-status.sh

Before proceeding to validator configuration, let the server run for 24 hours:

24-Hour Stability Checklist:

□ Server reaches "full" state
□ Server maintains "full" state (doesn't drop back)
□ Peer count remains stable (10+)
□ No service restarts required
□ Memory usage stable (not growing unbounded)
□ Disk usage as expected
□ No error storms in logs
□ CPU usage reasonable (< 50% average)

✅ Package manager installation is production-ready - Ripple maintains official Ubuntu packages used by major validators worldwide

✅ GPG verification ensures package authenticity - The signing key can be verified against published fingerprints

✅ Default configuration connects to mainnet - No additional configuration needed to join the network as a stock server

✅ Synchronization typically completes in under an hour - Fresh servers reach "full" state quickly with good connectivity

⚠️ Optimal node_size setting for your hardware - Default "medium" works, but "large" may be better with 64+ GB RAM; requires monitoring to optimize

⚠️ Ideal online_delete setting - Trade-off between disk usage and ledger history retention; depends on your use case

⚠️ Long-term stability - 24-hour check is minimum; real validation of stability requires longer observation

📌 Skipping GPG key verification - Installing from unverified sources could install compromised software

📌 Using non-stable repository branches - Unstable and nightly branches are for development, not production validators

📌 Ignoring synchronization issues - A server stuck in "syncing" may have connectivity problems that will affect validation

📌 Proceeding before 24-hour stability confirmation - Enabling validation on an unstable server damages reputation

Package manager installation is straightforward and the recommended approach for production validators. The process takes about 30 minutes of active work, then 15-60 minutes of passive waiting for synchronization. The key is not rushing—verify the GPG key, confirm synchronization completes, and allow 24 hours of stability testing before proceeding to validator configuration.

At this point, you have a running rippled server that follows the network but doesn't participate in consensus. It's a "stock server" or "tracking server." The next lessons will transform it into an active validator.

Assignment: Complete rippled installation and document a stable, synchronized server.

Requirements:

• Screenshot of apt-cache policy rippled showing installed version

• Screenshot of /opt/ripple/bin/rippled --version output

• Document the repository and branch configured

• Screenshot of sudo systemctl status rippled showing active (running)

• Screenshot of systemctl is-enabled rippled showing enabled

• Document any configuration changes made (or note that defaults are used)

• Screenshot of server_info showing "full" state (or "tracking" if still syncing—note expected time to full)

• Document peer count and complete_ledgers range

• Compare your validated_ledger.seq to livenet.xrpl.org current ledger

• Run the monitoring script at start, 12 hours, and 24 hours

• Document any issues observed

• Confirm server maintained "full" state throughout

• Note memory usage trend (stable or growing?)

• PDF or Markdown document with screenshots

• Include timestamps showing 24-hour observation period

• Note any issues and resolutions

• Successful installation with version verification (25%)

• Proper service configuration (25%)

• Verified synchronization (25%)

• Documented stability over 24 hours (25%)

Time investment: 1 hour active work + 24 hours observation
Value: A verified, stable rippled installation ready for validator configuration

1. Installation Security (Tests Security Awareness):

Why is it important to verify the GPG key fingerprint when adding Ripple's repository?

A) To ensure faster download speeds
B) To verify you're installing authentic packages, not compromised software from an attacker
C) To get access to additional features
D) GPG verification is optional and provides no security benefit

Correct Answer: B
Explanation: GPG signing ensures package authenticity and integrity. An attacker who compromised the download server could distribute malicious packages. By verifying the GPG key fingerprint matches what Ripple publishes, you confirm packages are genuinely from Ripple and haven't been tampered with. This is critical for software that will participate in financial infrastructure.

2. Server States (Tests Technical Understanding):

A freshly installed rippled server shows server_state: syncing and peers: 3. What does this indicate?

A) The server is fully operational and ready for validation
B) The server is connected to the network and downloading ledger history; it needs more time to reach "full" state
C) The server has failed to synchronize and needs troubleshooting
D) The configuration is incorrect

Correct Answer: B
Explanation: "syncing" with 3 peers indicates normal operation for a new server. It's connected to the network and catching up. More peers would be better (target 10+), but synchronization should proceed. The server will progress through tracking to full state, typically within an hour. Only if it remains stuck in syncing for extended periods is troubleshooting needed.

3. Configuration (Tests Practical Knowledge):

The default rippled configuration binds the admin RPC port to 127.0.0.1. What is the security purpose of this?

A) It makes the admin interface faster
B) It prevents external access to administrative commands, requiring local or SSH-tunneled access
C) It's required by the protocol
D) It reduces memory usage

Correct Answer: B
Explanation: Binding to 127.0.0.1 (localhost) means only processes on the same server can access that port. External attackers cannot directly reach the admin RPC, even if they know the port. To administer the server, you must either be logged in locally or use an SSH tunnel. This is a defense-in-depth measure that limits attack surface.

4. Synchronization (Tests Operational Knowledge):

Why should you wait 24 hours after initial synchronization before proceeding to validator configuration?

A) rippled requires a 24-hour warmup period
B) To verify the server maintains stable operation without crashes, memory leaks, or synchronization drops
C) The network requires new servers to wait 24 hours
D) To accumulate more ledger history

Correct Answer: B
Explanation: The 24-hour observation period is about verifying stability. A server might reach "full" state but then crash, leak memory, or drop back to "syncing." Discovering these issues before enabling validation prevents reputation damage. A validator that goes up and down repeatedly will develop poor agreement statistics and may never be trusted.

5. Troubleshooting (Tests Diagnostic Skills):

A server shows server_state: full but peers: 2. What should you investigate?

A) Nothing—the server is synchronized
B) Low peer count may indicate connectivity issues (firewall, NAT) that could affect validator performance; investigate and resolve
C) Restart the service to get more peers
D) The peer count is intentionally limited for security

Correct Answer: B
Explanation: While the server is synchronized (full state), only 2 peers is concerning. Validators should have good connectivity (10+ peers) for reliable message propagation. Low peer count could indicate firewall issues (port 51235 not reachable), NAT problems, or network configuration issues. Investigating this before enabling validation ensures your validation messages will propagate effectively.

For Next Lesson:
With a stable, synchronized server confirmed, Lesson 5 will dive deep into the rippled configuration file. We'll examine each section, understand options for customization, and prepare the configuration for validator operation.

End of Lesson 4

Total words: ~5,200
Estimated completion time: 55 minutes reading + 1 hour active work + 24 hours observation