Questions for Maintainers

Hey! @regulartim @mlodic Before finalizing this PR, I have a few questions:

1.Re-running init

Right now ./start init skips existing env files. Should it offer to regenerate them, or keep it safe and skip like it does now?

2.Version Management

Do you want git tag checkout like IntelOwl (./start up --version 2.0.0), or just stick with Docker image versions?

3.Testing the Script

How should I test the bash script itself? Shell testing framework, integration tests, or just manual testing?

4.Docker Auto-Install

Currently it offers to install Docker on Ubuntu/Debian. Should I:

• Add more distros?
• Just check and show instructions?
• Keep it as is?

5.Any Other Features?

• ./start backup - Backup database and volumes
• ./start restore - Restore from backup
• ./start health - Health check all services
• ./start clean - Remove all data and reset

Thank you!

Hey @opbot-xd ! Looks great so far. 👍

Right now ./start init skips existing env files. Should it offer to regenerate them, or keep it safe and skip like it does now?

I think you should ask if they should be regenerated and override them in silent mode. Do you think that's sensible?

Do you want git tag checkout like IntelOwl (./start up --version 2.0.0), or just stick with Docker image versions?

Don't they have to align anyways? If the local files are on version 1.6.0 for example and you start the docker image 3.0.0, that might break things. So I would guess the safest think to do is to rely on both.

How should I test the bash script itself? Shell testing framework, integration tests, or just manual testing?

That's a great question, unfortunately I don't have an answer for that. It would be fine for me to rely on manual testing. If we have some kind of automated testing - great! If that means that we have to maintain a complicated testing framework, then I don't know if that's worth it.

Add more distros?

Yes, the more the better. Packet managers don't change much over time. So if we support a specific distro, after an initial test, it's should not be much work to maintain that support. In the best case we would match the distros supported by T-Pot: Alma, Debian, Fedora Server, OpenSUSE, Rocky, Ubuntu.

Any Other Features?

All the features you listed are nice to have in my opinion. So if you like them and think they provide value to users and/or developers, feel free to implement them! :)

Also, the name of the script ("start") does not really reflect what it does. Can you think of a better name? I have some suggestions but I am open for your ideas: greedybear, gb, manage, ctl

Script Naming:
Initial start → gbctl due to greedybear/ directory conflict. Follows kubectl/systemctl convention.

Quick Start:

./gbctl init --prod && ./gbctl up --prod

Also implemented:

