Initial skills documentation — 25 categories, all SKILL.md + references + scripts
This commit is contained in:
root
@@ -0,0 +1,147 @@
|
||||
# Admin-AI Migration Plan: Hetzner → app1
|
||||
|
||||
**Source:** 178.156.167.181 (Hetzner CPX41, 93% disk)
|
||||
**Target:** 152.53.36.131 (app1, RS 4000, 3% disk)
|
||||
**DNS:** admin-ai.itpropartner.com
|
||||
|
||||
## Current State
|
||||
|
||||
### Source (Old AI Box)
|
||||
- LiteLLM v1.84.0 (ghcr.io/berriai/litellm) + Postgres 16
|
||||
- 39 configured models with direct API keys (Anthropic, DeepSeek, Google, OpenAI, Groq, xAI, OpenRouter)
|
||||
- Open WebUI (0.9.6) — 121 MB SQLite DB
|
||||
- Ollama — 8 local models (~10 GB), 7 cloud-proxy models
|
||||
- Qdrant vector DB — small, optional
|
||||
- Caddy reverse proxy
|
||||
- 226G disk at 93% — critical threshold
|
||||
|
||||
### Target (app1)
|
||||
- Docker + Compose v5.3.1 already installed
|
||||
- Ollama + Open WebUI + n8n already running
|
||||
- Caddy 2.6.2 active on 80/443
|
||||
- 1TB at 3% used, 32 GB RAM
|
||||
- Caddy already proxies: n8n.itpropartner.com, ai.itpropartner.com
|
||||
|
||||
## Migration Plan
|
||||
|
||||
### Phase 0 — Pre-flight (no downtime, no DNS changes)
|
||||
|
||||
- [x] Pull LiteLLM image on app1
|
||||
- [x] Set up LiteLLM + Postgres docker-compose on app1
|
||||
- [x] Export Postgres DB from old → import to app1
|
||||
- [x] Add Caddy config for admin-ai.itpropartner.com on app1
|
||||
- [ ] Test admin-ai endpoint on app1 via direct IP or internal DNS — **model routing failure, clean restart in progress**
|
||||
- [ ] Pull needed Ollama models on app1 (llama3.2:3b, qwen2.5:7b) — not needed, ollama already running on app1
|
||||
|
||||
### Phase 1 — Cutover
|
||||
|
||||
- [ ] Switch Hermes to fallback chain (OpenRouter deepseek-chat)
|
||||
- [ ] Update DNS: admin-ai.itpropartner.com → 152.53.36.131 (TTL 60)
|
||||
- [ ] Monitor admin-ai endpoint
|
||||
- [ ] Run end-to-end model test through app1
|
||||
- [ ] Verify vision (gemini-pro-latest) works
|
||||
|
||||
### Phase 2 — Restore Primary
|
||||
|
||||
- [ ] Switch Hermes back to admin-ai primary
|
||||
- [ ] Verify all 22 cron jobs pass
|
||||
- [ ] Verify Anita's profile
|
||||
|
||||
### Phase 3 — Decommission (after 3 days stable)
|
||||
|
||||
- [ ] Keep old box running for rollback
|
||||
- [ ] After verification, decom Hetzner AI server
|
||||
|
||||
## Detailed Steps
|
||||
|
||||
### Step 0: Pull LiteLLM image on app1
|
||||
|
||||
```bash
|
||||
ssh -i /root/.ssh/itpp-infra root@152.53.36.131
|
||||
docker pull ghcr.io/berriai/litellm:v1.84.0
|
||||
```
|
||||
|
||||
### Step 1: Create LiteLLM docker-compose on app1
|
||||
|
||||
Create `/root/docker/litellm/docker-compose.yml` and `/root/docker/litellm/.env`.
|
||||
|
||||
The docker compose needs BOTH `.env` (master key + salt key) AND `config.yaml` (database_url + enforce_database). Even in DB mode, LiteLLM requires config.yaml for routing. Without it, models are listed but completions fail silently.
|
||||
|
||||
### Step 2: Export/import Postgres DB
|
||||
|
||||
On old server:
|
||||
```bash
|
||||
PGPASSWORD=litellm docker exec litellm_postgres pg_dump -U litellm -d litellm_db --no-owner > /tmp/litellm_db_dump.sql
|
||||
```
|
||||
|
||||
SCP to app1 (route through Core if needed):
|
||||
```bash
|
||||
scp root@178.156.167.181:/tmp/litellm_db_dump.sql /tmp/
|
||||
scp /tmp/litellm_db_dump.sql root@152.53.36.131:/tmp/
|
||||
```
|
||||
|
||||
On app1, start Postgres first, then import:
|
||||
```bash
|
||||
cd /root/docker/litellm && docker compose up -d litellm_postgres
|
||||
sleep 5
|
||||
PGPASSWORD=litellm docker exec -i litellm_postgres psql -U litellm -d litellm_db < /tmp/litellm_db_dump.sql
|
||||
```
|
||||
|
||||
### Step 3: Start LiteLLM on app1 (CRITICAL)
|
||||
|
||||
Start LiteLLM only after Postgres import completes AND is healthy:
|
||||
|
||||
```bash
|
||||
cd /root/docker/litellm && docker compose up -d litellm
|
||||
sleep 60 # Prisma migrations take 30-60s on first start with restored DB
|
||||
curl -s http://127.0.0.1:4000/health/liveliness # Should return "I'm alive!"
|
||||
```
|
||||
|
||||
**⚠️ CRITICAL — model routing failure on first start (Jul 13, 2026):** After DB import, models appear in `/v1/models` but ALL completions fail with "Invalid model name passed." This occurs even with identical SALT_KEY, DB dump, and Docker image. Root cause is a LiteLLM startup race condition — the model routing table takes time to populate from the DB.
|
||||
|
||||
**Fix:** Do a clean restart (`docker compose down && docker compose up -d`). Wait for the full startup cycle (30-60s for Prisma migrations + model index rebuild). Test completions, not just the models endpoint. A model in `/v1/models` that fails completions means the routing layer didn't initialize properly on first boot. Verify with:
|
||||
|
||||
```bash
|
||||
curl -s http://127.0.0.1:4000/v1/chat/completions \
|
||||
-H "Authorization: Bearer sk-lbhhxIk_9pQ2Vmlym7bWPA" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"model":"deepseek-chat","messages":[{"role":"user","content":"Hi"}],"max_tokens":5}'
|
||||
# Should return actual completion text, not "Invalid model name"
|
||||
```
|
||||
|
||||
**⚠️ config.yaml MUST be mounted:** Even in DB mode (`STORE_MODEL_IN_DB=True`), LiteLLM requires `config.yaml` with `general_settings.database_url` and `general_settings.enforce_database: true`. Mount as a volume alongside the compose file.
|
||||
|
||||
**⚠️ Healthcheck curl pitfall:** The `ghcr.io/berriai/litellm` image does not include `curl`. A `CMD-SHELL curl` healthcheck produces 6000+ consecutive failures and marks the container `(unhealthy)` permanently. Use `wget -qO-` or a Python-native healthcheck instead.
|
||||
|
||||
**⚠️ Separate compose per service:** The old box uses a monolithic `/opt/ai/docker-compose.yml` with 6 containers. The new deployment uses the Docker standard — one service per `/root/docker/<name>/` directory.
|
||||
|
||||
### Step 4: Test on app1 via loopback
|
||||
|
||||
```bash
|
||||
curl -s http://127.0.0.1:4000/v1/models -H "Authorization: Bearer sk-lbhhxIk_9pQ2Vmlym7bWPA"
|
||||
# Should return 121+ models
|
||||
```
|
||||
|
||||
### Step 5: Add Caddy config on app1
|
||||
|
||||
Caddy already configured:
|
||||
```
|
||||
admin-ai.itpropartner.com {
|
||||
reverse_proxy 127.0.0.1:4000
|
||||
}
|
||||
```
|
||||
|
||||
### Step 6: DNS cutover
|
||||
|
||||
Flip DNS A record to 152.53.36.131, verify with curl to admin-ai.itpropartner.com.
|
||||
|
||||
## Rollback
|
||||
|
||||
If cutover fails:
|
||||
1. DNS back to 178.156.167.181
|
||||
2. Switch Hermes back to admin-ai (old box still running throughout)
|
||||
3. Old box continues operating — zero data loss
|
||||
|
||||
## Provider API Keys
|
||||
|
||||
All model API keys are encrypted in Postgres using LITELLM_SALT_KEY. As long as the same SALT_KEY is used on app1, the keys migrate transparently via the Postgres dump. Direct provider env vars (OPENAI_API_KEY, etc.) are all empty — everything routes through Postgres-stored keys or OpenRouter.
|
||||
@@ -0,0 +1,54 @@
|
||||
# Consolidation & Migration Plan
|
||||
|
||||
## Strategy
|
||||
|
||||
**Target:** Move all Hetzner workloads onto netcup root servers. Hetzner's Jul 2026 pricing makes new Hetzner VPSes uneconomical (3-5x netcup for equivalent compute).
|
||||
|
||||
**Keep at Hetzner:** app1-bu (warm standby), tony-vps (Anthony's box)
|
||||
|
||||
## Netcup target servers
|
||||
|
||||
| Server | Tier | Purpose | Est. Cost/mo |
|
||||
|--------|------|---------|-------------|
|
||||
| **Core** (exists) | RS 2000 (8C/16G/512GB) | Hermes, portal, Docker, misc services | ~$20 |
|
||||
| **Monitor** (new) | RS 1000 (4C/8G/256GB) | AI/LLM, monitoring, automation | ~$12 |
|
||||
| **Web** (new) | RS 1000 (4C/8G/256GB) | WISP, web apps, docs | ~$12 |
|
||||
|
||||
## Migration phases
|
||||
|
||||
### Phase 1 — ai.itpropartner.com (CRITICAL: 92% disk)
|
||||
- Containers: LiteLLM, Open WebUI, Ollama, Qdrant, Caddy
|
||||
- Move to: Monitor (if exists) or Core temporarily
|
||||
- Method: docker-compose stack transfer
|
||||
- Disk issue: 199G of 226G used. Ollama models + Qdrant vectors are the likely culprit
|
||||
|
||||
### Phase 2 — unms.forefrontwireless.com + unifi
|
||||
- unms: 9 containers (UNMS/UISP, UCRM, RabbitMQ, PostgreSQL, Netflow)
|
||||
- unifi: Native app + MongoDB + MariaDB
|
||||
- Move to: Web (new RS 1000)
|
||||
- Method: docker-compose for UNMS, package migration for UniFi
|
||||
|
||||
### Phase 3 — hudu.itpropartner.com
|
||||
- 5 containers: Hudu app, SWAG certbot, PostgreSQL, Redis
|
||||
- Move to: Web or Monitor (co-locate)
|
||||
- Method: docker-compose stack transfer
|
||||
|
||||
### Phase 4 — n8n, docker host, fleettracker360
|
||||
- n8n: 2 containers (n8n + PostgreSQL)
|
||||
- docker: 7+ containers (NPM, RustDesk, Uptime-Kuma, StrongSwan)
|
||||
- fleettracker360: Traccar (Java, 26+ tracking ports)
|
||||
- Move to: Core (has capacity: 6% disk, 8 dedicated cores)
|
||||
- Method: docker-compose stacks + Traccar Java migration
|
||||
|
||||
### Phase 5 — wphost02 (review)
|
||||
- RunCloud + WordPress sites (Apex, BoxPilot, etc.)
|
||||
- Option A: Move to Web (rsync + DB dump)
|
||||
- Option B: Stay at Hetzner — keep simple
|
||||
|
||||
## Key considerations
|
||||
|
||||
- netcup provisioning via SCP REST API: `servercontrolpanel.de/scp-core/api/v1/`
|
||||
- Auth: Keycloak OIDC password grant (customer# + CCP password)
|
||||
- New netcup root servers take ~5-15 min to provision
|
||||
- DNS needs updating at SiteGround after each migration
|
||||
- Test each service for 24h before decommissioning old box
|
||||
@@ -0,0 +1,25 @@
|
||||
# Core Rebalance Plan — Service Migration
|
||||
|
||||
**Created:** July 12, 2026
|
||||
**Status:** Planned, not yet executed
|
||||
|
||||
## Target Architecture
|
||||
|
||||
### Core (152.53.192.33) — Hermes Command Center
|
||||
Keep: Hermes Agent, LiteLLM, Ollama (lightweight fallback), local scripts, SSH access.
|
||||
|
||||
### app1 (152.53.36.131) — Service Hub
|
||||
Move everything else: Caddy, Ops Portal, OSINT API, Super Search, SearXNG, Grafana, all cron jobs, ops data collector.
|
||||
|
||||
### DNS Changes
|
||||
- ops.itpropartner.com → app1 IP
|
||||
- core.itpropartner.com → app1 IP
|
||||
- sign.itpropartner.com → app1 IP
|
||||
- admin-ai.itpropartner.com → Core IP (stays)
|
||||
|
||||
### Phase Plan
|
||||
1. Prep (30 min) — snapshot, audit app1, stage files
|
||||
2. Move (2 hr) — services Core → app1
|
||||
3. LiteLLM (30 min) — Hetzner old-ai → Core
|
||||
4. Ollama (15 min) — app1 → Core
|
||||
5. Rename (15 min) — app1-bu → core-bu
|
||||
@@ -0,0 +1,22 @@
|
||||
# IT Pro Partner — Infrastructure Rebalance: IP & DNS Changes
|
||||
> Last Updated: July 12, 2026
|
||||
|
||||
See /root/.hermes/references/ip-dns-changes.md for the full reference document.
|
||||
|
||||
## Quick Reference
|
||||
|
||||
| Domain | Old IP | New IP | Status |
|
||||
|--------|--------|--------|--------|
|
||||
| unifi.itpropartner.com | 143.198.185.17 (DigitalOcean) | 152.53.39.202 (app2) | ✅ DNS updated |
|
||||
| unms.forefrontwireless.com | 5.161.225.131 (Hetzner) | 152.53.39.202 (app2) | ⏳ Propagation |
|
||||
| ops.itpropartner.com | 152.53.192.33 (Core) | 152.53.36.131 (app1) | Pending rebalance |
|
||||
| core.itpropartner.com | 152.53.192.33 (Core) | 152.53.36.131 (app1) | Pending rebalance |
|
||||
| sign.itpropartner.com | 152.53.192.33 (Core) | 152.53.36.131 (app1) | Pending rebalance |
|
||||
| admin-ai.itpropartner.com | 178.156.167.181 (old-ai) | 152.53.192.33 (Core) | Pending LiteLLM migration |
|
||||
|
||||
## Servers to Cancel
|
||||
old-ai (CPX41), old app1 (CPX11), docker (CPX11), unms (CPX21), unifi (CPX21), hudu (CPX21), fleettracker (CPX11), wphost02 (CPX21)
|
||||
Total savings: ~$104/mo
|
||||
|
||||
## Servers to Keep
|
||||
core-bu (CPX11→CPX31), tony-vps (CPX21)
|
||||
@@ -0,0 +1,5 @@
|
||||
This is a pointer — the canonical file lives at:
|
||||
/root/.hermes/references/master-apps-services.md
|
||||
|
||||
See that path for the complete ITPP Master Apps & Services Inventory.
|
||||
Created Jul 11, 2026 during a full infrastructure audit across all 8 servers.
|
||||
+57
@@ -0,0 +1,57 @@
|
||||
## Infrastructure Migration Plan (Jul 2026)
|
||||
|
||||
### Target Architecture
|
||||
|
||||
| Server | Provider | Model | Cost/mo | Role |
|
||||
|--------|----------|-------|---------|------|
|
||||
| **Core** | netcup RS 2000 | 8C/16G/512GB | ~$24 (paid) | Hermes, Docker (Vaultwarden, Docuseal, SearXNG, Twenty), Portal, Prometheus, Uptime-Kuma, Caddy, VPN |
|
||||
| **app2** | netcup RS 4000 | 12C/32G/1TB | ~$44 | UNMS/UISP, UniFi Controller, Hudu, Traccar |
|
||||
| **app3** | netcup RS 2000 | 8C/16G/512GB | ~$24 | WordPress/Apex, web apps |
|
||||
| **app1-bu** | Hetzner CPX11 (2C/2G) | Staying | Paid | Warm standby for Core. Keep in place. |
|
||||
|
||||
### Migration rules
|
||||
|
||||
1. **Zero downtime for admin-ai.itpropartner.com** — LiteLLM (deepseek-chat proxy for Sho'Nuff) must stay live during migration. Set up new LiteLLM on Core first, test via alternate URL, switch DNS.
|
||||
2. **Admin-ai uses PostgreSQL for model configs** — DB dump/restore, not config file.
|
||||
3. **Open WebUI conversations are in SQLite** — stop container, copy `/app/backend/data/` (1.9 GB), restore on new box.
|
||||
4. **Migration order:** AI stack first (most critical), then UNMS/UniFi, then web apps.
|
||||
5. **app1-bu stays warm at Hetzner** — do not migrate. It's the safety net.
|
||||
6. **New boxes follow Docker install standard** — `/root/docker/<service>/`, healthchecks, resource limits, internal networks, named volumes, .env chmod 600.
|
||||
7. **SSH key for new boxes:** Deploy `itpp-infra` key during provisioning.
|
||||
8. **New boxes provisioned via netcup SCP** (no API for provisioning — use web UI at servercontrolpanel.de).
|
||||
9. **app2 needs RS 4000** — UNMS (10 containers + Java/PostgreSQL/RabbitMQ) + UniFi (Java + MongoDB + MariaDB) + Hudu (5 containers) + Traccar (Java + 26 ports) needs 12C/32G to avoid contention.
|
||||
10. **Billing:** Monthly (not annual), Virginia (Manassas) location.
|
||||
|
||||
### admin-ai migration — critical path
|
||||
|
||||
admin-ai.itpropartner.com (LiteLLM on ai box at Hetzner) serves the deepseek-chat model that powers Sho'Nuff. It is the most critical service. Sequential steps:
|
||||
|
||||
1. Set up new LiteLLM + PostgreSQL on Core (or Monitor box)
|
||||
2. Dump old PostgreSQL: `docker exec litellm_postgres pg_dump -U litellm litellm_db > litellm-dump.sql`
|
||||
3. Restore on new PostgreSQL
|
||||
4. Test new proxy: `curl http://new-box:4000/v1/models` — should show all models
|
||||
5. Update Hermes config to point at new proxy for testing
|
||||
6. Switch admin-ai DNS record to new IP
|
||||
7. Keep old ai box running for 7 days as fallback
|
||||
|
||||
### Cron after migration
|
||||
|
||||
- Core retains: `hermes-live-sync`, `hermes-system-config-sync`, `hermes-docker-sync`, `ops-data-collector`, `shark-scraper`, `home-router-daily-backup` (via WG to 10.77.0.2), `vps-threshold-check`
|
||||
- app2 gets: local UNMS/UniFi/etc. cron jobs, node_exporter for Prometheus scraping
|
||||
- app3 gets: WordPress cron, node_exporter
|
||||
- app1-bu keeps: `hermes-standby-watchdog`, `hermes-standby-sync`
|
||||
|
||||
### Cost comparison
|
||||
|
||||
| | Current (Hetzner) | Target (netcup) |
|
||||
|---|---|---|
|
||||
| Servers | 9 + app1-bu | Core + app2 + app3 + app1-bu |
|
||||
| Monthly | ~$150-160 | ~$68 (app2 + app3) + Core (paid) |
|
||||
| Savings | — | **~$82-92/mo** |
|
||||
|
||||
### Unchanged services
|
||||
|
||||
- Nginx Proxy Manager (stays on docker Hetzner box — remaining services there still need reverse proxy)
|
||||
- RustDesk (stays on docker Hetzner box)
|
||||
- StrongSwan Docker (stays on docker Hetzner box)
|
||||
- RunCloud MariaDB instances on decommissioned Hetzner boxes — not migrated, databases stay with their apps
|
||||
@@ -0,0 +1,37 @@
|
||||
# netcup API Access Investigation — Jul 8, 2026
|
||||
|
||||
## Summary
|
||||
The netcup REST API was NOT successfully configured. All three API paths returned errors or authentication failures.
|
||||
|
||||
## Endpoints Tested
|
||||
|
||||
### SCP REST API (servercontrolpanel.de)
|
||||
- **Endpoint:** `https://www.servercontrolpanel.de/scp-ui/api/v1/servers`
|
||||
- **Auth tried:** `X-API-Key` header, `Authorization: Bearer` header
|
||||
- **Result:** HTTP 200 — returns SCP login HTML, not JSON
|
||||
- **Body contains:** `<nc-unauthorized></nc-unauthorized>` — CCP API key doesn't authenticate SCP Keycloak
|
||||
- **SCP version:** 2026.0703.095128
|
||||
|
||||
### CCP REST API (customercontrolpanel.de)
|
||||
- **Endpoint:** `/rest/v1/servers`, `/api/v1/servers`
|
||||
- **Auth tried:** `X-API-Key`, Bearer, query param
|
||||
- **Result:** HTTP 404 — all paths
|
||||
|
||||
### JSON-RPC (ccp.netcup.net)
|
||||
- **Endpoint:** `https://ccp.netcup.net/run/webservice/servers/endpoint.php?JSON`
|
||||
- **Auth:** `{"action":"getProducts","param":{"apikey":"..."}}`
|
||||
- **Result:** 200, but `"Invalid entry for field apikey"` — needs customer# + API password
|
||||
|
||||
| Endpoint | HTTP | Auth | Result |
|
||||
|----------|------|------|--------|
|
||||
| ccp.netcup.net/webservice/v2_0/ | 404 | SOAP | Not Found |
|
||||
| ccp.netcup.net/endpoint.php?JSON | 200 | JSON-RPC | "Invalid apikey" |
|
||||
| customercontrolpanel.de/rest/v1/servers | 404 | X-API-Key | Not Found |
|
||||
| servercontrolpanel.de/scp-ui/api/v1/servers | 200 | X-API-Key | Returns login page |
|
||||
| servercontrolpanel.de/scp-ui/api/v1/openapi | 200 | X-API-Key | Same — HTML, not JSON |
|
||||
|
||||
## Likely Fix
|
||||
SCP needs its own API key generated within the SCP interface (not CCP Master Data). Or JSON-RPC with customer number + API password.
|
||||
|
||||
## Status
|
||||
netcup API: UNCONFIGURED. Provisioning via web interface + SSH only.
|
||||
@@ -0,0 +1,59 @@
|
||||
# Super Search — MCP Server Architecture Pattern
|
||||
|
||||
Updated: 2026-07-12
|
||||
|
||||
## Architecture
|
||||
|
||||
```
|
||||
Client (Hermes) → localhost:8899/mcp (FastMCP HTTP)
|
||||
|
||||
Tools:
|
||||
web_search(query, limit=5) — multi-provider chain
|
||||
web_extract(url) — Trafilatura → Firecrawl
|
||||
web_search_premium(query) — Exa direct (DRE-grade)
|
||||
```
|
||||
|
||||
## Provider Chain with Rate Limiting
|
||||
|
||||
Each provider has a token bucket rate limiter, TTL cache, and the chain falls through on failure:
|
||||
|
||||
```
|
||||
web_search → 1. SearXNG (local, 30 req/s, 2min cache)
|
||||
→ 2. Exa (paid, 10 req/s, 5min cache)
|
||||
→ 3. OpenCorporates (free, 1 req/s, 1hr cache) — company records
|
||||
→ 4. CourtListener (free, ~100/min, 1hr cache) — court cases
|
||||
→ 5. Firecrawl (paid, 5 req/min, 5min cache)
|
||||
```
|
||||
|
||||
On 429/rate-limit: exponential backoff respecting Retry-After header, then fall to next provider. On 5xx: immediate fallback.
|
||||
|
||||
## Files
|
||||
|
||||
- `/root/docker/super-search/server.py` — FastMCP server (v1.2.0+)
|
||||
- `/root/docker/super-search/ratelimit.py` — TokenBucket, TTLCache, retry helpers
|
||||
- Systemd service: `super-search.service`
|
||||
- Venv: `/root/docker/super-search/venv`
|
||||
|
||||
## Rate Limit Configuration
|
||||
|
||||
```python
|
||||
RATE_LIMITS = {
|
||||
"searxng": {"tokens": 30, "interval": 1.0},
|
||||
"exa": {"tokens": 10, "interval": 1.0},
|
||||
"firecrawl": {"tokens": 5, "interval": 60.0},
|
||||
"opencorporates": {"tokens": 1, "interval": 1.0},
|
||||
"courtlistener": {"tokens": 10, "interval": 6.0},
|
||||
}
|
||||
CACHE_TTL = {
|
||||
"searxng": 120, "exa": 300, "firecrawl": 300,
|
||||
"opencorporates": 3600, "courtlistener": 3600,
|
||||
}
|
||||
```
|
||||
|
||||
## Adding a New Provider
|
||||
|
||||
1. Add rate limit and cache TTL to config dicts in ratelimit.py
|
||||
2. Add `_newprovider_search()` function decorated with `@rate_limited_search("newprovider")`
|
||||
3. Add to the `web_search` fallback chain in order
|
||||
4. Bump version, restart service: `systemctl restart super-search`
|
||||
5. Verify: `hermes mcp test super-search`
|
||||
Reference in New Issue
Block a user