Fix chameleon persona implementation — HTML corruption, missing robots.txt, compose profiles

[Divyateja2709]

Hi @adrianwinckles,
Following on from the chameleon persona PRs (PR8-PR11), this PR addresses several issues that were preventing the implementation from working reliably end to end.

The chameleon persona system works by running WordPress and Drupal as separate nginx containers behind the ModSecurity WAF reverse proxy. When Shodan detects the honeypot, shodan_watcher.py calls swap_persona.sh to stop the current persona container and start a different one. The WAF always proxies to persona-app network alias so the swap is transparent.

HTML files had trailing garbage after
Both personas/wordpress/html/index.html and personas/drupal/html/index.html had markdown documentation text accidentally pasted after the closing tag. This produces invalid HTML which could cause unexpected behavior with scanners that parse HTML to identify applications.
2. robots.txt returning 404 for WordPress and Drupal personas

The nginx configs for both WordPress and Drupal personas had location = /robots.txt { try_files $uri =404; } but the actual robots.txt files didn't exist on disk. Real WordPress and Drupal sites always expose a robots.txt — scanners check this as part of fingerprinting. A 404 here immediately weakens the disguise.
3. Persona containers never created so swap always failed

persona-wordpress and persona-drupal had Compose profiles set. This meant on a normal docker compose up these containers were never created. When swap_persona.sh tried to run docker start persona-wordpress it would fail because the container simply didn't exist. Removed the profiles so all persona containers are created on startup. Added a call to swap_persona.sh generic at the start of modsec_entry.sh so only one persona is active at a time from the beginning.

No CI
Added a GitHub Actions workflow that triggers on any PR touching honeytraps/waf_modsec/, builds the Docker image, and runs run_tests.sh automatically.

to check
bash
cd honeytraps/waf_modsec
docker compose up --build

--- Generic persona
curl -i http://localhost:9091/
---Expect: 200, generic content

--- Swap to WordPress
bash ./scripts/swap_persona.sh wordpress
curl -i http://localhost:9091/
--- Expect: X-Generator: WordPress 5.8.1

-- WordPress robots.txt
curl http://localhost:9091/robots.txt
---Expect: WordPress style robots.txt with /wp-admin/ entries

--- Swap to Drupal
bash ./scripts/swap_persona.sh drupal
curl -i http://localhost:9091/
--- Expect: X-Generator: Drupal 7

Run all tests
bash run_tests.sh

Update — CI workflow fix:
The initial GitHub Actions workflow ran the full run_tests.sh which builds the Docker image and spins up containers. This worked locally but timed out in GitHub Actions due to the large base image size (owasp/modsecurity-crs:apache) and multi-container test setup.
Updated the workflow to:

Use docker/setup-buildx-action for better Docker support in CI
Build the WAF image explicitly before running tests
Run only the single-container tests that work reliably in GitHub Actions (test_crs_*.sh, test_shodan_watcher_disabled.sh)
Skip the multi-container swap tests which require docker compose networking — these are verified locally as shown in the verification steps above

The full test suite including persona swap tests still runs correctly locally via bash run_tests.sh.