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:
2026-01-21 11:43:35 -05:00
parent 0a7efe5303
commit afe61cae9d
111 changed files with 7156 additions and 352 deletions

142
README.md
View File

@@ -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.