A city public-works team finds TCL-only EEM applets too limited for a remediation that needs richer parsing. Which pattern best extends on-box automation?
Select an answer to reveal the explanation.
Short Explanation
EEM is the doorbell; Guest Shell Python is the handyman with a full toolbox. Keep the doorbell on the router, then let Python do the fancy parsing TCL struggles with—still local to the public-works box.
Full Explanation
Public-works teams that find TCL-only EEM applets too limited for remediation needing richer parsing should trigger Guest Shell Python from EEM so event detection stays on-box while Python handles richer logic. That pattern extends on-box automation without abandoning local event correlation. EEM remains the sensor; Python becomes the richer actuator/parser.
Abandoning on-box automation for console-only manual fixes forever ignores the requirement for richer automation. Replacing EEM with unrestricted debug all as remediation is unsafe and not automated repair. Moving the entire routing domain into a single VLAN 1 bridge is an unrelated network redesign.
Exam caveat: passing context from EEM into Guest Shell safely (environment, files, rate limits) matters as much as the Python code itself. Operational check: create an EEM trigger that invokes a Guest Shell script on a lab event, verify parsing and remediation actions, and ensure failures are logged. Publish the pattern in the public-works automation standards so teams do not fork one-off hacks. Record the chosen control and the rejected alternatives in the municipal change record so future on-call staff understand which failure modes were avoided for city services.