4.7 KiB
Repository Genericization - Summary
What Was Changed
Your rsyslog repository has been made generic with environment-based configuration. All hardcoded paths and server-specific settings can now be configured via a configuration file.
Files Created/Modified
New Files
-
config.env - Template configuration file
- Contains all configurable variables with defaults
- Checked into Git (safe to share)
- Use as reference for what can be configured
-
config.local.env - Environment-specific overrides (create this locally)
- Copy from config.env and customize for your server
- Gitignored - won't be committed
- Use for sensitive/server-specific settings
-
validate-syntax.sh - Comprehensive validation script
- Validates shell script syntax
- Checks configuration file format
- Validates Ansible playbooks
- Validates rsyslog config syntax
- Exit code 0 = all pass, exit code 1 = failures
-
CONFIGURATION.md - Setup and usage documentation
- Quick start guide
- Configuration options explained
- Troubleshooting tips
-
.gitignore - Prevents accidental commits
- Ignores config.local.env and *.local.env
- Ignores SSH keys and credentials
- Standard patterns for Python, editors, logs
Modified Files
-
apply.sh - Now loads configuration
- Reads config.env or config.local.env
- Uses variables for paths instead of hardcoded values
- More verbose output showing what paths it's using
-
drift-check.sh - Now loads configuration
- Reads config.env or config.local.env
- Uses variables for server and Git paths
- More transparent about what it's comparing
How to Use
Step 1: Create local configuration
cp config.env config.local.env
Step 2: Edit for your server
nano config.local.env
Update these key variables:
SERVER_HOSTNAME- Your server IP/hostnameRSYSLOG_MAIN_CONFIG- Server path to main config (e.g.,/etc/rsyslog.conf)RSYSLOG_CONFIG_DIR- Server path to config dir (e.g.,/etc/rsyslog.d)PUSHGATEWAY_URL- Your Prometheus pushgateway (if using metrics)
Step 3: Validate everything
./validate-syntax.sh
All checks should pass ✓
Step 4: Use your scripts
./apply.sh # Apply config to server
./drift-check.sh # Check if server matches Git
Configuration Options
Server Paths (Customize per environment)
RSYSLOG_MAIN_CONFIG- Where rsyslog.conf lives on serverRSYSLOG_CONFIG_DIR- Where modular configs live on server
Git Paths (Usually same for all)
GIT_RSYSLOG_MAIN_CONFIG- Path to config in Git (default: files/rsyslog.conf)GIT_RSYSLOG_CONFIG_DIR- Path to configs in Git (default: files/rsyslog.d)
Ansible
ANSIBLE_INVENTORY- Path to hosts.ymlANSIBLE_PLAYBOOK_DIR- Path to playbooks dirANSIBLE_CONFIG- Path to ansible.cfg
Other
REPO_NAME- Label for your repoPUSHGATEWAY_URL- For Prometheus metricsLOG_LEVEL- debug/info/warn/error
Adapting for Other Services
To use this for a different service (nginx, apache, etc.):
-
Update file paths in config.env:
GIT_MAIN_CONFIG="nginx.conf" GIT_CONFIG_DIR="nginx.d" MAIN_CONFIG="/etc/nginx/nginx.conf" CONFIG_DIR="/etc/nginx/conf.d" -
Update the validation/restart command in apply.sh
-
That's it! The scripts work with any service.
Configuration Loading Order
Scripts load config in this order:
- Check for
config.local.env(local overrides) - Fall back to
config.env(defaults) - Use environment variables if set
This allows you to:
- Keep generic defaults in Git (config.env)
- Override locally for each server (config.local.env)
- Keep secrets out of version control
Validation
Run this anytime you make changes:
./validate-syntax.sh
Checks for: ✓ Bash script syntax errors ✓ Required config variables ✓ Configuration file format ✓ Ansible playbook syntax ✓ rsyslog config syntax
Next Steps
- ✓ Repository is now generic
- → Create config.local.env for each server
- → Run validate-syntax.sh before deploying
- → Check Ansible playbooks work for your server list
- → Update .woodpecker.yml if needed for CI/CD secrets
Files Not Changed
These remain as-is for now (as requested):
- ansible/playbooks/* - You'll review per server
- ansible/inventory/hosts.yml - You'll update with your servers
- .woodpecker.yml - Kept as-is, already parameterized
Key Improvements
✓ Generic - Works on any server with configuration ✓ Validated - Built-in syntax checking ✓ Safe - Local overrides never committed to Git ✓ Portable - Easy to adapt for different services ✓ Documented - Clear configuration options ✓ Maintainable - Centralized config, no hardcoding