Document the validate.sh script functionality: - Add Validation section after SSL Stack components - Describe script usage and invocation - List validation checks performed: - Required top-level files and directories - Initializer directory structure - Apply script syntax - Path consistency between apply scripts and configs/scripts 🤖 Generated with [Crush](https://github.com/charmassociates/crush) Assisted-by: GLM-5 via Crush <crush@charm.land>
235 lines
7.8 KiB
Markdown
235 lines
7.8 KiB
Markdown
# KNEL Configuration Management - FetchApply
|
|
|
|
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 uses:
|
|
- Salt for system configuration and automation
|
|
- Ansible for ComplianceAsCode deployment
|
|
|
|
## Overview
|
|
|
|
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 Salt/Ansible-based management.
|
|
|
|
## Repository Structure
|
|
|
|
```
|
|
.
|
|
├── 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
|
|
│ ├── unattended-upgrades/ # Automatic security updates
|
|
│ ├── dell-config/ # Dell server specific configurations
|
|
│ ├── ssl-stack/ # SSL stack compilation (dev systems)
|
|
│ ├── ldap-auth/ # LDAP authentication (placeholder)
|
|
│ ├── 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
|
|
|
|
### Prerequisites
|
|
|
|
- Linux server (Ubuntu 18.04+ or Debian 10+ recommended)
|
|
- Root or sudo access
|
|
- Internet connectivity for package downloads
|
|
|
|
### Install FetchApply
|
|
|
|
First, install FetchApply on your system:
|
|
|
|
```bash
|
|
curl https://source.priveasy.org/Priveasy/fetch-apply/raw/branch/main/install -o /tmp/install
|
|
sudo bash /tmp/install --operations-repository-url=https://git.knownelement.com/KNEL/KNELConfigMgmt-FetchApply.git
|
|
```
|
|
|
|
### Usage
|
|
|
|
Once installed, FetchApply will automatically:
|
|
|
|
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:
|
|
|
|
```bash
|
|
sudo fa
|
|
```
|
|
|
|
## System Detection
|
|
|
|
The system automatically detects:
|
|
|
|
- **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
|
|
|
|
## Initializers
|
|
|
|
### Core Setup
|
|
- **system-setup** - System detection and variable setup
|
|
- **packages** - Package installation with conditional logic (includes build tools for SSL stack, ansible-core for ComplianceAsCode, salt-minion for ongoing management, tailscale for VPN)
|
|
- **user-configuration** - Shell settings and user preferences
|
|
|
|
### 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 ongoing configuration management
|
|
|
|
### Security
|
|
- **2fa** - Set up Google Authenticator for 2FA
|
|
- **wazuh** - Deploy Wazuh security monitoring agent
|
|
- **security-hardening** - SCAP/STIG compliance hardening (includes auditd, systemd, logrotate configs)
|
|
- **unattended-upgrades** - Configure automatic security updates
|
|
|
|
### Specialized
|
|
- **dell-config** - Dell server specific optimizations (CPU performance, OMSA tools)
|
|
- **ssl-stack** - Compile OpenSSL, nghttp2, curl, APR, and Apache from source (dev systems only)
|
|
- **ldap-auth** - LDAP authentication configuration (placeholder for Cloudron)
|
|
|
|
### Monitoring
|
|
- **oam** - Operations and Maintenance tools (up2date script)
|
|
|
|
## Configuration Management Tools
|
|
|
|
The system installs clients for specific management purposes:
|
|
|
|
- **Ansible Core** - For deploying ComplianceAsCode content from https://github.com/ComplianceAsCode/content
|
|
- **Salt Minion** - For ongoing system configuration, automation, and orchestration
|
|
- **Tailscale** - VPN connectivity for secure remote access
|
|
|
|
## Tool Responsibilities
|
|
|
|
| Tool | Primary Responsibility | When Used |
|
|
|-------|-------------------|-----------|
|
|
| FetchApply | Initial server provisioning | Once at deployment |
|
|
| Salt | Ongoing configuration & automation | Continuously |
|
|
| Ansible | ComplianceAsCode deployment | Periodically/on-demand |
|
|
|
|
## Security Features
|
|
|
|
- SSH key-based authentication only
|
|
- 2FA support via Google Authenticator (gradual rollout)
|
|
- Wazuh security monitoring
|
|
- SCAP/STIG compliance hardening
|
|
- AIDE file integrity monitoring
|
|
- Automatic security updates
|
|
|
|
## Specialized Configurations
|
|
|
|
### Dell Servers
|
|
- Automatic CPU performance tuning
|
|
- Dell OpenManage Server Administrator setup
|
|
- Ethernet configuration scripts
|
|
|
|
### Development Workstations
|
|
- SSL stack compilation (OpenSSL 1.1.0h, nghttp2, curl, APR, Apache)
|
|
- HTTP/2 enabled Apache HTTPd
|
|
- Custom SSL installations
|
|
|
|
### Future Services
|
|
- Beszel monitoring (to be deployed via Salt)
|
|
- Netbird networking (to be deployed via Salt)
|
|
- LDAP authentication (Cloudron integration)
|
|
|
|
## Migration Path
|
|
|
|
This system provides a foundation for comprehensive management:
|
|
|
|
1. **FetchApply** - Initial server provisioning (this repo)
|
|
2. **Salt Master** - Ongoing configuration management and automation
|
|
3. **Ansible Playbooks** - ComplianceAsCode deployment and management
|
|
4. **Future Services** - Beszel monitoring and Netbird networking via Salt
|
|
|
|
## Compliance Management
|
|
|
|
Ansible will be used specifically to deploy and manage:
|
|
- Compliance frameworks from https://github.com/ComplianceAsCode/content
|
|
- Security baselines and hardening rules
|
|
- Compliance validation and reporting
|
|
- Documentation generation
|
|
|
|
## SSL Stack Compilation
|
|
|
|
Available on development workstations or when `COMPILE_SSL_STACK=true`:
|
|
- OpenSSL 1.1.0h with weak ciphers enabled (legacy compatibility)
|
|
- nghttp2 for HTTP/2 support
|
|
- curl with HTTP/2 and custom OpenSSL support
|
|
- Apache HTTPd with HTTP/2 enabled
|
|
- Custom installations at `/usr/local/custom-ssl/`
|
|
|
|
## Validation
|
|
|
|
The repository includes a validation script to verify structure and configuration:
|
|
|
|
```bash
|
|
./validate.sh
|
|
```
|
|
|
|
This checks:
|
|
- Required top-level files and directories
|
|
- Initializer directory structure
|
|
- Apply script syntax
|
|
- Path consistency between apply scripts and configs/scripts directories
|
|
|
|
## Troubleshooting
|
|
|
|
For detailed status information:
|
|
|
|
```bash
|
|
sudo fa status
|
|
```
|
|
|
|
To run specific initializers:
|
|
|
|
```bash
|
|
sudo fa run <initializer-name>
|
|
```
|
|
|
|
To compile SSL stack:
|
|
|
|
```bash
|
|
COMPILE_SSL_STACK=true sudo fa run ssl-stack
|
|
```
|
|
|
|
To pause automatic runs during maintenance:
|
|
|
|
```bash
|
|
sudo fa pause
|
|
```
|
|
|
|
To resume automatic runs:
|
|
|
|
```bash
|
|
sudo fa resume
|
|
```
|
|
|
|
## Repository Information
|
|
|
|
**Issues:** https://projects.knownelement.com/project/reachableceo-vptechnicaloperations/timeline
|
|
**Discussion:** https://community.turnsys.com/c/chieftechnologyandproductofficer/26
|
|
|
|
## License
|
|
|
|
This project is licensed under the terms specified in the LICENSE file. |