Case file: API write verificationPersonal project, verified against a live Wazuh manager. It is not a customer ticket.
Problem
A PUT could return HTTP 200 while the write was silently skipped. The JSON body reported error: 1 and the file remained unchanged.
Reproduction
A PUT against an existing filename without overwrite=true returned HTTP 200 but did not update state.
Resolution
Send overwrite=true, inspect the body-level error and total_failed_items fields, and verify the resulting state.
Prevention
Check every PUT and DELETE response body, abort partial reconciliation on failure, and retain regression coverage.
Report
API says success, remote state unchanged
Reproduce
HTTP 200, body error: 1, file unchanged
Isolate
Existing filename, overwrite flag absent
Resolve
Explicit overwrite plus body-level verification
Document
Regression test and operator guidance
Signature interaction
The Resolution Desk
Pick one example ticket, then follow it through three clear phases:
Diagnose, Resolve, and Close. Each phase reveals
the specific step and evidence that matter at that moment; deeper
knowledge-base and escalation paths stay available when needed.
FARHAT SYSTEMS 1200Memory OKStarting support workstation
A user cannot sign in. A locked account, a forgotten password, or a sign-in that fails without an obvious reason.
Follow the ticket in three phases
Diagnose ยท choose a step
More paths: knowledge base and escalation
Account lockout or sign-in failure / Intake
Intake
Confirm who is affected, on what device, before assuming a cause.
What I would clarify with the user
Whether it is one account or several, which device and app they are signing into, and whether anything changed recently, a new password, a new device, recent travel.
What I would check
The account status and whether the lockout counter or recent failed attempts line up with what the user describes.
README
The five tickets are representative examples that show
how I work a case. They are not case records. The
documented cases, with real evidence and sources, are
in the casework file.
Drag a window by its title bar, or focus one and use
the arrow keys. On a narrower screen the machine steps
aside and the desk runs on the page directly.
Farhat Systems · Support Workstation
These five tickets are representative example scenarios built to
show how I approach a case. They are not individual case
records. The documented cases, with real evidence and sources, are
in support casework.
A member's phone showed pop-ups and battery drain I
could not explain. I isolated the device, used ADB and
install timestamps to identify the package, and
reverse-engineered the APK to confirm what it was doing.
ADB, APKTool, JADX
VirusTotal and OSINT correlation
Identifiers and sample redacted
A deployment client reported success on a write that never
happened. I reproduced the failure, traced it to a missing
overwrite flag, and added the check that catches it now.
REST, JSON
Regression test added
Runbook with rollback
Single sign-on, a database, and web services running across
macOS and Linux. Most of the work was diagnosing the
failures: container ownership conflicts, a port collision, a
key-length limit.
Docker, Linux, macOS
Authentik SSO, PostgreSQL
Setup and operating docs
→
Full case files, including a synthetic workflow lab, are in
support. Casework
has the details.
Frontline experience
17 months on the help desk.
Oct 2023 to Feb 2025
STEM Office Help Desk, Butte College
First point of contact for the STEM department's 300+
students, faculty, and staff, taking 20 to 30 requests a day
at the walk-up desk, by phone, and over email. I troubleshot
Windows 10 and 11, macOS, hardware, peripherals, software,
Microsoft Office and Outlook, and WLAN connectivity, tracked
every request through TeamDynamix, and handled password
resets and account unlocks through the campus portal. I
explained causes and next steps to people with very different
technical backgrounds, and wrote 10 or more troubleshooting
guides and procedural references for the department.
Cisco Networking Academy IT Essentials and Switching, Routing, and
Wireless Essentials · Linux Professional Certification,
Butte College · A.S. Cybersecurity and Information
Assurance, Butte College
Outside that role, I built a synthetic SSO diagnosis lab,
Assertion Desk, to keep that same discipline sharp against SAML
failures: work through the checks in order, name the specific
one that actually failed, and never mark something resolved on
a guess.
Communication sample
The same problem, two audiences.
Writing sample drawn from the Android device investigation in
Casework,
written mid-investigation rather than after the fact. Not a
customer device. Identifiers and the sample stay redacted.
Customer-facing update
I have the phone off your other networks while I work on it, so
whatever it is doing stays on that one device. The pop-ups and
the battery drain are coming from an app that got installed, not
from the phone itself, and I have narrowed it to a single app by
matching install dates against when you first noticed the
problem. I will confirm what it was actually doing before I
remove anything, and I will tell you plainly whether anything
else needs to come off.
Engineering handoff
Device and scope:
Single Android handset, examined after the fact
Reported symptoms:
Unexpected pop-ups, faster than normal battery drain
Containment:
Device isolated from other networks before analysis
Narrowing method:
ADB package list, install timestamps against symptom onset
Static analysis:
APK decompiled with APKTool and JADX to confirm behavior
Corroboration:
Indicator correlation through VirusTotal and open-source research
Disclosure limit:
Package identifiers and the sample redacted for publication
Technical range
What I actually run.
End-user systems
Windows 10/11, macOS, Linux, hardware and peripherals, Office
and Outlook, software installation and configuration,
virtualization with VMware, VirtualBox, and UTM.
Connectivity
Wi-Fi and WLAN, TCP/IP, DHCP, DNS, and VLAN fundamentals,
switching and routing foundations.
Product and integration support
REST APIs, JSON, SQL and PostgreSQL project work, logs and
response inspection, Python and Bash, Linux and Docker.
Support operations
Intake and prioritization, ticket tracking in TeamDynamix,
escalation evidence, walkthroughs, runbooks, knowledge-base and
procedural writing.
Contact
Support work with clear ownership.
Rochester, Minnesota. Targeting help desk, service desk,
deskside, technical support, application support, product
support, and NOC roles, and open to remote roles across the
United States.