u/larva_pso

[removed]

I must be doing something wrong here. Qwen 3.8 27b ctx256k , Q4 18gb with ollama+Hermes Agent, RTX3090ti. Using Opensuse tumbleweed.

I can't even get the model to edit a PDF file , even if I provide a file that has the contest to be added to the other PDF document , it keeps thinking and thinking and trying and it ends up in a truncate operation.

Must local models just keep failing for me, I don't really know if it's Hermes the culprit of this problem or what but I can't get a local model to do simple tasks like this ones .

suggestions. ? anyone having similar issues ?

Small MSP owner here (WISP/voice/managed security shop). Like everyone, I got tired of per-endpoint pricing and being a tenant in someone else's product, so I did the thing you're not supposed to do: built my own RMM. It now manages our real fleet, and this week we crossed the line where it does everything we actually used NinjaOne for. Figured I'd share what it can do and, more usefully, what broke along the way.

The stack: Python/FastAPI + SQLite behind Caddy, vanilla JS dashboard, PowerShell 5.1 agent running as a SYSTEM scheduled task (every minute), self-updating from the server. Boring on purpose.

What it does today: multi-tenant fleet with tenant-safe device identity (same hostname across customers), health/monitoring with Discord alerts (offline, disk I/O events, SMART, failed patches), scripts with scheduling and automation policies, ScreenConnect integration, Bitdefender GravityZone integration (protection status per device, install-from-console on unprotected machines), a systray agent for end users (support requests + screenshots straight into the console), one-click reboot/WoL, AI-assisted failed-job analysis, nightly backups, a recovery center with a pinned known-good agent, and a NinjaOne-style device page — live inventory down to BitLocker per volume, firewall profiles, local admins, hotfix history, adapters, uptime.

The part I'm proudest of — patch management. A patching overview across the whole fleet (compliance counters, top pending updates, per-customer drill-down), plus a pending queue where identical driver variants stack properly and every update shows its policy stance. Allow/deny per update, per device or fleet-wide: deny actually hides the update from Windows itself with verified enforcement (the endpoint reports back hide-succeeded, and un-deny restores it), approve installs through the platform's isolated worker. Behind it: Windows Update policy per customer with live inheritance, per-category stances (drivers/firmware report-only, feature updates manual, security auto-approved by severity with a soak delay), and every worker run kept as history server-side.

And this week: a proper MSI with NinjaOne-style uninstall protection (buttons disabled in Apps & Features, removal requires a token), hosted on the server so the dashboard hands techs a one-paste deploy command — and the Remove button in the console now does full offboarding: authorized uninstall, Windows Update policy restored, hidden updates un-hidden, folders gone, record retires itself.

Now the scar tissue, because this is the actual content:

1. I took my entire fleet offline once. Put Windows Update COM calls in the same process as check-in. One hung WUA call = agent never checks in = can't even push the fix remotely. Rebuilt it as an isolated worker process with hard timeouts that the core agent launches and never waits for. A stuck update now means "degraded patch status," never a dead device. If you build agents, this is the lesson: the heartbeat path must depend on nothing.
2. A one-character PowerShell bug ate two development cycles. return ,@($x) inside a function plus @(...) at the call site double-wraps arrays — my update-hide code was calling COM setters on empty arrays for weeks and the errors looked exactly like a COM permissions problem. Audit both ends of every array return.
3. MSI custom actions default to 32-bit-ish contexts. My installer helper expanded %ProgramFiles% to (x86) and quietly pointed the agent task at a file that didn't exist. And Windows Installer by design won't overwrite "modified" unversioned files, so takeover installs kept the old agent. Test installers on a disposable VM first — I learned this on live machines, do not recommend.

Honest gaps: no code signing yet (OV cert is next — unsigned + PowerShell means you'd better be friends with your AV console), SQLite not Postgres, no RBAC granularity, no ticketing. And obviously: one person's homebrew vs. a vendor's team — you're trading their support for total control and $0/endpoint. For us, with the fleet size we have and security services being our core business anyway, that trade finally makes sense.

Not selling anything, not open-sourcing (yet?) — just sharing because I read this sub for years thinking "someday." Happy to answer anything about the architecture, the patch enforcement, or the many ways I set my own fleet on fire. 🔥