• Environment file regeneration (with backup in interactive mode, auto-override in silent mode)
• Version management with git tag checkout (aligns code + Docker images)
• Multi-distro Docker installation support (Alma, Fedora, Rocky, OpenSUSE - matching T-Pot
• And features like health, backup, restore and clean.

Minimal Installation Support?

Hi @regulartim
You mentioned wanting the script to "not clone the whole repo but only the files that are necessary" for deployment. After reading and learning about Ansible playbook, I think this could really help with your automation goals.

Suggested approach:

Create a lightweight bootstrap.sh that can be downloaded and run standalone:

curl -sSL https://raw.githubusercontent.com/honeynet/GreedyBear/main/bootstrap.sh | bash

This bootstrap script would:

1. Download only essential files via GitHub API or raw URLs:

   • gbctl (main management script)
   • docker/ directory (compose files, configs)
   • configuration/ directory
   • manage.py, pyproject.toml, requirements/
   • Template files (docker/env_file_template, etc.)

2. Then automatically run ./gbctl init --prod --silent

Would this be valuable?
Thanks

@regulartim finally the PR is ready to review.
But I believe the gbctl script is getting huge. Can you please suggest some ways to refactor the code.
Thanks.

Hey @opbot-xd ! I'm really excited to test this, but it might take a while. Will get back to you next week.

Would this be valuable?

Yes, I think it would!

Totally fair points! I agree the script grew larger than initially planned as I added features from the feedback.

Here's what I've verified works:

# Basic flow
./gbctl init --prod           ✓ Creates env files, prompts for regeneration
./gbctl init --prod --silent  ✓ Auto-backups and regenerates without prompts
./gbctl up --dev              ✓ Starts with [local.override.yml](http://_vscodecontentref_/0) (hot reload)
./gbctl health                ✓ Shows service status with visual indicators
./gbctl ps / logs             ✓ Passes through to docker compose

# Version management
./gbctl up --prod --version v1.2.0  ✓ Sets REACT_APP_INTELOWL_VERSION, includes version.override.yml

would test more commands as well.
Also I am concerned about the size of the script as well(900 lines). Any suggestions for that?

could you also provide some screenshots as a reference here?

If the code is well written and organized, imho it doesnt matter the size of the file, this is a standalone script so it is fine

tim@ct-greedybear-test:~/GreedyBear$ ./gbctl create-admin --username tim --password tim --email tim@nothing.net
[INFO] Creating Django superuser...
[INFO] Creating superuser in non-interactive mode...
CommandError: You must use --first_name with --noinput.

Did I use it the wrong way?

Actually it was due to custom user model requirements! I missed that both first_name and last_name are required fields.

1. Refined create-admin: I've updated the command to provide dummy values for both:
   • DJANGO_SUPERUSER_FIRST_NAME="admin"
   • DJANGO_SUPERUSER_LAST_NAME="user"

This satisfies all the REQUIRED_FIELDS for the custom user model (email, first_name, last_name).

I've tested it locally and verified it works!

I played around with the script and overall, it looks very solid. There are a few things that need further attention though:

1. The logs shown are not very informative, except for occasions where the application does not start correctly. The really interesting logs are somewhere else, e.g. `/var/lib/docker/volumes/greedybear_generic_logs/_data/django/greedybear.log`.

2. I find it a little confusing which switch belongs to what command. Is there a better way to do that?

3. The mechanisms of controlling the version of GreedyBear which gets started, looks not very solid to me. As I said, we need to make sure the version of the container that is starting corresponds to the git branch that is checked out.

4. I think setting the version (for example prod or stag) should be done via the `init` command, not via `up`. This to me would be a clearer separation of concerns: `init` prepares the environment and `up` only starts the app.

Thanks for the feedback! I agree these changes will significantly improve the CLI's usability. Here is my plan to address each point:

1. Logs: I'll enhance the logs command.

   • By default, ./gbctl logs will show container stdout (like it does now).
   • I'll add a specific ./gbctl logs app command that execs into the container and tails the actual Django log file (/var/log/greedybear/django/greedybear.log), so you don't have to hunt for the volume on the host.

2. Switch Confusion & 4. Init vs Up: I'll combine these by shifting configuration to the init phase.

   • init will become the single source of truth for configuration. It will save your choices (Prod/Dev, Elastic enabled/disabled, etc.) into a config file (e.g., .gbctl.conf).
   • up will essentially become flag-less (or just overrides). You'll just run ./gbctl up, and it will respect the configuration set during init.
   • This removes the confusion of "do I need --elastic here?" effectively solving point 2 by implementing point 4.

3. Version Control:

   • I'll add a check in up that compares the requested version/tag with the currently checked-out git branch (if running from source).
   • If there's a mismatch (e.g., running latest container while on a feature branch), it will warn the user.

Does this approach sound good to you?

Does this approach sound good to you?

Yeah, sounds good! :) I think after that we can merge and create separate issues if something else comes up.

I have implemented the changes as planned!

1. Configuration Persistence: gbctl init now saves your configuration (prod/dev, elastic, etc.) to .gbctl.conf. Subsequent commands like gbctl up automatically load this config, so you don't need to repeat flags.
2. Logs App: Added gbctl logs app which tails the internal Django logs (/var/log/greedybear/django/greedybear.log) directly from the containe.
3. Version Check: gbctl up now checks if your git branch matches your deployment mode (e.g., warns if you are running Prod on a feature branch), unless you pinned a specific version.

If you think your PR is ready to get a final review, please click the "re-request review" on the top right, next to my profile picture.