feat: add OpenAI-compatible provider for local LLM support#1
Open
marcs7 wants to merge 1 commit intowolfsoftwaresystemsltd:masterfrom
Open
feat: add OpenAI-compatible provider for local LLM support#1marcs7 wants to merge 1 commit intowolfsoftwaresystemsltd:masterfrom
marcs7 wants to merge 1 commit intowolfsoftwaresystemsltd:masterfrom
Conversation
wolfsoftwaresystemsltd
pushed a commit
that referenced
this pull request
Apr 16, 2026
Folded WolfSecure's scanner logic into the main wolfstack binary as a new src/security.rs module — no more separate plugin, no per-node install dance, no architecture-mismatch pain. Findings flow into the existing System Check UI under a 'Security' category, into the periodic alerting pipeline with per-finding cooldown, and into the AI health-check prompt so the assistant treats active threats as top-priority. Posture checks: - Risky services listening on 0.0.0.0 (Docker 2375, Redis, MongoDB, Postgres, MySQL, Elasticsearch, memcached, Kibana) - /etc/wolfstack/ config files that are world- or group-readable - Cluster secret too short or low-entropy - sshd_config with PermitRootLogin yes / PasswordAuthentication yes - SSH exposed without fail2ban or sshguard running Active-attack detection: - SSH brute-force in progress (>=10 failed auths from one IP within the last 5 minutes, via journalctl with auth.log fallback that filters by leading syslog timestamp) - Known crypto-miner processes (xmrig, minerd, cpuminer, ethminer, t-rex, nbminer, lolminer, cgminer, and friends) — the #1 post-compromise payload - Recent executable files in /tmp or /dev/shm (<24h, classic malware staging) - Established outbound connections to RAT / C2 / mining-pool ports (4444, 6667, 9001, 14444, etc) excluding RFC1918 peers Integration: - GET /api/system-check now runs dependency + security checks in parallel via tokio::join!, appending findings to the existing checks array — frontend renders 'Security' as a new category automatically - Background tokio task runs the security scan every 5 min, fires alerts via alerting::send_alert() on critical findings (Discord/Slack/Telegram/email), with a per-check-name 1h cooldown so a prolonged attack doesn't spam channels - AI health_check() loads security findings and threads them into the LLM prompt so alerts + proposed [ACTION] fixes account for active threats, not just CPU/RAM/disk Bugs caught in pre-commit review (all fixed): - ssh_is_exposed was reading wrong field from ss -tlnp (Netid column dropped changes indexing); now uses ss -tulnp with explicit tcp filter - scan_outbound_suspicious assumed 5 fields but ss suppresses State column when filtered — fixed to use fields[3] - auth.log fallback used to read the entire log; now tails 2000 lines AND filters by leading syslog timestamp to enforce the 5-minute window - Alert cooldown key stripped of dynamic counts so 'SSH brute-force (3 IPs, 47 attempts)' doesn't re-alert every scan
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a third AI provider option ("OpenAI Compatible") that works with any OpenAI-compatible API endpoint, enabling local LLM usage via tools like
LiteLLM, Ollama, vLLM, llama.cpp, etc.
This allows WolfStack users to run AI features entirely self-hosted without requiring external API keys from Anthropic or Google.
Changes
Backend (
src/ai/mod.rs)openai_api_keyandopenai_base_urlfields toAiConfigcall_openai()function implementing OpenAI/v1/chat/completionsAPIchat(),health_check(), andanalyze_issue()/v1/modelsendpointBackend (
src/api/mod.rs)ai_save_confighandles newopenai_api_keyandopenai_base_urlfieldsFrontend (
web/index.html)Frontend (
web/js/app.js)Testing
Tested with:
Use Case
Many self-hosted users run local LLMs for privacy, cost, or latency reasons. This PR enables WolfStack's AI features (chat assistant, health monitoring,
issue analysis) to work with any OpenAI-compatible endpoint — no cloud API keys required.