Skip to content

Conversation

@CodeMonkeyCybersecurity
Copy link
Owner

No description provided.

Signed-off-by: chickenj0 <github.skimmer925@passmail.net>
@CodeMonkeyCybersecurity CodeMonkeyCybersecurity merged commit 15ed706 into main Feb 5, 2025
CodeMonkeyCybersecurity added a commit that referenced this pull request Oct 13, 2025
…ake LiteLLM default

CRITICAL FIXES - DO NOT DEPLOY WITHOUT THESE:

Issue #1: Open WebUI Not Connected to LiteLLM (CRITICAL)
- Added OPENAI_API_BASE_URL=http://litellm-proxy:4000 to docker-compose.yml
- Added OPENAI_API_KEY=${LITELLM_MASTER_KEY} to docker-compose.yml
- Added connection variables to .env template
- Without this, Open WebUI has NO backend and is completely non-functional

Issue #2: LiteLLM Now DEFAULT (as requested)
- Changed from --use-litellm flag to --direct-mode flag
- LiteLLM production mode is now enabled by default
- Direct mode is opt-in for development only
- Updated all help text and examples

Issue #3: Enhanced User Experience
- Clear indication of production vs development mode
- Warning message when using direct mode
- Production features list shown by default

TECHNICAL DETAILS:

Docker Compose Changes:
- openwebui service now has environment block
- OPENAI_API_BASE_URL uses Docker service name (litellm-proxy:4000)
- OPENAI_API_KEY references LITELLM_MASTER_KEY from .env
- Proper service-to-service communication on Docker network

Environment File Changes:
- Added OPENAI_API_BASE_URL=http://litellm-proxy:4000
- Added OPENAI_API_KEY=${LITELLM_MASTER_KEY}
- These tell Open WebUI where to find LiteLLM

CLI Changes:
- Removed: --use-litellm flag
- Added: --direct-mode flag (disables LiteLLM)
- Default behavior: LiteLLM enabled
- Updated examples to show default is production-ready

Type Changes:
- Added DirectMode bool field
- UseLiteLLM set to true by default when DirectMode is false
- Clear separation between production and development modes

Success Message Changes:
- Shows LiteLLM URLs by default
- Lists production features enabled
- Warning when direct mode is used

VERIFICATION:
✅ AZURE_MODEL format correct: azure/gpt-4
✅ Docker service names correct: litellm-proxy
✅ LiteLLM config structure correct
✅ Volume mounts correct
✅ Open WebUI connection configured
✅ LiteLLM is default mode
✅ All packages compile successfully

This fixes the critical issue where Open WebUI would deploy but have
no backend to connect to, resulting in a completely non-functional system.

Reference: OPENWEBUI_LITELLM_REVIEW.md for detailed technical review
CodeMonkeyCybersecurity added a commit that referenced this pull request Oct 13, 2025
…ment

VERIFICATION COMPLETE - ALL ISSUES FIXED ✅

Confirmed in current codebase:
✅ Issue #1: Open WebUI connection to LiteLLM - FIXED (lines 727-732)
✅ Issue #2: LiteLLM default mode - FIXED (lines 95-97, cmd flags)
✅ Issue #3: Environment variables - FIXED (lines 612-614)

All critical configuration points verified:
✅ AZURE_MODEL format: azure/%s (line 598)
✅ Service name: http://litellm-proxy:4000 (not localhost)
✅ LiteLLM config: os.environ/AZURE_MODEL (line 673)
✅ Volume mount: ./litellm_config.yaml:/app/config.yaml (line 737)
✅ DirectMode defaults to false (LiteLLM enabled by default)

Status: READY FOR TESTING

Includes complete testing checklist and deployment steps.
CodeMonkeyCybersecurity pushed a commit that referenced this pull request Nov 22, 2025
Architecture enforcement: Extracted business logic from cmd/create/wazuh.go
to pkg/wazuh/setup/ following Assess → Intervene → Evaluate pattern.

Changes:
- Reduce cmd/create/wazuh.go from 854 lines → 384 lines (55% reduction)
- Webhook integration command reduced to 52 lines (pure orchestration)
- Create pkg/wazuh/setup/ package with 8 files:
  * types.go (37 lines) - Config, DefaultConfig
  * install.go (89 lines) - Main Install() (Assess → Intervene → Evaluate)
  * checks.go (103 lines) - CheckWazuhInstalled, TestIntegration
  * configuration.go (175 lines) - Webhook, token, env file, ossec.conf
  * dependencies.go (50 lines) - InstallPythonDependencies
  * scripts.go (290 lines) - InstallIntegrationScripts, script templates
  * service.go (35 lines) - RestartWazuhManager
  * utils.go (69 lines) - PromptYesNo, CopyFile, PrintSuccessMessage

Architecture Compliance:
- cmd/create/wazuh.go webhook integration now pure orchestration (52 lines)
- All business logic in pkg/ with proper organization
- Follows Assess → Intervene → Evaluate pattern in Install()
- All exported functions have godoc comments
- Structured logging with otelzap.Ctx(rc.Ctx)
- No file operations, exec.Command, or loops in cmd/ orchestration

File Organization:
- cmd/create/wazuh_templates.go → pkg/wazuh/setup/scripts.go (renamed)
- Script templates now properly encapsulated in pkg/
- All 17 helper functions successfully migrated

Verification:
- go build ./pkg/wazuh/setup/... passes ✓
- go vet ./pkg/wazuh/setup/... passes ✓
- Zero functionality lost
- 17 functions successfully migrated

Impact:
- cmd/create/wazuh.go: 854 → 384 lines (470 lines extracted)
  Note: File remains 384 lines due to other subcommands (mapping, docker, credentials, cleanup)
  Webhook integration command: 52 lines (94% reduction from original)
- Improved testability (pkg/ functions unit-testable)
- Better organization (setup logic grouped by responsibility)
- Maintains all Wazuh integration functionality

Part of systematic cmd/ to pkg/ migration (#3 of 15 files).
Next: Additional high-priority files from top 15 list.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants