Skip to content

[Feature] Replace brittle run.sh script with robust Python manage.py CLI #7

@Sumit-ai-dev

Description

@Sumit-ai-dev

Description

Greetings EventHorizon maintainers,

I've been diving into the framework codebase in preparation for GSoC, and I noticed the run.sh script used to manage the protocol tarpits could use a bit of an upgrade to match the robustness of the C server logic.

Right now, the stop and status commands in the bash script are marked as # TODO. Furthermore, bash argument parsing is a bit brittle without explicit type validation (e.g., accidentally missing a port argument).

Since the primary users and researchers of EventHorizon are working in Python, it makes sense for the deployment tooling to be Python-native too!

Proposed Fix: Introduce manage.py

I've already developed and tested a robust Python replacement script (manage.py) that cleanly supersedes run.sh:

  1. Replaced Bash with Python argparse: Swapped fragile bash regex parsing with strict, type-safe Python arguments (e.g., forcing ports to be integers).
    1. Implemented # TODO: stopServer: Leveraging psutil, the stop command now gracefully targets and sends SIGTERM exclusively to running EventHorizon binaries without disrupting the host OS.
    1. Implemented # TODO: status: Built a clean, dynamic status table identifying active protocols, their strict PIDs, and running uptimes in seconds.
    1. Optimized Execution: Uses os.execv to perform a clean OS-level process handoff to the target C binaries, leaving zero Python overhead running around the trapped connections.
      Bonus: This seamlessly drops into the current docker-compose.yml and docker/tarpits/Dockerfile workflow merely by adding python3.

Testing & Verification

I have full pytest coverage built out with unittest.mock proving it correctly routes to the binaries inside Docker scenarios securely.

# Example usage:
python3 manage.py start telnet 23 100 4096
python3 manage.py status
python3 manage.py stop telnet

I would love to hear your thoughts on this approach! I am more than happy to discuss any architectural feedback or changes you'd like to see. If this looks like a valuable addition to the framework, I would be thrilled to have this issue assigned to me so I can finalize the PR.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions