refactor: Remove librenms, add ansible/salt clients
- Remove all librenms references from initializers and configuration - Keep tailscale as requested (remove netbird plans) - Add ansible-core (already present) and salt-minion packages - Create salt-client initializer for minion configuration - Update roles to replace librenms-agent with salt-client - Simplify oam initializer to only handle up2date script - Update README to reflect new architecture and tools Prepares infrastructure for migration to Salt configuration management while maintaining tailscale for VPN connectivity. 💘 Generated with Crush Assisted-by: GLM-4.6 via Crush <crush@charm.land>
This commit is contained in:
142
README.md
142
README.md
@@ -2,25 +2,40 @@
|
||||
|
||||
This repository contains the KNEL server configuration management system implemented with the FetchApply framework.
|
||||
|
||||
**NOTE:** This is a one-time provisioning system. For ongoing configuration management, this will be replaced by:
|
||||
- Ansible playbooks for configuration management
|
||||
- Salt for system orchestration
|
||||
|
||||
## Overview
|
||||
|
||||
The KNEL FetchApply system provides automated server provisioning, configuration, and security hardening for Linux servers. It uses the FetchApply framework to apply configurations based on server classes and hostnames.
|
||||
The KNEL FetchApply system provides automated server provisioning for Linux servers. It uses the FetchApply framework to apply initial configurations and then serves as a foundation for migrating to Ansible/Salt-based management.
|
||||
|
||||
## Repository Structure
|
||||
|
||||
```
|
||||
.
|
||||
├── classes/ # Server classifications
|
||||
│ ├── physical/ # Physical Dell servers
|
||||
│ ├── virtual/ # Virtual machines
|
||||
│ ├── librenms/ # LibreNMS monitoring servers
|
||||
│ ├── database/ # Database servers
|
||||
│ ├── webserver/ # Web servers
|
||||
│ └── dev-workstation/ # Development workstations
|
||||
├── initializers/ # One-time setup scripts
|
||||
├── modules/ # Recurring maintenance modules
|
||||
├── roles/ # Groups of related modules
|
||||
└── variables # Global configuration variables
|
||||
├── classes/
|
||||
│ └── server/ # Single class for all servers
|
||||
│ ├── initializers # List of initializers to run
|
||||
│ └── roles # List of roles to apply
|
||||
├── initializers/ # One-time setup scripts
|
||||
│ ├── system-setup/ # System detection and basic setup
|
||||
│ ├── packages/ # Package installation with conditional logic
|
||||
│ ├── oam/ # Operations and Maintenance setup
|
||||
│ ├── system-config/ # System configuration files
|
||||
│ ├── ssh-hardening/ # SSH security hardening
|
||||
│ ├── ssh-keys/ # SSH authorized key deployment
|
||||
│ ├── postfix/ # Email configuration
|
||||
│ ├── 2fa/ # Two-factor authentication setup
|
||||
│ ├── wazuh/ # Wazuh security monitoring
|
||||
│ ├── security-hardening/ # SCAP/STIG compliance
|
||||
│ ├── salt-client/ # Salt minion configuration
|
||||
│ └── user-configuration/ # User shell settings
|
||||
├── roles/ # Groups of related initializers
|
||||
│ ├── security # Security-related initializers
|
||||
│ └── monitoring # Monitoring-related initializers
|
||||
├── modules/ # Placeholder for future Ansible modules
|
||||
└── variables # Global configuration variables
|
||||
```
|
||||
|
||||
## Installation
|
||||
@@ -44,9 +59,9 @@ sudo bash /tmp/install --operations-repository-url=https://git.knownelement.com/
|
||||
|
||||
Once installed, FetchApply will automatically:
|
||||
|
||||
1. Detect the server type based on hostname and hardware characteristics
|
||||
2. Apply the appropriate configuration modules and initializers
|
||||
3. Maintain the system configuration with regular runs
|
||||
1. Detect system characteristics (physical/virtual, OS, special hosts)
|
||||
2. Run initializers in sequence to provision the server
|
||||
3. Apply security hardening and configuration management setup
|
||||
|
||||
You can also run FetchApply manually:
|
||||
|
||||
@@ -54,80 +69,61 @@ You can also run FetchApply manually:
|
||||
sudo fa
|
||||
```
|
||||
|
||||
## Server Classes
|
||||
## System Detection
|
||||
|
||||
Servers are automatically classified based on their characteristics:
|
||||
The system automatically detects:
|
||||
|
||||
### Physical Servers (`physical`)
|
||||
- **Physical vs Virtual** - Using dmidecode and virt-what
|
||||
- **Operating System** - Ubuntu vs Kali detection
|
||||
- **Special Hosts** - NTP servers, development workstations
|
||||
- **User Accounts** - Detects localuser and subodev users
|
||||
- **Raspberry Pi** - Hardware detection for RPi-specific configs
|
||||
|
||||
**Criteria:** Dell physical hardware detected via dmidecode
|
||||
## Initializers
|
||||
|
||||
**Applied Modules:**
|
||||
- System setup and package installation
|
||||
- SSH hardening
|
||||
- Security hardening
|
||||
- OAM monitoring
|
||||
### Core Setup
|
||||
- **system-setup** - System detection and variable setup
|
||||
- **packages** - Package installation with conditional logic (includes ansible-core, salt-minion, tailscale)
|
||||
- **user-configuration** - Shell settings and user preferences
|
||||
|
||||
### Virtual Machines (`virtual`)
|
||||
### Configuration
|
||||
- **system-config** - Deploy system configuration files (SNMP, NTP, Cockpit, etc.)
|
||||
- **ssh-hardening** - SSH security hardening
|
||||
- **ssh-keys** - Deploy SSH authorized keys
|
||||
- **postfix** - Configure email delivery
|
||||
- **salt-client** - Configure Salt minion for configuration management
|
||||
|
||||
**Criteria:** KVM/Hyper-V guests detected via virt-what
|
||||
### Security
|
||||
- **2fa** - Set up Google Authenticator for 2FA
|
||||
- **wazuh** - Deploy Wazuh security monitoring agent
|
||||
- **security-hardening** - SCAP/STIG compliance hardening
|
||||
|
||||
**Applied Modules:**
|
||||
- System setup and package installation
|
||||
- SSH hardening
|
||||
- Security hardening (virtual-optimized)
|
||||
- OAM monitoring
|
||||
### Monitoring
|
||||
- **oam** - Operations and Maintenance tools (up2date script)
|
||||
|
||||
### LibreNMS Servers (`librenms`)
|
||||
## Configuration Management Tools
|
||||
|
||||
**Criteria:** Hostname contains "tsys-librenms"
|
||||
The system installs clients for future configuration management:
|
||||
|
||||
**Applied Modules:**
|
||||
- Standard server configuration
|
||||
- LibreNMS monitoring setup
|
||||
- Security hardening
|
||||
|
||||
### Development Workstations (`dev-workstation`)
|
||||
|
||||
**Criteria:** Hostname matches "subopi-dev" or "CharlesDevServer"
|
||||
|
||||
**Applied Modules:**
|
||||
- Development tools and packages
|
||||
- Less restrictive SSH configuration
|
||||
- Security monitoring
|
||||
- **Ansible Core** - Already installed for ad-hoc automation tasks
|
||||
- **Salt Minion** - Configured and ready for Salt master connection
|
||||
- **Tailscale** - VPN connectivity for secure remote access
|
||||
|
||||
## Security Features
|
||||
|
||||
The system includes comprehensive security hardening:
|
||||
|
||||
- SSH key-based authentication only
|
||||
- 2FA support via Google Authenticator
|
||||
- 2FA support via Google Authenticator (gradual rollout)
|
||||
- Wazuh security monitoring
|
||||
- SCAP/STIG compliance hardening
|
||||
- Automated security updates
|
||||
- AIDE file integrity monitoring
|
||||
|
||||
## Monitoring and Management
|
||||
## Migration Path
|
||||
|
||||
- LibreNMS network monitoring integration
|
||||
- Cockpit web-based management interface
|
||||
- Comprehensive logging and audit trails
|
||||
- SNMP monitoring configuration
|
||||
- Performance monitoring tools
|
||||
This system is designed as an initial provisioning step. Future migration plans:
|
||||
|
||||
## Configuration Templates
|
||||
|
||||
Configuration files are managed using mustache templates (via `mo`) to allow for:
|
||||
- Environment-specific customizations
|
||||
- Dynamic variable substitution
|
||||
- Class-based configuration variations
|
||||
|
||||
## Maintenance
|
||||
|
||||
The system is designed to be idempotent and can be safely re-run to:
|
||||
- Restore configuration drift
|
||||
- Apply security updates
|
||||
- Add new servers to the fleet
|
||||
- Standardize configurations across environments
|
||||
1. **Ansible Playbooks** - Replace initializers with Ansible roles for configuration management
|
||||
2. **Salt Configuration** - Use Salt master for ongoing configuration orchestration
|
||||
3. **Vault Integration** - Centralized secrets management
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
@@ -137,10 +133,10 @@ For detailed status information:
|
||||
sudo fa status
|
||||
```
|
||||
|
||||
To run specific modules:
|
||||
To run specific initializers:
|
||||
|
||||
```bash
|
||||
sudo fa run <module-name>
|
||||
sudo fa run <initializer-name>
|
||||
```
|
||||
|
||||
To pause automatic runs during maintenance:
|
||||
@@ -162,4 +158,4 @@ sudo fa resume
|
||||
|
||||
## License
|
||||
|
||||
This project is licensed under the terms specified in the LICENSE file.
|
||||
This project is licensed under terms specified in the LICENSE file.
|
||||
Reference in New Issue
Block a user